Tooltable as Plugin

[mintracer]

Hej Terje,

last week on the printnc discord, we where thinking about the tooltable, since a user was planning his toolmagazine with 40 tools and then realized that the max amount is 16.

So we discused the tooltable implementation and Drew came up with some cool ideas to make it as an Plugin, to store toolinfomations on the sdcard, maybe with an import option for exisiting tooltables (Fusion or similar).

An Option for a tooltable driven manual Toolchange would also be cool, since there a QTC Spindles and manual "ATC".

If stored externally, there are no limits anymore... what is actually limiting the tooltable?

what do you think? :)

cheers Einar

[terjeio]

The current limit is kind of arbitrary and can be extended, at least until NVS storage is exhausted.
I would rather extend it than add code to read it from/write it to file system storage, this since the tooltable is used and manipulated by the core (in _gcode.c:).

An Option for a tooltable driven manual Toolchange would also be cool, since there a QTC Spindles and manual "ATC".

I am not familiar with these, can you describe what a "tooltable driven manual Toolchange" workflow would be like?

[mintracer]

for example QTC : https://www.youtube.com/watch?v=wXX63plHJCk&t=121s

here for example all 3 modes... QTC and ATC are both manually changed but the tools are prefixed... the offsets would be in the tooltable...

https://www.youtube.com/watch?v=hEsqC7cdP2A

[terjeio]

IMO all these modes are currently supported, though fully automatic mode (ATC) requires either plugin code or tool change macro(s) added. The tool table is useful only when having indexed tools and offset(s) from the tool table is applied after changing a tool by including gcode for that (G43, G43.2 and G43.2).
AFAICT gcode specifications does not specify a mode where the tool table offset is applied automatically on a tool change if that is what you want.

[andrewmarles]

I have not researched this in depth, but I was looking at redirecting gc_state.tool and implementing the necessary functions based on reading/writing to a file in local storage rather than NVS.

I think that "tooltable driven manual toolchange" refers to a spindle that has toolholders and known tool offsets, but the actual tool change itself is performed manually by the operator rather than automated with a rack or umbrella.

[terjeio]

I was looking at redirecting gc_state.tool and implementing the necessary functions based on reading/writing to a file in local storage rather than NVS.

IMO it would be better to add function pointers for settings_write_tool_data() and settings_read_tool_data(), this would allow a "clean" plugin implementation. And N_TOOLS would have to be changed from a constant to a hal struct variable for it to work.

[terjeio]

The core has now been updated to allow plugin code to add tooltable handling and the default code has been changed to handle up to 32 entries.

[andrewmarles]

I saw this. Looks great, thank you so much for making those changes.