One request, several scans
A move request lasts one PLC scan. The move itself lasts two seconds. The function-block instance remembers the accepted operation across later calls, which is why it must remain in the cyclic program after the request pulse disappears.
An Execute-type block normally accepts an operation on a rising edge and latches its parameters according to the installed library's rules. Holding Execute TRUE does not mean repeatedly issuing the same move. Dropping Execute does not cancel an accepted ordinary move. To issue another operation with the same instance, complete the documented lifecycle and provide another rising edge.
Read the outputs as an operation record
Busy means an operation is outstanding. Active, when the block exposes it, means that command currently controls the axis. A buffered command can be Busy while it waits and not yet Active. Neither value is a direct measurement of shaft motion.
Done means the block reached its defined completion condition. For a positioning command, inspect the vendor's target-window and completion settings. For other block families, Done may mean a parameter operation or coordinate assignment completed. It does not universally mean a load is stationary or safe to enter.
CommandAborted means another operation interrupted the command. Error means the block reports a refusal or failure; ErrorID identifies it. A sequencer that watches only Done can wait forever after either outcome.
| Event | Application response |
|---|---|
| Command accepted | Keep calling the instance and track operation ownership |
| Busy and not Active | Keep the queued request accounted for |
| Done | Advance only after the machine's other completion conditions pass |
| CommandAborted | Enter the defined interruption or replacement path |
| Error | Record ErrorID and diagnose before retrying |
Not every block has this entire output set. MC_Power is Enable-driven; MC_MoveVelocity commonly reports InVelocity rather than a positioning-style Done. MC_Stop has special locking behavior. Copying one generic pin diagram onto every block hides these differences.
Trace an indexing move
Assume the axis starts enabled and stationary. At scan 10, Execute changes from FALSE to TRUE with a target of 200 mm. The block accepts that target. Scans 11 onward continue calling the same instance. The planner changes demand while feedback advances. At completion, the terminal status is reported according to the library's output-reset rules.
In Beckhoff's documented general rules, terminal status stays asserted while Execute remains high. If Execute was already low during execution, the terminal output is visible for one cycle. Capture it in the sequencer when it occurs. Read your library's rules rather than assuming the HMI will always see a short pulse.
TryPLC's bench models a simpler output lifecycle and does not reproduce every vendor pulse-retention rule. Its purpose here is to make acceptance, ownership and target latching visible.
A target that changes on screen
Start the bench move to 200 mm. While it is Busy, move the target slider to 300 mm. The accepted move still uses 200 mm. The slider now represents the next request's input, not a live rewrite of the accepted target. Lower Execute, let the operation finish, advance a scan, then raise Execute to accept 300 mm.
If your application allows on-the-fly updates, use a documented block and update mechanism. Do not infer that changing an input tag must change a motion operation already in progress.
Keep each request identifiable
Use a command identifier in your machine sequence. Record the instance, accepted target, command time and outcome. This prevents an HMI request for station B from being mistaken for completion of an earlier station A move. Two independent routines writing Execute to the same instance can produce an edge sequence that neither routine intended.
A one-axis arbiter can own the instances and accept requests from manual control, automatic sequence and recovery. Each request either becomes accepted, is refused with a reason or waits under a bounded policy. It should not disappear silently.
Exercises
Describe the trace when Move A is replaced by Move B in Aborting mode. A should report interruption rather than successful arrival; B takes ownership if accepted. Then describe a buffered B: it can be Busy before it becomes Active. The single-axis runtime supports Aborting only. The bench exposes one move instance; use Halt or Stop to observe interruption by another operation.
References
Beckhoff general rules document parameter latching, output reset and the MC_Stop exception. PLCopen provides the common contract.