A fixed 16-entry HMI alarm handler fits a machine with 16 or fewer distinct alarm conditions. Count the conditions first. A project carrying more, such as a 63-condition bottling line, needs ladder-based alarm logic or a platform with a bigger documented limit; the built-in handler is a small-machine option.
A built-in alarm handler on a small touch panel carries a fixed 16 alarm entries. That number settles the choice before anything else: count the distinct alarm conditions on your machine. Sixteen or fewer, and the handler fits and saves you writing ladder for every condition. More than 16, as on a line that lists over 60 alarm conditions, and the set overflows the handler; the alarm logic belongs in ladder or on a platform with a bigger documented limit. This article compares the two approaches, works the arithmetic on a 63-condition list, and ends with the decision for each case.
What the 16-entry limit decides
The handler is a fixed-size object: 16 entries, one alarm condition per entry. The fit test is a count, not a judgment call.
Count every condition the operator must see as its own alarm:
- Each discrete switch that raises an alarm: guard doors, E-stops, jam sensors, a low-air-pressure switch.
- Each threshold that fires on its own. The high limit and the high-high limit on one tank level are two conditions, because they trigger at different values and call for different responses.
Identical devices do not merge on their own. Six drive overtemperature switches are six entries unless you deliberately group them behind one shared message.
The second number is allocation. The handler occupies whatever space its release gives it in panel data memory. A configurable start address and word count in the data registers, V-memory on platforms that use that register naming, is the feature to look for in your software release notes. Where the notes print no allocation setting, plan around the fixed one. The 16 figure is the release's documented capacity, so the fit is a paper comparison: list the conditions, count them, done.
Built-in handler or ladder logic compared
Both routes put alarms on the panel screen. They differ in who sets the size and the behavior.
| Built-in alarm handler | Ladder-based alarm logic | |
|---|---|---|
| Alarm capacity | Fixed at 16 entries | Set by the rungs and data registers you write |
| Setup | Configure entries in the panel software | A rung or two per condition, plus latch, acknowledge and message registers |
| Latching and acknowledgment | As the release documents | You write it; every condition keeps its own bit |
| Data memory | Fixed allocation, no documented start-address setting | You choose and document the register range |
| Detail in grouped entries | One message per entry | A grouped entry can carry a fault code that names the device |
| Right fit | 16 or fewer distinct conditions | Any count, including a 63-condition line |
Where the built-in handler wins
Small machines fit with room to spare. A standalone semiautomatic packager, a bench press or a small mixer commonly lists 8 to 14 conditions: E-stop pressed, guard open, low air pressure, motor overload, part present, a couple of analog limits. Configure the handler, fill 14 of the 16 entries, and you skip writing and maintaining a rung set for every condition. Size the alarm text for the operator standing about 3 ft from the panel: at the 30 ft of viewing distance per inch of capital height figure (FHWA), that is 0.1 in capitals, large enough on any 10-inch or larger panel. The trade is behavior: the machine's alarms behave as the release documents, the same as every other machine running that release. For a small machine that is usually the right trade, because the documented behavior covers the standard cases: show the entry, mark it active, clear it when the condition clears.
Where ladder-based alarm logic wins
Any list above 16 conditions. Ladder writes what the handler fixes:
- Every condition keeps its own fault bit, so a grouped summary can still name the device through a code register. The message and bit-width limits of multi-state indicators apply when one display object stands for several causes.
- Acknowledgment is yours to define. Mapping an alarm acknowledgment to a PLC bit shows the standard pattern and keeps the acknowledge state in the controller, not in the panel.
- The same rungs drive more than the screen: a stack light, an andon tower or a line-stop output can follow the same bits the panel reads, with alarm bits updated each PLC scan, typically every 10 to 100 ms on a small machine.
A hybrid works on mid-size machines: keep the built-in handler for the 16 entries the operator answers most and run the rest in ladder under the same acknowledgment rules. Once conditions outnumber entries, something has to carry the difference, and ladder is the part you control.
Example: counting a bottling line's 63 alarms
Scenario: you take over a bottling line whose alarm list holds 63 distinct conditions, 41 discrete and 22 analog thresholds, shown on a 15-inch panel read by an operator from about 3 ft (0.9 m). Grouping conditions by shared message and response is the rationalization step that published alarm-management guidance, such as the ISA guide, walks through. Here is the arithmetic:
- 18 door, guard and E-stop switches become 2 entries, one for guards and one for E-stops: 63 - 18 + 2 = 47 entries.
- 8 drive overtemperature limits become 1 entry: 47 - 8 + 1 = 40 entries.
- 6 jam sensors along the conveyor become 1 entry: 40 - 6 + 1 = 35 entries.
Grouping took the list from 63 alarm conditions to 35 entries, and 35 is 19 entries past the handler's 16. The handler can carry the most urgent 16; the remaining 19 need ladder logic behind them, or the whole set moves to ladder for one consistent behavior. With the grouped entries the operator clears a jam from the summary and, because each sensor keeps its own fault bit, the panel can point to the right one of the 6 stations in under 30 s instead of a walk down a 60 ft conveyor.
One safety note: a grouped E-stop entry that hides which station tripped turns a reset into a walk down the line. Keep the per-station bit in the ladder even when the panel shows one summary entry, and give each safety interlock an indication the operator can tell apart from the next.
What the documented limits look like elsewhere
16 sits at the small end of a range vendors publish explicitly:
- One panel vendor's published alarm limits allow up to 4,000 alarms in a single controller, with no more than 1,000 of them instruction-based alarms.
- One SCADA server documents 40,000 monitored tags for alarms per server, of which up to 10,000 can be analog tags.
The operator-facing objects carry their own numbers, and history depth is one of them. When a panel keeps only the last 64 events, saving the alarm history beyond a 64-entry limit to USB is the documented way to keep more. Capacity is a printed number, not a guess: read the limit list for your exact panel software and version, then compare it with your counted conditions.
The decision
Count first; the count decides everything after it.
- 16 or fewer distinct conditions, each fine as its own entry: use the built-in handler, configure it, and test each entry against its device.
- More than 16: the handler stops at its 16 entries. Move the alarm logic to ladder in full, or keep the handler as a top-16 summary and run the overflow in ladder under the same acknowledgment rules.
- You need a configurable memory range, custom acknowledgment or per-device detail inside grouped entries: ladder, because those behaviors are yours to write there.
- A plant-wide alarm requirement or a list in the hundreds: specify a platform whose published limits cover the count, in the 4,000-per-controller or 40,000-tag class, and make the condition count the first line of the specification.
- Alarms that must be readable from across the floor, 20 ft or more away: that is an andon question. Where a small screen fits on an andon board covers the screen choice, and a separate signage display playing your own content, listed under shop-floor screens, can carry the same summary as content rather than as an HMI connection.
Recommendation: Count the distinct alarm conditions before you configure or write anything. At 16 or fewer, use the built-in handler and spend the engineering time elsewhere. Above 16, write the alarm logic in ladder with one fault bit per condition and treat the 16-entry handler as a summary object at most. On a list of 60-plus conditions, specify a platform with a documented alarm capacity that covers the whole list.
Questions
Can I set the handler's V-memory start address and word count to raise the limit?
The handler described here documents a fixed capacity of 16 entries and no allocation setting. Look for a configurable start address and word count in the release notes of your exact panel software version; a later release that adds one will print it there. Until your notes show it, do not plan the project around a configurable range. Carry the alarm set in ladder instead, where you choose the data registers and document them yourself.
Why does my alarm history object show fewer entries than my alarm list?
Display capacity is a separate limit from handler capacity. On one platform, the history object that shows and updates logged alarms is limited to 100 entries on screen, while the mode that lists stored alarms can display 1,000. The handler's 16 entries decide what can be in alarm at once; the history object decides how many past events you can scroll through. Check both numbers when you size a project.
What is the difference between an alarm limit and an alarm handler?
An alarm limit is a setpoint that makes a condition fire: the high limit, the low limit or a band on an analog value, configured per tag. The alarm handler is the object that collects the conditions those limits produce, shows them to the operator and tracks acknowledgment. A machine can carry more configured limits than the handler has entries; what the handler cannot do is show more conditions than its entry count as distinct alarms.
Should safety alarms be grouped to fit the handler?
Give each safety condition its own bit in the PLC and its own indication, even when the panel shows a grouped summary. If four E-stops share one entry, an operator restarting the line cannot tell which station tripped without walking the machine. Keep the per-station bit in the ladder so the cause is one register read away, and group only conditions that share a message without hiding the cause.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.