Build a self-resetting PLC alarm bypass timer

Why do the alarms fire during a water change?

The readings really do cross the alarm limits during a clean: draining drops the water level and the temperature, and the PLC compares every live value against the same band it uses to catch a failed heater or a leak, so it alarms exactly as designed.

Your email condition is a comparison, something like temperature above its high limit or below its low limit, level outside its band, evaluated on every scan against the live processed values. Draining the tank drops the level sensor reading, and with the heater off or its element exposed the temperature falls too, so both comparisons go true during a routine clean. Nothing is broken and nothing is mis-wired. The logic does what you asked it to do; the maintenance window just needs a state of its own.

Why not freeze the readings from the panel?

Freezing the values fails in both directions: if a reading is already outside the limits when the clean starts, the frozen copy keeps that alarm alive, and if it is inside, the frozen copy hides a real fault until the panel looks normal for hours.

A screen change on the panel changes what the operator sees. The alarm and email engine keeps evaluating whatever registers its tags point at, so navigation neither masks the comparison nor stops an email.

Freezing fails in both directions at once. Hold a value that was already past its limit and the alarm stays active through the whole clean. Hold a value that was still inside and the panel hides a real fault: the heater can fail mid-clean while the screen shows a comfortable number. A bypass that only a person can cancel adds the third failure mode. The clean ends, the shift moves on, and the mask is still armed when the genuine fault arrives that night.

What should a timed bypass actually do?

The bypass should inhibit exactly two alarm outputs, the temperature alarm and the level alarm, for a fixed time while the PLC keeps measuring, and it must end unattended when the timer finishes, with the power-loss alarm left outside the mask.

Four jobs, in order: capture the request, time the window, gate only the alarms the clean disturbs, and restore normal alarming with no operator action. The PLC program owns the state and the clock; the panel button only asks. That is the same division of labor as mapping an HMI alarm acknowledgment to a PLC bit: the panel sends the request, the PLC decides what it means and when it ends.

One line stays outside the mask. Never gate the power-loss alarm or anything wired to a safety interlock; this bypass covers nuisance email from planned maintenance and nothing else.

How do you build the bypass in the PLC?

Build it as three PLC rungs, a momentary request bit from a panel button, a bypass latch that the request sets and the timer done bit clears, and a self-resetting on-delay timer, then add one gate rung on each alarm the clean disturbs.

What you need:

• The addresses of the two floating-point registers that hold the processed temperature and level, and of the two comparisons or alarm bits that drive the emails.
• Two spare bits, one for the request and one for the latch, and one on-delay timer with a 1 second time base.
• On the copy route, a second pair of registers for reporting.

The bit names below (BYP_REQ, BYP_ON, TMR_BYP) are illustrative; your project's own tag style wins.

1. Point the panel button at BYP_REQ as a momentary write, and clear BYP_REQ in the PLC on the scan after the latch rung has used it, so a sticky button cannot keep re-arming the mask.
2. Latch rung: BYP_REQ in parallel with BYP_ON, in series with the normally closed timer done contact, drives the BYP_ON coil. The request sets the latch; the done bit breaks it.
3. Timer rung: BYP_ON starts TMR_BYP, an on-delay timer. Enter the preset in the timer's own units; 30 minutes is 1800 on a 1 second time base. When the done bit sets, the normally closed contact in the latch rung opens on the next scan, BYP_ON drops, the timer rung goes false, the timer resets and the done bit clears, so the next press starts a fresh window.
4. Gate rung: let the raw comparisons run every scan into raw alarm bits, and make the panel-facing alarm bit raw AND NOT BYP_ON. Gate the temperature and level conditions only.
5. If your PLC supports timed interrupts or timed subroutines, park the latch and timer rungs there so the bypass clock survives conditional jumps and program edits; a published walkthrough of timed subroutine sequences shows the arrangement on a small fixed-I/O PLC.

What does the panel watch while the bypass is on?

The panel keeps watching value registers either way: on the gate route it reads the live registers and only the two alarm bits are masked, and on the copy route it reads reporting registers that carry processed values normally and nominal good values during the bypass.

Pick one.

Gate only. The panel's numeric objects keep reading the live registers, so the operator watches the true falling level the whole time, and only the two alarm bits are masked. Use this route whenever the panel can alarm from a PLC bit.

