On an AXF F 2152 controller, OPC UA alarms and events and OPC UA variable history use different controller services. Notifications and alarms go to the Notification Logger database, while variable samples go to the IDataLogger Service. Do not assume that a successful historical-data query for variables proves that an OPC UA client can retrieve missed alarm and event notifications through the same interface.
Separate alarm and variable history paths
| Data type | Controller component | Confirmed access or display path |
|---|---|---|
| Notifications and alarms | Notification Logger | PLCnext Engineer and the controller's Web-based Management |
| Historical variables | IDataLogger Service | OPC UA client through the IDataLogger Service API |
The Notification Logger stores notifications and alarms in a database separate from the variable-history database. This separation is the key architectural constraint when diagnosing records missed during an OPC UA client outage.
What happens during an OPC UA client connection loss
The controller records notifications and alarms through its Notification Logger rather than through the connected OPC UA client. Therefore, investigate the controller-side Notification Logger when checking whether alarms generated during a client disconnection were retained.
The available evidence does not establish that the controller exposes stored Notification Logger records as OPC UA historical alarms or events. It confirms only that PLCnext Engineer and Web-based Management display those records. It also confirms that OPC UA historical variable access uses the IDataLogger Service API. Treat OPC UA event replay after reconnection as unconfirmed until a supported history interface is identified and tested.
Verify retention and client recovery
- Confirm that live OPC UA alarms and events reach UaExpert before starting the test.
- Disconnect UaExpert, then generate a known notification or alarm in the controller.
- Open PLCnext Engineer or Web-based Management and verify that the Notification Logger contains the alarm generated during the disconnection.
- Reconnect UaExpert and determine whether the missed alarm is returned by any configured historical event function or whether only new live events arrive.
- Query a logged variable separately through OPC UA historical data access. Use that result only to validate the IDataLogger path, not alarm-history availability.
If the record appears in the Notification Logger but not in UaExpert after reconnection, controller-side retention is working while OPC UA retrieval of stored alarms remains unavailable or unconfigured. If the record is absent from the Notification Logger, investigate notification generation and controller logging before troubleshooting the OPC UA client.
FAQ
Does the AXF F 2152 retain alarms when UaExpert disconnects?
Notifications and alarms are logged by the controller's Notification Logger in a separate database. Verify outage retention by generating an alarm while UaExpert is disconnected and checking PLCnext Engineer or Web-based Management.
Can UaExpert read OPC UA alarm history from the IDataLogger?
The confirmed IDataLogger interface serves logged variable history through the IDataLogger Service API. The evidence does not confirm that it serves stored notifications, alarms, or events.
Why can I retrieve historical variables but not missed OPC UA alarms?
The data follows separate paths: variables use the IDataLogger Service, while notifications and alarms use the Notification Logger. Confirm the missed alarm in PLCnext Engineer or Web-based Management, then test separately whether the OPC UA server exposes a supported historical event interface.
