Galaxy: MXAccess quality byte 0x02 unmapped (JoePlatform/JoeAppEngine ScanState read Bad 0x80000000) #866

New Issue

2026-11-11T12:14:10-05:00

dohertj2 commented

2026-11-11 12:14:10 -05:00

Found by the #614 read-only live run against VD03 (2026-11-11). Reading JoePlatform.ScanState and JoeAppEngine.ScanState returns Bad (0x80000000), and the driver logs Unrecognised MXAccess quality byte 0x02.

The platforms themselves are deployed (deployed_package_id is set) but apparently not running. Capture what MXAccess sends for an undeployed or stopped engine's attributes, and map 0x02 to a specific status code instead of generic Bad. 0x02 may be the OPC DA Bad_ConfigError-style substatus; check the gateway's documentation.

Found by the #614 read-only live run against VD03 (2026-11-11). Reading `JoePlatform.ScanState` and `JoeAppEngine.ScanState` returns Bad (0x80000000), and the driver logs `Unrecognised MXAccess quality byte 0x02`. The platforms themselves are deployed (`deployed_package_id` is set) but apparently not running. Capture what MXAccess sends for an undeployed or stopped engine's attributes, and map 0x02 to a specific status code instead of generic Bad. 0x02 may be the OPC DA `Bad_ConfigError`-style substatus; check the gateway's documentation.

dohertj2 added the priority:p3 type:followup labels 2026-11-11 12:14:10 -05:00

dohertj2 referenced this issue

2026-11-11 12:14:10 -05:00

Galaxy: AVEVA/licence-gated proofs; fire-and-forget native ack #614

dohertj2 referenced this issue

2026-11-11 15:14:35 -05:00

Galaxy StatusCodeMap: Warning/Pending status rows and the detected_by comms-error rule (#866 review residuals) #872

dohertj2 referenced this issue from a commit

2026-11-11 15:38:12 -05:00

fix(galaxy): #866 map MxStatus failure details by the MxStatusDetail vocabulary, not as OPC DA quality

dohertj2 referenced this issue from a commit

2026-11-11 15:38:12 -05:00

fix(galaxy): #866 grade OK-status data changes by the item's OPC DA quality

dohertj2 referenced this issue from a commit

2026-11-11 15:38:12 -05:00

Merge #866 #870 #871 #872: MxStatus detail vocabulary + quality grading, ring event queue, CI races

dohertj2 commented

2026-11-11 15:38:32 -05:00

Fixed, pushed to master in 363f0d81 (71b3b7f3, 875b8217, 1a08b4f7).

Cause: 0x02 was not a quality byte. A status row's detail is MXAccess's MxStatusDetail code verbatim: mxaccessgw's MxStatusProxyConverter copies MXSTATUS_PROXY.detail straight through, and every producer of status rows goes through it. Detail 2 is MX_E_PlatformCommunicationError, which is what a deployed but stopped platform's attributes return. FromMxStatus sent any detail ≤ 0xFF through the OPC DA quality table, which mis-named every low code. For example, MX_E_InvalidObjectId (8) surfaced as BadNotConnected, MX_E_Overflow (20) as BadCommunicationError, and a detail in the Uncertain band published Uncertain for a failure.

Fix: failure rows now map by the gateway.md vocabulary, then by category:

timeout → BadTimeout
platform or engine comms → BadCommunicationError
invalid ids or references → BadConfigurationError
type and conversion errors → BadTypeMismatch
overflow or out of range → BadOutOfRange
not readable / not writable, access, and initialising keep their existing mappings

The category-fallback warning logs once per (detail, category).

Second defect, found in review: the gateway fills Statuses on every data change, so the item's OPC DA Quality was never read. An off-scan, Bad or Uncertain attribute with an OK status row was published Good. A failure status row still wins; otherwise the quality byte grades the value, which matches the legacy rule of ≥ 192 = Good.

Live check, read-only on VD03 (DEV):

healthy ScanState and _TestArea attributes stay Good;
JoePlatform.ScanState and JoeAppEngine.ScanState now read BadCommunicationError (0x80050000) instead of 0x80000000;
no warnings.

ScadaBridge impact: Galaxy Bad values now carry specific sub-codes. An attribute whose quality is not Good can now arrive as Bad or Uncertain where it used to arrive as Good. Residuals are in #872.

Fixed, pushed to master in `363f0d81` (`71b3b7f3`, `875b8217`, `1a08b4f7`). **Cause:** 0x02 was not a quality byte. A status row's `detail` is MXAccess's `MxStatusDetail` code verbatim: mxaccessgw's `MxStatusProxyConverter` copies `MXSTATUS_PROXY.detail` straight through, and every producer of status rows goes through it. Detail 2 is `MX_E_PlatformCommunicationError`, which is what a deployed but stopped platform's attributes return. `FromMxStatus` sent any detail ≤ 0xFF through the OPC DA quality table, which mis-named every low code. For example, `MX_E_InvalidObjectId` (8) surfaced as BadNotConnected, `MX_E_Overflow` (20) as BadCommunicationError, and a detail in the Uncertain band published Uncertain for a failure. **Fix:** failure rows now map by the gateway.md vocabulary, then by category: - timeout → BadTimeout - platform or engine comms → BadCommunicationError - invalid ids or references → BadConfigurationError - type and conversion errors → BadTypeMismatch - overflow or out of range → BadOutOfRange - not readable / not writable, access, and initialising keep their existing mappings The category-fallback warning logs once per (detail, category). **Second defect, found in review:** the gateway fills `Statuses` on every data change, so the item's OPC DA `Quality` was never read. An off-scan, Bad or Uncertain attribute with an OK status row was published Good. A failure status row still wins; otherwise the quality byte grades the value, which matches the legacy rule of ≥ 192 = Good. **Live check, read-only on VD03 (DEV):** - healthy ScanState and `_TestArea` attributes stay Good; - `JoePlatform.ScanState` and `JoeAppEngine.ScanState` now read `BadCommunicationError` (0x80050000) instead of 0x80000000; - no warnings. **ScadaBridge impact:** Galaxy Bad values now carry specific sub-codes. An attribute whose quality is not Good can now arrive as Bad or Uncertain where it used to arrive as Good. Residuals are in #872.

dohertj2 closed this issue

2026-11-11 15:38:32 -05:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#866