tpost.g does not apply tool offset

dc42

I can't see anything wrong with how it is coded. However, just before the tpost.g file is run, the firmware updates the current user position based on where the head currently is. For example, suppose tool 0 has an X offset of -10mm and Y has an X offset of +20mm. You are using tool 0 and you move it to X=50. The head reference point will be at X=60. Then you execute T1. Assuming the tfree file doesn't move the head, at the start of tpost.g the HRP is still at X=60. So the current user X coordinate will be set to X=80, which is where the nozzle of tool 1 is.

Your situation is slightly different if you are using a tool changer. In your tpre file you are moving the X coordinate of the HRP to the correct position to pick up the tool, say it is at X=100. If the nozzle is 10mm to the right of the HRP, then the nozzle is at X=110, so when tpost starts the current X coordinate will be changed from 100 to 110. If your intention is to move the nozzle over a brush to clean it, this is exactly what you want.

If you still think there is a bug, please provide your tool change files and explain in more detail which tool change causes a problem and what happens.

smoki3

Thanks for you feedback. As I understand you explanation then we are on the same side.

But I have a Nozzlebrush script as an macro. Lets call it "nozzlebrush.g".

This macro moves the nozzle of any tool to the brush and clean it.

As soon I call this macro in tpost.g then my printer crashes, because at the moment the nozzlebrush.g is called still the old coordinate system is active.

If I run first T1 and after the tool change is finished i call nozzlebrush.g my printer is not chrashing and moves as it should to brush.

These are roughly my scripts:

tpre.g
G1 X50 F18000 ; Xpos of tool1
G1 Y200 ; Ypos of tool1
M280 P5 S180 ; lock tool
G1 Y100 ; move away from dock

tpost.g
M116 P1 ;wait heater
G1 Z0 R2 ; recovery Z Pos
M98 P"/macros/nozzlebrush.g"

nozzlebrush.g
G1 X220 Y100 F18000 ; brush pos
G1 Y80 F1000

dc42

In which axis is the tool offset that you say is not being applied?

smoki3

It in X and Y axis. I did now a detailed analysis and I unfortunately broke my printer

But I have some results:

This is my tool offset:
G10 P2 X5.32 Y46.45 Z-13.12

and this my tpost.g
M116 P2 ; wait for heater
M106 R2 ; restore fan
G1 E5 F2000 ; unretract after tool change
M703 ; filament config
G1 R2 Z0 F720 ; move Z to print position
G1 X189 Y175 ; added for testing
M42 P5 S0 ; Turn off servo

So my expectation is that the nozzle is after the tool change at pos. X189 Y175. But it isn't - it is at X194.32 Y221.45.
You can see the printer moves without the tool offset to the marked position and than applies the offset. I also can see this while moving on the paneldue. After it finished the movement then it applies the offset.

I hope it get more clear now.

smoki3

case GCodeState::m109ToolChange2:	// Select the new tool (even if it doesn't exist - that just deselects all tools) and run tpost
		if (LockMovementAndWaitForStandstill(gb))		// wait for tpre.g to finish executing
		{
			reprap.SelectTool(gb.MachineState().newToolNumber, simulationMode != 0);
			UpdateCurrentUserPosition();					// get the actual position of the new tool

			gb.AdvanceState();
			if (AllAxesAreHomed())
			{
				if (reprap.GetTool(gb.MachineState().newToolNumber) != nullptr && (gb.MachineState().toolChangeParam & TPostBit) != 0)
				{
					String<ShortScratchStringLength> scratchString;
					scratchString.printf("tpost%d.g", gb.MachineState().newToolNumber);
					DoFileMacro(gb, scratchString.c_str(), false);
				}
			}
		}
		break;

Does UpdateCurrentUserPosition(); apply the tool offset? Should there not something called like tooloffsetTransform?

dc42

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

case GCodeState::m109ToolChange2: // Select the new tool (even if it doesn't exist - that just deselects all tools) and run tpost
if (LockMovementAndWaitForStandstill(gb)) // wait for tpre.g to finish executing
{
reprap.SelectTool(gb.MachineState().newToolNumber, simulationMode != 0);
UpdateCurrentUserPosition(); // get the actual position of the new tool
  	gb.AdvanceState();
  	if (AllAxesAreHomed())
  	{
  		if (reprap.GetTool(gb.MachineState().newToolNumber) != nullptr && (gb.MachineState().toolChangeParam & TPostBit) != 0)
  		{
  			String<ShortScratchStringLength> scratchString;
  			scratchString.printf("tpost%d.g", gb.MachineState().newToolNumber);
  			DoFileMacro(gb, scratchString.c_str(), false);
  		}
  	}
  }
  break;
Does UpdateCurrentUserPosition(); apply the tool offset? Should there not something called like tooloffsetTransform?

UpdeateCurrentUserPosition calls GetCurrentUserPosition (which is a misnomer because it actually returns the machine position in Cartesian coordinates), then it calls ToolOffsetInverseTransform to work out the user coordinates that correspond to that machine position.

PS - which firmware version are you using?

dc42

I confirm that the behaviour is not as expected. I created a tool with G10 X and Y offsets of +10mm each, and I put G1 X50 Y50 in the tpost file. It ended up at X60 Y60 in user coordinates.

I will investigate this.

smoki3

This post is deleted!

smoki3

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

I confirm that the behaviour is not as expected. I created a tool with G10 X and Y offsets of +10mm each, and I put G1 X50 Y50 in the tpost file. It ended up at X60 Y60 in user coordinates.

I will investigate this.

Thanks! I am ok fw 2.02

dc42

I've found the reason for the difference in behaviour. Whenever any system macros are run automatically, RRF uses machine coordinates not user coordinates. The primary reason for this is to avoid applying workplace coordinate offsets. For example, if you are using workplace coordinates and you want to home the machine or do a tool change, then you don't want to apply the workplace coordinate offset to the moves that home the printer or swap the tool. Following a discussion with CNC users several weeks ago, RRF treats tool offsets in the same way as workplace coordinate offsets.

If you never use workplace coordinate systems, then a workaround is to select a workplace coordinate system in your tpost file. For example, you can put G54 at the start of tpost.g to select workplace coordinate system #1.

For the future, it might make sense for RRF to ignore workplace coordinates in system macro files but to apply tool offsets (they would then be applied in the tfree and tpost files, but not in tpre because on tool is selected at that point). Bear in mind that this would affect your tfree file, because the XYZ coordinates that you move the tool to when docking it would be adjusted by the tool offset; unless you used G53 to specify machine coordinates.

smoki3

@dc42 that's wired. May it make sense to don't apply it to the system macros but as soon a user macro is called it uses the tool offset.

Because for tpre and tfree it makes sense to be independent from the tool offset.
Or we have a bit in M98 to choose which coordinate system is called

dc42

I don't see why it would make sense in the general case to apply tool offset by default to tpost but not to tfree, because in either case a tool is selected.

I can think of a few solution:

Provide a command to specify that you don't want workplace coordinates to be used but you do want to use tool offsets. Possibly a parameter to the G53 command.
When conditional GCode and variables are implemented, you will be able to add tool offsets explicitly if you need to.

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!