dohertj2/lmxopcua
1
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases Wiki Activity

MTConnect: surface CONDITION data items as Part 9 alarms (IAlarmSource) #626

New Issue
Closed
opened 2026-10-08 09:21:54 -04:00 by dohertj2 · 1 comment
dohertj2 commented 2026-10-08 09:21:54 -04:00
Owner
Copy Link
Copy Source

Split from #613 (its P1.5 fast-follow). In the MTConnect driver a CONDITION data item surfaces as a plain String today; it should be a native Part 9 alarm, using the Galaxy native-alarm pattern (IAlarmSource, materialised once at the raw tag with ConditionId = RawPath, fanned to the raw device folder and every referencing equipment folder).

Sources: docs/drivers/MTConnect.md (CONDITION / P1.5 section); MTConnectObservationIndex.cs; CLAUDE.md native-alarm rules (Acknowledge and AddComment only for native conditions; ack refused off-Primary, #597).

Effort: L, high risk (alarm lifecycle, state mapping, redundancy).

  • Design the MTConnect Condition state (Normal/Warning/Fault/Unavailable) -> Part 9 mapping (severity, active/retain, message from the condition text, native code), including how Unavailable and a new sequence are handled
  • Implement IAlarmSource on the driver (subscribe / transition events keyed by RawPath), reusing the Galaxy native-alarm projection pattern
  • Decide acknowledgement behaviour (MTConnect has no ack; probably a server-side condition with Acknowledge routed nowhere)
  • Tests: agent fixture/mock transitions Normal->Fault->Normal, restart/replay of the current state, comms loss
  • Docs (MTConnect.md) and a live check against the MTConnect agent fixture
  • EVENT-category vocabularies as OPC UA enumerations (#613 item, parked): today they are strings; revisit together with this work or leave as won't-fix

Filed 2026-10-08 by the hardware-available issue sweep.

Split from #613 (its P1.5 fast-follow). In the MTConnect driver a CONDITION data item surfaces as a plain String today; it should be a native Part 9 alarm, using the Galaxy native-alarm pattern (`IAlarmSource`, materialised once at the raw tag with `ConditionId = RawPath`, fanned to the raw device folder and every referencing equipment folder). Sources: docs/drivers/MTConnect.md (CONDITION / P1.5 section); `MTConnectObservationIndex.cs`; CLAUDE.md native-alarm rules (Acknowledge and AddComment only for native conditions; ack refused off-Primary, #597). Effort: L, high risk (alarm lifecycle, state mapping, redundancy). - [ ] Design the MTConnect Condition state (Normal/Warning/Fault/Unavailable) -> Part 9 mapping (severity, active/retain, message from the condition text, native code), including how Unavailable and a new sequence are handled - [ ] Implement `IAlarmSource` on the driver (subscribe / transition events keyed by RawPath), reusing the Galaxy native-alarm projection pattern - [ ] Decide acknowledgement behaviour (MTConnect has no ack; probably a server-side condition with Acknowledge routed nowhere) - [ ] Tests: agent fixture/mock transitions Normal->Fault->Normal, restart/replay of the current state, comms loss - [ ] Docs (MTConnect.md) and a live check against the MTConnect agent fixture - [ ] EVENT-category vocabularies as OPC UA enumerations (#613 item, **parked**): today they are strings; revisit together with this work or leave as won't-fix *Filed 2026-10-08 by the hardware-available issue sweep.*
dohertj2 commented 2026-10-08 16:33:52 -04:00
Author
Owner
Copy Link
Copy Source

Fixed in b82c09d2 (MTConnect CONDITION data items as opt-in native Part 9 alarms via TagConfig.alarm; Warning 500 / Fault 800; UNAVAILABLE keeps an active condition active with quality-only BadNoCommunication). Live gate found two adjacent defects, fixed in cd03b1b5: condition Severity was re-bucketed to 5 points (Fault read 900, now exact 800), and Client.CLI/UI selected ActiveState/Id as one QualifiedName so every alarm read inactive. Live-gated on docker-dev against the MTConnect fixture: Fault Active/800, Unavailable stays Active, Normal Inactive. Pushed a8b07ae1.

Fixed in b82c09d2 (MTConnect CONDITION data items as opt-in native Part 9 alarms via TagConfig.alarm; Warning 500 / Fault 800; UNAVAILABLE keeps an active condition active with quality-only BadNoCommunication). Live gate found two adjacent defects, fixed in cd03b1b5: condition Severity was re-bucketed to 5 points (Fault read 900, now exact 800), and Client.CLI/UI selected ActiveState/Id as one QualifiedName so every alarm read inactive. Live-gated on docker-dev against the MTConnect fixture: Fault Active/800, Unavailable stays Active, Normal Inactive. Pushed a8b07ae1.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
auto-managed
queue management
 cross-driver
queue management
 driver/abcip
queue management
 driver/ablegacy
queue management
 driver/focas
queue management
 driver/mqtt
MQTT / Sparkplug B broker-subscribe driver
 driver/opcuaclient
queue management
 driver/s7
queue management
 driver/twincat
queue management
 phase/1
queue management
 phase/2
queue management
 phase/3
queue management
 phase/4
queue management
 phase/5
queue management
 phase/6
queue management
 queue/blocked
queue management
 queue/done
queue management
 queue/failed
queue management
 queue/in-progress
queue management
 queue/queued
queue management
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#626
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?