A sequence moves forward one step at a time, and something has to decide when it is allowed to take each step. In a sequential chart, that decider is the transition condition: a boolean expression that sits between one step and the next and must become true before the sequence advances. The active step simply holds and keeps doing its work until its transition condition clears, at which point control passes to the following step. Understanding transition conditions, and choosing them well, is the difference between a sequence that advances when the process is genuinely ready and one that lurches ahead on a blind timer.
Step transition condition in one line: A step transition condition is the boolean expression placed between two steps in a sequence that must become true for control to advance from the currently active step to the next one. The active step stays active and continues its actions until its transition condition is satisfied, then the sequence moves on. A transition can be tied to an event, such as a level or position being reached, or to time, such as a fixed delay, and the choice between the two strongly affects how well the sequence tracks reality.
In a step-based sequence, exactly one step in a given path is active at a time, and that active step carries out its assigned actions for as long as it holds. Directly after the step, before the next step, sits the transition and its condition. The rule that drives the whole sequence is simple: when a step is active and its following transition condition becomes true, the sequence deactivates that step and activates the next one. Both parts are required together, the step must currently be active and the condition must be true, which is why the transition can only ever fire for the step that is actually running.
The consequence of this rule is that a step holds until its transition clears. If the condition never becomes true, the sequence simply waits at that step indefinitely, continuing whatever actions the step commands. This is a feature, not a bug: it means the sequence naturally pauses until the process is ready to move on, rather than charging ahead on schedule regardless of whether the previous step actually finished. A fill step, for instance, keeps filling and keeps the sequence parked exactly until its transition says the target is reached.
Because only the active step's transition is evaluated for advancing, the sequence has a clear, single-threaded flow along each path: it is always waiting on precisely one condition, the transition after the current step. This makes a sequence far easier to follow and troubleshoot than a pile of independent rungs, because at any moment you can point to the one step that is active and the one condition it is waiting for. If a sequence is stuck, the question is never vague; it is always which transition condition after the active step has failed to become true.
Transition conditions come in two broad flavors, and the difference matters a great deal. A timed transition advances the sequence after a fixed delay from when the step became active, so the condition is essentially the timer has elapsed. Timed transitions are simple and predictable, and they are the right choice when a step genuinely just needs to wait a defined interval, such as a settling time or a minimum dwell. Their weakness is that they assume the step's work is done when the clock runs out, whether or not it actually is.
An event transition, by contrast, advances when a real condition about the process becomes true, such as a level reaching a setpoint, a valve confirming it is fully open, a pressure crossing a threshold, or a weight being reached. Event transitions track the actual state of the plant rather than the clock, so the sequence advances precisely when the process is ready and not a moment before. This is usually the more robust choice, because it self-corrects for variation: if a step takes longer than expected this time, an event transition simply waits, whereas a timer would have moved on regardless.
The pitfall is using a timer where an event is what you really mean. If a fill step is advanced by a fixed timer chosen to be long enough usually, then any batch that fills slower than usual will move on before it is truly full, and any batch that fills faster wastes time waiting. Tying the transition to the genuine condition, the level reached, makes the sequence correct for every batch regardless of flow rate. Timers still have their place, often as a backstop that faults the sequence if an event transition takes unreasonably long, but as the primary condition an event usually beats a clock.
Consider a batch fill step whose job is to add liquid to a vessel up to a target level. The natural transition condition is an event: level at or above setpoint. While the vessel fills, the fill step stays active, holding the fill valve open, and the sequence parks there. The instant the level transmitter reads at or above the target, the transition condition becomes true, the fill step deactivates, and the sequence advances to whatever comes next, perhaps a mix or a hold step. The sequence advanced exactly when the vessel was genuinely full, not on a guess about how long filling should take.
Compare that with the tempting but weaker approach of advancing the fill step after a fixed number of seconds. That timer works only as long as flow, viscosity, supply pressure, and starting level all stay the same, and it silently under-fills or over-runs the moment any of them varies. The level-reached transition is immune to all of that, because it is watching the thing that actually matters. A common robust design keeps the level-reached event as the real transition and adds a separate long timer purely as a fault check, so a fill that never reaches level raises an alarm rather than hanging forever.
This event-driven behavior is exactly what makes a sequence trustworthy to run and watch remotely. When a batch sequence is monitored over SCADA, the dashboard can show which step is active and, just as usefully, which transition condition it is waiting on, so a remote operator sees not only that the fill step is running but that it is waiting for level at setpoint. If a step overstays, the operator immediately knows which condition has not cleared, turning a remote it is not progressing into a specific it is stuck waiting for level. Because the transitions are tied to real process conditions, the remote view reflects the true state of the plant rather than the state of a clock.
Two things at once: the current step must be active, and the transition condition immediately following that step must become true. Only then does the sequence deactivate the current step and activate the next one. Because both parts are required, the transition can only ever fire for the step that is actually running, which keeps the sequence to a clear single-threaded flow along each path.
The sequence simply holds at the active step and keeps performing that step's actions, waiting indefinitely for the condition to clear. This is intentional, because it means the sequence pauses until the process is genuinely ready to move on rather than charging ahead on schedule. In robust designs a separate fault timer catches a transition that takes unreasonably long and raises an alarm instead of hanging forever.
Prefer a process event, such as a level or position being reached, whenever the step's completion is defined by a real condition, because an event transition advances precisely when the process is ready and self-corrects for variation. Use a timer only when the step genuinely just needs to wait a fixed interval, such as a settling time. A common robust pattern uses the event as the real transition and a long timer as a backstop fault check.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.