An HMI email address can live in an ASCII string tag instead of a static address book field. Set the tag up once in the project, write the new address from a text entry screen or controller logic before the alert fires, and the customer's address change needs no project edit afterwards. Size the string tag for the longest address the plant will use.
An HMI alert email does not have to be a project edit waiting to happen. The panel's Address Book accepts an ASCII string tag in its Name and Mail Address fields, so the address behind an email event can change at runtime as a plain value. Set the tagged entry up once in the programming software. Give the operator or the controller logic a way to write the string, and bind every email event to that entry by name. After that, a customer who changes their email address changes a value on the touchscreen. You never open the project for it. This page walks through the setup, works the tag sizing with real lengths, and ends with the checks to run before you hand the panel over.
Why the address book takes a tag
The Address Book is the panel's list of mail recipients. The Event Manager picks recipients from it whenever a Mail action fires. Each entry carries a Name field and a Mail Address field. The name is how the Event Manager selects the recipient, so an event stays bound to its entry even when the address behind it changes.
Both fields accept an ASCII string tag. The panel's help says only ASCII string tags are valid in them, and its own example of a runtime change is a Text Entry object writing the new address while the project runs. That gives you a fixed binding with a moving address: the event always fires to the same entry, and the string tag carries whichever address the plant wants today.
One boundary to check before you design around this: if your panel's address book help does not print a tag option in these fields, the tag route is not available on it and the address stays a project value. Where the tag option exists, the panel still offers no runtime page for adding records. Plan one entry per logical destination and let each entry's tag hold the current value.
| Field | What you enter | What moves at runtime |
|---|---|---|
| Name | Fixed text, or an ASCII string tag | The label the Event Manager selects by |
| Mail Address | Fixed text, or an ASCII string tag | The address the mail goes to |
| Event Manager binding | The entry's name | Nothing; it stays fixed |
What you need
- One session in the panel's programming software. The tagged entry is project configuration; everything after that session is a value.
- An ASCII string tag for the address. Add a second tag only if the recipient's name must change with it.
- A write path for the string: a Text Entry object on a maintenance screen, or controller logic that writes the tag.
- A mail server the panel is allowed to send through. If alert mail never leaves the building at all, the usual culprit is the SMTP server setup, not the address book.
- A list of every email event that should follow an address change, so none of them stays bound to a static entry.
Set up the tagged entry and bind the events
- In the project's Address Book, create one entry per logical destination and type a clear name for each, such as Maintenance alerts. The name is permanent; the Event Manager finds the entry by it.
- In the Mail Address field, enter the ASCII string tag in place of a typed address. Tag the Name field too only when the displayed label must change with the address.
- Bind every Mail action in the Event Manager to the tagged entry. A Mail action needs at least one Address Book assignment. An event left on an old static entry keeps mailing the old address no matter what the tag holds.
- Add the write path. A Text Entry object on a maintenance screen is the help file's own example, and it needs no controller code. If the controller writes the string instead, remember that text occupies registers: the way an ASCII string packs into V-memory words sets how many words one address needs.
- Order the writes. The email event fires on its trigger, the same way a screen change fires on a PLC alarm bit, so the tag must hold the complete new address before that trigger turns on. Block the event while the tag is blank or mid-write, and guard the value in logic the way you would clamp numeric entry limits in ladder logic.
- Settle who owns the tag. If two stations can write the address tag, decide who wins the write before commissioning, and leave maintenance one screen that shows the current value.
If any of these emails carries an alarm a person answers, keep a horn or stack light on the same trigger. Mail is a convenience path; the local call to action should never ride on it.
Example: sizing the address tag for a plant that changes mail domains
The case is the one this setup exists for: a customer changes email providers and the alert address moves with them. The lengths below are a typical plant pair, the tag length is the value commissioned at setup, and the caps come from the email standards.
Inputs:
- Old address: local part 6 characters at a 16-character domain, 23 characters in total.
- New address: local part 11 characters at a 17-character domain, 29 characters in total.
- String tag as commissioned: 24 characters.
- Email standards caps: 64 characters before the @, 255 after it.
The rule in words: the string tag must hold every character of the address, @ and dots included. An address longer than the tag cannot be stored complete. The event then mails a partial value or nothing, so size the tag once for the longest address the plant will accept.
The arithmetic: count the new address. The local part maintenance is 11 characters, the @ is 1, plantmail is 9, the dot is 1, example is 7: 11 + 1 + 9 + 1 + 7 = 29 characters. The tag commissioned at 24 characters is 5 characters short. The address itself is legal, because the standards cap the part before the @ at 64 characters and the domain at 255, and 29 sits far inside both.
The result: resize the tag to 32 characters, the next round figure above 29, in one final project edit. Both addresses now fit, the 23-character old one with 9 characters spare and the 29-character new one with 3.
The decision: the no-project-edit promise holds while the address stays at or under the tag length. With a 32-character tag, any address of 32 characters or fewer loads from the touchscreen. Anything longer is one more project edit. The caps of 64 and 255 describe the worst case anyone could hand you, about 320 characters in total, so agree the plant's maximum at handover and size the tag to it.
Check the route end to end
- Watch the tag while the new address is entered and confirm the complete address is in it before anything triggers.
- Fire the event by its production path and confirm the message lands at the new address.
- Enter a second controlled test address, fire again, confirm arrival, then load the real address.
- If the tag shows the new value and mail still lands on the old one, the event is bound to a different entry with a static address; fix the binding by name.
- If nothing arrives anywhere, the address book is innocent; go back to the mail server settings and the network path.
- Record the tag name, the entry name, the tested addresses and the agreed maximum length on the handover sheet. Questions during commissioning can go through our contact page.
An email reaches one inbox. When the line also needs a board the whole shift can read, that is a separate job, and the shop-floor alert boards page covers the screen side of it.
Recommendation
Recommendation: Standardize each customer program on one tagged Address Book entry per logical destination: a fixed Name, an ASCII string tag in the Mail Address field, a Text Entry object on a maintenance screen, and a tag sized above the longest address agreed at handover. Choose this setup whenever the customer may change the alert address after commissioning. Keep typed static addresses only for destinations that will genuinely never move, such as your own service inbox, and say so on the handover sheet so the next technician knows which is which.
Questions
Can the operator add a new recipient to the address book from the touchscreen?
No. The touchscreen can change the value of a tagged entry, but nothing documented lets a runtime user add records to the Address Book. Plan one entry per logical destination, such as one for maintenance alerts and one for the plant manager, and let each entry's string tag carry the current address. If a customer insists on a self-grown contact list, confirm that feature in the panel's own help before promising it.
Where do the mail server settings live, since they are not in the address book entry?
The Address Book entry decides who receives the mail; the project's mail setup decides how it goes out, and that is where the SMTP server and its login live. When one changed address alone never receives mail, check that address character by character. When no address receives mail at all, the fault sits in the mail setup or the network path.
How long an address should the string tag be sized for?
Email standards allow up to 64 characters before the @ and 255 after it, a theoretical worst case of about 320 characters, but plant alert addresses rarely pass 30. Agree a maximum with the customer, size the tag above it, and record the limit on the handover sheet. The 29-character address in this article's example fits a 32-character tag.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.