Showing results for 
Search instead for 
Did you mean: 

EAL Motion Delay Times

New Poster

EAL Motion Delay Times

During our testing with the Easy Automation Library (EAL), we see an added communciation delay time while waiting for a move around 150ms. This added delay is in addition to the motion profile, and since the Movement.Wait command is tied to the drive's internal motion interpolator (S437 bit 0), it should not have anything to do with settling time on the axis.

Is there a way to improve this?

Regular read/write request for non motion commands take less than 5ms.

I should mention our tests were running with a straight connection from our PC to the drive, no ethernet switch, and the application is very minimum:




MPB20V28 Firmware

Thank you in advance,



Tags (4)

Re: EAL Motion Delay Times

I performed some additional tests with the EAL library. As a correction of the reporting of Nate, I do use a GB switch between the PC and the drive. And I use the .NET library (just like our customer).

I adapted the code for an absolute move to also measure the duration of the motion command:


And I made a Move absolute that polls S-0-0342 (Is the same as S-0-0437 bit 0, but this one does not require any bit-masking to check a single bit).


The this.TargetPositionAttained is a property of my axis class, it actually reads parameter S-0-0342 and returns a true value when this parameter is equal to 1.

The results are:

  • Movements without jerk will result into the MoveAbsolute duration of around 57ms
  • When I poll the target position attained parameter, the time I am polling is very close to the actual motion time (around 1ms higher
    > It seems that the MoveAbsolute method returns when the axis motion has started
    > The total overhead on a move is mainly the duration of the MoveAbsolute (98%) -> The preparation of the move…
  • When I use the Movement.Wait mechanism to synchronize, the Wait duration is around 25ms longer as the actual motion time
    > The total overhead is now increased

  • Movements with jerk will result into a MoveAbsolute duration of around 60ms
  • When I poll the target position attained parameter, the time I am polling is now around 28ms longer as the motion time
    > When I look into the scope data, I can see the axis profile going into a constant velocity of zero for 28ms before accelerating
    > The MoveAbsolute method still returns when the axis motion has started (with velocity zero though)
    > Again, the polling does not add much overhead (1ms)
  • When I use the Movement.Wait mechanism to synchronize, the Wait duration is around 50ms longer as when polling
    > The overhead is now increased to around 140ms


So if there is a way in reducing the overhead, it has to come from:

  • Optimizing the MoveAbsolute -> average time is around 60 ms
  • Optimizing the Movement.Wait -> average time depends on type of move, but at least 25ms (Polling can reduce this to 1ms!)
  • Optimizing the jerk profile generation
    -> This may be move profile dependent
    -> 28 ms for the short move I used for testing (dx=2mm, v=100mm/s, a=1000mm/s^2, j=10000mm/s^3)



Tags (3)
Long-established Member

Re: EAL Motion Delay Times

I guess there is no possibility to improve this behavior because a move absolute is not only a single write parameter command. Its more a sequence with lots of parameters which needs to be written.

Also keep in mind EAL is using a non real time communication, so your measured time can be correct for today but tomorrow when there is i.e. more traffic on your network the time can change.
So if you need a real time communication we recommend to use a fielbus like EtherCAT or Sercos.

Best regards,