How Do I Count GRAFCET Cycles in Siemens TIA Portal?

The sequence runs, but the cycle total does not increment correctly, increments every scan, or returns to zero unexpectedly. Follow the request from the cycle-complete event through the sequence logic, the counter input, the CTU instance, and the CYCLE value. The decisive design choice is the event definition: increment once when a full GRAFCET cycle completes, not while a step remains active.

Where does the cycle-count request travel?

A cycle counter has a short data path. A field condition or internal sequence transition confirms completion. The program converts that condition into a single rising event. The event reaches the count-up input of CTU. The counter updates its current value, which the application reads as CYCLE.

Call the counter from logic that executes during normal PLC scans. Do not conditionally skip its call for long periods while expecting it to retain an accurate view of the input transition. The GRAFCET decides when a cycle is complete; the counter records that event.

Does the completion condition change cleanly?

Layer one comes first when completion depends on a sensor or other field input. Monitor the raw input before inspecting CTU. It must reach both logical states and remain stable enough for the PLC input processing and cyclic program to observe the intended transition.

If the raw input never changes, troubleshoot power, wiring, input status, and the device condition. If it changes several times during one mechanical event, the counter can receive several completion requests unless the sequence logic qualifies the signal. If it changes correctly but the GRAFCET transition does not, compare the raw input with every condition in that transition.

Are you counting scans, steps, or completed cycles?

Define the count event before placing the block. A PLC scan is one execution of cyclic logic. A GRAFCET step may remain active for many scans. A completed cycle is the transition from the end of the sequence back to its designated initial state. These are different events.

Incrementing while the final step is active counts executions, not cycles. For example, logic equivalent to CYCLE := CYCLE + 1 under a level condition adds one on every scan that the condition remains true. A CTU instead counts a false-to-true transition at its count-up input. That behavior fits cycle counting when the input becomes true once per completed sequence.

Does CTU receive one rising edge per cycle?

Monitor the final transition, the signal connected to the count-up input, and CYCLE together. Run one controlled cycle. The transition must go from false to true once, and CYCLE must increase once. Before the next cycle, the count input must return false; otherwise the next completion cannot create another rising edge.

If the input toggles once but the value does not change, verify that the same CTU instance is called and monitored. A counter requires persistent instance state to remember the previous input state and its accumulated value. Reusing or reinitializing that state can make the result appear frozen or erratic.

If the value changes more than once, search for parallel completion paths, repeated sequence re-entry, and multiple calls that operate on the same counter state. If the monitored value changes correctly but an HMI value does not, the PLC counter is working; trace the HMI tag connection, update path, and displayed variable separately.

Where should counter initialization and reset occur?

Initialization is a control decision, not a permanent action attached to the initial step. Driving the reset input continuously while the initial step is active can hold the counter at zero whenever the sequence waits there. Reset from a deliberate event such as an operator reset command or a defined initialization pulse.

Choose startup behavior explicitly. If the count must start at zero after initialization, pulse the counter reset during that initialization. If the total must survive a restart, place the counter state in storage configured for the required persistence and do not connect routine startup logic to its reset. The installation requirement decides between those branches.

How do you implement and verify the resolving branch?

1. Identify the transition that means the entire GRAFCET cycle has finished. Do not select a condition that merely means the final step is active.
2. Confirm that the transition becomes true once during one controlled cycle and returns false before the next cycle.
3. Create a completion event from that false-to-true transition. If the transition logic already produces one clean edge per cycle, use it directly; otherwise add edge-detection logic.
4. Call one CTU instance from the normal cyclic program path. Connect the completion event to its count-up input.
5. Expose the counter's current value as CYCLE. Use a data type and counter range appropriate for the required operating total; read the permitted range from the selected instruction and project configuration.
6. Connect reset to a deliberate initialization or operator-reset event. Do not hold reset active throughout the initial GRAFCET step.
7. Download the change and monitor the completion event, reset condition, and CYCLE simultaneously.
8. Start with a known value, execute several complete cycles, and confirm that CYCLE advances by one after each completion and does not change while any step is merely waiting.

CycleCompleteEvent ----> CTU count-up input
ResetEvent ------------> CTU reset input
CTU current value -----> CYCLE

FAQ