Tool Change: Moving in axis without calling them

Danal

May we also see the tfre/pre/post macros?

smoki3

@Danal said in Tool Change: Moving in axis without calling them:

May we also see the tfre/pre/post macros?

You can see them in the first post and also can download it from the drive links from the second post.

Danal

Ah, they are in the config zip. Got it.

Danal

Running:

Board: Duet 3 MB6HC (MB6HC)
DSF Version: 1.1.0.5
Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta12 (2019-11-02b1)

I see no evidence that the system attempts to restore the position of the carriage at the end of the toolchange, that is at the end of the 'post' macro.

If I have a G0 or G1 with R2, near the end of 'post', I can get it to restore. Without that, it stays wherever the last move in Post puts it, no matter where it was prior to the Tn command.

smoki3

@Danal

I don't know if there is a difference but I use a Duet 2 WiFi with duex5 on a corexy.

It has nothing to do with the tpost script. The problem is between the tfree and tpre and if you have defined tool offsets for both tools in all 3 axis.

And it also only happens if you do a direct tool change from Tx to Ty without a T-1.

With the first G1 X76 in the tpre script I expect that the printer is just moving in the X Axis but also the Y axis and the Z axis (like it will restore the old position of these axis just without the tool offset)

My assumption is that the tool offsets is not correctly deleted and the printer have the wrong coordinates. Because after the tfree tool off set is inactive.

Danal

I believe I see what is causing the move. I do not believe it is related to "G60 S2" or "G1 R2..." in any way.

The way the macros are written, and given these G10s in config.g, I'd expect a G1 move during a T1 T2 swap to move Y by about -73.8, even if Y were not specified in the move Gcode itself.

G10 P0 X0.0 Y74.5 Z-16.22 ; Set tool 0 axis offsets
G10 P1 X0.55 Y74.20 Z-16.28 ; Set tool 1 axis offsets
G10 P2 X0.06 Y74.00 Z-16.35 ; Set tool 2 axis offsets
G10 P3 X0.25 Y75.00 Z-16.10 ; Set tool 3 axis offsets

During 'tfree1' the offsets for tool 1 are active. At the end of 'tfree1' the machine does a state change to "T-1" (i.e. no tool mounted) and all tool offsets go away at that state change. This continues to be true during the execution of "tpre2", there is no tool mounted and therefore no offsets in force. That tool is only considered mounted at the end of "tpre2", and only then would the offsets (for tool 2) be in force.

Therefore, any G1 or G0 move will cause Y to move to where it would be with no (tool) offset applied. Whether Y is specified in the line of gcode or not.

Danal

This can be fixed two ways:

Make every move in 'tpre' macros have a g53.
Do very little in 'tpre' and do the actual mount and position of the tool in 'tpost'. During 'tpost', tool offsets will be active.

There is no right or wrong between these two... still I personally prefer (2).

smoki3

@Danal said in Tool Change: Moving in axis without calling them:

This can be fixed two ways:

Make every move in 'tpre' macros have a g53.

Do very little in 'tpre' and do the actual mount and position of the tool in 'tpost'. During 'tpost', tool offsets will be active.

There is no right or wrong between these two... still I personally prefer (2).

Yes this is the workaround that I am actually using. But it is not possible for the Z axis because in a print the Z height is variable.

But this a definitely a bug because in tpre.g tool offset is inactive so the should be no difference if I use a G53 or not. If you do a T-1 between the tool change you get a completely different behavior.

Danal

Just for reference, here is a set of files that does minimal work in 'pre' and does most of the work in 'post'.

http://danalspub.com/wp-content/uploads/2019/11/Backup-Toolchange-Jubilee-Nov-16-19-0945.zip

Keep in mind these files are NOT "golden" in any way... they just work on my machine.

Oh, and they are designed to move the new tool to the same position the old tool had before the tool change. If you don't want this, just take out the three G1 (or G0) commands at the end of 'post' that have the "R2" in them.

smoki3

@Danal
Why do you expect a Y movement?

With the end of the tfree.g the tool offset is gone. So every move you do after this is in the global coordinate system, no matter it was before with the activated tool offset. And the tool offset of the new tool get activated after the tfree.g (before the tpost.g)
And if I place my toolhead G53 G1 Y165 then it have to stay there until it gets another Y axis command. (same for the Z and X axis)

smoki3

@Danal said in Tool Change: Moving in axis without calling them:

Just for reference, here is a set of files that does minimal work in 'pre' and does most of the work in 'post'.

http://danalspub.com/wp-content/uploads/2019/11/Backup-Toolchange-Jubilee-Nov-16-19-0945.zip

Keep in mind these files are NOT "golden" in any way... they just work on my machine.

