tpost.g does not apply tool offset



  • Hi,

    I have a similar machine like the e3d tool changer. I am now trying to tweak the tool changer scripts.

    So now I noticed that the tpost.g doest not apply the tool offset. I try to call the nozzle clean feature in the tpost.g script. Then my printer is crashing because the tool offset is not applied at this moment.

    Is this by design or a bug?
    For me it makes no sense. Because if the tool offset is not applied in this script we can simply just use the tpre.g script. For my understanding the tpost.g script will be executed "post" the tool change. That means the tool is already aktive. But every movement is without the tool offset.


  • administrators

    I agree, that doesn't sound right. I'll look into this next week.


  • administrators

    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.



  • 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


  • administrators

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



  • 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.



  • 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?


  • administrators

    @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?


  • administrators

    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.



  • This post is deleted!


  • @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


  • administrators

    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.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.