In Wonderware 8.01, the Historical Alarm object displays alarms and can also include events. The available evidence does not identify a dedicated almQuery expression that selects event records by record type. The supported diagnostic path is to test whether alarm priority can separate the two record sets.
Observed Historical Alarm Behavior
Events are enabled, and selected setpoint tags log events. When the Historical Alarm object includes events, it displays them together with alarms. This confirms that event records reach the history display, but it does not establish a native event-only filter.
Priority-Based Filter Decision
| Requirement | Candidate query strategy | Evidence status |
|---|---|---|
| Event-only window | Select the priority assigned to event records | Suggested workaround; verify in the application |
| Alarm-only window | Exclude the priority assigned to event records | Suggested workaround; verify in the application |
This approach works only if events and alarms can be distinguished reliably by their configured priorities. The evidence does not provide priority values or confirm that Wonderware 8.01 assigns a unique priority automatically.
Configure and Test Separate Views
- Review the logged event and alarm records and determine whether their priorities are distinct.
- Create a second Historical Alarm object for the proposed event-only window.
- Set its
almQueryto include the event priority and test it against known event and alarm records. - Modify the existing object's query to exclude that priority.
- Trigger a known setpoint event and a known alarm, then confirm that each record appears in only its intended view.
Limitations and Verification
Do not rely on priority filtering if an alarm and an event can share the same priority; the query would then classify records incorrectly. If priorities overlap or cannot be assigned independently, the evidence provides no confirmed almQuery method for separating records by event-versus-alarm type in version 8.01.
FAQ
How do I display only events in Wonderware 8.01?
Test an almQuery filter based on a priority used only by events. Verify the result with one known event and one known alarm because a dedicated event-type filter is not established by the available evidence.
How do I remove events from a Wonderware Historical Alarm object?
Exclude the event-specific priority from the existing object's query. This is reliable only when no alarm uses that priority.
Can alarms and events share the same priority when filtering?
Not if priority is the separation key. Shared priorities prevent the query from distinguishing alarms from events, so revise the priority assignments or use another confirmed discriminator available in the application.