Program Control Instructions

Program Control — An Overview

Every PLC scan you’ve seen so far follows the same rigid pattern: read all inputs, execute every rung in order, write all outputs, repeat. That predictability is the PLC’s superpower — every machine engineer can look at a ladder program and know exactly when each rung will run.

Program control instructions bend that rule on purpose. They give you tools to:

• Skip a section of rungs entirely (JMP / LBL).
• Force every output in a section to OFF while still letting the rungs scan (MCR).
• Call a reusable block of code from anywhere in the program (JSR / SBR / RET).
• Read or write an I/O point right now, mid-scan, without waiting for the I/O update phase (IIN / IOT).
• Schedule code to run at strict time intervals, independent of scan time (STI).
• Catch runtime errors with dedicated fault-handler routines.
• End the scan early for testing or freeze the CPU for diagnostics (TND / SUS).

Each instruction is a tool, and like any tool it has a right and a wrong way to be used. The chapter’s goal is to make you fluent with all of them, so you can pick the right one for any control problem — and just as importantly, recognise when you should leave them alone.

Master Control Reset (MCR)

An MCR zone is a section of program bracketed by two MCR instructions. The first MCR (at the top of the zone) sees the rung condition that controls the zone — typically your safety chain. The second MCR (at the bottom) closes the zone with an unconditional rung. Everything between them is “inside the zone”.

Two states matter:

• Zone enabled — the first MCR’s rung is true. Rungs inside the zone execute exactly as if the MCR pair didn’t exist. Your normal logic runs and drives outputs as designed.
• Zone disabled — the first MCR’s rung is false. All non-retentive outputs (OTE) inside the zone are forced to 0. The rungs are still scanned, but their OTE results are overridden. Latched outputs (OTL/OTU), timer accumulators (RTO), and counter accumulators retain their values — which is sometimes what you want, and sometimes a trap.

Jump (JMP) and Label (LBL)

JMP tells the scan to skip ahead to a matching LBL instruction. When the JMP rung is true, the rungs between JMP and LBL are not scanned at all. They don’t run; they’re invisible to the processor for that scan. When the JMP rung is false, scan continues normally and reaches the rungs between JMP and LBL one at a time.

Each JMP/LBL pair shares an integer label number (e.g., LBL 03). You can have many JMP/LBL pairs in a program, each with its own number. You can also have multiple JMP instructions targeting the same LBL — different conditions all funnel to the same skip target.

The critical difference between JMP and MCR:

JMP/LBL is also used for backward jumps (jumping to an earlier LBL) on some platforms — but most engineers avoid this because it’s the ladder equivalent of a goto loop and can blow past the watchdog timer if the loop never exits.

Subroutines (JSR / SBR / RET)

A subroutine is a separate program file containing reusable code. It’s called from the main program with a JSR (Jump to Subroutine) instruction, executes from start to finish, then returns to the rung after the JSR. The same subroutine can be called from many places in the main program, or even from inside other subroutines.

Three instructions work together:

• JSR — placed in the main program. Names the subroutine file to call (e.g., JSR file:U3). Optionally lists input parameters and output destinations.
• SBR — placed at the very first rung of the subroutine file. Receives the input parameters listed in the JSR.
• RET — placed at the end of the subroutine. Returns control to the rung after the JSR. Optionally returns output values to the caller.

When to write a subroutine

Whenever you find yourself copying the same logic into multiple places. The classic uses:

• Diagnostic and alarm logic that runs the same way for every motor, valve, or station.
• Scaling routines that convert raw analog values to engineering units — written once, called from every analog rung.
• Recipe selection where one subroutine handles “load recipe parameters” and is called whenever a new recipe is selected.
• Conditional logic that’s only relevant when a particular feature is enabled — wrap it in a subroutine and only call it then.

Immediate Input/Output Instructions (IIN / IOT)

Recall from Chapter 5 the three-phase scan: read all inputs into the input image, run all rungs, write the output image to all outputs. This means a typical input is read once per scan at the very beginning, and a typical output is written once per scan at the very end. For most applications, that’s plenty.

For some applications, that’s far too slow. An emergency-stop signal needs to disable outputs within milliseconds. A safety light curtain on a high-speed press cannot wait for the next scan to fire its stop relay. For these cases, two instructions break the normal scan rule:

• IIN — Immediate Input. When this instruction executes, the PLC stops, reads the named input directly from the I/O card, updates the input image table for that bit, and continues. Subsequent rungs see the freshly-read value, not the value from the start-of-scan image.
• IOT — Immediate Output. When this instruction executes, the PLC stops, writes the named output directly to the I/O card without waiting for the end-of-scan output update, and continues. The actual physical output changes state immediately.

Use IIN/IOT sparingly. Each instruction adds CPU overhead because it forces a hardware access mid-scan. Reserve them for genuinely time-critical signals — emergency stops, light curtains, safety mats, protective interlocks. Everything else is fine on the normal scan.

Forcing External I/O Addresses

“Forcing” is a debugging feature of the programming software, not a ladder instruction. It lets the engineer override the actual hardware state of any input or output bit. A forced bit reads or writes whatever value the engineer set, regardless of what the wire or the program says.

Two flavours:

• Force input ON / OFF — pretend the input is at the forced state. The CPU and your ladder logic see it as forced. Useful for testing rungs without having to physically actuate a switch or sensor.
• Force output ON / OFF — drive the physical output to the forced state regardless of the rung result. Useful for proving wiring, testing actuators, and simulating fault conditions.

