PLC execution order: tracing logic across task layers

Separate the execution layers

“Function block” can describe a stateful software component, a call to that component, or a graphical symbol. It does not identify how the controller schedules the surrounding program.

A program organization unit, or POU, is a broader term that includes programs, function blocks and functions. These do not all become independent entries in a task schedule. A task may run a configured sequence of programs, while those programs call functions and function block instances internally.

Follow these layers from the task down to the statement that matters. Moving a block inside one program does not necessarily change when that program runs relative to another.

Read the task configuration before the drawing

If a dependency crosses separate programs, start with their task assignments. Two programs shown next to each other in a project tree may belong to different tasks. The tree may also be organized for navigation rather than execution.

Where the runtime provides an ordered program call list, use that list to establish the sequence within the task. Confirm its meaning in the manufacturer's documentation rather than assuming that every displayed list is an execution schedule.

Record these details for both producer and consumer:

• The task that calls the program.
• Whether the task is periodic, event-triggered or another supported type.
• The configured program call sequence.
• The task priority and whether another task can interrupt it.
• Any condition that prevents the relevant call from executing.

A producer earlier in one task does not establish its order relative to a consumer in another task. A higher-priority task may interrupt a lower-priority task, depending on the runtime. Separate tasks can also run at different intervals.

For cross-task data, use the controller's documented data-sharing or synchronization method when consistency matters. Reordering program names is not a substitute for defining how a complete set of values passes between tasks.

Trace Structured Text through its control flow

Structured Text normally executes statements in sequence along the active control-flow path. Assignments and calls on that path therefore matter in their written order. Conditions, loops and returns determine which statements are reached and how often they execute.

Consider a simple dependency: one statement calculates Ready, and a later statement copies Ready into Permit. Assuming ordinary shared-variable access in the same task, no intervening writer and no interrupting writer, the later statement reads the newly assigned value.

Reverse those statements and Permit reads whatever value Ready held at that point. That may be a value from an earlier execution, but it could also have been written elsewhere. Trace the writers before calling it a one-cycle delay.

Do not extend statement ordering into a universal rule that expressions execute from left to right. Operator precedence and parentheses determine how an expression is grouped. Evaluation order, including whether parts of a Boolean expression are skipped, must be checked against the language implementation.

If a calculation depends on a function call changing shared state before another call reads it, split the operations into explicit statements and document the dependency. This makes the intended order easier to review and avoids relying on an unsupported expression-evaluation assumption.

Function block instances need the same care. Check where each instance is called and whether the call is conditional. Calling an instance twice can update its internal state twice. Skipping a call does not mean its outputs have been recalculated for the current pass.

Read SFC as active steps and transitions

A Sequential Function Chart describes sequence state through steps, transitions and associated actions. It is not a generic grid of blocks that can always be read left to right and then top to bottom.

Begin with the active steps. Then identify their actions, action qualifiers and the conditions that permit transitions. Qualifiers can affect when an action starts, remains active or stops. Parallel branches introduce additional ordering questions that graphical position alone may not answer.

For a particular value, establish:

• Which active action writes it.
• Whether that action executes on the current pass.
• Whether another action can write the same value.
• When transition conditions are evaluated relative to action execution.
• What the runtime documents about action ordering and branch processing.

An action may itself contain Structured Text or another supported language. That creates another execution layer inside the chart. Establishing which SFC action runs does not, by itself, explain the sequence of statements within that action.

If correctness depends on one parallel action executing before another, make the dependency explicit using an appropriate sequence or documented coordination method. Do not rely on their apparent position on the page.

Follow one value from producer to consumer

A useful trace follows one variable rather than the entire application. Suppose a calculation produces BatchReady, and a reporting program copies it into StatusReady.

Under a simple same-task model, with direct variable access and no other writer, the difference is:

A previous-pass value is not automatically a fault. Some applications deliberately use a stable snapshot. The fault is an undocumented mismatch between the value's timing and the consumer's requirement.

For each dependency, note the producer, consumer, intervening writes and expected age of the data. If several values must represent the same machine state, define how they become one consistent snapshot. Reading each variable successfully does not prove that the group belongs to the same update.

Also separate program-variable timing from physical I/O timing. Input acquisition, process-image updates, output transfer and communications can occur at different points depending on the controller. A later program statement does not necessarily mean a physical output has already changed.

Check the sequence without changing machine behavior blindly

Use the manufacturer's supported monitoring, trace or simulation tools to compare the expected sequence with execution. A watch window alone can miss intermediate changes because its refresh rate is separate from the task's execution rate.

Useful evidence includes task timing, existing sequence counters, chart state and a trace of the producer and consumer variables. Adding diagnostic variables or counters is itself a program change and belongs under the site's change-control procedure.

Review a proposed ordering change for effects beyond the variable being investigated. Moving a call may alter timer behavior, instance state, I/O handling or the data seen by other programs. Follow the approved safe commissioning procedure before applying changes to running equipment. Preserve safety functions and do not change their execution to make a trace easier to read.

Keep display timing separate from control timing

A factory status page can show a previous value even when the PLC's internal dependency is correct. The reporting task, communications update and display refresh each add another stage. Diagnose those separately rather than rearranging machine logic to compensate for a slow screen.

For that downstream problem, the guide to factory screen update delay explains the distinction between data collection and what becomes visible.

The boundary also matters when deciding what the screen is for. A factory status display or operator HMI serves different requirements. An informational display should not be treated as proof that a control sequence or safety condition has completed.

The practical result of tracing PLC execution order is a documented dependency: which task runs the producer, which path reaches the consumer, and whether the consumer receives a current result or an intentional earlier snapshot. Establish that before changing the sequence.

Questions