OpcUaClient: TargetNamespaceKind=Equipment default (requires UnsMappingTable) is vestigial in v3 #648
Assignees
dohertj2 (dohertj2)
Clear assignees
dohertj2 (dohertj2)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dohertj2/lmxopcua#648
Reference in New Issue
Block a user
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?
Found during the #619 opc-plc alarm gate. A raw-authored OpcUaClient driver config without an explicit TargetNamespaceKind fails Initialize, because the default is Equipment, which requires a UnsMappingTable. In v3 UNS references are explicit (UnsTagReference), so the mapping table appears meaningless. The gate had to seed TargetNamespaceKind=SystemPlatform (
fdee129f) to get a driver up. The AdminUI OpcUaClientDriverForm also defaults to Equipment.Decide: remove the Equipment mode and the mapping table, or default to SystemPlatform (and make the form follow).
Fixed on master (
dd05baed, mergedda43278e, pushede7dd7425).TargetNamespaceKind,UnsMappingTable, the enum,ValidateNamespaceKind, the AdminUI 'Namespace mapping' section, the OpcPlcProfile workaround and the docker-dev seed key are all removed. Stored DriverConfig JSON still carrying either key parses and initialises (unknown keys ignored) — pinned byLegacy_namespace_keys_are_ignored_by_parse_and_initialise; the AdminUI form loads legacy keys and drops them on the next save. Reviewed (sonnet, APPROVE); AdminUI.Tests 1652/1652, OpcUaClient.Tests 217/217.