OPC UA / umati tool data — research

[sliptonic]

Research thread for an OPC UA integration. Not yet an issue because the shape of the client is genuinely open — this is where to pool findings.

What we know

• OPC UA for Machine Tools (OPC 40501-1 / umati) is the companion spec that models machine-tool data, including a tool list; big-vendor controllers increasingly expose it (Siemens Sinumerik ONE, Heidenhain TNC7, Okuma, DMG MORI via their gateways).
• Siemens exposes tool nodes over OPC UA but behind a paid option (see docs/CLIENT_LANDSCAPE.md — Sinumerik row); other vendors vary in what subset of the tool model they publish and whether it's read-only.
• Python has a solid stack (asyncua), so a proof-of-concept reader is cheap once we know which real controller/gateway to test against.

Open questions

1. Which companion-spec nodes actually carry tool geometry/offsets in the wild, and are they writable anywhere, or is OPC UA read/harvest-only in practice?
2. Is umati adoption far enough along that one client covers multiple vendors, or does each controller need its own quirks layer (like MTConnect agents do)?
3. Where does this sit vs MTConnect (Wave 1: MTConnect CuttingTool asset client (gap-finder) #8)? They overlap as live-machine-data standards; MTConnect has the free hobbyist-visible ecosystem, OPC UA has the industrial installed base.
4. Does anyone have access to a machine or simulator (Sinumerik ONE trial, umati sample server at opcua.umati.app) we can develop against?

If you run a machine that speaks OPC UA, sharing a node-tree dump of its tool area would advance this more than anything else.

Findings welcome below — this graduates to an implementation issue when the target and access path are pinned.