Email operators when PLC power returns after an outage

Can the PLC email you while its power is off?

No, because the controller, the panel and the network switch usually share one power feed, so the device that would compose and send the email goes down at the same moment as everything it needs to reach. An email needs three live pieces: a powered sender, a powered network path and a reachable mail server. Drop the feed and all three die together, so an alert during the outage has to come from something the outage does not touch. Map the feed before designing anything: the typical PLC-controlled system architecture reference shows how controller, panel and switch usually hang off one distribution circuit, and only equipment outside that circuit survives it. Decide the message on purpose. If operators must hear during the outage, that is the battery-backed design at the end of this page. If a restoration notice with a time stamp is enough, the rest of this page builds it from hardware already in the cell. An event logged on the panel's screen and an email that lands in a phone fail at different points, so every test here ends at the mailbox.

Which PLC bit says power came back?

Use the CPU's first-scan system bit, which is ON for exactly one scan, about 1 to 10 ms on a small controller, at the moment the processor enters RUN after power-up or after a stop-to-run command. CPU families name it differently: SP0 on one common line, FirstScan on another. Your CPU manual lists it under system bits or system flags, and one vendor's documentation describes its first-scan bit as an enable signal that occurs when the PLC is first powered on or when it transitions from stop to run, which is exactly what a restoration produces. Verify it once before building on it: put the programming software's watch on the bit, take the CPU from stop to RUN once in a safe window, and check that it reads ON for a single scan and then clears. Read the bit for what it says: the processor entered RUN. A technician flipping the mode switch fires it too, so treat the mail as a restart notice and let the shift log settle the cause. The same first scan is the right place to settle the rest of the retentive state after a long outage, which initialize PLC bits to a safe state after a long power outage covers.

Why latch the one-scan pulse into a flag?

Latch it because a one-scan pulse lasts a few milliseconds, while most panels sample their tags on a poll cycle set to 1,000 ms by default, so a pulse that falls between two samples never reaches the event manager. Panels read PLC data on a poll, and that default tag-group rate is the one you meet most often. Faster settings down to 100 ms exist, but a pulse that lives and dies inside a single scan can still fall between two samples. The event manager acts on what a sample sees, so the pulse has to be held until the next sample is certain to land on it. One rung does it:

restart_flag := (first_scan_bit OR restart_flag) AND NOT hmi_ack

Name the two tags in the panel exchange area and make restart_flag retentive, so a second power dip cannot erase it before the mail leaves. With the latch in place the poll rate stops mattering: at 100 ms or at the default, the flag is ON until the handshake clears it. The race is gone.

Worked example: does a 5 ms pulse survive a 1,000 ms poll?

No, not unlatched: the 5 ms pulse has only a 0.5 percent catch rate per event, so across twenty restorations there is about a 9.5 percent chance that at least one alert never arrives. The example inputs are a 5 ms scan, so the first-scan bit holds ON for 5 ms, and a panel sampling every 1,000 ms. Substitute your own scan time and poll setting; the method is the same division.

Unlatched, the bit is caught only when a sample lands inside the pulse: 5 ms / 1,000 ms = 0.005, a 0.5 percent catch rate per event. Over twenty restorations, the chance of at least one miss is 1 - 0.995^20 = 1 - 0.905 = 0.095, about 9.5 percent, so roughly one run of twenty loses an alert.

Latched, the flag sets in the same scan the pulse occurs and holds, so the next sample, at most one poll cycle later, is certain to read ON. Capture then needs only that power stays back for one poll cycle plus the mail round trip, a couple of seconds on a normal server.

How do you set up the latch, the event and the mail action?

Three pieces: a two-rung latch in the PLC, one event in the panel's event manager with a mail action, and an acknowledge bit the panel writes back so the flag clears after the notice goes out. What you need: a CPU with a retentive flag area, the retentive ranges printed in its manual; a panel with a built-in event manager and a mail action; an authenticated mail account the panel may use; one supervised restart window.

