topic_unsolved inconsistent axis control around tool changing
gnydick last edited by
I think this has to do with one of my numerous previous posts that never got solved. I don't know why I'm so lucky to find so many of them....
When selecting a tool, nothing moves other than what's in your tpre# and tpost# scripts. It's up to the user to make sure to jog all necessary axes to make sure there won't be a crash when moving the tool out for the first time, namely, the bed/Z-axis.
However, when freeing a tool, the printer automatically moves the bed/Z-axis to match the position at the time of freeing the tool.
Unless I'm overlooking something, I can't find it in any script.
This has caused endless crashes while measuring offsets and doing other calibration steps.
I'm getting really tired of all of these little opinionated implementations causing damage to my printer.
I really wish things worked 1-way. Either do nothing for the user, or do everything. Trying to keep track of what's going to kill my printer is getting tiring.
This is one of the cases where we can't please everyone. It used to be the case that at the end of a tool change sequence, we restored X and Y but not Z. This usually meant that Z was restored on the following XY move. We had numerous complaints about this. So about a year ago I changed it to restore all the tool coordinates. I think you are the first person to complain about this since the change.
To be clear, the XYZ position is restored at the end of the complete tool change sequence, not at the end of running tfree if there is a new incoming tool.
What are you doing that is leading to crashes?
gnydick last edited by
@dc42 it's hard to explain. Buy my point is that there's inconsistent implementations.
Some things are handled for the user, some things aren't.
If something is handled for the user, then if the user doesn't know it and tries to handle it, it can cause crashes. If something isn't handled and thought it is, it can cause crashes.
I'm saying that you have to either handle all circumstances, which is impossible, or handle none.
One of my previous posts that's been dropped on the floor talks about how Z is restored, then XY, instead of all at once and that was causing blobs to slide into the side of the print. I asked, why aren't all of the axed restored at once? No answer. It's a poor decision to pick an order at all and not allow for override. It'd be more sensible to just restore all axes at once or for a 3D printer to restore the tool head extrusion direction into the face of the print, normally Z last, but I imagine anything is possible.
Back to my original question here, it always happens when I don't expect it, so it's hard to catalog exactly what's happening.
There are times I'll unload a tool and the bed will try to come up through the tool head.
It's always after I've done tool changes with P0 at some point.
Other times, the Z offset is lost track of. I'll calibrate one tool, issue a G10 Z command for one tool while it's loaded to make sure the Z position is reflected correctly on the screen, then move on to another tool and the measurement is wrong. Each subsequent tool has a larger and larger offset. I even went so far as to do a full homing between each calibration and it didn't work correctly.
The only way I was able to measure my z offsets was by setting them all to zero, then doing the paper test, writing down the offsets, editing the config and rebooting.
All in all, I'm just very frustrated that I seem to uncover things that never get answered. Like the unbaby step I demonstrated a couple years ago.
Or features people clamor for and you'll respond that it won't help or do any good, like S curve. But now it's on the near term road map.
I don't use Duet because I want to be part of a cult of personality, like it seems so many others do, I use it because there is no better alternative, but that's a relative measure.
It won't be long until someone gets as annoyed as I am but has the right skills to make their own and hurt duet market share. It's not like the is that esoteric, especially since it's all open source.
That's the fate of any open source project that insists on its opinionated way of doing things and seeing the world, it gets replaced.