Why is better this:

(appart from the download during run ...?

 Chris,

thanks for that explanation, again another piece of good automation from you.

You mean using the restart task command at the end of the task ?

Because we use the while true loop with a Time wait (at the end) of 0 ms, in order to force the execution of the next task.

Is that perfectly equivalent to your solution or you suggest to remove the loop and the wait and just use (at the very end of the task) a restarttask ?

ChristophD

Hello,

because all motion tasks running in the same task level in the operation system with other tasks.
If all motiontaks are cyclic it can be a performance problem for other taks that the taskscheduler can not start other tasks because the motiontaks never ending .

if you use the _restarttask you can guarantee that the task scheduler can start some other needed tasks.

Regards

Christoph

The quoted text of the OP says the following:

If you use an endless loop (like a DO.. WHILE TRUE loop) in a motion task, or a tight loop for example waiting for an input, be sure to insert a _waitTime(T#0s); in the body of the loop. This can be T#0s, or it can be larger.

When a motion task encounters any kind of wait, the task scheduler can move onto a different task. Otherwise it would be stuck wasting two whole time slices, looping millions of times.

However, if you choose to do the above even if correctly using wait statements, if ANY motion task is in RUNNING, or RUNNING WAITING state... then you cannot use the Download in Run feature.

To be able to Download in PLC RUN mode (as opposed to having to STOP), the suggested solution is to use task related commands in the BACKGROUND task, to watch the states of these motion tasks and control them.

For example, polling the state of the motion task(s) each loop in the background task. Watching for when the motion task completes (task state STOPPED), and restarting that motion task if that's what you want as a programmer. Or creating a condition on your machine where there is an "idle condition" so that none of the motion tasks are running, even going so far as to forcibly stop them all, if you want to do a download still in RUN mode.

If you do not want to download in RUN mode, ignore the part about managing the motion task(s) in the background cyclic task. But still be sure that your loops in the motion tasks have some kind of wait: _waitTime or wait for condition or "wait for motion done" command attributes.