1. Pick two tags in the panel exchange area, restart_flag and hmi_ack, and make restart_flag retentive.
2. Enter the latch rung from the last section early in the program, so every later rung sees the settled value.
3. Add the acknowledge clear in the PLC: IF NOT restart_flag THEN hmi_ack := 0. The panel sets the acknowledge and the PLC clears it.
4. In the panel project, open Database >> Event Manager, add an event, select Add Action, choose the Mail action, and select restart_flag as the tag that triggers it. An application note for one common panel family prints this same walk-through.
5. Set the trigger to the flag's rising edge, and write the subject and body to carry the time and the tag name.
6. Enter the mail account, the server details the panel manual lists, and the operator distribution list.
7. Give the same event a second action that writes hmi_ack ON, so the handshake closes within one poll cycle. If the panel cannot write a tag back, hang a 30 s reset timer on restart_flag in the PLC instead; the mail fires inside the first poll cycle, well inside 30 s.

How do you clear the flag so the notice sends once?

The panel's acknowledge bit clears the flag and the PLC clears the acknowledge, so the pair returns to zero and the next restoration arrives as a fresh rising edge that fires one mail. Trigger type decides the rest. An edge-triggered event fires on the flag's rising edge and stays quiet however long the flag holds ON. A level-triggered event with a repeat interval mails again at that interval until the condition clears, and a stuck flag fills the mailbox with copies. The handshake ends both: the panel writes hmi_ack ON as it sends, the latch drops restart_flag, the clear rung resets hmi_ack, and the pair is back to zero for the next restoration. The reset path is where these builds fail in practice, and check the reset path when a PLC flag triggers an HMI event once walks its failure modes. Expect one quirk: a second power dip inside the handshake window leaves the flag ON through both outages, and one notice goes out after the second restoration, which is the correct summary for operators anyway.

How do you test the chain without stopping production?

Book one maintenance window, restart the controller once under supervision, and watch four stages in order: the flag in the PLC, the event in the panel's history, the send in the mail account's activity, and the message in the operator mailbox. Each dark stage isolates the fault to the link after it:

1. restart_flag in the PLC software: sets within one scan, holds ON.
2. The panel's event history: the event appears within one poll cycle at the default rate.
3. The mail account's activity: the send appears within seconds.
4. The operator mailbox: the message lands within a minute on a normal server.

No flag means the rung or the tag address. A flag with no event means the panel was not talking to the PLC, and after a power restore the switch is the first suspect, which test the managed switch when HMI panels stay invisible after power up covers. An event with no send points at the mail account or the server settings; a send with no message points at the delivery path. The panel's own boot adds tens of seconds before the first sample, one more reason to test startup and runtime first when choosing an HMI panel. Run one controlled restart per change. A controller that later drops out of RUN with no power cut points at its supply, and check the AC power supply first when a PLC drops out of run mode starts that diagnosis.

What if the alert must arrive during the outage itself?

Then power the reporter separately: put the panel, its switch and its router on battery power sized from their nameplates, and watch communication loss instead of the first-scan bit, because a panel that stays alive can mail while the cell is still dark. A panel on battery power sees the PLC stop answering, and its driver raises the communication error condition that panel manuals list among the events the manager can act on. Mail on that condition and the notice goes out while the outage is happening, not after. Where the mail path leaves the site over cellular, send HMI alarm emails over a cellular router covers the connection side. The restoration notice from this page then becomes the back-to-normal message that closes the incident, with its time stamp marking the return. The battery-sizing arithmetic in the FAQ works one example from nameplate watts.

Recommendation: build the restoration notice from the hardware in the cell when a 'power is back, controller in RUN' message is enough: retentive restart_flag with the latch rung, a rising-edge mail event on it, the hmi_ack handshake, and one supervised restart to test the chain. Add battery power on the panel, switch and router, with the communication-loss event as the trigger, only when operators must hear about the outage while the cell is still dark.

Questions