Turn the Boolean’s rising edge into a pending event, then submit it through a supported, authenticated mail client or gateway. Commission event capture and mail delivery separately, define retries and restart behavior, and distinguish server acceptance from inbox delivery.
A PLC Boolean does not send mail by itself. It must create an event request, and a supported mail client or notification gateway must carry that request to an authenticated mail service. For PLC email alerts, separate those two jobs: first prove that one activation creates one request, then prove that the mail path works. Keep email outside the machine’s safety functions and time-critical control logic.
One event is different from one delivered email
A Boolean can remain TRUE for thousands of PLC scans. If the program requests mail whenever that level is TRUE, it can generate repeated messages for the same condition.
Use a rising-edge detector, or equivalent event logic, to recognize the transition from FALSE to TRUE. Capture that transition as a pending notification rather than passing a one-scan pulse to a client that might already be busy.
There are three separate outcomes to track:
- Event captured: the application recorded the condition becoming active.
- Message accepted: the mail server accepted the submitted message for processing.
- Message delivered: the receiving mail system delivered it, possibly to quarantine rather than the inbox.
These outcomes are not interchangeable. In particular, ordinary SMTP submission alone cannot establish that exactly one message was delivered. If the server accepts a message but the connection breaks before the client receives confirmation, a retry can produce a duplicate. A stable event identifier helps identify repeated notifications for the same occurrence.
Choose one supported mail path
The PLC does not have to handle the internet-facing mail connection itself. Choose the transport that your installed runtime supports and your network policy permits.
| Mail path | What it does | What to establish first |
|---|---|---|
| Runtime-supported mail library | The control application submits mail through a documented client interface | Runtime compatibility, supported authentication, TLS support and execution behavior |
| Local notification gateway | The PLC passes an event to a separate service that handles mail | A supported event interface, access controls, queue behavior and diagnostic records |
| Site-approved mail relay | A compatible client submits to a controlled relay that handles onward delivery | Approved submission settings, sender permissions and restrictions on relay access |
Obtain software and documentation through the manufacturer or its authorized distribution channels. Package availability alone does not establish compatibility with the installed runtime or the mail service’s current authentication requirements.
Start with one path. Adding several transport methods before the first test succeeds makes it harder to determine which component owns a failure. Do not use an unrestricted relay as a workaround for authentication problems.
Match the mail service settings
Get the complete submission configuration from the approved mail service configuration. Do not infer it from an account name or from settings used on a different device.
Confirm these items before connecting the event logic:
- Server hostname and connection port: the sending device must resolve the hostname and reach the configured service.
- TLS mode: implicit TLS and STARTTLS use different connection sequences. The client must support the required mode.
- Authentication method: the client must support the method permitted for the sending account or service identity.
- Sender permission: successful authentication does not necessarily authorize every sender address.
- Recipient policy: the service may restrict destinations or require additional approval for external delivery.
- Clock and certificate trust: certificate validation depends on appropriate time settings and trusted certificate information.
If the client cannot meet the required authentication or TLS policy, choose a compatible supported client or approved gateway. Do not disable certificate checks or weaken the mail service’s security to make an older client connect.
Use a dedicated sending identity with only the permissions needed. Store credentials through the platform’s documented secret-handling mechanism where available. Keep passwords, tokens and complete authentication exchanges out of source exports, screenshots and diagnostic logs.
Give the event a small state machine
An edge detector identifies an occurrence. A state machine manages what happens after that occurrence.
A useful arrangement has ready, pending, submitting, retry-wait and completed or failed states. The names matter less than having clear transitions and observable results.
When the condition rises, capture the event identifier, event time and relevant machine context. Keep that snapshot stable while the message is pending. Otherwise, a delayed notification may contain a later machine state rather than the state that caused it.
The pending state waits until the mail client can accept a request. The submitting state watches the client’s documented busy, completion and error outputs. It also applies a timeout so that an unresolved operation cannot hold the notification logic indefinitely.
After a known failure, enter a timed retry state or a terminal failure state according to the fault type. Do not retry every PLC scan. Limit attempts, space them apart and expose the final failure locally. Authentication rejection usually needs configuration correction, not rapid repetition.
Re-arm according to an explicit rule. Commonly, the condition must return to FALSE before another activation can create a new event. If a second event occurs while the first is pending, define whether it enters a bounded queue, is combined with an existing event or raises an overflow indication. Silent loss is not a useful default.
Decide what a restart means
A condition that is already TRUE at startup needs a deliberate policy. Depending on initialization, an edge detector may treat it as a new activation or may wait for a later FALSE-to-TRUE transition.
Decide whether startup should report an existing condition. Also decide what should happen to notifications that were pending before power was lost.
Retaining an event identifier and submission state can reduce accidental resends, but it does not remove SMTP’s uncertain-outcome case. A retained record might say that submission started without proving whether the server accepted the message.
For important notifications, use a documented persistent queue or gateway with delivery records. Define queue capacity, retention behavior and overflow handling. Keep recovery behavior separate from the machine’s own alarm acknowledgement and reset logic.
Commission the path in separate tests
First prove mail submission without a machine event. Use the selected client’s documented test function, or a controlled application request, to send a clearly marked test notification to an approved destination.
Record the submission result and confirm receipt. A successful test from a laptop does not prove that the PLC or gateway has the same routing, name resolution, certificate trust or firewall permissions.
Next, observe the event logic with mail submission disabled. One controlled FALSE-to-TRUE transition should create one pending event. Holding the Boolean TRUE should not create more. Resetting it and activating it again should create the next event according to the re-arm rule.
Then connect the two parts and check:
- One controlled activation produces one client submission during a successful attempt.
- A sustained TRUE condition does not repeatedly submit messages.
- A busy client does not lose a newly captured request.
- A simulated transport failure produces the intended timeout and retry state.
- A restart follows the chosen startup policy.
- Queue overflow and final delivery failure produce a visible diagnostic indication.
Run failure tests through a controlled test configuration, not by disturbing production control traffic. Confirm that notification delays do not block the control task. Use the client’s documented asynchronous interface or a separate gateway where appropriate.
Trace missing mail hop by hop
Log state changes and results, not every PLC scan. Useful records include the event identifier, request time, attempt count, client result, error category and server response where available. Exclude secrets and unnecessary message content.
| Observation | Boundary to inspect | Next check |
|---|---|---|
| No pending event appears | Boolean capture | Edge detection, initialization, filtering and re-arm conditions |
| Event is pending but no submission starts | Application-to-client handoff | Busy state, request handshake, queue state and client availability |
| Hostname cannot be resolved | Name resolution | Configured DNS service and the exact mail hostname |
| Connection times out or is refused | Network transport | Route, permitted destination, configured port and service availability |
| TLS negotiation fails | Secure session | Required TLS mode, clock, trust information and client compatibility |
| Authentication or sender is rejected | Submission policy | Supported authentication, account permissions and allowed sender identity |
| Server accepts the message but it is not visible | Downstream delivery | Recipient accuracy, quarantine, filtering and delivery records |
| Multiple messages describe one occurrence | Event or retry handling | Level-triggered requests, restart behavior and uncertain submission outcomes |
A successful ping does not establish that the mail submission service is reachable. Likewise, an authentication success does not establish that the server accepted the message. Preserve the distinction between each boundary when recording results.
Keep local alarm handling independent
Email is a secondary notification channel. Network outages, service policy changes and delivery filtering can delay or prevent it. It must not replace a safety function, an interlock or a required local alarm indication.
Keep the active condition and its acknowledgement in the control system. Accepting or reading an email should not automatically clear the machine condition.
For a separate local view, distinguish a factory status display from an operator HMI before deciding where to show information and where to accept control input. The email queue should report events, not become the authoritative record of current machine state.
Questions
Why does a PLC Boolean send repeated emails?
A sustained TRUE condition may request mail on every PLC scan. Detect the FALSE-to-TRUE transition, capture it as a pending event and prevent overlapping submissions. Define when the event can re-arm, and check whether retries or restart behavior are creating additional submissions.
Can PLC email alerts reliably deliver exactly one message per event?
Not reliably through ordinary SMTP submission alone. A server can accept a message before the connection fails, leaving the client uncertain about the result. Retrying may create a duplicate. Stable event identifiers and documented queue behavior help manage this uncertainty.
Why is an email missing when the mail client reports success?
Confirm what the client means by success. Server acceptance means the message entered the mail service for processing, not that it reached the inbox. Check the recipient, delivery records, quarantine and filtering before changing PLC trigger logic.
Should email replace a local machine alarm?
No. Email depends on systems outside the machine’s immediate control and may be delayed or lost. Keep safety functions, interlocks and required local alarm handling independent. Use email only as a secondary notification channel with visible diagnostics for submission failures.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.