A controller with no power cannot send an alert, so send the email when power comes back. Use the first-scan system bit to latch a request bit that fires one email at restart, and copy the clock to retentive V-memory every 60 seconds so the message carries the failure time to within 60 seconds. The generator's 30 to 60 second transfer keeps the process alive; the alert still waits for power.
A controller that has lost its feed cannot send anything: no CPU running, no network up, no email leaving. So the alert goes out at restart, and it should carry the time the power went. Two pieces do that. The CPU's first-scan system bit catches the boot and latches a request bit that fires exactly one email. A 60 second timer copies the clock into retentive V-memory while the plant runs normally, so the message can name the minute the feed dropped. The generator's 30 to 60 second start time keeps heaters and pumps alive through the transfer; the alert still waits for power, because the controller is dark until a feed reaches it. This page gives the ladder, the arithmetic for a real outage, and a 3 minute test of the whole path.
What you need
A CPU that documents email. The CLICK PLUS manuals document secure email; the instruction list for your CPU model tells you whether yours sends mail. If it cannot, the same ladder can drive the operator panel's email feature instead, and the panel needs its own feed back before it sends.
The mail details: server address, an account the server accepts, and the recipient list. Email operators when PLC power returns after an outage walks that notification side end to end.
An Ethernet drop on a network that is fed again when power returns. A controller that is up while its switch is still dark has no route out.
Two spare retentive V-memory addresses for the hour and minute, and one spare control bit for the request.
The ladder, step by step
- Pick the timestamp addresses. Choose V-memory addresses inside the retentive range printed in the CLICK PLC user manual's memory map. Retentive means the CPU holds the value through a power loss; an address outside that range comes back at zero and the timestamp is gone. How retentive memory behaves across a loss, including using it to restart pumps, is in PLC retentive memory so pumps restart after a power loss.
- Save the clock every 60 seconds. Build a self-resetting timer with a 60 second preset. On its completion, copy the real-time clock's hour and minute, the clock registers the same manual lists, into the two retentive addresses, and let the timer start over. One rung, one copy per minute.
- Catch the first scan. The CLICK help file's System Control Relays page lists the FirstScan bit: ON for the first scan after power-up or after a stop-to-run transition, OFF after that one scan. Put a normally open contact on it and drive a SET of the request bit. The contact is live for a single scan, so the SET is what keeps the event. The first scan is also where control bits take their safe start values; initialize PLC bits to a safe state after a long power outage covers that housekeeping.
- Fire one email, then clear the request. Use the request bit to trigger the email instruction your CPU documents; on a CLICK PLUS, the secure email feature's manual walks the server, account and DNS fields. Reset the request bit when the send finishes, from the instruction's done output if it has one. One restart then produces one message and the next restart produces the next. If the mail feature prints register values into the text, add the two saved addresses so the message carries the hour and minute. If it cannot, keep the timestamp on the operator panel and say in a fixed line of text where to read it.
- Word the subject for both cases. FirstScan fires after a power failure and after a software stop and run alike, so a technician who stops and runs the CPU at 2 p.m. sends the same email a failed utility feed sends at 2 a.m. A subject like "power restored or CPU restarted" stays true in both. In a tank room nobody stops and runs the controller by hand overnight, so a 2 a.m. message still means a feed came back.
Example: 75 unmonitored minutes at the tank
The save timer runs every 60 seconds. Utility power fails at 14:07:40. The last save was at 14:07, so the two retentive addresses read 14:07, and the true failure sits in the following 60 seconds, 40 seconds ahead as it happens.
First ending: the generator starts and carries the feed 45 seconds after the failure, at about 14:08:25. The CPU boots, FirstScan sets the request bit, and the email leaves at about 14:08:30 reading "power restored or CPU restarted; last saved clock 14:07". The crew knows within a minute of the transfer that the utility feed dropped, and the timestamp is good to within 60 seconds.
Second ending: the generator fails to start. The controller is dark until a technician brings the utility feed back at 15:22. The email leaves at 15:22 and still carries 14:07. The number the crew needs is the gap: 15:22 minus 14:07 is 1 hour 15 minutes, so heaters and filters ran with nobody watching for about 75 minutes. Check your own building against the same three figures: a 60 second save interval, a 30 to 60 second generator transfer, and a failure time reported early by at most 60 seconds.
How to check it worked
Do the first test in a maintenance window with someone watching the tank. Cutting the feed is a real outage for every heater, pump and light on that circuit, however short you make it.
- Cut the feed for 3 minutes at a known second, say 10:00:20, then restore it. Expect exactly one email, arriving within about a minute of the reboot, with a saved clock of 10:00. The failure came 20 seconds after the last save, so a 10:00 timestamp is exactly what correct looks like at a 60 second interval.
- Read the two retentive addresses after the reboot. They should still show 10:00. If they show zero, the addresses sit outside the retentive range, and step 1 of the ladder needs different addresses.
- Stop and run the CPU from the software, with the power left alone. The same email should fire once. That exercises the FirstScan contact, the SET, the send and the reset with the power system untouched.
- If no email arrives, check DNS on the controller first; a send that fails right after power returns is usually name resolution, and HMI panel email send error: check DNS first gives the order to work the problem. After DNS, check the recipient address and the switch between the controller and the network. A switch on the failed feed comes back on its own schedule, so the controller can be up with no route out.
Where this design stops
The email reports a restart, and it only leaves if a feed returns. If power never comes back, no message ever leaves, so a tank or a process that must be watched through a long outage needs a second path that does not depend on the building supply: a battery-backed dialer, or a monitoring service watching a UPS contact. If the controller sits on a UPS or another feed that never drops, it never reboots, FirstScan never fires, and the trigger moves to that UPS contact wired to an input. The rest of the ladder, the 60 second clock save and the single email per restart stay the same.
If the crew should get the notice as a text on their phones, send HMI alarm emails to a phone as text messages covers the message path. More answers on shop-floor controls and screens live in our factory and plant section.
Recommendation: if the CPU reboots when a feed returns, use FirstScan to SET a request bit, trigger the documented email instruction from that bit, reset the bit when the send finishes, and copy the clock to retentive V-memory every 60 seconds, so the message carries the failure minute good to within 60 seconds. If the CPU sits on a UPS or a feed that never drops, keep the same ladder and trigger the request bit from the UPS contact wired to an input. For any tank or process that must be watched even when no feed returns, add a battery-backed alarm path beside this one.
Questions
What if the email never arrives after a real outage?
Work the path in order. Check the DNS setting on the controller first, because a send that fails right after power comes back is usually name resolution. Then check the recipient address. Then check the network switch between the controller and the rest of the network: a switch that sits on the failed feed comes back on its own schedule, so the controller can be up with no route out. Once the network is healthy, stop and run the CPU once more; the same email is designed to fire on that transition, so it should then arrive.
How close is the failure time in the message?
Within one save interval. With a 60 second save, the reported minute is the last full minute the CPU saw, and the true failure falls somewhere in the following 60 seconds. Cut the save timer to a 10 second preset and the bound tightens to 10 seconds. Pick the interval from how precisely the crew needs the failure time; the only cost is a copy instruction that runs more often.
Does the first-scan email fire on every power-up?
Yes. The FirstScan bit is designed to fire on power-up and on a stop-to-run transition from the software, so a daytime stop and run sends the same message as a night power failure. Word the subject so it covers both. If operators stop and run the CPU routinely during the day, gate the request bit behind a time window or an operator bypass bit so those transitions stay quiet and the overnight path stays armed.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.