Most HMI projects have no screen switch for alarm logging, so the working method is a request bit the screen writes to the PLC; the PLC gates the one rung that triggers that alarm. Keep the inhibit to a declared window, verify the alarm before and after, and leave alarms with a safety role alone.
Most HMI projects give you no switch that turns alarm logging on and off while the line runs. The working method sits in the PLC: the screen writes a request word, the logic gates the one rung that triggers that alarm with its own bit, and the PLC stops generating the alarm. Display and log go quiet with it, because both read the bit the PLC sets. Applied to a single nuisance alarm, inside a declared window, with a proof test at each end, this is a clean troubleshooting tool. Spread across a whole alarm group, it blanks warnings the line still needs. This article gives you the wiring, the mask arithmetic, the verification, and the one case where the method is off limits.
What the inhibit actually stops
Three separate events make up one alarm. The PLC sets the alarm bit; that is generation. The HMI shows the banner and sounds the horn; that is presentation. The alarm log writes the timestamped record; that is retention. A rung inhibit removes generation, and presentation and retention follow, since both read the bit the PLC sets. That is the point of the method when the event itself has to stop for a while. If the only complaint is a banner crowding the screen, hiding the alarm banner on the HMI screen is the smaller job; the alarm keeps working underneath it.
What you need
- PLC program access, and the rung that sets the alarm bit already found. One rung per alarm you plan to inhibit.
- One free 16-bit integer word in the PLC data table, initial value 0. The screen writes the word; each alarm rung tests one bit of it.
- An existing HMI screen with room for one pushbutton and one status indicator, and permission to edit the project.
- The alarm's normal trigger condition written down, so you can reproduce it for the proof test.
- A declared window with an owner: 2 hours in the example below.
- Confirmation that the alarm bit drives no interlock, no stop and no protective response. If it drives any of those, this method is off limits for that alarm.
Wire the request into the alarm rung
- Open the rung that sets the alarm coil. In effect it reads
Trigger AND NOT Fault_Done SETS Alarm_4_Bit. The names here are examples; your project uses its own.Triggeris the field condition, andAlarm_4_Bitis the bit the panel and the log read. - Add the inhibit contact in series, so the rung becomes
Trigger AND NOT Fault_Done AND NOT Req_Bit_4 SETS Alarm_4_Bit. WithReq_Bit_4at 0 the rung behaves exactly as it did. With it at 1, the rung cannot set the coil. Nothing else in the program changes. - Map the request as one word. Give the HMI a single integer tag, the request word, and give each alarm its own bit: bit 4 requests the inhibit for alarm 4, bit 9 for alarm 9. The screen writes the whole word; each rung tests only its own bit. That is the standard split, the HMI handles the word and the PLC uses its bits, and it keeps one tag on the screen and one pattern in the logic. The write-from-screen mechanics are the same ones used to map an HMI alarm acknowledgment to a PLC bit.
- Echo the effective state back to the panel. Compute
Inh_Active_4 := (Req_Word AND 16) <> 0in the PLC and display that bit. The pushbutton writes; the indicator reads what the PLC actually holds. The screen's own button state can end up stale after a communications drop, and the echo fixes that. Map the two texts from the PLC bit with the two-state text method. - Supervise the link with the heartbeat. The screen toggles a heartbeat bit about every 1 s, and the PLC clears the request word to 0 if the heartbeat holds still for 3 s. A dropped cable then restores every alarm to service, which is the safe direction. The heartbeat arrangement itself is covered in the PLC heartbeat counter article.
- Clear the request word in the PLC startup logic. A power cut mid-window then brings the machine back with all alarms in service instead of one still suppressed.
- Test both states before the real window. With the word at 0, reproduce the fault condition once and watch the alarm fire. Set bit 4, reproduce it again, watch the panel stay quiet while the indicator shows inhibited, and trip a different alarm on purpose to confirm you gated one rung and only one.
- Tell the floor. Put the alarm number and the window on the shop-floor signage or the shift board, so the incoming crew knows the quiet alarm is planned and when it ends.
Example: alarm 4 quiet for a 2-hour window
A packaging line throws alarm 4, ejector jam, every few minutes because a photoeye is dying. The sensor swap is booked for Tuesday, 14:00 to 16:00, and left alone the repeated alarms will have the crew chasing phantom jams through the whole job. Alarm 4 sounds a horn and writes a log entry, and drives nothing else: no stop, no interlock.
The request word is a 16-bit INT at 0. Bit 4 belongs to alarm 4, so the mask is 2^4 = 16. From the screen, the operator's maintained button writes 16 into the word. The PLC computes Inh_Active_4 := (Req_Word AND 16) <> 0; 16 AND 16 gives 16, so the indicator reads ALARM 4 INHIBITED, and the Req_Bit_4 contact in the alarm rung opens.
Halfway through the job the crew wants alarm 9, carton low count, quiet as well. Bit 9 gives a mask of 2^9 = 512, and the button now writes 16 + 512 = 528. Alarm 4 stays gated, alarm 9 goes quiet, and a deliberate trip of alarm 2, door open, still fires, which confirms the gating is per-bit.
At 16:00 the screen writes 0. Proof test: block the photoeye once on purpose. Alarm 4 appears on the panel, the log gains one entry stamped that minute, and the window is closed.
How to check it worked
- Before the window, word at 0: trip the real condition once. The alarm fires and the log records it. Note the timestamp.
- During the window, bit 4 set: the indicator reads INHIBITED, the alarm stays quiet with the fault present, and a second alarm still fires when tripped on purpose.
- Communications dead: with the inhibit on, stop the HMI runtime or pull its cable. The 3 s heartbeat watchdog clears the word, the indicator returns to normal, and the alarm is back in service.
- After the window, word at 0: trip the condition once more. The alarm fires and the new log entry carries a current timestamp. If it stays quiet, check the word value first: a nonzero value means the screen never wrote 0.
When to leave the alarm alone
One question decides whether this method is allowed on a given alarm: does the same rung drive anything besides the horn and the log? If the alarm bit also feeds an interlock, a protective stop or a guard response, leave that rung untouched. Take the planned stop, or have the controls engineer split the logic so the protective path stays live while a separate logging-only copy is gated.
Recommendation: gate the single alarm-trigger rung with one bit of an HMI-written request word, echo the PLC state back to an indicator, clear the word at startup and on heartbeat loss, and keep the inhibit inside a declared window such as 2 hours with a named owner. Use it on nuisance alarms with no protective role, and proof-test the alarm at both ends of the window.
Questions
Can the HMI turn alarm logging on and off directly?
In most HMI projects, alarm logging is configured when the project is built and downloaded, and there is no supported screen object that pauses the log while the machine runs. The supported route is on the PLC side: gate the rung that sets the alarm bit. Before building the gate, search your HMI software's own documentation for a logging control; if your version has one, that object is the better tool.
How long can an alarm inhibit stay active?
Treat it as a session with an end time, not a setting. A declared window such as 2 hours with a named owner keeps a suppression from hardening into the way the line runs. If the work outlasts the window, close it, proof-test the alarm, and open a new window on paper before writing the bit again.
Does the inhibit survive a PLC power cycle?
It does if the request word is retentive, and that is the wrong default for a troubleshooting tool. Put the word in non-retentive memory or clear it in the startup logic, so a power cut during the window brings the machine back with every alarm in service. Run the proof test again after any restart to confirm the alarm fires.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.