tpost.g does not apply tool offset

mhackney

David, I'm investigating further because even after modifying my tool change scripts, I am seeing odd behavior.

My T3 has a dock position (machine coordinates) at X305.0 - so it is convenient to watch.
I created a tpreX.g files for each tool that positions to the machine coordinates for each tool and picks up the tool then backs out.

I edited my tpostX.g files to remove all code except the wait for the hot end to warm up and then call a macro to wipe the nozzle on my wipe brush

I edited my tfreeX.g files to add a G53 before any movement code to dock - which is all in machine coordinates and matches the coordinates in the tpre files

Now the fun begins... (I'll post the files for T3 at the end of this)

I homed and clicked Select in the Tools tab in Settings. I watched the head move to X305.1 !!! and dock harshly. I then undocked and that was also done at X305.1.

Firstly, my T3 X offset in G10 is X0.15 (not 0.10).

Wanting to dig in a bit I decided to put some debugging "print" statements in. So I added print code at the entry and exit of each of the 3 files like this:

M400
M118 P0 S"enter tpre3: "
M114

(with the appropriate string in M118 of course)

I also added the print to tfree3.g after I do a G53 to change to machine coordinates. That looks like:

G53 ; move to machine coordinate system

; move to dock
G1 X305.0 Y190.0 F15000
M400
M118 P0 S"moved to dock in tfree3: "
M114

Notice that I do a move to X305.0 after calling G53 and then the print messages happen

So now, I again home and run the tool change for T3 with the Select/Deselct buttons.

Here is the output for Select followed by Deselect T3 (starting with an empty tool head):

ANALYSIS
From the bottom up of the logs:

So from bottom up (first command is at bottom):

CLICK SELECT

tpre3 was called and it movement happening in machine coordinates
T3 issued - this must be coming from the firmware before tpost3 is called
tpost3 is entered - this is done BEFORE tpre3 was completed! X position is in tool coordinates (X305.15)
tpre3 is exited and once again in machine coordinates X305.0
tpost3 is exited

CLICK DESELECT

tfree3 is entered
T-1 issued
move to dock X305.15 is in tool coordinates - this was printed AFTER G53 was called and a movement in X was made. It should have been X305.0 from my understanding
tfree3 is exited and left in tool coordinates

So I am completely baffled by a few things...
And this of course depends on if this data is reliable...

Where does the initial X305.1 that I observe on occasion come from?
Why is the move to the dock in tpre3.g in tool coordinates X305.15?

I am baffled that my tool changer worked before and even more baffled that it works now!

Here ate the T3 scripts:
2_1551377659258_tpre3.g 1_1551377659258_tpost3.g 0_1551377659255_tfree3.g

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:

I added support for workplace coordinate offsets, needed by the CNC community.
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.
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:

did not use any of the tpreX macros, everything is in tpostX and tfreeX
created the offsetsoff.g as shown above that clears offsets for all tools
create an offsetson.g configured to enable the offsets for all tools
removed the offset G10s from config.g
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
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.