Programmable logic controllers (PLCs) are inherently driven by state machines and step-wise, sequential instructions. In industrial automation, representing these flows clearly and deterministically is essential for predictable behavior and maintainable systems.

cinnamon intentionally embraces a text-only programming model based on IEC Structured Text, rather than graphical notations such as Sequential Function Chart (SFC). Textual code is easier to review, diff, and merge; it fits modern development practices and enables straightforward CI/CD automation without the impedance mismatches of diagram-based artifacts.

At the core of cinnamon are CycleManagers. They orchestrate flow control, transitions, and state management, allowing you to implement step sequences and process flows with minimal boilerplate. Instead of hand-coding control logic, you declare intent and let CycleManagers drive execution reliably from state to state.

CycleManagers are configurable at both the step and sequence levels. This lets teams fine-tune timing, transition criteria, error handling, and recovery behavior per step while also shaping the overall execution strategy for the entire process.

States and returns

The CNM_ReturnTypes library defines two standard types for single- and multi-cycle methods/state machines/step chains, aligned with PLCopen-compliant function blocks. SingleExecutionState is used for multi-cycle operations that are edge triggered, while SingleExecutionResult applies to single-cycle executions. The shared fields ERROR, SUCCESS, and ABORTED intentionally use the same numeric values. Because the two enums are non-strict, this design makes them conditionally compatible.

Accordingly, the same library also defines the DefaultSteps for state machines that cinnamon CycleManagers implement by default and from which they derive their current state:

DefaultSteps

cinnamon provides two types of CycleManagers. The SimpleCycleManager can be used anywhere in the code independently of the rest of the framework, but it requires cyclic assignment of control signals (such as stop request or stepping, if needed). It resides in the CNM_CycleManager library. The NodeCycleManager, on the other hand, requires a Node for initialization but can query signals like stop request or stepping from the Node on its own, and therefore reduces cyclic signal assignment. It resides in the CNM_OpmodeHandling library and is the recommended choice for mode step sequences.

Both CycleManagers must be called cyclically with an execute input; a pause input is available but optional. It is critical that they are called exactly once per cycle, since many internal functions rely on edge-based behavior and will malfunction if invoked more than once.

A rising edge on the execute input starts the sequence: the step transitions from IDLE to INIT (step 1) and cycleManager.state changes to BUSY. A falling edge on execute causes cycleManager.state to switch to ABORTED if the sequence has not yet reached SUCCESS — in that case the current step is also set to ABORTED for one cycle. If the sequence has already completed successfully, cycleManager.state remains SUCCESS and the step returns to IDLE.

A rising edge on the pause input places the currently active step (cycleManager.step.current) into the PAUSE state while execution is active. A falling edge on pause triggers a transition back to the last active step, effectively resuming execution where it left off.

The SimpleCycleManager is declared as a plain instance without constructor arguments:

The NodeCycleManager requires an interface pointer to its owning Node instance—typically THIS^, where THIS refers to the current instance of a class derived from AbstractNode:

SimpleCycleManager Inputs

NodeCycleManager Inputs

CycleManagers offer clear transition primitives, so you don’t have to manage steps or states manually. Sequences stay lean and focus on intent.

• proceed() finishes the current step and moves unconditionally to the next one (current + 1 by default).

• proceedWith(step) finishes the current step and jumps unconditionally to the specified step for branching.

• evaluate(state) checks a SingleExecutionState: on SUCCESS the sequence advances to the next step; on ERROR it moves to the ERROR step (or to a provided error step with evaluate(state, errorStep)). While the state is BUSY, IDLE, or ABORTED, the sequence stays in the current step.

  Note: evaluate() ignores the state in the first cycle it is called, because SingleExecutionState machines may retain the last state from a previous execution. To reset and restart a SingleExecutionState machine, the boolean flag cycleManager.executeStep can be used which is FALSE in the first cycle of a step and TRUE thereafter until the step ends. Use it to drive nested step chains, for example: cycleManager.evaluate(state := pusher.extend(execute := cycleManager.executeStep));.

• waitFor(value) moves to the next step as soon as the boolean input becomes TRUE; otherwise, the chain remains in the current step.

• executeCommand(ICommand) runs a command and interprets its return state with edge handling: in the first cycle the command is called with execute := FALSE (e.g., for pre-checks); in subsequent cycles it is called with execute := TRUE. The ICommand interface exposes executeCommand(execute) : SingleExecutionState which the CycleManager invokes with proper edge handling.

• Additionally, two single-cycle helpers are available: enter(ISingleAttempt) runs only in the first cycle of a step, and leave(ISingleAttempt) runs once as soon as transition conditions to the next step are met. ISingleAttempt provides invoke() : SingleExecutionResult, that the cycleManager will execute at the right time.

• Two special methods are provided for error scenarios: acknowledge() can be used to jump back from an error step to the previous step, but only if this step was reached via an error transition. handle(IMessage) was already explained in part 1; the method raises an error, waits until it is cleared, and can then either return to the previous step—if the step was reached via an error using handle—or proceed to the next step if the optional input resumeWithLastStep is set to false.

You can freely combine these methods within a step; a step change occurs only when all used methods report SUCCESS .

• cycleManager.step.current is a read-only property that returns the active step of the execution

• cycleManager.step.last is a read-only property that returns the previous step

• cycleManager.step.next can be used to set the next step after the current one succeeds

• cycleManager.executeStep is a boolean property that is false in the first cycle of a new step and then stays true until the next stepchange, intended to be used to start edge triggered operations within a step

• cycleManager.errors.isInErrorStep is true if the current step was reached by evaluating an error

• cycleManager.state returns the current state of the execution

cycleManager.configuration offers a fluent API that improves discoverability and IntelliSense support.

You can configure either a single step or the entire sequence:

• cycleManager.configuration.step applies only to the current step and resets when the step changes.

• cycleManager.configuration.sequence applies to all steps but can be overridden by step-level settings.

The following options are available for both sequence and step:

• stepWidth sets the increment for the next step when none is specified; the default is 1.

• errorStep defines the step to jump to when an ERROR state occurs.

• timeout limits the maximum execution time of a step. When it elapses, the CycleManager proceeds to timeoutStep.

• timeoutStep specifies the step to jump to on a timeout.

• pause.enable() allows pausing. pause.disable() disallows pausing (for example, during non-reversible processes).

• stepping.enable() aenables stepping so the CycleManager waits until stepControl is TRUE before changing steps. stepping.disable() allows automatic step changes.

• stopRequest defines the behavior when the stopRequest input becomes TRUE :

  • stopRequest.ignore() continues sequence execution.

  • stopRequest.immediate() stops immediately by setting the current step to SUCCESS .

  • stopRequest.afterSuccessfulStep() waits for the current step to complete, then proceeds to SUCCESS instead of advancing to the next step.

  • stopRequest.onBusy() ends the sequence if the current step has not yet succeeded (for example, while waiting for a handshake with another unit). It does not stop if the handshake succeeds.

• The following option applies only to sequence configuration: requireSuccessStep is a boolean. If set to TRUE, the CycleManager guarantees execution of operations within the SUCCESS step. The cycle manager's state changes to SUCCESS only if the SUCCESS step succeeds, for example, with proceed or evaluate(SUCCESS).

Using the CycleManager to execute multiple commands parallel

Using enter() and leave() to execute a motor for a given time

A looping sequence with handling, processing and handshakes