Queues and blended moves

The second command arrives too late

A carriage must pass an inspection point and continue to unload. The first segment is already braking when the application finally issues the second move. The planner may no longer be able to form the requested transition. A blending setting cannot recover lookahead that the application never supplied.

BufferMode describes how a new operation relates to an outstanding one. Aborting replaces the current command. Buffered waits for its predecessor's defined completion. Blending modes specify a transition relationship, subject to the block, dynamics and runtime restrictions.

Busy is not ownership

When move B is accepted behind move A, B can be Busy while A remains Active. B must continue to be called and its acceptance/error state must remain visible to the sequencer. When A reaches the transition condition, B takes ownership.

A queue is a runtime resource with a finite policy. Do not assume unlimited depth or infer acceptance from a rising edge alone. If the queue is full or a combination is unsupported, handle the error and preserve enough command identity to explain what was refused.

The nominal velocity choice still has to be feasible. Same-direction moves at 100 and 300 mm/s suggest a 100 mm/s transition for Low or Previous and 300 mm/s for Next or High, but acceleration distance, direction reversal and vendor restrictions can prevent those values.

Buffered is not necessarily a zero-speed wait

For ordinary point-to-point positioning, Buffered waits for the preceding positioning completion. A continuous command has a different terminal condition. CODESYS documents cases where a buffered operation follows a continuous movement at its relevant attained-velocity condition. Read the exact block pairing before generalizing from two position moves.

A direction reversal generally needs braking. A command to go right and immediately return left cannot traverse the join at a nonzero rightward velocity while instantly acquiring a leftward velocity. The planner must respect dynamics even if a mode name suggests a high transition speed.

Plan the application queue

Represent every segment with an identifier, target, dynamics and requested relationship. Track submitted, accepted, active and terminal states. If an operator changes the recipe, decide whether the change applies to queued segments, future segments or the whole cycle after a controlled stop. Rewriting tags behind accepted requests is not a queue-management policy.

Keep manual motion and recovery out of the automatic queue unless the arbiter deliberately admits them. An Aborting manual request may be permitted, but the interrupted automatic sequence must be told that its operation did not complete.

Profile bench exercise

The profile bench shows isolated segment dynamics; it does not execute BufferMode or queues. Use it to calculate whether a segment has enough distance to reach its nominal transition speed. For 100 mm/s and acceleration of 200 mm/s², acceleration alone needs 25 mm. A 10 mm segment cannot contain the same full-speed transition from standstill.

Draw two velocity traces: one with a stop between segments, one with a feasible continuous join. Mark the scan when B must already be accepted. On a vendor simulator, run both modes and record Busy, Active, Done and CommandAborted for both instances.

Common mistakes

Issuing B only after A.Done prevents the planner from knowing B while it plans A's approach. Treating B.Busy as proof that A completed confuses outstanding work with current ownership. Assuming every motion block supports all BufferMode values can produce a refused command even though the enum compiles.

TryPLC's ST runtime currently supports Aborting only. The course does not silently add buffering to the engine; the timing and queue exercises above must be verified on the target vendor runtime.

References

CODESYS multiple-movement overview documents BufferMode and continuous-operation transitions. PLCopen provides the common motion definitions.