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

Heidenhain native alarms (#831): follow-ups #839

New Issue
Closed
opened 2026-11-11 03:27:27 -05:00 by dohertj2 · 1 comment
dohertj2 commented 2026-11-11 03:27:27 -05:00
Owner
Copy Link
Copy Source

From #831.

  • Condition type/class names for ALARM: selectors are generic; map Heidenhain alarm classes to Part 9 classes.
  • The /raw browse picker does not offer ALARM: selectors; they can only be typed manually.
  • Controller alarms that match no configured ALARM: selector are dropped silently — log/count them so missed alarms are discoverable.
From #831. - Condition type/class names for `ALARM:` selectors are generic; map Heidenhain alarm classes to Part 9 classes. - The /raw browse picker does not offer `ALARM:` selectors; they can only be typed manually. - Controller alarms that match no configured `ALARM:` selector are dropped silently — log/count them so missed alarms are discoverable.
dohertj2 added the type:followuppriority:p3 labels 2026-11-11 03:27:27 -05:00
dohertj2 commented 2026-11-11 05:24:37 -05:00
Author
Owner
Copy Link
Copy Source

Done (ddc1f29e). Pushed to master in d1b6cad2. Heidenhain conditions get a Part 9 class (emergency stop → Safety, groups 1–2 → Process, 4–5 → System, else Base); the /raw browse offers an AlarmConditions/ folder of ALARM: selectors; unmatched controller alarms are counted (otopcua.driver.alarms.unmatched, /hosts) and logged at most once a minute. Mapping unproven on hardware: #853.

Done (`ddc1f29e`). Pushed to master in `d1b6cad2`. Heidenhain conditions get a Part 9 class (emergency stop → Safety, groups 1–2 → Process, 4–5 → System, else Base); the /raw browse offers an `AlarmConditions/` folder of `ALARM:` selectors; unmatched controller alarms are counted (`otopcua.driver.alarms.unmatched`, /hosts) and logged at most once a minute. Mapping unproven on hardware: #853.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
auto-managed
queue management
 blocked
Blocked by dependency or external hold
 cross-driver
queue management
 cross-repo
Needs coordinated change in another family repo (wire contract etc.)
 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
 migrated
Migrated from a markdown backlog (2026-11 standardization)
 phase/1
queue management
 phase/2
queue management
 phase/3
queue management
 phase/4
queue management
 phase/5
queue management
 phase/6
queue management
 priority:p0
Must-have / blocking
 priority:p1
High priority
 priority:p2
Normal priority
 priority:p3
Low priority / nice to have
 queue/blocked
queue management
 queue/done
queue management
 queue/failed
queue management
 queue/in-progress
queue management
 queue/queued
queue management
 type:bug
Defect in shipped behaviour
 type:debt
Technical debt / hygiene
 type:deploy-gate
Rollout/deploy/migration step not yet done on an environment
 type:docs
Documentation work
 type:feature
Feature implementation
 type:followup
Follow-up deferred from a plan, PR or gate
 type:infra
Infrastructure and scaffolding
 type:review-finding
Unfixed finding from an architecture/code review
 type:test
Test work
No Label priority:p3 type:followup
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#839
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?