The cMT-FHDX-820 receives event activity correctly, but the acknowledgement state crosses a category boundary inside the HMI runtime. In EasyBuilder Pro v6.09.02.651, LB 9043 reports that an unacknowledged event exists without limiting that result to Category 0. Events assigned to Categories 250-255 can therefore keep the bit active even when those categories exist only to supply event bar charts.
Where does the event path stop?
Follow the event from its initiating condition into the EasyBuilder Pro event log, then through category assignment and finally into the HMI system tags. Categories affect how records are organized and presented, but they do not create a category selector for the global unacknowledged-event indication.
| Path stage | Observed result | Diagnostic meaning |
|---|---|---|
| Event acquisition | Category 0 and Categories 250-255 reach the event log | The event conditions are reaching the HMI. |
| Category assignment | Category 0 represents alarms; Categories 250-255 supply event bar charts | The records have distinct application purposes. |
| Acknowledgement aggregation |
LB 9043 activates for unacknowledged records from either group |
The global indication is not constrained to Category 0. |
| Operator action | The event display can acknowledge an individual alarm or all alarms | An acknowledge-all command can affect records outside the intended alarm workflow. |
Layer one first when events are missing or intermittent. Here, Categories 250-255 already appear in the event bar charts and influence LB 9043. That observation proves their data path reaches the runtime. The fault boundary is the acknowledgement aggregation behavior, not the physical connection or event trigger.
Which Category 0 approach fits the requirement?
EasyBuilder Pro cannot acknowledge or select unacknowledged alarms by category through LB 9043. The practical choice is between retaining the global bit or building a Category 0 reminder from category-specific status tags.
| Approach | Category scope | Information supplied | Effect on audit workflow |
|---|---|---|---|
LB 9043 |
All participating event categories | At least one unacknowledged event exists | Cannot isolate the reminder to Category 0. |
LB-12400 |
Category 0 | An alarm exists in Category 0 | Can present a Category 0 reminder, but does not itself identify acknowledgement state. |
LW-11500 |
Category 0 | Number of alarms in Category 0 | Adds a count to the reminder, but does not perform acknowledgement. |
| Individual event-display acknowledgement | The alarm selected by the operator | Acknowledges the selected record | Provides a discrete operator action that can be checked in the operation log. |
Use LB-12400 as the Category 0 reminder condition and optionally show LW-11500 as the active alarm count. Direct operators to acknowledge Category 0 alarms individually. Do not use acknowledge-all when Categories 250-255 must remain outside the alarm acknowledgement workflow.
Why does LB 9043 remain active?
LB 9043 answers one global question: whether an unacknowledged event exists. It does not expose a category input or category mask. When a Category 250-255 timing event enters the event log without being acknowledged, that event satisfies the global condition even if every Category 0 alarm has been acknowledged.
This distinction also limits the workaround. LB-12400 indicates that a Category 0 alarm exists, while LW-11500 reports the number of Category 0 alarms. Neither address is identified as a Category 0 unacknowledged count or unacknowledged flag. If an acknowledged alarm remains active, read both tags during a test to determine whether the reminder follows alarm existence or alarm acknowledgement in the project’s configured event behavior.
The category-specific tags solve category isolation for notification. Individual acknowledgement solves operator selection. They do not turn LB 9043 into a filtered system bit.
How should the Category 0 reminder be configured?
- Retain Category 0 for alarm events and Categories 250-255 for the sequence and cycle-time events used by the bar charts.
- Remove
LB 9043from the logic that drives the Category 0-only reminder. It can remain elsewhere if the application still needs a global unacknowledged-event indication. - Drive the Category 0 alarm-present reminder from
LB-12400. - Display
LW-11500when operators need the number of Category 0 alarms in addition to the Boolean reminder. - Make the reminder direct the operator to the event display, where Category 0 alarms are acknowledged individually.
- Avoid connecting the reminder to an acknowledge-all action. The required workflow is record selection followed by individual acknowledgement.
- Keep the operation log enabled for the relevant operator action and signed-in-user workflow already used by the project. The category status tags only drive indication; they do not create an audit entry by themselves.
If the functional requirement is specifically “Category 0 contains an unacknowledged alarm,” rather than “Category 0 contains an alarm,” test the behavior before acceptance. The deciding measurement is the state of LB-12400 and value of LW-11500 after an active Category 0 alarm is acknowledged but before its initiating condition clears.
How is the revised behavior verified?
- Start with no active test alarms and record the baseline values of
LB 9043,LB-12400, andLW-11500. - Trigger one Category 250-255 event used by an event bar chart. Confirm the chart receives the event. The Category 0 reminder driven by
LB-12400must remain inactive, regardless of the state ofLB 9043. - Trigger one Category 0 alarm. Confirm
LB-12400indicates that the alarm exists andLW-11500reflects the Category 0 alarm count. - Sign in as a test operator and acknowledge that alarm individually in the event display. Check the operation log for the expected user and acknowledgement action.
- While the alarm condition remains active, record whether
LB-12400andLW-11500change. This establishes whether the reminder represents alarm existence or the desired unacknowledged state. - Clear the Category 0 alarm condition and confirm the category-specific indication and count return to their expected inactive values.
Which implementation pitfalls recur?
| Pitfall | Result | Correction |
|---|---|---|
Treating LB 9043 as Category 0 status |
Timing events keep the alarm reminder active. | Use LB-12400 for the Category 0 alarm-present indication. |
Treating LW-11500 as an unacknowledged count |
The displayed meaning may not match the operator instruction. | Label it as the Category 0 alarm count and test acknowledged-but-active behavior. |
| Using acknowledge-all | The command does not preserve the intended category-specific workflow. | Require individual selection and acknowledgement. |
| Assuming a status tag creates an audit record | The reminder works, but user attribution may be absent. | Verify the individual action separately in the operation log. |
| Troubleshooting communications after events are visible | Work concentrates on a path that is already passing records. | Trace the category and acknowledgement aggregation inside the HMI runtime. |
FAQ
How do I filter LB 9043 to Category 0?
You cannot apply a category filter to LB 9043 in the stated cMT-FHDX-820 project using EasyBuilder Pro v6.09.02.651. Replace it in the Category 0 reminder with LB-12400.
How do I display the number of Category 0 alarms?
Read LW-11500, which reports the number of alarms in Category 0. Treat it as an alarm count, not as an unacknowledged-alarm count.
How do I keep Categories 250-255 from triggering the alarm reminder?
Drive the reminder from LB-12400 instead of LB 9043. Categories 250-255 may still affect the global bit, but they will not create the Category 0 alarm-present indication.
How do I verify signed-in alarm acknowledgements?
Trigger one Category 0 alarm, sign in as the test user, acknowledge that alarm individually, and confirm the operation log records the expected user and action. Then clear the alarm and verify LB-12400 and LW-11500 return to their expected inactive values.