Tool offset honored but not displayed correctly...

THP

Tool offset honored but not displayed correctly on Web Interface or PanelDue.
This has been a minor bug for me for a while (before 2.x rtos firmware) but not a concern for me until recently (if you read down, it is still not anything significant just very misleading/ confusing actions by the web interface and PanelDue).
I am running 2.02 RC6 currently on a custom IDEX build. If I call a tool change once, it will not update the z position to reflect the tool offset. If I call the tool change a second time, the position displayed is updated to include the proper extruder height offset. I have a Z limit switch so I have an offset on Z on the G10 command "G10 P0 X0 Y0 Z-.25 S0 R0" and "G10 P1 Y0.25 U5.25 Z-.01 S0 R0" in the config.g file.
The commands and positions are listed below as entered on the web interface to try to explain it. This starts with no tool selected but calls T-1 to clear tools to be sure. Note: Z axis does not physically move during this whole test.

G-Code	Z readout (mm)	Comment
G1 Z20 F200	20	Sets initial working height
T-1	20
T-1	20
T0 P0	20
T0 P0	19.75	This accounts for extruder offset
T-1 P0	19.75
T-1 P0	20.00

The same can be repeated for Tool 1 as shown above with Tool 0. The P0 at the end of the tool does not affect the final outcome. If I do a normal "T0" without the P0 added, the Z height is correctly reflected during the tool change, but as soon as the tool change is complete, the offset disappears.

Update before I even posted this. I tested more and it appears that the the position is respected by internally by the Duet, but not displayed on the web interface or PanelDue until a second call to the tool, or z motion is called.

Below is a new table showing the test. Note: I tested with and without "P0" with a Tx command and no difference was experienced.

G-Code	Z readout (mm)	Comment
T-1	20
T-1	20
G1 Z20 F200	20	Sets initial working height
T-1	20
T-1	20
T0	20	Did full tool change with purge. During tool change height changed to 19.75 but reset to 20 at the end of the tool change
G1 Z20 F200	20	Z axis moves as expected to compensate for length
T-1 P0	20
G1 Z20 F200	20	Z axis moves as expected

As noted earlier, it takes a z movement command to force an update in the position displayed or a second call to the same tool.

Let me know if you need/want my config file or tool change files.

Thanks,
THP

dc42

This behaviour is intentional, although I agree it is confusing. The reasons for it are:

The displayed coordinates are the coordinates in user space. Most of the time they are the coordinates from the last G0 or G1 command that was executed.
When you send a G1 or G0 command, for any axes that you don't specify, those are the coordinates that it default to.
When using a 2-head FDM printer, the heads often have slightly different Z offsets. When the slicer wants to change tool, it sends a Tn command to select the new tool, and a G1 Xxx Ynn command to position it. However, it typically won't include a Z coordinate. So on a tool change, it's important that the user Z coordinate is the same as it was before the tool change happened. This means that the firmware must not update the user Z coordinate, even though it doesn't accurately reflect the actual position.

I'm not sure that there is a good way to avoid this. It took a long time to get this behaviour "right" so that it works with all configurations of multi-head FDM printers. Possible solutions might include:

Require that all users of multi head FDM machines use tpost#.g files with a G1 R2 Z0 command at the end of each one;
Make the displayed coordinates different from the default coordinates for G0/G1 commands (although I think that could be very confusing)
Add an extra flag in the coordinate display to indicate that the tool isn't actually at the position displayed
Behave differently when the machine is in CNC mode not FDM mode

mwinterm

@dc42 First of all thank you for pointing me to the right thread.

I'm using a DuetWifi with the latest firmware 2.02 to control a CNC router and experience the same problem in the CNC context.

T0 ; select tool 0
G0 Z50 ; move to position Z50, position shows Z50
G10 P0 Z0 ; set tool lengths of tool 0 to 0
G10 P1 Z10 ; set tool lengths of tool 1 to 10
T1 ; select tool 1, position still shows Z50 instead of Z40
G91 ; go to relative positioning
G0 Z0 ; no movement is expected to occur however Z moves down 10 and now correctly indicates Z50
T0 ; select tool 0 again, position shows Z50 instead of Z60
G0 Z0 ; again no movement expected but Z moves up 10 and again correctly displays Z50

As explained by @dc42 the Z position is not updated after a tool change and with the first G0/G1 move the difference is noticed and compensated by an according move which obviously can make sense in a scenario when a tool change is executed between two tools / heads with very similar length.
However in a CNC setup this behavior is wrong and potentially dangergous as it leads to unexpected Z-movements which are not alwyas small as tool lengths can greatly vary (and believe me it is not fun when my 3.5t Mikron with a maximum table load of 1.1t makes unexpected moves... ;-0000
However I'm even doubtful that it is a good behavior for a dual head printer as the z-correction done with the first G0/G1 move (typically resulting in a slanted move) can potentially lead to a collision with already printed material when switching from the longer to the shorter tool. I think the Z-move to the correct height should be executed before any other movement. Therefore in my opinion @dc42 's first proposal (Require that all users of multi head FDM machines use tpost#.g files with a G1 R2 Z0 command at the end of each one) would be the way to go.

However I learned that selecting the tool twice is a work-around that is kind of solving the problem for me at the moment. But longer term there should be another solution as it is awkward and kind of hard to explain to CNC guys why the should always do two tool changes...

dc42

It's occurred to me that putting M400 at the end of tpost.g may work around this issue, because that should cause the user position to be updated from the machine position. Please try it.

mwinterm

@dc42 good idea and indeed the M400 updates the tool position. However if I put the M400 in the corresponding tpostX.g files the position is not updated and a corrective z-movement still happens with the next G0/G1 move. First I thought that the tpostX.g files are not executed. But then I modified tpost0.g to

G10 P0
M400
G10 P0

and the the other tpostX.g files accordingly. Now with every TX tool change command I get the tool information reported twice which shows that the scripts are executed. However the M400 is not updating the tool position when called in the tpostX.g. If I call it manually again after the T command everything it does its job again...

dc42

Thanks for trying it. I've now looked at the code and i can see why that doesn't work. I'm planning either a 2.02.1 or an early 2.03 release, and in that version I will have the user tool position corrected after a tool change when the printer is in CNC or laser mode.