Diagnostics and recovery sequences

Two routines own the same carriage

Automatic transfer requests 250 mm. A manual routine requests 20 mm in the same scan. Both use permitted move instances on the same axis. Whichever operation takes ownership under the call order and command mode can interrupt the other, leaving the automatic sequence waiting for a Done that will never arrive.

Give each axis or group one command arbiter. Manual controls, the automatic sequencer and recovery routines submit requests to that owner. The arbiter decides which request is accepted and reports its outcome. This makes priority and interruption policy visible instead of letting program order decide them accidentally.

Keep an operation record

Record command ID, instance, accepted parameters, axis state, feedback, time and outcome. On failure, preserve ErrorID and relevant drive/axis diagnostics before issuing reset. A log that contains only the latest message loses the events immediately before a trip.

Timeout should lead to a defined control response and diagnostic capture. It should not blindly advance the sequence or assume the axis stopped. Stopping action and safety reaction belong to their respective designed systems.

Restart from evidence

After an interrupted transfer, inspect actual position, coordinate validity, gripper/clamp condition and product identity/location. A retained sequence number cannot establish those facts. The carriage may have coasted, a brake may have held it or the product may have been removed while power was off.

Choose a recovery strategy per machine state. Some states permit continuing to a known station after checks. Others require returning under manual control, rehoming or rejecting a partly processed product. Define permission separately from fault reset, and require a separate restart action where the machine design calls for one.

A persistent MoveRequest can become a new edge after readiness changes. Clear or deliberately revalidate pending requests during recovery. Do not let an old HMI command survive a fault without an explicit policy.

Task timing and diagnostics

Call motion instances in the required cyclic task. Record task period and the relation to the motion/fieldbus cycle. Jitter, late updates and stale data can affect both behavior and traces. A 20 ms teaching scan is not a production recommendation for every servo application.

TryPLC advances the bench by one deterministic 20 ms scan when stepped. Run scans schedules those same virtual increments; browser scheduling can make wall-clock playback slower, so the displayed virtual time is scan count multiplied by 0.02 s. It is not a measurement of fieldbus jitter.

Bench investigation

Create three outcomes. First, enable the drive and finish a move. Second, interrupt a move with Halt or Stop. Third, request a move while disabled. Record the distinct terminal statuses and axis state. Explain which machine step should run after each outcome; only the successful path may use the original move's completion condition.

Try issuing a new target without a new Execute edge after an error. Then release Execute for a scan and retry. A retry needs a new request lifecycle as well as corrected conditions.

Acceptance tests

A transfer sequence should be tested with normal arrival, replacement command, rejected parameter, held Stop, lost power and invalid reference. Add a case where the axis reaches its target but the product sensor never confirms transfer. This catches the common mistake of treating motion completion as process completion.

Keep failed test state visible for investigation. Repeated reset-on-failure loops conceal whether a result came from the original request or a later retry.

References

Beckhoff general motion rules describe command outcomes. PLCopen motion-control specifications include user guidance; apply the installed vendor's task and diagnostic requirements.