inconsistent axis control around tool changing

[gnydick]

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....

Anyway...

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.

[dc42]

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]

@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.

[chazrogers]

@dc42 @gnydick why can the behavior on tool change not be dictated by the user? why must the firmware dictate a move to previous z location regardless of any effort by the user to avert the action? I can understand a default action to take on a tool change, but no way to prevent moving to previous z coordinate?!?! There have been a number of users frustrated by this behavior and inability to change it. it seems some of these users cannot even articulate what is happening because of the fact that their machine is performing this action without them dictating it to do so.

[dc42]

@chazrogers the reason that RRF moves the new tool to the same Z position as the old tool is because that is what slicers expect when they generate GCode for multi-material prints. As I said in my earlier post, in earlier versions of RRF we had many complaints that the Z position was not restored immediately after a tool change.

If you don't want the position restored after a tool change, you can change it. The position restored is the one stored in restore point #2, where the position at the start of executing the T command was stored. You can overwrite the contents of this restore point using command G60 S2 in your tool change files. Note, the restore point information includes the feed rate as well as the coordinates.

[chazrogers]

@dc42 The z position can be restored immediately after a tool change by issuing those commands inside of the tool change files. It doesn't have to be a firmware default. Now that it is a firmware default, it leaves users without control when it doesn't have to be that way.

While the fact that you can change a restore point is true, it is somewhat misleading in the context of my post. When a tool change occurs, the z axis will return to the restore point (whatever that value is) regardless of what the user dictates in any tool change files. It's dictated in the firmware and it doesn't have to be. It causes frustration to many users because they need more control over their workflow and to countless others who do not ever understand why their machine is diving into their bed when they have not dictated a move in the first place and cannot articulate the issue.

[dc42]

I agree that for CNC machines, restoring the position after a tool change does not make sense.

As an experiment, in 3.4.0beta6 RRF will not restore the position after a tool change. We may have to revert that change (perhaps only when the machine is in FDM mode) if it causes too many issues for users.