A manual button email that arrives every time proves the mail path works, so an intermittent Event Manager miss is a trigger, event-condition or clock problem. Hold the trigger bit at least 500 ms, read the Error tab against the miss time, and check the panel clock after a daylight-saving change.
When an HMI sends the manual button email every time and still misses Event Manager emails, the mail path is healthy and the event chain is not. Three branches can drop the message: the PLC bit that never reaches the panel, the event condition or its reset, and the panel clock when the event runs on a schedule. One installation ran exactly this pattern. It held its trigger for 5 s, sent cleanly for weeks, then missed events for a day or two. The mail server was never the fault. Work the three branches in the order below and the miss shows itself.
Why does the manual button email work every time?
The button exercises the mail path only, from the panel through your server to the inbox. The event email runs a longer chain. It goes from the PLC bit through the panel's read of that bit, through the event condition, then into the mail path, so an early link can drop it.
A manual send that arrives tells you the panel can authenticate, reach the server and deliver. Every minute after that belongs to the trigger, the condition and the clock. Two dead ends you can skip early: no new device joined this network before the misses began, and panels on different programming-software versions missed alike. A version sweep or a network change hunt pays nothing here.
What should you check first when event emails miss?
Split the problem by what still works. If the manual send succeeds, leave the mail server, DNS and relay settings alone and test the event chain, from the PLC bit to the panel's event condition.
| What you see | What it points at | The next check |
|---|---|---|
| Button email arrives, event emails miss | The mail path works; the trigger, the condition or the schedule failed | Watch the bit at the PLC and at the panel for one missed event |
| Button and event emails both miss | A total send failure, not an event fault | Start with delivery and check DNS first |
| Panel shows the bit change, no email arrives | The event condition, its reset or the send action | Walk the condition and the reset once in the event editor |
| Misses began in March, at the daylight-saving change | The panel clock, for scheduled events | Read the panel clock beside a wall clock at event time |
| Error tab lists communication errors near a miss | The link between PLC and panel | Fix the link, keep the mail settings untouched |
Only the second row touches the mail setup. If every send fails, check DNS first before anything else. Confirm the panel points at a reachable relay, since it needs an SMTP server, not a webmail address.
How long does the PLC trigger bit need to stay on?
Hold the bit on for at least 500 ms, the field figure for a panel polling a PLC over Ethernet. A one-shot shorter than the interval between the panel's reads can come and go between two of them. Put a 0.5 s timer in front of the unlatch rung and the width stays at 0.5 s.
Past 500 ms, width comes off the suspect list. The installation behind this article latched its trigger for a full 5 s before unlatching and still missed events intermittently. Stretching the pulse spends scan time without buying reliability. A bit raised while the panel is still starting up gets missed the same way; gate the bit until the panel is ready for any event that can occur at power-up.
Where do you read the panel's communication errors?
Open System Screen > Information > Error on the panel and read the communication error list against the time of a miss. An entry within a minute or two of the missed event points at the link between PLC and panel.
The button email keeps working while those errors sit in the list, because the button never reads the PLC. Note the entries with their times before you clear anything. To watch both ends of the link without standing at the cabinet, read tag values from the panel's web server from your desk and compare the PLC's bit state with the panel's view of it. For what makes a polled panel drop a response at all, the page on why a panel sometimes misses PLC responses goes a level deeper. Track the error count over a full day: a link logging errors hourly is a different repair from one logging two a week.
Can the daylight-saving change cause missed event emails?
It can, through the panel clock. A schedule stored in the panel runs on panel time, and after the March change a clock still on standard time runs every scheduled event one hour, 3600 s, off the wall clock.
The field case that matches this pattern began missing roughly when daylight-saving time started in March. Treat the date as a pointer to the clock, not as a verdict. The test costs one minute: at the next scheduled event time, read the panel clock beside a known-good clock. An exact 3600 s offset names the clock as the fault; an offset under a minute clears it.
For a PLC-triggered event the clock still matters, because the Error tab stamps its entries with panel time. An error stamped 13:00:38 on a panel running an hour behind is 14:00:38 wall time. Add the offset before comparing against your miss list. To fix it at the source, set the panel clock from the PLC so both read the same time. Handle the spring and fall changes with the steps for setting the PLC clock from the operator panel at daylight-saving time.
What does a worked example with numbers look like?
Here is a scenario carried through its numbers: three shift reports a day at 06:00, 14:00 and 22:00, 21 events over 7 days, 19 emails received, 2 missed, and both misses matched by entries in the Error tab.
A packaging line emails one scrap report per shift, triggered by a PLC bit the program latches and unlatches after 5 s. Over one week: 3 events a day × 7 days = 21 events. The inbox holds 19, so 21 − 19 = 2 misses, a rate of 2 ÷ 21 = 0.095, just under 10 percent. The button email sent at 09:12 on both bad days arrived, which clears delivery.
The Error tab shows two communication errors, stamped 14:00:38 and 22:00:12, against triggers at 14:00 and 22:00: offsets of 38 s and 12 s, both inside the 2-minute window. The failed branch is the PLC-to-panel link. Address the cable, the switch port or the PLC's scan load, and leave the mail settings, the pulse width and the schedule untouched. Had the tab been clean while the panel showed the bit change, the next stop would be the event condition and its reset. Had these been scheduled events with the panel clock 3600 s behind, the clock would have been the repair.
What is the fix once you know which branch failed?
Fix the branch that failed. A link fault gets the cable, the switch port or the PLC load addressed. A condition fault gets the event condition and its reset rewritten. A clock fault gets the panel time corrected, then you retest.
Run one controlled test around the repair:
- Record the panel, the event type, the expected trigger time, the bit state at the PLC, the panel clock reading and the current Error tab entries.
- Force one real event cycle and watch the bit at both ends, at the PLC and at the panel.
- Repair the single branch that failed.
- Force the event again and confirm the email lands, then let real cycles run.
Record every original setting before the first change, and change one thing at a time. Two changes at once leave you unable to say which one mattered.
Recommendation: Hold any new trigger bit at 500 ms minimum and stop there; the field case held 5 s and still missed, so extra width buys nothing. If the Error tab carries a communication error within about 2 minutes of a miss, put your hours into the PLC-to-panel link and touch nothing in the mail setup. If the tab is clean and the panel shows the bit change, rewrite the event's condition and reset. If the events run on a schedule and the panel clock sits 3600 s off the wall clock after a daylight-saving change, correct the clock first.
When the panel's event path keeps missing after those repairs, take the panel out of the chain: sending the mail from the PLC with its own mail function makes the controller both the trigger and the sender, and the panel becomes a viewer.
When should you stop adjusting and escalate?
Stop when one controlled test shows the panel receiving the bit, the clock reading true and the Error tab clean while the email still misses. At that point you have cleared every branch you can see and the vendor needs the record.
Hand over the timestamps, the clock reading and the Error tab entries from every miss, plus the event type and the pulse width. Do not keep nudging clocks and schedules in the meantime; each unrecorded adjustment erases the evidence that would have named the fault. Keep the event log running until several clean weeks pass, because this fault hides for weeks at a time.
Questions
How long should you keep logging after a change?
Long enough to cross the fault's hiding period. The pattern behind this article ran clean for weeks, then missed events for a day or two, so a quiet weekend settles nothing. Keep a one-line record of every event time, the panel clock reading and any Error tab entry until several weeks pass with no miss, then stop.
What should you hand over when the event still misses?
Send the panel model and software version, the event type (PLC-triggered or scheduled), the tag address it watches, the exact timestamps of every miss, the panel clock reading at those times, and a copy of the Error tab entries. Add the trigger's pulse width and how often the event runs. That package answers the first round of questions support will ask.
Can operators keep using the manual send button during the fix?
Yes, and it keeps reporting intact while you work. The button reaches the same recipients through the same server, so it is a valid path for urgent notices. Treat it as a stopgap: it sends when a person presses it, so it covers nothing that happens unattended, such as an overnight alarm transition.
Is updating the panel software the fix?
Update as a planned change, not as a first move. One installation ran a mix of current and older programming software across its panels and the misses did not follow the version split, so a blanket re-download spends downtime without a suspect. Update when the vendor names the version in writing, and keep the event log running across the change.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.