Copy to reporting registers. When the email rules compare register values directly and cannot alarm from a bit, copy the processed values into the reporting registers on every scan with BYP_ON off, and write the nominal good values there on every scan with BYP_ON on. Point the panel tags at the reporting registers, label them so everyone knows which value is which, and leave the live registers untouched for troubleshooting.

Either way, drive the banner from BYP_ON. A two-state text object that shows 'Cleaning Bypass' while the latch is on is the same method as showing two text states on an HMI from one PLC bit, and the same trick displays a PLC countdown timer on an HMI panel if you want the remaining minutes on screen. Banner and gate read the same bit, so what the operator sees and what the email engine does cannot drift apart.

How long should the bypass timer run?

Set the timer preset to the longest realistic clean plus a 5 minute margin: a clean that runs 25 minutes of drain, rinse and refill gets a 30 minute preset, because the bypass exists to cover the work, never to shorten the alarm recovery.

Time one full clean with a stopwatch, from the request press to the moment both readings are back inside their bands and steady. Add 5 minutes for the slow days and enter that total as the preset. If different crew members take different times, or you want the value adjustable, point the timer preset at a holding register the panel writes and clamp it inside the PLC; the pattern is the same as adding an operator-settable start delay when the HMI has no scripting.

What does a 30-minute water change look like in a worked example?

With a 30 minute bypass armed at 14:05 and a low limit of 24.0 °C, the falling level and the 21.8 °C reading during the drain set the raw alarm bits, the gated outputs stay off, no email leaves, and normal alarming resumes at 14:35.

Setup: temp alarm band 24.0 to 28.0 °C, level band 30 to 38 cm, nominal reporting values 26.0 °C and 34 cm, the band midpoints: (24.0 + 28.0) / 2 = 26.0, and (30 + 38) / 2 = 34. The clean was timed at 25 minutes, so the preset is 25 + 5 = 30 min, entered as 1800 on a 1 second time base.

• 14:05. The operator presses the button. BYP_REQ sets, BYP_ON latches, TMR_BYP starts counting from 1800, the banner comes on and the reporting registers switch to 26.0 °C and 34 cm.
• 14:08 to 14:33. Drain, filter rinse, refill. At 14:12 the water reads 21.8 °C, below the 24.0 °C low limit, and the level reads 22 cm, below the 30 cm floor. Both raw alarm bits are true. Each panel-facing bit computes raw AND NOT BYP_ON, which is 1 AND 0, so both stay off. No alarm, no email. The live registers still hold 21.8 °C and 22 cm, so anyone troubleshooting sees the real tank.
• 14:35. 14:05 plus 1800 s is 14:35. The done bit sets, BYP_ON drops, the timer resets, the banner clears and the reporting registers resume copying the live values, which are back inside both bands. The 5 minute margin absorbed the slow refill: the clean ran 25 min, from 14:08 to 14:33.

Without the bypass, the 14:12 readings would have emailed at 14:12, mid-clean. With a genuine heater failure at 14:50, after the window, the email goes out on the first scan the value crosses.

How do you check the bypass before relying on it?

Check it on the bench by forcing one value past its limit with the bypass off, watching the email arrive, then arming the bypass, confirming the banner and the silence, and confirming the alarm returns one scan after the 30 minute timer finishes.

1. With the process normal and the bypass off, move one alarm limit temporarily so a live reading sits outside it, and confirm the email arrives. That proves the alarm path is wired end to end.
2. Arm the bypass. Confirm BYP_ON sets, the banner shows, and the forced condition produces no email for the full 30 minutes.
3. Watch the live registers during the bypass and confirm they keep updating with the real tank.
4. Let the timer finish unattended. One scan after the done bit sets, confirm BYP_ON is off, the banner is gone and the forced condition emails again.
5. Put the limit back, then pull control power briefly with the bypass armed and confirm the power-loss alarm still notifies. That condition stays outside the mask.

Each result points at a specific rung. Emails keep arriving with BYP_ON on: the panel rules still read the live registers, so move the gate or the tags. Banner never shows: the text object points at BYP_REQ, not BYP_ON. Alarm never returns: the normally closed done contact is missing or mis-addressed in the latch rung.

Recommendation: gate the temperature and level alarm outputs in the PLC with a request bit, a self-resetting latch and an on-delay timer, preset to the measured clean plus 5 minutes, 30 minutes for a 25 minute clean, and keep the power-loss alarm and anything tied to a safety interlock outside the mask; use the copy-to-reporting-registers route only when the panel's email rules compare register values directly and cannot alarm from a PLC bit.

Questions