tool change - clarification on tpre and tpost

mikeabuilder

I'm working on improving our tool changing process and I have a sort-of technical question about the tpree and tpost macros. I don;t find the answerin the doc page https://docs.duet3d.com/User_manual/Tuning/Tool_changing.

I'm guessing and would like to know if I'm right about the meaning of a couple of phrases on the doc page. Specifically, these statements

Actions to do with the old tool before it is released - macro name: tfreeN.g where N is the tool number;
Actions to do with the new tool before it is selected - macro name: tpreN.g where N is the tool number;
Actions to do with the new tool after it is selected - macro name: tpostN.g where N is the tool number.

"it is released" - I think this means "while state.currentTool is still the old tool number"

"it is selected" - I think this actually means " the state.currentTool is changed to the new tool number".

And so the description of commands that "must" be in tpost are those that rely on state.currentTool being the new tool number and tpre are commands that must happen while state.currentTool is -1.

There's a good example of a command that really must be in tpost (M116), but no examples of commands that really must be in tpre.

I ask all of this because I'm contemplating putting no commands into tpre, and all of the commands for locking, undocking, pre-heating, and wiping into tpost.

Am I about to do another foolish thing?

gloomyandy

@mikeabuilder

@mikeabuilder said in tool change - clarification on tpre and tpost:

I ask all of this because I'm contemplating putting no commands into tpre, and all of the commands for locking, undocking, pre-heating, and wiping into tpost.

Why?

What is the advantage of doing that? I'm pretty sure that one of the problems you will see is that the coordinate system in tpost will include the offsets for the newly selected tool, this will typically make moving to the correct location to collect the tool more complex. I think it will also make aborting a toolchange more complex (maybe not even possible), as the system will be assuming that after tpre has completed the tool has been selected. Basically you will be out of sync with the state that the system is in.

Don't get me wrong, you can probably do what you want, I just suspect you may be introducing more problems than you will be solving.

mikeabuilder

@gloomyandy - thanks for your thoughts on this topic. I would really like to understand the state changes in the system through the tpre and tpost execution steps. It's not clear (at least to me) in the documentation.

My advantage in putting all my operations into tpost is slight - simplification of the macros I need to maintain, and teach to others to maintain. And I'm one of those people that wants to understand why.

Reading the current documentation, it isn't clear that tpre operates with state.currentTool = -1, which I believe is required for moves to be in machine coordinates and not tool coordinates (hence my obtuse question about "selected"). As a result, in my tpre, I preface all moves with G53 to force machine coordinates to be used.

And about aborting tool changes and the system assuming tpre has completed - I currently have no abort logic, though I've been thinking about adding some inputs to detect successful tool capture. I'll need to think some more about what to do in an abort situation. These may be the good reason to use tpre.