Deprecate [EMCIO]DB_PROGRAM: unify tool data on one interface

[grandixximo]

At the 2026-09 dev meeting, removal of the tool database interface ([EMCIO]DB_PROGRAM) was proposed. It has active users (#4422, #4408), so a straight removal is off the table. This issue is to hash out what unification looks like instead. The shape below is a starting point, not a settled plan, and I do not have bandwidth to drive it (multiaxis and TP work ongoing), so: comments on the shape welcome, and if you want to own any of it, please say so.

What db_program does that the tool table file cannot

1. Custom per-tool schema (diameter, tooth count, usage hours, grade) in an external database.
2. Load/unload event stream, for tool usage tracking.
3. Dynamic tool-number => pocket resolution at load time.

Everything else duplicates what the tool table file plus the existing Python/NML interface already provides. Note the event stream is coarse: only load/unload and offset puts. Spindle on/off and motion are not part of the protocol, so real cutting-time or cutting-distance tracking already requires the db program to watch HAL itself.

Proposal (draft shape)

Keep one canonical in-core tool table, one persistence mechanism (the file), and standard status/HAL as the observation interface, the same pattern as the rest of LinuxCNC:

1. Add a tool-data-changed notification usable from userspace (a HAL pin or stat field, an epoch counter bumped on any tool data change). Today an external app can observe load/unload via iocontrol pins but has no way to learn about G10 offset changes without polling. This looks like the only real capability gap, but I may be missing others.
2. Separately, pursue an extended tool data model (standardized diameter/tooth-count style fields visible to all GUIs). That is the actual feature most db_program users seem to be after (ref Feature Request: add fields to tool table #4408), and it shrinks the remaining reasons to run an external db program.
3. Once 1 and 2 land, deprecate DB_PROGRAM with a migration recipe: a short example Python script using the linuxcnc module plus HAL that reproduces the usage-tracking pattern.

Open questions

• Is the capability list above complete? Anyone using db_program for something it does not cover?
• Is the epoch/notification pin the right mechanism, or is there a better fit (NML status, a message channel)?
• Should the extended tool data model block deprecation, or can they proceed independently?

Non-goals

• No change to the tool table file format as part of this issue.
• No removal before a replacement recipe exists and at least one release cycle of deprecation notice.

Future ideas

• Per-tool cutting stats: a userspace HAL watcher could integrate feed motion while the spindle is on (pins exist today: motion.current-vel, spindle.0.on, iocontrol tool pins) and accumulate per-tool cut distance, average feed, and usage hours. This subsumes the "operating hours" use case the db_program docs describe, with no core changes needed.

[alex-pres]

The main problem here for extending tool table in an external program is the inability to link info in reliable way.
If external software / GUI links by tool# pocket# it is not reliable : main tool table always can be changed in unexpected way.

I see following solutions to this:

1. the better one - have one field in tool.tbl that is machine readable/writeable and have free format, for example string up to 255 chars. provide API for third-party programs to read/write it and it solve most of problems. because record is stored along with the tool it is most likely will be in sync.
2. auto assign UUID to each record in tool table. It is stable for all life of that line. When record is removed then added, new UUID assigned. In this case third-party software may link additional info by UUID
3. keep DB_PROGRAM as is

What is use for additional tool info ?

My example - I am developing a custom GUI that will store tool D, tool Z#, mill tool type, tool grade manufacturer and lathe insert code + holder code. Why not? It looks good and it is really useful! It can automatically display Vc and Fz values and can advise on speed and feed [ if you specify stock material ].