Troubleshooting the Ignition Vision Alarm Status Table

After a PC reboot, the Vision Alarm Status Table can show active, unacknowledged alarms while its ACK button stays disabled; selecting an alarm may leave the selected-alarm dataset at zero rows. In the reported Ignition 8.1.49 case, clicking a row checkbox also produced a NullPointerException in the table’s button-state update path. Check the Designer console first: that exception separates a component failure from an ordinary selection or acknowledgment issue.

Check the Designer console when ACK stays disabled

Reproduce the problem in the affected Vision client or Designer session and watch the console while selecting an active, unacknowledged alarm. Record the full exception and the action that triggers it. The reported trace begins with:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException: Cannot invoke "java.lang.Boolean.booleanValue()" because the return value of "com.inductiveautomation.ignition.common.alarming.AlarmEvent.getOrDefault(com.inductiveautomation.ignition.common.config.Property)" is null
at com.inductiveautomation.factorypmi.application.components.AlarmStatusTable$FooterPanel$ButtonPanel.updateEnabled(AlarmStatusTable.java:2524)

• If this exception appears on checkbox selection: the component is failing while it recalculates whether the ACK button should be enabled. Continue by checking whether the selected-alarm dataset also remains empty, then collect a reproducible case for support.
• If no exception appears: treat the disabled button as a selection, alarm-state, or component-configuration problem until you isolate it. Continue to the dataset and selection checks below.

The trace is not an alarm acknowledgment rejection from the gateway. It is a Java null dereference in the Vision table’s button update code, invoked after the table selection changes. The call to getOrDefault(...) returned null where the component attempted to use a Boolean value. The stack trace does not identify the property name, so do not guess a particular alarm property or edit alarm configuration on that basis.

Check whether the table actually selects an alarm

Click the checkbox for one visible active, unacknowledged alarm and inspect the selected-alarm dataset in the Designer component context. The reported failure showed that the selected dataset remained empty or had zero rows.

• Checkbox changes, dataset gets a row: the table selection is being represented; next check whether the console logs an exception and whether the button state changes.
• Checkbox changes, dataset stays at zero rows: selection is not reaching the selected-alarm dataset. This matches the reported symptom. Check the console during the same click before changing filters or alarm configuration.
• No selectable row or checkbox interaction: first confirm that the displayed row is still active and unacknowledged, then inspect the component’s selection behavior and alarm filters.

Keep the checks tied to the same alarm row and same session. A stale display, a row that changes state while you test, or a different selection can make the dataset result misleading.

Compare the visible alarm state with the selected row

Manual ACK mode does not make every alarm row immediately acknowledgeable: the table must have a valid selection, and the alarm must still be in a state that permits acknowledgment. Compare the alarm’s displayed state before and after selecting it. If it clears, becomes acknowledged elsewhere, or disappears from the active view, repeat with a currently active, unacknowledged alarm.

Check the version and reproduce without changing alarm logic

The reported environment was Ignition 8.1.49 with a Vision Alarm Status Table in manual ACK mode. Treat that as the version and configuration where the behavior was observed, not as proof that every 8.1.49 installation is affected or that other versions are unaffected.

1. Record the exact Ignition version and confirm the component’s ACK mode is manual.
2. Open the affected view and identify one active, unacknowledged alarm.
3. Select that alarm once while monitoring the Designer console.
4. Record whether the selected-alarm dataset gains a row, whether the ACK button enables, and whether the null-pointer exception appears.
5. Repeat in a fresh session using the same view and alarm conditions. Note whether the behavior follows the session or reproduces consistently.

Do not spend time repeatedly rebooting the PC as the primary fix. A restart may change session conditions, but it does not explain or correct a null dereference in the component. Do not change alarm priority, acknowledgment mode, or alarm definitions merely to force the button enabled; that can alter operator behavior without addressing the selection-path failure.

Separate a component failure from an acknowledgment failure

Use the button behavior and alarm state to classify the fault before pursuing gateway acknowledgment diagnostics.

• Button stays disabled, selection dataset remains empty, and the exception occurs: prioritize the Vision component failure. Capture the event sequence and console trace.
• Button stays disabled, selection is present, but the exception is absent: test another currently active, unacknowledged alarm and inspect the component’s configured alarm source and filters. The evidence does not name a specific configuration property to change.
• Button enables but the alarm remains unacknowledged after the action: record the resulting alarm state and inspect the acknowledgment path separately. A disabled button and a rejected acknowledgment are different failures.

This distinction avoids wasting time changing gateway alarm settings when the observed failure happens earlier, inside the Vision table’s selection-driven enablement update.

Use a controlled recovery and verify the operator workflow

No configuration workaround or fixed software revision was established for this case. Until the component behaves correctly, use only an approved alternate acknowledgment path already available in the project; do not bypass site alarm-handling procedures or make an untested change to production alarm logic.

1. Preserve the affected project configuration and capture the version, view, alarm state, selected-dataset result, and console trace.
2. In a controlled test session, reproduce with one active, unacknowledged alarm and confirm whether checkbox selection populates the selected-alarm dataset.
3. If the null dereference occurs, stop treating rebooting or alarm edits as the resolution and submit the reproducible case to Inductive Automation support.
4. After a vendor-provided correction or approved project change, repeat the same selection test. Confirm the dataset contains the selected alarm, the manual ACK button enables, and the alarm state changes to acknowledged after the operator action.

Stop testing and escalate to official Inductive Automation support when the exception reproduces or the dataset remains empty despite a valid alarm selection. Include the complete console trace, exact Ignition version, component settings, and reproduction steps; resume the affected workflow only after the acknowledgment path passes the verification checks.

FAQ