Drive one spare output point with a rung that is true every scan, bench test the point through a run-to-program transition, then alarm the HMI on that bit going off. The card's per-point program-mode state setting decides whether the method works on a given machine; the 10 s bench test settles it before operators rely on the banner.
You can give an HMI a controller-not-in-run alarm even when its driver has no read of the controller's mode. Drive one spare output point with a rung that is true every scan, bench test that the point drops when the key goes to program, then alarm the HMI on that point going off. The method rests on one documented behavior: when a controller leaves run, it stops scanning the program and writing outputs, and the output card applies the state its configuration assigns to each point for program mode. Current output-card manuals give three choices per point: Off, On, and Hold last state. That setting and a short bench test settle whether the method works on your machine before an operator ever relies on the banner. This page gives the symptoms, the test, the wiring, the alarm settings, and the timing arithmetic.
Why a stopped controller drops the spare output
In run, the controller scans the program every cycle, and a rung that is true every scan holds the spare point on for as long as the program runs. Turn the key to program and the scanning stops. The rung stops executing, the point stops receiving its true condition, and the card applies its configured program-mode state.
The manual for the output card documents that per-point program-mode state and its three choices: Off, On, and Hold, which keeps the last state. The method needs Off. A point left at Hold keeps the indication lit through a program-mode stop, and the HMI never sees the drop; that is the one failure the bench test exists to catch.
Two cleaner sources win when they exist. If the controller publishes a mode or status value the HMI's driver lists, alarm on it directly. Some controllers expose the mode as a string value; read it with a plain display object before designing around it, because many drivers do not list string data.
Symptoms and what each one points to
- No banner when the key goes to program, and the indication stays lit. The point's program-mode state is Hold, or the rung never made it into the project the controller is running. Check the card's configuration for the point first, then confirm which project is running.
- The banner trips while the controller is running. The alarm condition is inverted. Trip on bit-off and clear when the bit returns.
- A communications alarm arrives at the same moment. The controller or the network went down, with the keyswitch untouched; let the HMI's own communications-failure alarm carry that case and keep the two alarms separate.
- The controller drops out of run with nobody at the key. That is a different fault, and the supply is the first check; see PLC drops out of run mode: check the AC power supply first.
- The heartbeat bit the panel writes for the controller keeps toggling in program. It lives on the panel's side of the link, written on the panel's schedule so the controller can check the panel; it follows the link and says nothing about the keyswitch. It is the wrong bit for this job; the spare output is the right one.
Bench test the spare point before you trust it
- Put the machine in a safe state, and confirm the spare point is wired to nothing that can start, move, or heat anything. If it already drives an indicator lamp, leave the lamp in place; at 24 V DC, the common level for discrete I/O, a lamp makes a clean test light.
- Add the rung: one condition that is true every scan, driving the spare point. Use your project's own tag for the point; a point address carried over from another project is the fastest way to energize the wrong terminal.
- In run, confirm the point's LED on the card is lit and that nothing on the machine changed.
- Move the key to program using the procedure your site authorizes, hold it there for 10 s, and watch the LED. Off is the passing result.
- Return to run and confirm the LED comes back on.
- If the LED held through step 4, open the card's configuration, set that point's program-mode state to Off, and repeat steps 3 to 5. If the manual lists no program-mode state at all, this point is no good as a run signal; use a status value the driver reads or a different card.
Each step changes one thing, which is what makes the result decisive; the same one-change-at-a-time discipline is why each test should prove one cause.
Wire the indication and set the alarm
Two routes take the bit to the HMI:
- Read the output point's own tag through the HMI driver, if the driver reads output data. No wiring, and the bench test still applies.
- Wire the spare contact to a spare input channel and alarm on the input. The contact, the wire, and the terminal join the tested path, so a pulled wire at the lamp alarms the same way a stopped controller does. Reserve one spare input channel for it.
Alarm settings, in the editor's own fields: source, the readable bit from either route; condition, bit off; delay, 2 s if the editor offers an alarm delay, so a pass through program during commissioning does not page anyone.
Alarm evaluation follows the bit's state, and how an alarm logs on a bool's state changes decides whether one pass through program shows one banner or a page of them: the alarm arms on the transition to off and clears when the point returns.
One keyswitch detail: many switches have a third position between run and program, and on some controllers that position also stops the panel's communications, so the HMI loses its read instead of seeing the bit drop. What the panel does in that position is its own subject; see the middle keyswitch position and panel communications.
While the panel work is open, put the crew's response steps where operators look. A shop-floor notice screen carrying the same status wording keeps that posting job off the HMI.
Example: a packing line panel
A packing line HMI watches a controller whose keyswitch the maintenance crew turns to program about twice a week to clear jams, 5 minutes a session. The plant wants the banner up within 5 s of the key leaving run. The output card is a 16-point 24 V DC discrete card with 15 points in use and 1 spare; the input card has 3 spare channels.
Bench test: LED on in run, off after 10 s in program, on again back in run. The point's program-mode state is already Off, so no configuration change is needed.
Build: the spare contact wires into 1 of the 3 spare input channels, leaving 2 for growth. The HMI reads that bit every 1 s, the read interval of the group it sits in, and the alarm trips on bit-off with a 2 s delay.
Timing, from key to banner: count the drop as 0 s, because the card applies its program-mode state as output scanning stops; add 1 s to the next read; add the 2 s delay. 0 + 1 + 2 = 3 s, under the 5 s target with 2 s to spare. Back in run, the bit returns, the delay expires, and the banner clears on the following read.
Line 2 failed the same test: its older card held the point on through 10 s in program. That card's configuration did offer the program-mode choice, the point went to Off, and the repeat test passed. Both lines now alarm on the keyswitch and stay quiet while running.
Recommendation
Recommendation: Use the spare-output method whenever the HMI's driver has no mode or status read. Take a point that drives nothing but the indication, add the unconditional rung, confirm the point's program-mode state is Off in the card's configuration, pass the three-step bench test, then alarm on bit-off with a 2 s delay. Wire through a spare input channel when you want the contact, the wire, and the terminal inside the tested path; read the output's own tag when the input card has no spare channel. If the bench test shows the point holding in program, set the card's program-mode state for that point to Off and test again. If the card offers no such setting, use a status value the driver reads or a different card, and keep the same bench test as the gate for any variant.
Questions
Does the spare output also catch a controller fault or a power cut?
A fault that stops the scan and a power cut both stop the rung, so the point drops and the banner shows if the HMI's read survives. A power cut usually takes the HMI's read down with it, so that case belongs to the HMI's own communications-failure alarm. Configure both alarms; between them they cover the keyswitch, a stopped controller, and a dead link.
Why does the heartbeat bit keep toggling in program mode?
The panel writes that bit on its own schedule so the controller can check the panel link, and the write keeps going while the controller's program is stopped. The bit therefore follows the panel link, and it is the wrong source for a run-mode alarm. Use it for its own job and take the run signal from a spare output.
How should I choose the alarm delay?
Start from how fast the crew must know. Count the drop itself as 0 s, add your project's read interval for the bit, add the delay, and keep the total inside the response time the plant expects. On the packing line example that budget is 1 s to the next read plus a 2 s delay, 3 s against a 5 s target. Raise the delay only if commissioning passes through program often enough to page people needlessly.
What if there is no spare output and no spare input channel?
Three ways out: free a point that drives only an indicator, add a one-slot output or input card to a spare rack slot, or alarm on a mode or status value the controller publishes and the driver actually reads. Whatever you pick, the gate is the same bench test: the indication must be off in program and on in run before the alarm goes live.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.