tpost.g does not apply tool offset

[dc42]

Hi Michael,

Each timed message block that DWC displays shows the command that DWC thinks was responsible for those messages, followed by the messages, with the earliest one at the top. So the actual sequence that DWC performed was:

Sent T1
Received "enter tpre3"
Assume that the response to the T3 command was complete, so display a message block timed at 12:57:36
Receive "exit tpre3"
Receive "enter tpost3"
Time out waiting for a further response, so display a message block timed at 12:57:39
Receive "exit tpos3"
Time out waiting for a further response, so display a message block timed at 12:57:47

and so on.

What we need is a mechanism that works well not only for tool changers but also for IDEX machines, single head multiple nozzle machines, and as many other possibilities that we can envisage.

This is how we got here:

1. I added support for workplace coordinate offsets, needed by the CNC community.
2. It is clear that workplace coordinate offsets should not be used when homing, performing tool changes, pausing etc. So I added code to not apply workplace coordinate offsets when system macro files are being run. I did this by implementing a "sticky G53" bit and setting it at the start of running a system macro file.
3. The CNC community complained that when G53 is in effect, tool offsets should not be applied. So I modified the effect of G53 to suppress the use of tool offsets as well as the use of workplace coordinate offsets.

What I think is needed is to have separate bits for suppressing use of tool offsets and suppressing workplace coordinate offsets. So workplace coordinate offsets would still be suppressed in system macro files, but tool offsets would be used in tfree and tpost. You would be able to issue movement commands with tool offsets suppressed by prefixing those G1 commands with G53.

[mhackney]

Thanks for the detail David.

In the meantime, I've implement the offsetson.g and offsetsoff.g macros I mentioned above. It turns out that Greg at E3D originated them and my friend Roy implemented it on our tool changer OpenCore machine yesterday (although it only has 1 tool to test at this time) and was successful. So I changed my E3D tool changer today and am getting the cleanest, quietest tool changes on all combinations of first tool, tool change, last tool put back that I've ever had. Here is what we did:

1. did not use any of the tpreX macros, everything is in tpostX and tfreeX
2. created the offsetsoff.g as shown above that clears offsets for all tools
3. create an offsetson.g configured to enable the offsets for all tools
4. removed the offset G10s from config.g
5. in tpostX.g, call the offsetsoff.g macro immediately at the start of the file. Perform all docking movements. Then call offsetson.g before moving to the wipe area or in my case, calling the wipe macro
6. in tfreeX.g call offsetsoff.g immediately at the start of the file or after any wipe movements if you have them but before the docking movements

I've only done 50ish tool changes so far but everyone of them have been quiet. In the past few months, 50 changes would have had knocks and bangs and clanks!

[T3P3Tony]

@dc42 just following up on this. Its good that the users can use macros to work around the issue with tool/workspace etc coordinated but I think its important to confirm how it does and should work.

[dc42]

In the next beta I am changing it so that in system macros, tool offsets will be applied but workplace coordinates will not.

[mhackney]

Well, the situation got more confusing! I thought the explicit offsetson/offsetsoff macros solved the problem, and they did but only partially.

The original issue described above with docking positions was solved bu using the offsetson/offsetsoff macros. However, on my tool changer I have two Bowden V6 tools as T0 and T1 and two Titan Aero direct drive tools as T2 and T3. The tool offsets for these Aeros are significantly different than T0 and T1. So I needed to add a second wipe brush to the right side of the printer for T2. Because of the size of the tool, its nozzle is over the bed when the tool just misses the top plate on the left side of the machine, so it doesn't reach the wipe brush. And this is where all heck breaks loose.

I've done a set of experiments testing all combinations of tpre2, tpost2 scripts that have the printer coordinates for the brush location (X294.0 Y170.0 should be the starting point of the brush wipe in machine coordinates) embedded in the tpost or tpre script itself or called as an external macro. I've called the offsetson/offsetsoff macros before and after the code to move to the wipe tower. In every case, the tool (2) tip is not positioned at the correct place to initiate the wipe and in all cases it is the same wrong location. In some cases, the DWC shows the correct position (X294.0 Y170.0) and others it shows the position as the position with the T2 offset applied. But in all cases 1) the tool pickups that happen in machine coordinates are perfect and 2) the tool nozzle does not position itself to wipe on the brush correctly and all combines end up with the nozzle in the same incorrect place. This is very perplexing. If I run g-code to print, all is fine with the print but the tool wipe for T2 misses the brush.

Although I've focused on T2 above, this issue also applies to the other tools. Since T0 and T1 are so similar, you have to pay close attention but can indeed see the slight difference in brush starting position. T3 wipes on the left side and is very similar X to to T0 and T1 but it's Y offset is larger so it misses the brush in Y (it is too far back from the actual wipe starting position.

This is incredibly consistent. Does not matter if I use pure tool scripts or use the offsetson/offsetsoff macros discussed above.

I'm wondering if I'm seeing this issue because I have significantly different tool XY offsets for these tools whereas most tool changers are using the same tool for all 4 tools.

[smoki3]

@dc42 will it then also applied in tpre and tfree?

[dc42]

@smoki3 said in tpost.g does not apply tool offset:

@dc42 will it then also applied in tpre and tfree?

tfree - yes.
tpre - no, because no tool is selected when that file is run.

[smoki3]

@dc42 then we need an option to disable it in tfree. Because a dock and a parking position will never in the tool coordinate system

[dc42]

@smoki3 said in tpost.g does not apply tool offset:

@dc42 then we need an option to disable it in tfree. Because a dock and a parking position will never in the tool coordinate system

You will be able to prefix movement lines with G53 to do that.