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:
EAL SDK 2.0
MPB20V28 Firmware
Thank you in advance,
Nate
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)
