Hide the alarm banner at the bottom of an HMI screen

What the bottom row is

The strip along the bottom edge is the Alarm Banner. While at least one alarm event with Display checked is active, the panel prints that event's alarm text there. The HMI software's help file states the rule directly: check Display to show the alarm text in the banner at the bottom of the screen; clear it and the alarm does not show there.

The banner is one of three surfaces an alarm can occupy. The alarm history keeps a record of each event you send to it. An Alarm List object shows alarms on a screen you design, with its own display settings. Display controls the banner only; the history and the list answer to their own settings.

Symptoms and what each points to

• One line of alarm text appears along the bottom edge each time a condition goes active. That event's Display check box is checked, and clearing it stops the listing for that event.
• Only some alarms list. Display is set per event, so the events that list are the ones still checked.
• An event vanished from the alarm history after an edit. Show in Alarm History was cleared on that event. Re-check it to bring the records back.
• The text still lists after Display was cleared. Either a different event is the one going active, or the panel is still running the previous project. Confirm the edit on the event that actually fires, then transfer the project again.

The fix, event by event

1. Open the project in the HMI programming software and open the alarm event whose text lists. It opens in the Event Edit window.
2. Select the Alarm tab. An event with extra actions shows extra tabs beside it; those hold the actions, and the display control stays on the Alarm tab.
3. Clear the Display check box.
4. Leave Show in Alarm History checked if the record is still wanted. Clear it only when the event should leave the history as well.
5. Save and transfer the project to the panel, so the project that runs is the project you edited.
6. Repeat for every event whose text should stop listing. Editing one event changes nothing on the others.

Step 3 touches display only. The event still goes active, its actions still run, and the panel stops printing its text in the banner.

Example: what the banner takes on a 15 inch panel

Take a 15 inch touch panel in the XGA format common at this screen size, 1024 × 768. That resolution is exactly 4:3, and a 15 inch diagonal at 4:3 divides by the 3-4-5 rule into 9 in tall and 12 in wide. 768 rows over 9 in gives 768 / 9 = about 85 pixels per inch.

Say the alarm text in the project is 30 px tall. One banner row of that text then takes 30 / 85 = about 0.35 in, or 9 mm, of screen height, which is 30 / 768 = 3.9 percent of all 768 rows. On a screen whose bottom row already carries process values or function labels, that 9 mm strip is what the standing banner takes from every graphics screen.

The 30 px is the example input. Read the real text height from your project and rerun the two divisions. The decision they feed: if the bottom row is worth more than a standing text line, clear Display on the events you do not need live, and read those alarms from the history or an Alarm List screen on demand. The row you get back can carry something operators actually read; how to display a PLC counter value where operators can see it covers the placement of one such value.

Test the change

1. Pick a window where the process can take a deliberate alarm, and force the condition the event watches so the event goes active. Do it only with the process in a safe state; a forced alarm looks real to everyone watching the panel.
2. Watch the bottom edge. The event's text should no longer list.
3. Open the alarm history and confirm the event is recorded there.
4. Repeat for each event you edited. If a line still lists, confirm Display is cleared on that event's Alarm tab and transfer the project again.

Keep alarms reachable without the banner

Routine events hidden from the banner still have a home. Put an Alarm List object on a diagnostics or maintenance screen: it shows alarms as a screen, with settings of its own, separate from the per-event banner switch. Operators open that screen when they want the full picture, and the graphics screens keep their bottom rows.

For state at a glance without a text line, an indicator object carries the active condition; show three alarm states with one HMI indicator walks through one object covering three states. The words each event prints in the list and in the history are also set per event; operator text in HMI alarms shows how to write them for the person reading them.

The decision

Recommendation: Clear the Display check box on every alarm event whose text you do not need on screen during normal running, keep Show in Alarm History checked so the records stay complete, and put an Alarm List on a diagnostics screen for the alarms that matter live. Test each edited event with a forced condition before production needs the alarm for real. Clear Show in Alarm History only for events you also want out of the records, and note it in the project so the next person knows the gap in the history is deliberate.

Questions