Tool Change: Moving in axis without calling them

smoki3

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

I understand why offsets are/aren't applied. They correlate to the "what tool number is currently mounted" status of the printer.

Therefore, I have G53 in front of the vast majority of the moves, because those moves need to deal with the parking posts in absolute terms.

I'll see if I can reproduce what happens in the above vids.

As you can see in my tpre script I also have G53 in front of every move. That this diagonal move does not exist in the script and only happens if you directly move from T0 to T1 if you do a T0 → T-1 → T1 it does not happen.

But I am not able to see at which coordinates. this diagonal move ends

smoki3

So I adjusted the tool offset not to this:

; Tooloffset
G10 P0 X0.00 Y50 Z0.0                    ; Set tool 0 axis offsets
G10 P1 X0.00 Y0 Z0.0                   ; Set tool 1 axis offsets

Then it looks like this:

https://photos.app.goo.gl/MzJ7iRV5FMb3namx7

As you can see the printer is moving diagonal 50mm in X axis (from the tpre.g) and Y axis (from removing the tool offset). The Z movement is gone because there is not Z tool offset defined.

Normaly it should just release T0 and move just 50mm in X axis as defined in the tpre script.

dc42

Please try the firmware at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. Running the Duet 2 version of this firmware on my tool changer, I don't see any diagonal moves, where as I did when running RRF 2.

Note, currently you cannot downgrade from this firmware via Duet Web Control when running with an attached SBC. That will be fixed shortly. Meanwhile, you can downgrade by running in standalone mode or by using Bossa.

smoki3

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

Please try the firmware at https://www.dropbox.com/sh/3azy1njy3ayjsbp/AACquxr2m00eV568RZg5QG5wa?dl=0. Running the Duet 2 version of this firmware on my tool changer, I don't see any diagonal moves, where as I did when running RRF 2.

Note, currently you cannot downgrade from this firmware via Duet Web Control when running with an attached SBC. That will be fixed shortly. Meanwhile, you can downgrade by running in standalone mode or by using Bossa.

The videos from above already with RRF3. This problem exists since 2.3 equal to RRF. With the tool changer scripts from E3D they bypass this bug because of calling X and Y axis in the first move of the tpre script. But there you can still see the Z axis movement during the first tpre move

smoki3

@dc42

So tested it again now. It happens exactly the same as you can see on post 25.

If I move the whole tpre script to the tpost and add G53 in front of every G1 then it works fine.

The problem is: The not called axes are moving exactly the distance of the tool offset from the cleared tool instead of just update the coordinates for the not called axes and just move the called axis.

There were the changes in 2.03:

May 25th:

Restore points (created by G60 and created automatically at the start of a pause or a tool change) now have their coordinates stored independently of any workplace offsets. So if you create a restore point and then change the workplace offsets, when you go back to the restore point it will go back to the same machine position regardless of the change in workplace offsets.

and this March 3rd:

-- Tool changers, IDEX printers and similar using tpre#.g and tpost#.g files: tool offsets are now applied within the tpre#.g and tpost#.g macros.

I assume that one of these leads to the bug.

dc42

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

So tested it again now. It happens exactly the same as you can see on post 25.

Is that with the RRF3 binary that I linked to, with build date yesterday?

smoki3

This post is deleted!

smoki3

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

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

So tested it again now. It happens exactly the same as you can see on post 25.

Is that with the RRF3 binary that I linked to, with build date yesterday?

Yes, downloaded it today and tested it 10 mins ago.

Build:
RepRapFirmware for Duet 2 WiFi/Ethernet 3.0RC1 (2019-12-14b5)

Danal

I am trying to get setup to test this with your exact files (except for absolute coordinates of the tool parking, of course).

More later today...

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+1 (2019-12-02b2)

I backed up all my pre/post/free files and copied yours in exactly. I set a Y tool1 offset of 25.

I do not see any diagonal moves occur. T0 T1, T0 T-1 T1, no sequence I've tried produces a diagonal move.

I DO see the final Y coordinate displayed in DWC for T1 jump from 100 to 125, when the T1 sequence ends.

smoki3

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

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+1 (2019-12-02b2)

I backed up all my pre/post/free files and copied yours in exactly. I set a Y tool1 offset of 25.

I do not see any diagonal moves occur. T0 T1, T0 T-1 T1, no sequence I've tried produces a diagonal move.

I DO see the final Y coordinate displayed in DWC for T1 jump from 100 to 125, when the T1 sequence ends.

You have to set the tool offset for T0. Best you try it to set the offset for both tool in all 3 axis. It's always from the tool which is clear.

I don't think the movement calculation is different for duet 3 and duet 2.

Here the issue exists and on all the tool changer videos on YouTube you see it as well (moving z axis after tfree)

Danal

I will give that a try. I'll just copy your tool offsets exactly.

Danal

OK, I have reproduced the diagonal move.

Interestingly enough, I then put messages (m117) and delays (G4) in the tpre1.g file... and the diagonal move WENT AWAY. Very, very, odd.

At this moment, I'm experimenting with delays and similar to find out exactly which command causes the diagonal move.

Danal

OK, to summarize: With exact copies of @smoki3 files, including the pre/post/free and the tool offset, the diagonal move is reproduced on my machine. Which is a CoreXY 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+1 (2019-12-02b2)

With all XYZ on the main board, only tools on the expander boards.

Some experimentation also shows:

A delay, such as G4 S1, positioned before any other commands in tpre1.g, stops the diagonal.
An M400, positioned before any other commands in tpre1.g, stops the diagonal. Note that I removed all the other M400s.
G53 in front of all move commands in tpre1.g has no effect, the diagonal still occurs.

Given that this appears to be timing sensitive, it begins to make more sense why exact copies of the files are needed to reproduce.

Anyway, I hope this helps dc42 figure out what's going on.

smoki3

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

OK, to summarize: With exact copies of @smoki3 files, including the pre/post/free and the tool offset, the diagonal move is reproduced on my machine. Which is a CoreXY 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+1 (2019-12-02b2)

With all XYZ on the main board, only tools on the expander boards.
Some experimentation also shows:

A delay, such as G4 S1, positioned before any other commands in tpre1.g, stops the diagonal.

An M400, positioned before any other commands in tpre1.g, stops the diagonal. Note that I removed all the other M400s.

G53 in front of all move commands in tpre1.g has no effect, the diagonal still occurs.

Given that this appears to be timing sensitive, it begins to make more sense why exact copies of the files are needed to reproduce.

Anyway, I hope this helps dc42 figure out what's going on.

Thanks for the nice analysis.

Good point with the timing. It also makes sense. I sure @dc42 will fix it. Maybe already for 3.0RC1

smoki3

So I also tried a M400 in the first line of the tpre script. Then everything is fine

smoki3

I also noticed that you have this diagonal movement when you dock your tool after the print. But as Danal mentioned it only happen if directly after the tfree script a G1 follows.

dc42

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

So I also tried a M400 in the first line of the tpre script. Then everything is fine

Thanks, from that I think I know what is going on, and I can fix it in 3.0 release.

smoki3

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

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

So I also tried a M400 in the first line of the tpre script. Then everything is fine

Thanks, from that I think I know what is going on, and I can fix it in 3.0 release.

Cool! So please also merge it to 2.xx

dc42

@smoki3, I have fixed this in the 3.0 stable release.

I am not planning to do any further 2.x releases, but you have an easy workaround (M400 at the start of the tpre and/or tpost file).