Siemens Ladder SET: Direct Logic Is Valid, Not Unsafe

A Siemens ladder SET instruction may execute without a preceding contact; the absence of a contact does not make the instruction unsafe or incomplete. When an event-driven OB executes, an unconditional SET records the event by making the target Boolean true. The real design questions are which OB executes the instruction, what resets the Boolean, and whether a literal, constant, or system-memory bit improves maintenance.

Symptom interpretation

The visible symptom is an alarm Boolean that becomes true when diagnostic logic runs. Read that result against the execution context before changing the rung: an unconditional instruction in an event-driven OB has different intent from the same instruction in OB1.

The term “event-driven OB” here means an organization block invoked for a particular event rather than continuously on every normal program cycle. Confirm the actual OB type and its invocation conditions in the project; the word “diagnostic” in a tag name does not establish how the block is scheduled.

SET instruction mechanism

A SET instruction is stateful. When its rung is true and the instruction executes, it writes true to the target Boolean. When the rung is false, SET does not clear that target. Clearing requires a corresponding reset operation or another deliberate writer.

An unconditional rung is effectively true whenever execution reaches it. Adding a normally open contact driven by the literal TRUE does not change the Boolean result:

// Pattern 1: unconditional
SET AlarmBit

// Pattern 2: explicit literal
TRUE ---- SET AlarmBit

Both patterns set the target each time that network executes. Pattern 2 documents that the unconditional state is intentional, but it does not add an interlock, diagnostic test, or protection against repeated execution.

Execution frequency matters more than rung appearance. In an event-driven OB, the latch captures an event that could disappear before cyclic alarm handling observes it. In OB1, the same network sets the bit every scan. Resetting it earlier in OB1 only creates a temporary false interval: a later FC or network can set it again before the cycle ends, and it remains true until the next reset.

Implementation-pattern comparison

The configured AlwaysTRUE system bit is not equivalent to a randomly selected memory bit that happens to be initialized true. The former is part of the CPU system-memory design; the latter is writable storage and can change through direct logic, overlapping addresses, interface assignments, or online commissioning actions.

TIA Portal user constants can be defined in the user-constants area of a tag table for PLC-wide use. A constant inside an FB keeps the meaning with the block when portability matters. For a short, self-evident network, the literal TRUE avoids address ownership entirely.

Pattern-selection procedure

1. Classify the OB. Determine whether the instruction runs cyclically, periodically, at startup, or on a diagnostic event. Do not select the pattern from the alarm tag name alone.

2. Define the required state transition. Use SET only when the alarm must remain true after the triggering execution ends. If the alarm should mirror a current condition, calculate it from that condition rather than latching it.

3. Assign one state owner. Identify the logic responsible for setting, acknowledging, and resetting the Boolean. Cross-reference the target and review every direct assignment, SET, reset, and block-interface connection.

4. Select the clearest true condition. Use an unconditional SET when reaching the network is itself the condition. Add a literal TRUE when the project convention requires visible intent. Use a named constant when the name communicates a configuration choice. Use configured AlwaysTRUE when searchable bypass logic is a deliberate project convention.

5. Keep commissioning controls separate. Place temporary memory tags in a dedicated commissioning tag table so they can be reviewed and removed after commissioning. A force or disable mechanism should remain visibly temporary rather than becoming normal alarm logic.

6. Document the reset rule. State whether reset follows acknowledgment, disappearance of the underlying fault, reinitialization, or another defined condition. A latched alarm without a defined reset path is incomplete even when its set rung is correct.

7. Choose the language by intent. Ladder is suitable when contacts and state transitions aid troubleshooting. If a block consists mainly of unconditional assignments executed from top to bottom, Structured Text may express that procedural intent more clearly.

Alarm-state ownership

A diagnostic OB and the cyclic program may both need access to the alarm state, but they should not compete as undocumented writers. Treat the latched Boolean as stored state with an explicit lifecycle: inactive, set by the diagnostic event, presented to alarm handling, acknowledged where applicable, and reset by the declared rule.

Multiple writers make online behavior dependent on execution order. If reset logic runs at the beginning of OB1 and a later FC sets the same memory again, the reset lasts only until that call. Moving the reset does not fix ambiguous ownership; consolidate the state transition or make the priority explicit.

Never pass a shared “always” memory bit to an InOut merely to satisfy an unused interface. An InOut permits the called block to modify the supplied storage. A call that writes true can therefore corrupt an ordinary AlwaysFalse memory tag and affect every network using it. Provide a dedicated variable with defined ownership or correct the block interface.

Verification checks

1. Check 1: OB invocation. Monitor or trace the relevant OB execution. Expect one execution per diagnostic occurrence for event capture, or repeated execution if the selected OB is cyclic or periodic.

2. Check 2: set transition. Trigger the diagnostic condition while monitoring the alarm Boolean. Expect it to change from false to true when the SET network executes.

3. Check 3: retention. Remove the initiating condition without executing the reset rule. Expect the alarm Boolean to remain true; otherwise another writer is clearing it.

4. Check 4: reset behavior. Execute the declared acknowledgment or reset condition after the fault state permits it. Expect the Boolean to become false and remain false through the rest of the cycle.

5. Check 5: writer audit. Cross-reference the alarm Boolean and any AlwaysTRUE or AlwaysFalse tag. Expect only the declared state owners; inspect every InOut use and every overlapping M address.

6. Check 6: alarm handoff. Observe the alarm consumer after the state transition. Expect the alarm to appear from the latched Boolean and to clear only under the same reset policy used by the PLC logic.

Recurring implementation pitfalls

Adding TRUE before SET is documentation, not protection. It cannot prevent an incorrect OB from running repeatedly, repair a missing reset, or resolve multiple writers. Review execution and ownership before changing syntax.

A user-created M tag named AlwaysTRUE has no inherent constant behavior. Renaming writable storage does not make it immutable. Likewise, resetting an altered memory bit at the beginning of OB1 leaves the remainder of the scan exposed to any later call that writes it.

Overlapping memory declarations create hidden aliases: two symbolic tags can address the same storage while appearing unrelated in ladder. Prefer literals or constants when writable storage is unnecessary, and inspect absolute addresses when older or migrated programs use M memory extensively.

Permanent bypasses disguised as commissioning bits weaken traceability. If a bypass must remain, give it a defined configuration owner and searchable name. If it is temporary, keep it in the commissioning tag table and remove its program references when commissioning ends.

FAQ