When one SCADA email message accepts only five tags, split a 22-tag report into five messages: four with five tags and one with the remaining two. Confirm the five-tag count in your own message editor first, number the five parts so the on-call operator can see when one is missing, and test one full reporting cycle before you rely on the set.
When one SCADA email message accepts only five tags, a 22-tag report still reaches the operator on call. It goes out as five messages: four carrying five tags each and one carrying the last two. The five-tag count is what the message editor allowed on the installation this split was built for, so the first job is to confirm where your own editor stops. The rest is arithmetic and testing. Assign every tag to exactly one message, number the parts so the operator can see when the set is incomplete, and watch one full reporting cycle before you trust the arrangement. This page walks through that check, the split, and the test, for a periodic system update sent to an operator on call over an 8-hour shift.
Why does one email message stop at five tags?
The message editor on the installation this fix came from accepted at most 5 tags per email. A 22-tag report could not go out as one message however the schedule, subject or recipients were set. That count is an observed limit of the installed software, so your editor is the authority: repeat the check in the next section before you build anything. Everything else about the message is untouched. The trigger works as before, so the report can still fire from the scheduler or from a Boolean event, the setup in PLC email alerts from a Boolean event, and recipients and subject carry over unchanged. Only the tag list per message shrinks.
What do you need before you split a tag report into several emails?
You need four things: the written list of all 22 tags, the settings of the message you are replacing, the product name and version of the installed software, and a test mailbox you can open yourself.
- The tag inventory: all 22 tag names with their addresses and units, in one list you can tick off.
- The current message: its schedule, recipients and subject, so the five replacements inherit them on purpose.
- The software identity: product name and version from the about screen, ready for a support question later.
- The test mailbox: one you control, so setup does not wait on the operator's inbox.
How do you confirm the five-tag limit in the message editor?
Open the periodic email message, add tags one at a time, and write down the count where the editor refuses the next one. On the installation this fix came from, that point sat at 5 tags.
- Create the periodic message, or open the existing one, in the message editor.
- Add tags one at a time and record the count at which the editor refuses the next tag.
- Send that message once to the test mailbox and confirm it arrives with live values.
- Read the product name and version from the about screen and write them down before you change any configuration.
If your editor accepts more than five, use your number everywhere the arithmetic below uses five. The method is unchanged; only the divisor moves.
How many emails do 22 tags need at five tags each?
Five emails carry 22 tags at five tags per message. Divide: 22 divided by 5 tags per email is 4 with a remainder of 2, so four messages fill up at five tags and a fifth message carries the last 2. The rule is ceiling division: divide the tag count by the tags per message and round up. At 25 tags the answer stays 5 emails; at 26 tags it becomes 6 emails. One constraint sits outside your software: mail providers throttle senders that push many messages in rapid succession, because burst sending matches spam patterns. Five short reports on a periodic cycle is low volume, but send the first manual tests about 60 seconds apart so a strict mail server never sees a burst.
Example: splitting a 22-tag report into five emails
A packaging line reports 22 tags to the operator on call each 8-hour shift. The tags are 10 oven temperatures, 6 conveyor statuses, 4 tank levels and 2 line stop counters, split into five messages of 5, 5, 5, 5 and 2 tags. Group the tags by equipment, so one lost part still leaves the operator a readable subset of the line.
| Message | Tags carried | Count | Running total |
|---|---|---|---|
| 1 of 5 | Oven temperatures T1 to T5 | 5 | 5 |
| 2 of 5 | Oven temperatures T6 to T10 | 5 | 10 |
| 3 of 5 | Conveyor C1 to C3, tank levels L1 to L2 | 5 | 15 |
| 4 of 5 | Conveyor C4 to C6, tank levels L3 to L4 | 5 | 20 |
| 5 of 5 | Line stop counters S1 and S2 | 2 | 22 |
Check the arithmetic: 5 + 5 + 5 + 5 + 2 = 22, and no message holds more than the 5 tags the editor allows. If part 3 never arrives, the operator still sees oven temperatures T1 to T10, conveyor C4 to C6, tank levels L3 to L4 and both line stop counters: 17 of the 22 values, grouped by equipment.
How do you configure and test the five messages?
Build each message from its group, put the part number in the subject, copy the schedule and recipients onto all five, and send one test of every message before you enable the set.
- Duplicate the existing message four times, or create five new messages, whichever the editor supports.
- Paste each group's tags into its message and tick every tag off the 22-item inventory as it lands; each tag goes into exactly one message.
- Label the subject or first body line with the part number, System update 1 of 5 through System update 5 of 5, so the operator can see when a part is missing.
- Apply the schedule and recipients to all five, then open each message again and confirm it kept its own schedule; duplication does not always carry settings across cleanly.
- Send each message once to the test mailbox, about 60 seconds apart, and check the values in each against the source system at send time.
- Tell the operator the update now arrives in five numbered parts, then enable the set and watch one full cycle.
How do you check that all 22 tag values reached the operator?
Mark the received emails against the 22-item inventory across one full reporting cycle. Every tag present once, no tag duplicated by accident, values matching the source system at send time. A part that never arrives is a delivery problem, not a grouping problem: test that message alone and walk the send path step by step, the same isolation that clears dropped PLC-triggered messages on a serial HMI panel. Values that disagree slightly between parts were sampled seconds apart. The five messages share one schedule but not one instant, so treat the set as a five-part report. If the operator needs one synchronized snapshot for a decision, verify against the source values at send time, as in step 5 above.
When should you stop splitting and ask for a supported fix?
Keep the five-part split while the report stays at or under 25 tags. Add a sixth message when the list reaches 26 tags, and take the limit question to the vendor once the report needs more than six parts. The split solves delivery; it leaves the per-message cap where it was. Raising that cap is a vendor question, and the four things to bring are the product name, the version, the count where the editor stops, and the report the operator needs. Skip undocumented edits to the email configuration: an apparent cap can be a constraint of the application, and untested changes to the send path can silence delivery without any error.
Recommendation: Split the 22 tags into five emails of 5, 5, 5, 5 and 2 tags, grouped by equipment, numbered 1 of 5 through 5 of 5, each verified with one test send, whenever your message editor stops accepting tags at five. Grow the set to a sixth email when the list reaches 26 tags, and bring the product name and version to the vendor when the report outgrows six parts.
Questions
Can the same tag go into two messages on purpose?
Yes, and it is a useful check. Repeating one stable tag, such as a line status bit, in the first and last message tells the operator at a glance that the whole set arrived. The tag counts against the five-tag capacity in both messages, so each of those messages then carries one fewer unique tag. Record the duplication in the inventory so the completeness check still expects 22 unique values.
Does the five-tag cap also apply to alarm-triggered emails?
Assume yes until the editor says otherwise. The count you measured is a property of the message, so build or open an event-triggered message, add tags one at a time, and note where the editor stops. The trigger and the tag list are separate settings: the trigger decides when the email goes out, the tag list decides what it carries, and the same five-part grouping fixes both paths.
Is there a way to send all 22 values in one message?
Possibly, through a scheduled report. Many SCADA packages can generate a report file, such as a PDF or spreadsheet, on a schedule and email it as an attachment, which puts all 22 values in one document and leaves the five-tag count where it belongs, in the tag list you add to a message body. Whether your installation has that reporting module is a vendor question; ask it together with the product name and version.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.