Oh, and they are designed to move the new tool to the same position the old tool had before the tool change. If you don't want this, just take out the three G1 (or G0) commands at the end of 'post' that have the "R2" in them.

I know there are many workarounds but it does not change the fact that this behavior is normal

Danal

I'd expect that move because that's my understanding of how g-code works, per the NIST standard.

The NIST spec defines the exact sequence of how coordinates are calculated for every move. "Running" that sequence of events for a G1 after a tool offset is removed WILL result in a move of an axis that is "no longer where it should be".

I could be wrong... but, given that the machine behaves the way the spec reads...

Danal

Of course, now I'm sitting here issuing sequences of M114, G10, G1, etc, etc, and I can't reproduce what I'm theorizing... so I probably am wrong...

I'll keep looking.

smoki3

@dc42
I found a video on the e3d forum where you can see the issue:

https://youtu.be/5RXE5qRVJgI

At 0:33 you can see the tool change and the moving Z-axis.

Danal

It seems likely to me that all the Z moves from between about :27 and :37 are coded into their pre/post/free macros. I have Z moves in mine, and they have to produce a good outcome no matter what the sequence of events. Therefore, moves occur during a regular single change that look a little weird. They are important when starting with no tool, or ending that way, or etc.

Danal

And, I have not had time to research this any further. I will be getting back to my toolchanging printer soon, to work out the final kinks. I will report back when I know something more about this issue.

smoki3

@Danal
no they are not coded. Just the lift of the nozzle before the tool change starts. Anything else is due to the fact that there is an issue after the tfree.g script with calculating the position.

If you do a T-1 and then a T1 you get a different behaviour. Then you dont have the Z-movement even though are running exactly the same scripts.

When you go back to 2.02 there you see you dont have this movements.

smoki3

@smoki3 said in Tool Change: Moving in axis without calling them:

@Danal
no they are not coded. Just the lift of the nozzle before the tool change starts. Anything else is due to the fact that there is an issue after the tfree.g script with calculating the position.

If you do a T-1 and then a T1 you get a different behaviour. Then you dont have the Z-movement even though are running exactly the same scripts.

When you go back to 2.02 there you see you dont have this movements.

I found this comment in the GCodes.cpp, which sound a bit like this bug @dc42

else if (rp != nullptr)
			{
				currentUserPosition[axis] = moveArg + rp->moveCoords[axis];
				// When a restore point is being used (G1 R parameter) then we used to set any coordinates that were not mentioned to the restore point values.
				// But that causes issues for tool change on IDEX machines because we end up restoring the U axis when we shouldn't.
				// So we no longer do that, and the user must mention any axes that he wants restored e.g. G1 R2 X0 Y0.
			}

Danal

@smoki3 said in Tool Change: Moving in axis without calling them:

and the user must mention any axes that he wants restored

Very interesting. I will keep that in mind as I research this further.

When you go back to 2.02 there you see you dont have this movements.

I can't run any version of 2; I am on Duet 3 hardware.

dc42

@smoki3 said in Tool Change: Moving in axis without calling them:

@smoki3 said in Tool Change: Moving in axis without calling them:

@Danal
no they are not coded. Just the lift of the nozzle before the tool change starts. Anything else is due to the fact that there is an issue after the tfree.g script with calculating the position.

If you do a T-1 and then a T1 you get a different behaviour. Then you dont have the Z-movement even though are running exactly the same scripts.

When you go back to 2.02 there you see you dont have this movements.

I found this comment in the GCodes.cpp, which sound a bit like this bug @dc42
else if (rp != nullptr)
			{
				currentUserPosition[axis] = moveArg + rp->moveCoords[axis];
				// When a restore point is being used (G1 R parameter) then we used to set any coordinates that were not mentioned to the restore point values.
				// But that causes issues for tool change on IDEX machines because we end up restoring the U axis when we shouldn't.
				// So we no longer do that, and the user must mention any axes that he wants restored e.g. G1 R2 X0 Y0.
			}

That change was introduced way back in firmware 1.19.

@Danal said in Tool Change: Moving in axis without calling them:

@smoki3 said in Tool Change: Moving in axis without calling them:

and the user must mention any axes that he wants restored

Very interesting. I will keep that in mind as I research this further.

When you go back to 2.02 there you see you dont have this movements.

I can't run any version of 2; I am on Duet 3 hardware.

I think the change in behaviour must be connected with this change, in the upgrade notes for 2.03:

Tool changers, IDEX printers and similar using tfree#.g and tpost#.g files: tool offsets are now applied within the tfree#.g and tpost#.g macros (but not in the tpre#.g file because no tool is selected at that point).

Perhaps there is a G1 command in the tfree or tpost file that needs to be corrected for tool offset, or else a G53 prefix added?