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

Heidenhain: confirm the alarm class/group to Part 9 condition-class mapping on a real control #853

New Issue
Closed
opened 2026-11-11 05:24:28 -05:00 by dohertj2 · 5 comments
dohertj2 commented 2026-11-11 05:24:28 -05:00
Owner
Copy Link
Copy Source

From #839. Condition classes for Heidenhain native alarms are mapped from the controller's alarm class/group (class 5 emergency stop → Safety; groups 1–2 → Process; 4–5 → System; others Base). LSV2 does not document the codes; the numbering is taken from HEIDENHAIN's DNC/RemoTools error enums from memory, consistent with the one recorded iTNC 530 alarm (class 7 Info, group 4 General) but otherwise unproven. Confirm on real hardware alongside #829. Labels only — selection and severity do not depend on them.

From #839. Condition classes for Heidenhain native alarms are mapped from the controller's alarm class/group (class 5 emergency stop → Safety; groups 1–2 → Process; 4–5 → System; others Base). LSV2 does not document the codes; the numbering is taken from HEIDENHAIN's DNC/RemoTools error enums from memory, consistent with the one recorded iTNC 530 alarm (class 7 Info, group 4 General) but otherwise unproven. Confirm on real hardware alongside #829. Labels only — selection and severity do not depend on them.
dohertj2 added the type:followuppriority:p3blocked labels 2026-11-11 05:24:28 -05:00
dohertj2 commented 2026-11-11 14:53:57 -05:00
Author
Owner
Copy Link
Copy Source

2026-11-11: observed class 7 / group 3 (Hermle PLC messages) on Hermle29 and Hermle70, mapped to Base as the table says. Classes other than 7 (notably class 5, emergency stop) and groups 1, 2, 5 and 6 are still unobserved. Raw alarm numbers read as negative (0x81xxxxxx).

2026-11-11: observed class 7 / group 3 (Hermle PLC messages) on Hermle29 and Hermle70, mapped to Base as the table says. Classes other than 7 (notably class 5, emergency stop) and groups 1, 2, 5 and 6 are still unobserved. Raw alarm numbers read as negative (0x81xxxxxx).
dohertj2 commented 2026-11-12 23:38:21 -05:00
Author
Owner
Copy Link
Copy Source

