HMI alarm history clear button not working: check active alarms first

Why won't the clear button empty my HMI alarm history?

The entries that refuse to go belong to alarms whose tags are still on in the controller. An active alarm keeps its place on screen until its condition clears, no matter how many times you press.

Alarm systems draw one line everywhere: a summary or active alarm is a condition that exists right now, and a historical alarm is a stored record of one that has ended. The clear command's job is the records. The panel's own help documentation for its alarm list object states that the Clear All button clears all the alarm data held in the panel. So when a press wipes the stored list and the same alarm still stands on screen, read that survivor as a current condition. The clear command's documented scope is the stored list; the alarm bits live in the controller and follow the process until the condition ends.

Which symptom points to the command path and which to an active alarm?

Read the screen within 5 seconds of one press: nothing at all changed points to the command path or the access level, old entries gone but the same survivors left points to live alarms, and old entries gone with new ones appearing is ordinary logging of fresh events.

Match your screen to one of these four:

• Nothing changed at all. The press never reached the panel. Either the access level was rejected, or the clear-history tag never moved from 0 to 1 while you pressed.
• The same entries survive every press. Those entries belong to alarms whose tags are still on; the clear emptied the stored records and the live alarms kept their places.
• Old entries wipe, new ones appear. The clear worked and the process raised fresh events. Resolve the new ones like any alarm, then clear again when the procedure allows.
• It cleared once and refuses a second time. The function tag latched at 1, so the next press adds no off-to-on transition, and the panel clears on transitions.

The first and last are states you can watch with the project's own diagnostics; the sections below give the checks for each.

How does the clear-history command reach the panel?

The command is a tag: the panel software publishes a clear-history function, you bind a tag to it, and each off-to-on transition of that tag wipes the history stored in the panel. The controller has to move the bit from 0 to 1 while you press.

Two paths reach the same stored list. A button on the panel screen, labelled Clear All on most alarm list objects, clears the data directly when an authorized operator presses it. The controller-driven function does the same job from the ladder, which is how plants let a script, a key switch or a maintenance screen do the clearing.

Check three things on this path:

1. Credentials. The access level configured on the control is checked at the press, so test with what an authorized operator normally uses.
2. The binding. The tag is bound in the panel software's PLC-to-panel function menu. Confirm the tag bound there is the one your button or rung drives, and watch it in the project's tag monitor or the ladder online while you press. A bit that sits at 1, or never leaves 0, explains a button that does nothing.
3. Pulse length. A small controller typically scans its full logic in 1 to 10 ms, so hold the tag on for at least 100 ms, ten scans or more even on the slowest small controller.

A function that fires on a bit transition is the same mechanism as any PLC flag driving an HMI event, and it carries the same trap: if the bit never returns to 0, the event never re-arms. PLC flag triggers an HMI event once: check the reset path works through that reset path rung by rung.

What do I check before pressing clear the first time?

Four boxes to tick before the first press: your access level is the authorized one, the clear-history tag moves from 0 to 1 under your press, entries the procedure must keep are recorded, and you know which alarms are active so the result reads cleanly.

• The records. If maintenance must keep entries, export or note date, time, tag and message for each one first. The clear empties the stored list, and the panel gives nothing back.
• The archive. The same archive-first step that applies to clearing HMI USB log storage from the panel applies here: copy what matters, then wipe.
• The chronology. Skip the clear while an investigation depends on the history's order of events; the list is that record.
• The active count. Open the summary and write down the alarms shown, so you can tell survived records from live conditions the moment the screen updates.

How do I find the alarm tags that are still active?

Open the active alarm or summary display, not just the history. It lists the conditions standing right now, and every tag on it must read 0 before a clear can leave the screen empty. Resolve each one through normal operation and watch the bit drop.

Every platform splits alarms the same way, and other systems fail in ways that show the split plainly: one knowledge-base page walks a history list that shows only the active alarms. Active alarms are the conditions that exist now; historical alarms are the stored records of conditions that ended.

Work the summary down to zero:

1. Note each alarm the summary shows.
2. For each, go to the source: the level switch, the drive fault, the guard circuit, whatever condition the logic watches.
3. Resolve it the way the machine's own procedure prescribes, and watch the tag drop to 0.
4. When the summary reads 0 active, the stored history is all that is left.

Never force an alarm bit off to empty the screen. The bit is the controller's statement that a condition exists, and forcing it off hides a live condition from the operator. A tag that is already on at power-up also behaves differently from one that turns on later; HMI alarm active at startup missing from list: gate the bit covers that startup case.

Worked example: what does one still-active alarm do to the clear button?

A palletizer panel holds 3 alarm-history entries, the operator presses Clear All once, 2 entries vanish and 1 stays on screen. The arithmetic to run is 3 entries minus 2 ended alarms, which leaves 1 active alarm the clear was never going to remove.

The survivor is labelled Hopper level low. Follow it:

1. Open the summary: the hopper-level tag reads 1. The level switch is still made because the hopper is still low.
2. Refill the hopper through normal operation. The switch opens and the tag reads 0. The summary now lists 0 active alarms.
3. Press Clear All once. The stored list empties, because the only things left in it were stored records.
4. The press that failed all morning works on the first try, and nothing about the button changed. What changed was the count: 3 entries with 1 active became 0 entries with 0 active.

The timing check rides along. The operator's press holds the clear tag on for 100 ms, and the controller scans in 1 to 10 ms, so the pulse spans 100 scans at the fast end and 10 scans at the slow end. That is comfortably more than the single off-to-on transition the function needs.

How do I prove the clear works after the alarms are resolved?

One fresh event is the proof: with the active count at 0 and the list cleared, raise one known alarm through normal operation, confirm it lists with a current timestamp, return the condition to 0, then press clear once and watch the entry go.

1. Produce the test event from a condition that belongs to normal operation: a guard door opened during changeover, a level you are filling anyway, the stop the line takes between orders. No forced bits, no bypassed interlocks.
2. Confirm the event lists with the current time and its configured message.
3. Clear the condition and watch the tag read 0.
4. Press clear once and confirm the entry disappears.

If the fresh event lists and then wipes while the old entries stay gone, the operator control, the function tag, the stored list and the display all work, end to end. If the line offers no safe test condition, verify from the next real alarm instead: the sequence is identical, and the process sets the timing.

When should I stop pressing clear and escalate?

Stop when every check above passes and the button still does nothing: access accepted, the tag observed moving from 0 to 1 under the press, 0 active alarms, one clear attempted. At that point the fault sits in the project configuration, and more presses only bury the evidence.

Stop changing the project. Collect the four items support will ask for: the screen behavior on each press, the tag states captured at the same moments, the active alarm list, and the binding between your button and the clear function. With those recorded, hand the case to the panel vendor's support line or the integrator who built the project; against the documented behavior of the alarm objects, they can usually name the misconfiguration in one pass.

Recommendation: Bring the active count to 0 before you touch clear. Resolve each alarm through normal operation, confirm every alarm tag reads 0, record or export any entries the procedure must keep, press clear once with an authorized credential, and prove the path with one fresh test event. If the button still does nothing after a verified 0-to-1 transition and 0 active alarms, stop pressing, capture the tag states, and escalate to the panel vendor or the integrator.

Questions