Object model and a tool change
-
At what point in the tool change process does the object model get updated with the tool being fitted?
Is it at the end of the tpostx.g file? -
After tpre has been executed and before tpost is.
-
Hmm, ok.
I think I need to rework my tool files then. At the moment, I have tprex moving towards the tool and then the actual tool pickup taking place in tpostx.
Maybe it would be worth while having some sort of process flow on the wiki?
-
We've made a note of this and it will I hope be done soon.
-
@jay_s_uk said in Object model and a tool change:
At the moment, I have tprex moving towards the tool and then the actual tool pickup taking place in tpostx.
I have that as well... and I still believe that is correct. What are you thinking?
-
If the OM update takes place between tpre and tpost, I need to have the tool in place by the end of tpre (I've fitted switches to each tool so I know if a tool is fitted. In the daemon file, I'm going to query whether the tool is supposed to be fitted and if printing is taking in place so if it isn't, I can pause the print).
I'll be moving most of the contents of tpost into tpre so it's similar to the E3D tool changer https://github.com/Duet3D/RRF-machine-config-files/tree/master/E3D_Tool_Changer
In an ideal world, there would actually be 3 states to each tool pickup:
-
Pre - all preparation required for the tool change
-
Tool Change - The actual picking up of the tool
-
Post - Restoring of fans, position and temperatures
-
-
@jay_s_uk said in Object model and a tool change:
If the OM update takes place between tpre and tpost, I need to have the tool in place by the end of tpre (I've fitted switches to each tool so I know if a tool is fitted. In the daemon file, I'm going to query whether the tool is supposed to be fitted and if printing is taking in place so if it isn't, I can pause the print).
I was 90% sure that is where you were going, and I don't believe that the current handling is a total lockout to what you want to do... I believe you are thinking that the daemon needs some way to know whether to check or not, and that the most reasonable way is to query the object model 'state' regarding what tool is mounted.
Great approach, very clean, just doesn't work with the sequence of:
111111111|XXXXXX|222222222 tfree | tpre | tpost
(where 1 is tool 1, x is no tool at all, and 2 is tool 2)
Doesn't work unless you put a bunch of stuff in tpre, that doesn't really fit there.
How about this:
A "global variable" (which, for now, must be some otherwise unused field in the object model) could also be used to tell the daemon to "check" or "not check". If checking is active, the daemon then looks at the object model, just like you planned.
tfree needs to set that global to "not check" as its first line.
tpost needs to set that global to "check" as its last line.
Thoughts?
-
I can see where you're coming from.
The daemon runs all the time so I was basically going to check if, for example, tool 0 was mounted and the printer is printing and tool 0 switch was not equal to 1.
I suppose I should also ask @dc42 at what point the OM is updated to show that a tool is no longer mounted? Is it at the start or end of tfree?
-
@dc42, when is a tool marked as not mounted?
before or after tfree?