Too much latency between multiple motor moves

[dre99gsx]

I have measured the time between motor moves, and noticed a latency of 10 - 20 ms. If the subsequent motor move does NOT need to change velocity, acceleration, deceleration, etc (in other words, after move 1, a call is made directly for move 2 with the same values), there is a latency of 10^-10 (using the time stamp features). As soon as I add a block between two motor moves which changes the 2nd motor move's accel, decel, vel, etc, It adds 10-20ms in between.

Is there a way to avoid this long time spent between these moves?

[Jochen]

I assume you are talking about a NI 73xx motion controller. I also assume you are programming in LabVIEW.
Whenever you run a sequence of moves configuring and starting a new move after the previous one is finished you will always see a non-deterministic delay between the moves. Fortunately the 73xx boards provide a feature called blending that solves this problem. When doing blended moves you can preload the new move constraints for a subsequent move while a move is running.

Please refer to the blending examples that are installed in your \LabVIEW\examples\motion\FlexMotion directory. In the One Axis.llb there is an example called Sequence of Blended One-Axis Moves.vi. In this example you can set the Blend Factor. Default is -1 which means ideal blending. In this case the acceleration phase of the next move is started as soon as the previous move starts decelerating. If you enter 0 as the Blend Factor the next move will start immediately after the previous move is completed. Positive values result in deterministic delays between the moves (e. g. Blend factor = 10 means 10 ms delay between the moves).

Especially when doing multi-axis moves blending is an interesting feature if you need to avoid the axes to stop at corners (important e. g. for laser writing or dispersion processes)

Best regards,

Jochen Klier
National Instruments Germany

[dre99gsx]

Excellent, I will give that a try.

[dre99gsx]

I took a look at the blended one-axis moves.vi. I began to play with timestamping, and noticed the following:

(Within the while loop, a position was loaded, and then the move was initiated) - Using Labview and MD7604/PXI7344 and running as RealTime)

Time between entering "Load Target Position.flx" and exiting was allways 1ms.
Time between entering "Start Motion.flx" and exiting was allways near 1ms.
No delay or waits were used in the while loop, and entire vi was run as high priority.

These times were calculated using a time stamp function before entereing the .flx, and after exiting (using a sequenced frame to assure stamps were taken in the correct order).

The issue I have is I must load completely different accel, decel, vel and target positions before each move (on the same axis). Since I must call "Load RPM", "Load Accel", "Load Decel", and "Load Target Position", this will introduce 4-5 ms before I actually initiate the "Start Move". If I run this in a while loop, I begin to see some delays. I may be able to load all the step values ahead of time for the NEXT move, and only initiate "Start Motion.flx" when the previous move was finished. That may be the answer?

Please advise, and thank you for the help thus far!

[Jochen]

The example that I mentioned in my first answer should do almost exactly what you request.
- In the first iteration of the loop the first move is started with the Start Motion.
- The inner while loop iterates only once in this case as the blend complete flag is set immediately after Start Move.
- In this state the first move is still running and the target position is loaded for the next move. If you want you can also move load velocity and load acceleration into the while loop to update these values for your move.
- In the next step Blend Motion is called (the first move is still running)
- The inner while loop checks if the first move is finished. The subsequent move is started (blended) automatically then without a delay.
- The vi exits the inner loop and loads the new parameters for the next move while the second move is running and so on.

Of course it takes some time to download the parameters but as long as your moves take longer than the time needed for the execution of these functions (load velocity, acceleration and target position) you won't get any delay between the moves. If the duration of the moves is actually shorter than this time (you mentioned 4-5 ms) then you should use contouring instead of blending (see examples).

You can find more information about blending, contouring and other motion control concepts here.


Jochen

[dre99gsx]

Thank you Jochen, I will do more research and play with this. I beleive you are correct in a enacting the blend motions (or contouring).

Out of curiousity, could my timestamps themselves not be accurate indications of when the motor moves start or stop? I placed each time stamp as close as possible to the start of a move, or at the moment a "move complete" has been generated.

Actually, what is the best way to log down (to memory of to file) the actual start time and end time of each move?

Message Edited by dre99gsx on 03-11-2005 10:18 AM

[Jochen]

Timestamping doesn't work very well this way with motion boards. The reason is the asynchronous nature of the execution of the calls to the motion board. The motion board has it's own CPU. Whenever you send commands to the motion board the CPU puts the commands onto a stack and executes them sequentially. Thus when you measure the execution timing of the NI-Motion calls in LabVIEW you don't measure the timing of the moves.

Jochen

[dre99gsx]

Aah, that would explain a few things as well. What do you recommend is the best way to timestamp the exact time a motor starts to move, and stops moving, eventually logging these times to a text file? Are there any .flx or .vi's included with NI-Motion that generate this data?

Message Edited by dre99gsx on 03-11-2005 10:20 AM

[Jochen]

Again, if you use blending you can define the timing of your moves with the accuracy of 1 ms. There are no functions available that return the inner timing of the board.
Why do you need the timing values? Do you want to synchronize something to the start and the stop of the move? In this case the breakpoint feature or high speed capturing could help you (see examples).
Please provide some details about your application so I may come up with some other ideas.

Jochen

[dre99gsx]

The start and stop timing values are needed to create a log file, which will be used to implement a timing diagram to precisely determine when the motor needs to be activated before other motors are activate, etc...

I have played with using the a 0-value of blend, and noticed the blend status blips on when the 1st move ends and the second move begins (I assume this would point to an exact point in time that motor a stoped, and motor B began). I can use that as a timing point to an extent. By using the timestamp method at the start and end of a motor move (using the move-complete status function coupled to a timestamp), I get inconsistent timing values of 10ms to 20ms apart from move to move, but as you stated, this is due to overhead in obtaining the time itself.

Essentially, I need a method of precisely logging the start and stop times of these motors for documentation and research related to the timing of adjacent motors for worst/best case scenarios... thanks!