tpost.g does not apply tool offset

smoki3

I think in tfree you don't need tool offset because your "dock" is in the absolute coordinate system.

But if have tested the G54 command in the tpost.g. Now everything works as it should. And it does not influence tfree and tpre.

T3P3Tony

Following on from this - and other tool changer discussions. For me the logical behaviour is:

No tool selected (T-1): No tool offsets applied.
Tool selected (Tn): G10 Pn tool offsets applied.

That behaviour should endure no matter if a user or system macro is executing, or wherever the gcode is coming from. It creates significant confusion to have any other behaviour, especially where macros are tested by sending lines of g-code individually from the console first - and then putting them in the macro

Furthermore the tool change system macros should definitely adhere to this so:

Tpre - no tool is selected (T-1 state). no offsets applied
TPostn -Tn is selected so tool offsets for that tool are applied.
TFreen - Tn is still selected until this macro completes so offsets are applied (by definition, this is the macro that frees up the tool so the tool is still selected until this macro completes).

If the workspace co-ordinates should not be applied to system macros then that exception should be built into the workspace coordinate logic - not pollute the tool logic.

I get that conditional gcode would allow this to be worked around - but this should be the default behaviour.

mhackney

David, we've been discussing this in the E3D tool changer slack channel where there has been some confusion about how to set up firmware tool changes. A number of us were not using tpreX.g and instead "doing everything" in the tpostX.g. This has led to inconsistent pickups. I'm surprised it has worked at all but my machine has been commissioned since early January and I've done 1000s of tool changes. But every so often, a tool pickup goes wrong. This usually results in a "minor" crash but the the tool was still able to be picked up. For a while I attributed this to sensor-less homing not being consistent and needing some attention. But yesterday I just happened to be watching a tool pick up and noticed on the PanelDue the X coordinate was not what I was expecting. It was the tool dock position in machine coordinates - X305.0 - PLUS the tool offset in X which was 0.15. So I was seeing X305.15 and expected to see X305 - the position in machine coordinates that I used to configure dock positions.

But this was not consistent. Sometimes I'd see X305.0. It seemed to depend on whether this was the first tool being picked up or a new tool being changed in.
Long story short, I found this thread and thought about it and posted in the channel where Tony was responding to my questions. I now understand that the issue was that some/all/most of us in the E3D beta30 group are not using tpre macros - we do the tool pick up in tpost and tpre is empty.

I now understand what coordinate system is used with these scripts and that accounts for the "sometimes" odd behavior. It is surprising to me that it worked at all in retrospect.

In thinking about this and Tony's comments above, it seems that the tfree is still a bit unclear. Tony uses tool coordinates for his tfree but I and others use machine coordinates, yet that works - sort of, most of the time. I like the idea of explicitly putting a G53 in tfree before doing the undock movement sequence. I've implemented that and with the minimal testing, things seem much smoother. But, how about this proposal to clarify, simplify documentation and usage and provide the full range of functionality:

Proposal for clarifying names and consistency:

tdockX.g - machine coordinates, script to dock the tool
post-dockX.g - tool coordinates, anything you need to do after picking up the tool, like wiping
pre-undockX.g - tool coordinates, anything you need to do before releasing the tool
undockX.g - machine coordinates, undock the tool script

This would be clear (I have to admit that I find "post" by itself confusing. In CNC world we use "post" when discussing the post processors in our CAM to generate the g-code and I have a mill that refers to putting back a tool as "posting") and would simplify and clarify documentation while providing the needed functionality

T3P3Tony

Hi @mhackney thanks for posting all the background and your proposal. I think dock/undock would be equally confusing for all those who use the tool change macros but without a docking mechanism. The best example of this is the "mixing" hotends with multiple inputs and one output.

The naming aside, I think that at any point the tool is physically on the pickup head, tool coordinates should apply. Any time the tool is not on the pickup head, machine coordinates should apply. This has the advantage that you can troubleshoot individual lines in the tool change macros confident that what is observed when lines are entered individually is what will happen when the macro is run, anything that breaks this behaviour concerns me.

mhackney

@t3p3tony good point about tools, I've been in "tool changer world" for a few months but have printers with mixing tools (Cyclops, Diamond) as well.

Regarding your comment about when the tool is on the pickup head, my comment on this regards docking the tool. It seems error prone to require using the tool coordinate system to dock a tool that is on the head. That's why I suggested a new tool change file on the undocking side that would be in the machine coordinates.

I suppose David's comment above about using G53 to change to machine coordinates in the tfree scripts would suffice and that is what I am implementing now.

I also noticed in some tool change configuration (not sure if E3D was the source or one of the beta testers) that there were two scripts in /sys

offseton.g and offsetoff.g

Here is an example of offsetoff.g:

;R - Standby
;S - Active
;Z - Subtract = up

;Tool 0
G10 P0 X0 Y0 Z0

;Tool 1
G10 P1 X0 Y0 Z0

;Tool 2
G10 P2 X0 Y0 Z0

;Tool 3
G10 P3 X0 Y0 Z0

I think the intent was to move the G10s to this file and take them out of config.g

Then, one could call the offsetoff macro when they needed to move in machine coordinates and offseton when they need to move in tool coordinates. I do not know the origins of these and how they are actually configured (as both were X0 Y0 Z0). Perhaps someone here knows.

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.