Every modern PLC programming environment shows forced bits with a clear visual indicator — usually a yellow halo or a “F” badge in the online monitor. There’s also typically a “forces enabled” indicator on the CPU itself (a flashing yellow LED on most Allen-Bradley CPUs) so anyone walking past the panel can see that the program is running with forces active.

The legitimate uses of forcing are testing, diagnostic work, and short-term troubleshooting. The illegitimate use is “patching” a wiring or programming problem with a permanent force instead of fixing the root cause. Don’t do that.

Safety Circuitry — Why Software Alone Is Not Enough

Every PLC program you’ll ever write contains some logic that’s “safety-related” — a stop button, an interlock, a guard switch. The temptation is to handle all of it in ladder logic. After all, the PLC is reliable and the rungs are right there. But there’s a critical principle that every controls engineer must internalise:

A PLC is a single point of failure. If the CPU crashes, the watchdog locks up, or the program has a bug, every “safety” interlock in software is lost.

Real industrial safety circuits use hardwired protection that does not depend on the PLC at all. An emergency-stop button connects through a safety relay directly to the contactor coils that drive the motors. Press the E-stop and the motor contactors drop out — no PLC involvement, no software, no firmware. Even if the PLC is on fire, the motors stop.

Two-channel monitoring

Modern safety circuits use two independent channels through the safety relay. Both channels must agree, both must transition together when the E-stop is pressed, and both must reset together when the system is rearmed. If either channel fails — open wire, stuck contact, welded relay — the safety relay refuses to allow restart. This is the core of how SIL (Safety Integrity Level) and PL (Performance Level) ratings are achieved.

Where the PLC fits in the safety system

The PLC’s role in a properly engineered safety system is monitoring and indication, not protection. Bring the safety relay’s status contacts back to PLC inputs so the program knows whether the safety chain is enabled. Use those bits to drive HMI indicators, alarm logs, and software interlocks for non-safety functions. The actual disconnection of motor power happens in the hardwired safety circuit, not in the PLC program.

Selectable Timed Interrupts (STI)

Most code in a PLC runs once per scan, and the scan time varies based on how much logic is true and how complex the math is. For most control jobs that’s fine. For some jobs — closed-loop control, motion profiles, fast data sampling — it’s not.

A Selectable Timed Interrupt is a special subroutine that runs at a strict time interval set by the engineer, regardless of where the main scan happens to be. Configure an STI with a 50 ms period and the PLC will execute that subroutine every 50 ms — interrupting the main scan if necessary, completing the STI’s logic, then resuming the main scan exactly where it left off.

What STIs are good for

• PID control loops that need a fixed sample rate to stay tuned correctly.
• Motion control calculations that depend on consistent timing.
• Data logging at precise intervals for trending and analysis.
• Filtering noisy analog signals using algorithms that assume a known sample period.
• Communication polling where another device expects data at a fixed cadence.

Fault Routines

Sometimes a PLC encounters something it can’t handle in normal logic — a math overflow, a divide-by-zero, an array index out of range, a watchdog timeout, a comms-card fault. Without intervention, the CPU faults and the entire program halts. Every output drops, every motor stops, the operator sees a flashing red LED. Recovery requires a manual fault-clear and often a restart.

A fault routine is a special subroutine that the PLC executes automatically the moment a runtime fault occurs. Inside the fault routine you can:

1. Log the fault — record the fault code, the rung that caused it, the timestamp.
2. Drive critical outputs to a safe state — close valves, turn off heaters, etc.
3. Try to clear the fault programmatically (some can be cleared, some cannot).
4. Decide whether to continue running or halt for operator attention.

Fault routines are typically configured in the controller properties (not as a normal subroutine call). The CPU knows to invoke them automatically when a fault is detected.

Temporary End (TND)

The Temporary End instruction does exactly what its name says — it temporarily ends the program scan. When TND is true, the rungs after TND are not executed for that scan. The PLC jumps to the end-of-scan output update, sends outputs, and starts the next scan from rung 0 as normal.

TND is a development and testing tool, not a feature you’d typically leave in production code. Two common uses:

• Section-by-section testing. When developing a long program, place a TND temporarily after the section you’re working on. The rungs below don’t run, so you can test just the section above without the rest of the program interfering.
• Conditional bypass. Place a TND with an XIC of a “test mode” bit. When in test mode, only the rungs above the TND run; production rungs below are skipped. Toggle the bit off and the full program runs.

Suspend (SUS)

The Suspend instruction is the diagnostic tool of last resort. When SUS is true, the PLC immediately halts execution, captures the entire CPU state to non-volatile memory, and stops. All outputs go to their failure-safe state. The CPU’s status LEDs change to indicate “suspended”. An engineer connecting with the programming software sees the captured state and can analyse exactly what was happening at the moment SUS fired.

Each SUS instruction has a suspend ID — an integer the engineer chose when writing the rung. When SUS halts the CPU, the suspend ID is recorded so you know which SUS instruction fired (you can have many in the program, each with a different ID).

When SUS is appropriate

SUS exists for catching intermittent faults that are too rare to reproduce on demand. Imagine a machine that mysteriously stops every two or three days for no apparent reason. You suspect a particular condition is causing it but can’t catch the moment in real time. Add a SUS rung that fires when that condition is detected. Next time it happens, the PLC freezes itself with the entire program state captured — every register, every bit, every counter and timer ACC. You connect the laptop, look at the snapshot, and find the cause.