Real-alarm evidence (2026-11-13, read-only, alongside the #829 gate)

Live ALARM:* conditions on three iTNC 530 controls, read through a deployed server:

Control Message (number + text) class group Mapped Part 9 class
Hermle49 (340490 03 SP10) 700520 Tool life exceeded 1 (Warning) 3 (Plc) BaseConditionClass
Hermle70 (606420 03 SP4) 701550 Cabin unlocked! B301 7 (Info) 3 (Plc) BaseConditionClass
Hermle29 (606420 03 SP4) 701550 Cabin unlocked! B301 7 (Info) 3 (Plc) BaseConditionClass

Both are 7xxxxx PLC (OEM/Hermle) messages, and both report group 3 = Plc. "Tool life exceeded" as class 1 Warning and a cabin-door notice as class 7 Info fit the DNC enum names. That makes three real records consistent with the numbering (with the earlier class 7 / group 4 one). The Safety (class 5) and Process/System (groups 1/2/4/5) branches are still unobserved, so this is corroboration, not proof. Leaving open until an E-stop or an operating/programming-group alarm is seen.

## Real-alarm evidence (2026-11-13, read-only, alongside the #829 gate) Live `ALARM:*` conditions on three iTNC 530 controls, read through a deployed server: | Control | Message (number + text) | class | group | Mapped Part 9 class | |---|---|---|---|---| | Hermle49 (340490 03 SP10) | `700520 Tool life exceeded` | 1 (Warning) | 3 (Plc) | BaseConditionClass | | Hermle70 (606420 03 SP4) | `701550 Cabin unlocked! B301` | 7 (Info) | 3 (Plc) | BaseConditionClass | | Hermle29 (606420 03 SP4) | `701550 Cabin unlocked! B301` | 7 (Info) | 3 (Plc) | BaseConditionClass | Both are 7xxxxx PLC (OEM/Hermle) messages, and both report group 3 = `Plc`. "Tool life exceeded" as class 1 `Warning` and a cabin-door notice as class 7 `Info` fit the DNC enum names. That makes three real records consistent with the numbering (with the earlier class 7 / group 4 one). The Safety (class 5) and Process/System (groups 1/2/4/5) branches are still unobserved, so this is corroboration, not proof. Leaving open until an E-stop or an operating/programming-group alarm is seen.
dohertj2 commented 2026-11-13 00:36:47 -05:00
Author
Owner
Copy Link
Copy Source

Documentation search (2026-11-13), commit 2e537dc6

I found no public source for DNC_ERROR_CLASS / DNC_ERROR_GROUP or their numeric values. The table in HeidenhainAlarmClasses was written from memory, and the code and docs now say so.

What public sources do establish:

  • Names, but not numbers. The iTNC 530 HSCI Technical Manual's PLC error table (.PET) documents:

    • a Class column: ERROR, FEED HOLD, PGM HOLD, PGM ABORT, EMERG. STOP, RESET;
    • a Group column: GENERAL, OPERATING, PROGRAMMING, PLC;
    • a separate E/W/I message-type column.

    That is the same class set, in the same order, as our codes 2–6, and the same group set as our 1–4. WARNING, INFO and NOTE in our table may be the message type folded into the LSV2 class code. That is unconfirmed.

  • The DNC numbering can't be assumed to match LSV2. The HEIDENHAIN DNC COM interface enums, as listed by a third-party plugin (Senseforce), disagree with LSV2 in one place:

    • ExecutionMode matches LSV2 R_RI 23.
    • ProgramStatus (0 IDLE, 1 RUNNING, …) does not match LSV2 R_RI 26, where real controls report 7 for Idle.

    So we can't assume LSV2 uses the DNC numbering.

  • pyLSV2 can't help. It keeps class and group as raw numbers with no names.

Evidence now: four real iTNC 530 records: 7/4 once, 7/3 twice, and 1/3 once. Both group-3 alarm types are machine-builder PET messages, which fits 3 = PLC.

Still unobserved: class 5, which is the Safety branch, and groups 1, 2, 4 and 5 in the Process/System mapping. Closing that needs hardware, or HEIDENHAIN's DNC/RemoTools SDK headers, which are not public.

## Documentation search (2026-11-13), commit `2e537dc6` I found **no public source for `DNC_ERROR_CLASS` / `DNC_ERROR_GROUP` or their numeric values.** The table in `HeidenhainAlarmClasses` was written from memory, and the code and docs now say so. What public sources do establish: - **Names, but not numbers.** The iTNC 530 HSCI Technical Manual's PLC error table (`.PET`) documents: - a **Class** column: ERROR, FEED HOLD, PGM HOLD, PGM ABORT, EMERG. STOP, RESET; - a **Group** column: GENERAL, OPERATING, PROGRAMMING, PLC; - a separate E/W/I message-type column. That is the same class set, in the same order, as our codes 2–6, and the same group set as our 1–4. WARNING, INFO and NOTE in our table may be the message type folded into the LSV2 class code. That is unconfirmed. - **The DNC numbering can't be assumed to match LSV2.** The HEIDENHAIN DNC COM interface enums, as listed by a third-party plugin (Senseforce), disagree with LSV2 in one place: - `ExecutionMode` matches LSV2 R_RI 23. - `ProgramStatus` (0 IDLE, 1 RUNNING, …) does **not** match LSV2 R_RI 26, where real controls report 7 for Idle. So we can't assume LSV2 uses the DNC numbering. - **pyLSV2 can't help.** It keeps class and group as raw numbers with no names. **Evidence now:** four real iTNC 530 records: 7/4 once, 7/3 twice, and 1/3 once. Both group-3 alarm types are machine-builder PET messages, which fits 3 = PLC. **Still unobserved:** class 5, which is the Safety branch, and groups 1, 2, 4 and 5 in the Process/System mapping. Closing that needs hardware, or HEIDENHAIN's DNC/RemoTools SDK headers, which are not public.
dohertj2 commented 2026-11-13 00:44:21 -05:00
Author
Owner
Copy Link
Copy Source

pyLSV2's issue tracker adds evidence and a verification route (commit 768abdc1)

  • A second user's iTNC 530 (pyLSV2#52) logged 010 Machine guard is open ! with class 3, group 3. It's the first class seen outside 1 and 7. A guard-open PLC message that holds the program fits 3 = PGM HOLD by its meaning, not just its number. All three machine-builder PLC messages now report group 3, which fits 3 = PLC.
  • Verification route (pyLSV2#13): HEIDENHAIN's TNCcmd RUNINFO F / RUNINFO N reads the same alarm list and shows the error class and group by name. It's read-only. Running it against Hermle29/49/59/70 while an alarm is active, and comparing its labels with our raw codes, would check the table against vendor software rather than memory. This needs a Windows host with TNCremo/TNCcmd that can reach the controls.
  • TNC 640 (pyLSV2#89) refuses the alarm-list reads (27/28) as an unknown telegram, so class/group only matter on iTNC 530.

Codes observed on iTNC 530 so far:

Class Group Count
1 3 1
3 3 1
7 3 2
7 4 1

All are consistent with the table. Class 5, the Safety branch, is still unobserved.

## pyLSV2's issue tracker adds evidence and a verification route (commit `768abdc1`) - **A second user's iTNC 530** ([pyLSV2#52](https://github.com/drunsinn/pyLSV2/issues/52)) logged `010 Machine guard is open !` with **class 3, group 3**. It's the first class seen outside 1 and 7. A guard-open PLC message that holds the program fits 3 = PGM HOLD by its meaning, not just its number. All three machine-builder PLC messages now report group 3, which fits 3 = PLC. - **Verification route** ([pyLSV2#13](https://github.com/drunsinn/pyLSV2/issues/13)): HEIDENHAIN's TNCcmd `RUNINFO F` / `RUNINFO N` reads the same alarm list and shows the error class and group by name. It's read-only. Running it against Hermle29/49/59/70 while an alarm is active, and comparing its labels with our raw codes, would check the table against vendor software rather than memory. This needs a Windows host with TNCremo/TNCcmd that can reach the controls. - **TNC 640** ([pyLSV2#89](https://github.com/drunsinn/pyLSV2/issues/89)) refuses the alarm-list reads (27/28) as an unknown telegram, so class/group only matter on iTNC 530. **Codes observed on iTNC 530 so far:** | Class | Group | Count | |---|---|---| | 1 | 3 | 1 | | 3 | 3 | 1 | | 7 | 3 | 2 | | 7 | 4 | 1 | All are consistent with the table. Class 5, the Safety branch, is still unobserved.
dohertj2 commented 2026-11-13 07:22:25 -05:00
Author
Owner
Copy Link
Copy Source

ignitionoee CR capture (2026-11-13), and acceptance. A 7 h read-only sample of 26 live iTNC 530s at CR showed standing alarm classes 1, 7 and 8 (Warning / Info / Error in the table). These are consistent with the recorded class 7 / group 4, class 7 / group 3 and class 1 / group 3 records. Class 5 (EmergencyStop, the only class that drives Safety) was not observed. Nothing contradicts the mapping, so no code change follows.

Accepted per owner decision 2026-11-13 (the driver is accepted if the findings do not change the code). The mapping stays labels-only, never selection or severity, and its hardware-unproven numbering stays documented in HeidenhainAlarmClasses remarks and docs/drivers/Heidenhain.md. Closing; reopen if a real class-5 record contradicts it.

**ignitionoee CR capture (2026-11-13), and acceptance.** A 7 h read-only sample of 26 live iTNC 530s at CR showed standing alarm classes 1, 7 and 8 (Warning / Info / Error in the table). These are consistent with the recorded class 7 / group 4, class 7 / group 3 and class 1 / group 3 records. Class 5 (EmergencyStop, the only class that drives Safety) was **not** observed. Nothing contradicts the mapping, so no code change follows. Accepted per owner decision 2026-11-13 (the driver is accepted if the findings do not change the code). The mapping stays labels-only, never selection or severity, and its hardware-unproven numbering stays documented in `HeidenhainAlarmClasses` remarks and `docs/drivers/Heidenhain.md`. Closing; reopen if a real class-5 record contradicts it.
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 blocked 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#853
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?