Tool Change: Moving in axis without calling them



  • It seems that 2.xx (2.02 is fine) and 3.xx have an issue with the tool offsets if you use a tool changer.

    If I do a tool change directly from T1 to T2 for example then the printer crashes because it want to recover his old position.
    If I do a tool change from T1 to T-1 and then to T2 everything is fine.

    It looks like if I do a direct change there is a issue when the tool offsets is deleted or applied. It seems that between the last move of tfree0.g and the first move of tpre1.g it is doing a recovery of the old position ( G1 R2).

    @dc42
    It was definitely not like this on 2.02 and the older 3.0.

    And its a really wired behaviour. Because I use:

    ; tfree0.g
    ; called when tool 0 is freed
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
    G91
    G1 Z10 F7200
    G90
    G53 G1 X0 F25000 ;XPOS
    G53 G1 Y190
    G53 G1 Y195 F5000
    M400
    M98 P"/macros/Toolhead/1. Toolhead unlock"
    G4 P320
    G53 G1 Y207 F5000
    M400
    G53 G1 Y165 F25000
    M400
    
    ; tpre1.g
    ; called before tool 0 is selected
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
    G1 X76 F25000
    M400
    G1 Y192
    M400
    M98 P"/macros/Toolhead/1. Toolhead unlock"
    G4 P400
    G1 Y207 F5000
    M116 P3
    M400
    M98 P"/macros/Toolhead/2. Toolhead lock"
    G4 P260
    G1 Y150 F15000
    

    The I only expect that only a X movement is done while the start of the tpre1.g but it first moves in X and Y.

    I copied something together to track this issue here:

    @dc42 said in New RepRapFirmware 3.0 early beta:

    If you read the firmware update motes for 2.03 you will see that tool offsets are now applied during tfree and tpost (but still not in tpre). Does that explain the issue? You can use G53 to prevent tool offsets being applied.

    That change I now, as you can see in my script they already include G53 commands in the tfree.g

    But the problem is:

    Look at the last movement of my tfree.g: It move to G53 Y165 (no tool offset)
    Then the script is finished. Then it starts with the G1 X76 in the tpre (still no tool offset)

    What I then expect is that the printer is just moving form G53 X0 (from the tfree.g) to the G1 X76.
    But it is also moving in the Y axis.

    For me it sound like more that it is a bug of this change:

    What new:

    Restore points (created by G60 and created automatically at the start of a pause or a tool change) now have their coordinates stored independently of any workplace offsets. So if you create a restore point and then change the workplace offsets, when you go back to the restore point it will go back to the same machine position regardless of the change in workplace offsets.
    

    It seem like it is restore the old positions from the tool coordinate system during a tool change. Because also tries to restore the Z position during the tool change.

    Means if you positioned the tool with G53 Y165 in the machine coordinate system then the tool stays at Y210 (depending on the tool offset) in the workplace coordinate system. Then you drop the tool! With the next movement of the tpre.g it tries to move with the machine cordnatesystem to Y210. Which is wrong at this point because for the tpre.g no tool offset is applied and it should just move in the axis you are calling.

    There is a workaround for this issue:
    If you put in the tpre.g the same command (G53 G1 Y165 F25000) on the first place then the printer is just restoring the Z position and the you can start with the tool change

    We already discussed in detail about this issue long time ago: https://forum.duet3d.com/topic/11343/new-reprapfirmware-3-0-early-beta/30



  • Your post from 15.08.2019:

    @dc42 said in New RepRapFirmware 3.0 early beta:

    @smoki3 said in New RepRapFirmware 3.0 early beta:

    That change I now, as you can see in my script they already include G53 commands in the tfree.g
    But the problem is:
    Look at the last movement of my tfree.g: It move to G53 Y165 (no tool offset)
    Then the script is finished. Then it starts with the G1 X76 in the tpre (still no tool offset)
    What I then expect is that the printer is just moving form G53 X0 (from the tfree.g) to the G1 X76.
    But it is also moving in the Y axis.
    For me it sound like more that it is a bug of this change:

    Please clarify. Are you saying that the G1 X76 command in tpre causes a move in the Y direction too? If so then this is certainly a bug. The coordinates stored in the tool change restore point should only be relevant at the end of the entire tool change sequence.

    My Post from 15.08.2019

    @dc42 Yes the G1 X76 also do a move in the Y direction. Also the Z axis is moving.

    It restores the coordinates where the nozzle was before. The reference point of the printer tries to reach the point where the nozzle was before.

    The only way actually can avoid this behavior is to put also a G53 G1 Y165 into the tpre.g script. Then only a Z move is done (but also this movement shouldn't be done).

    @dc42 I switched now back to 2.02.

    Here is everything fine. Also 2.04 and 2.03 has this issue. I tried also the old v3 build from the dropbox. Here also everthing is fine.

    I assume that it has something to do with the commits from May 25th.

    My post from 20.08.2019

    @dc42
    I have done some further testing:

    If I put not only "G1 X76" at the beginning of the tpre rather a "G1 X76 Y165" (Y165 same Y position as tfree) then just the X axis and Z axis is moving and Y axis stays as it should. Anyway the Z axis shouldnt move at this point.

    So if you don't but every single axis into the first command of tfree it will restore the old position of the tool head

    Your post from 23.08.2019

    https://forum.duet3d.com/topic/11343/new-reprapfirmware-3-0-early-beta/51

    My config from 29.08.2019

    @dc42 said in New RepRapFirmware 3.0 early beta:

    @smoki3 said in New RepRapFirmware 3.0 early beta:

    @dc42
    It was definitely not like this on 2.02 and the older 3.0.

    And its a really wired behaviour. Because I use:

    ; tfree0.g
    ; called when tool 0 is freed
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
    G91
    G1 Z10 F7200
    G90
    G53 G1 X0 F25000 ;XPOS
    G53 G1 Y190
    G53 G1 Y195 F5000
    M400
    M98 P"/macros/Toolhead/1. Toolhead unlock"
    G4 P320
    G53 G1 Y207 F5000
    M400
    G53 G1 Y165 F25000
    M400
    
    ; tpre1.g
    ; called before tool 0 is selected
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
    G1 X76 F25000
    M400
    G1 Y192
    M400
    M98 P"/macros/Toolhead/1. Toolhead unlock"
    G4 P400
    G1 Y207 F5000
    M116 P3
    M400
    M98 P"/macros/Toolhead/2. Toolhead lock"
    G4 P260
    G1 Y150 F15000
    

    The I only expect that only a X movement is done while the start of the tpre1.g but it first moves in X and Y.

    @smoki3, I am looking into this but I need your config.g file, also the toolhead unlock files that you call from the tool change files.

    I uploaded my config files and my tool changer macros:

    Config:
    https://drive.google.com/file/d/1xQ5j9E2WvJNFzIum62W02iligk8rOv4T/view?usp=sharing

    Macros:
    https://drive.google.com/file/d/1QcHqPQBpafr3AlDOjGM3XtQ7nB4VcalO/view?usp=sharing



  • May we also see the tfre/pre/post macros?



  • @Danal said in Tool Change: Moving in axis without calling them:

    May we also see the tfre/pre/post macros?

    You can see them in the first post and also can download it from the drive links from the second post.



  • Ah, they are in the config zip. Got it.



  • Running:

    Board: Duet 3 MB6HC (MB6HC)
    DSF Version: 1.1.0.5
    Firmware: RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 3.0beta12 (2019-11-02b1)

    I see no evidence that the system attempts to restore the position of the carriage at the end of the toolchange, that is at the end of the 'post' macro.

    If I have a G0 or G1 with R2, near the end of 'post', I can get it to restore. Without that, it stays wherever the last move in Post puts it, no matter where it was prior to the Tn command.



  • @Danal

    I don't know if there is a difference but I use a Duet 2 WiFi with duex5 on a corexy.

    It has nothing to do with the tpost script. The problem is between the tfree and tpre and if you have defined tool offsets for both tools in all 3 axis.

    And it also only happens if you do a direct tool change from Tx to Ty without a T-1.

    With the first G1 X76 in the tpre script I expect that the printer is just moving in the X Axis but also the Y axis and the Z axis (like it will restore the old position of these axis just without the tool offset)

    My assumption is that the tool offsets is not correctly deleted and the printer have the wrong coordinates. Because after the tfree tool off set is inactive.



  • I believe I see what is causing the move. I do not believe it is related to "G60 S2" or "G1 R2..." in any way.

    The way the macros are written, and given these G10s in config.g, I'd expect a G1 move during a T1 T2 swap to move Y by about -73.8, even if Y were not specified in the move Gcode itself.

    G10 P0 X0.0 Y74.5 Z-16.22 ; Set tool 0 axis offsets
    G10 P1 X0.55 Y74.20 Z-16.28 ; Set tool 1 axis offsets
    G10 P2 X0.06 Y74.00 Z-16.35 ; Set tool 2 axis offsets
    G10 P3 X0.25 Y75.00 Z-16.10 ; Set tool 3 axis offsets

    During 'tfree1' the offsets for tool 1 are active. At the end of 'tfree1' the machine does a state change to "T-1" (i.e. no tool mounted) and all tool offsets go away at that state change. This continues to be true during the execution of "tpre2", there is no tool mounted and therefore no offsets in force. That tool is only considered mounted at the end of "tpre2", and only then would the offsets (for tool 2) be in force.

    Therefore, any G1 or G0 move will cause Y to move to where it would be with no (tool) offset applied. Whether Y is specified in the line of gcode or not.



  • This can be fixed two ways:

    1. Make every move in 'tpre' macros have a g53.

    2. Do very little in 'tpre' and do the actual mount and position of the tool in 'tpost'. During 'tpost', tool offsets will be active.

    There is no right or wrong between these two... still I personally prefer (2).



  • @Danal said in Tool Change: Moving in axis without calling them:

    This can be fixed two ways:

    1. Make every move in 'tpre' macros have a g53.

    2. Do very little in 'tpre' and do the actual mount and position of the tool in 'tpost'. During 'tpost', tool offsets will be active.

    There is no right or wrong between these two... still I personally prefer (2).

    Yes this is the workaround that I am actually using. But it is not possible for the Z axis because in a print the Z height is variable.

    But this a definitely a bug because in tpre.g tool offset is inactive so the should be no difference if I use a G53 or not. If you do a T-1 between the tool change you get a completely different behavior.



  • Just for reference, here is a set of files that does minimal work in 'pre' and does most of the work in 'post'.

    http://danalspub.com/wp-content/uploads/2019/11/Backup-Toolchange-Jubilee-Nov-16-19-0945.zip

    Keep in mind these files are NOT "golden" in any way... they just work on my machine.

    Oh, and they are designed to move the new tool to the same position the old tool had before the tool change. If you don't want this, just take out the three G1 (or G0) commands at the end of 'post' that have the "R2" in them.



  • @Danal
    Why do you expect a Y movement?

    With the end of the tfree.g the tool offset is gone. So every move you do after this is in the global coordinate system, no matter it was before with the activated tool offset. And the tool offset of the new tool get activated after the tfree.g (before the tpost.g)
    And if I place my toolhead G53 G1 Y165 then it have to stay there until it gets another Y axis command. (same for the Z and X axis)



  • @Danal said in Tool Change: Moving in axis without calling them:

    Just for reference, here is a set of files that does minimal work in 'pre' and does most of the work in 'post'.

    http://danalspub.com/wp-content/uploads/2019/11/Backup-Toolchange-Jubilee-Nov-16-19-0945.zip

    Keep in mind these files are NOT "golden" in any way... they just work on my machine.

    Oh, and they are designed to move the new tool to the same position the old tool had before the tool change. If you don't want this, just take out the three G1 (or G0) commands at the end of 'post' that have the "R2" in them.

    I know there are many workarounds but it does not change the fact that this behavior is normal 🙂



  • I'd expect that move because that's my understanding of how g-code works, per the NIST standard.

    The NIST spec defines the exact sequence of how coordinates are calculated for every move. "Running" that sequence of events for a G1 after a tool offset is removed WILL result in a move of an axis that is "no longer where it should be".

    I could be wrong... but, given that the machine behaves the way the spec reads...



  • Of course, now I'm sitting here issuing sequences of M114, G10, G1, etc, etc, and I can't reproduce what I'm theorizing... so I probably am wrong... 🙂

    I'll keep looking.



  • @dc42
    I found a video on the e3d forum where you can see the issue:

    https://youtu.be/5RXE5qRVJgI

    At 0:33 you can see the tool change and the moving Z-axis.



  • It seems likely to me that all the Z moves from between about :27 and :37 are coded into their pre/post/free macros. I have Z moves in mine, and they have to produce a good outcome no matter what the sequence of events. Therefore, moves occur during a regular single change that look a little weird. They are important when starting with no tool, or ending that way, or etc.



  • And, I have not had time to research this any further. I will be getting back to my toolchanging printer soon, to work out the final kinks. I will report back when I know something more about this issue.



  • @Danal
    no they are not coded. Just the lift of the nozzle before the tool change starts. Anything else is due to the fact that there is an issue after the tfree.g script with calculating the position.

    If you do a T-1 and then a T1 you get a different behaviour. Then you dont have the Z-movement even though are running exactly the same scripts.

    When you go back to 2.02 there you see you dont have this movements.



  • @smoki3 said in Tool Change: Moving in axis without calling them:

    @Danal
    no they are not coded. Just the lift of the nozzle before the tool change starts. Anything else is due to the fact that there is an issue after the tfree.g script with calculating the position.

    If you do a T-1 and then a T1 you get a different behaviour. Then you dont have the Z-movement even though are running exactly the same scripts.

    When you go back to 2.02 there you see you dont have this movements.

    I found this comment in the GCodes.cpp, which sound a bit like this bug @dc42

    else if (rp != nullptr)
    			{
    				currentUserPosition[axis] = moveArg + rp->moveCoords[axis];
    				// When a restore point is being used (G1 R parameter) then we used to set any coordinates that were not mentioned to the restore point values.
    				// But that causes issues for tool change on IDEX machines because we end up restoring the U axis when we shouldn't.
    				// So we no longer do that, and the user must mention any axes that he wants restored e.g. G1 R2 X0 Y0.
    			}
    


  • @smoki3 said in Tool Change: Moving in axis without calling them:

    and the user must mention any axes that he wants restored

    Very interesting. I will keep that in mind as I research this further.

    When you go back to 2.02 there you see you dont have this movements.

    I can't run any version of 2; I am on Duet 3 hardware.


  • administrators

    @smoki3 said in Tool Change: Moving in axis without calling them:

    @smoki3 said in Tool Change: Moving in axis without calling them:

    @Danal
    no they are not coded. Just the lift of the nozzle before the tool change starts. Anything else is due to the fact that there is an issue after the tfree.g script with calculating the position.

    If you do a T-1 and then a T1 you get a different behaviour. Then you dont have the Z-movement even though are running exactly the same scripts.

    When you go back to 2.02 there you see you dont have this movements.

    I found this comment in the GCodes.cpp, which sound a bit like this bug @dc42

    else if (rp != nullptr)
    			{
    				currentUserPosition[axis] = moveArg + rp->moveCoords[axis];
    				// When a restore point is being used (G1 R parameter) then we used to set any coordinates that were not mentioned to the restore point values.
    				// But that causes issues for tool change on IDEX machines because we end up restoring the U axis when we shouldn't.
    				// So we no longer do that, and the user must mention any axes that he wants restored e.g. G1 R2 X0 Y0.
    			}
    

    That change was introduced way back in firmware 1.19.

    @Danal said in Tool Change: Moving in axis without calling them:

    @smoki3 said in Tool Change: Moving in axis without calling them:

    and the user must mention any axes that he wants restored

    Very interesting. I will keep that in mind as I research this further.

    When you go back to 2.02 there you see you dont have this movements.

    I can't run any version of 2; I am on Duet 3 hardware.

    I think the change in behaviour must be connected with this change, in the upgrade notes for 2.03:

    Tool changers, IDEX printers and similar using tfree#.g and tpost#.g files: tool offsets are now applied within the tfree#.g and tpost#.g macros (but not in the tpre#.g file because no tool is selected at that point).

    Perhaps there is a G1 command in the tfree or tpost file that needs to be corrected for tool offset, or else a G53 prefix added?



  • @dc42

    No I don't think so!

    I actually investigating:

    So frist my config:

    ; Configuration file for Duet WiFi (firmware version 1.21)
    ; executed by the firmware on start-up
    ;
    ; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
    
    ; General preferences
    G90                                                ; Send absolute coordinates...
    M83                                                ; ...but relative extruder moves
    
    ; Network
    M550 PCoreXY                                   	   ; Set machine name
    M552 S1                                        	   ; Enable network
    M586 P0 S1                                         ; Enable HTTP
    M586 P1 S0                                         ; Disable FTP
    M586 P2 S0                                         ; Disable Telnet
    
    ; Drives
    M584 X0 Y1 Z2 E3:4:5:6 U7                          		; Map Drives to Axis
    M669 K1                                            		; Select CoreXY mode
    M569 P0 S0                                         		; Drive 0 goes forwards
    M569 P1 S0                                         		; Drive 1 goes forwards
    M569 P2 S1                                         		; Drive 2 goes forwards
    M569 P3 S0                                         		; Drive 3 goes forwards
    M569 P4 S0                                         		; Drive 4 goes forwards
    M569 P5 S0                                         		; Drive 5 goes forwards
    M569 P6 S0                                         		; Drive 6 goes forwards
    M569 P7 S0                                        		; Drive 7 goes forwards
    M350 X16 Y16 Z16 E16:16:16:16 I1                   		; Configure microstepping with interpolation
    M350 U8 I0					   		; Configure microstepping without interpolation
    M92 X100 Y100 Z1600 U100 E460:460:460:460          		; Set steps per mm
    M566 X600 Y600 Z18 U2 E100:100:100:100         		   		; Set maximum instantaneous speed changes (mm/min)
    M203 X35000 Y35000 Z1200 U25000 E5000:5000:5000:5000    	; Set maximum speeds (mm/min)
    M201 X6000 Y6000 Z400 U500 E2500:2500:2500:2500         	; Set accelerations (mm/s^2)
    M906 X1650 Y1650 Z1100 U200 E1450:1450:1450:1450 I30    	; Set motor currents (mA) and motor idle factor in per cent
    M84 S120                                           		; Set idle timeout
    
    ; Axis Limits
    M208 X-13.5 Y-56 Z0 U0 S1                          		; Set axis minima
    M208 X316 Y202 Z270.20 U500 S0                     		; Set axis maxima
    
    ; Thermal Sensors
    M308 S0 P"bedtemp" Y"thermistor" T100000 B3950                   	; Set thermistor + ADC parameters for heater 0
    M308 S1 P"e0temp" Y"thermistor" T100000 B4725 C7.060000e-8       	; Set thermistor + ADC parameters for heater 1
    M308 S2 P"e1temp" Y"thermistor" T100000 B4725 C7.060000e-8       	; Set thermistor + ADC parameters for heater 2
    M308 S3 P"e2temp" Y"thermistor" T100000 B4725 C7.060000e-8      	; Set thermistor + ADC parameters for heater 3
    M308 S4 P"e3temp" Y"thermistor" T100000 B4725 C7.060000e-8      	; Set thermistor + ADC parameters for heater 4
    
    ; Hardware
    M950 H0 C"bedheat" T0
    M950 H1 C"e0heat" T1
    M950 H2 C"e1heat" T2
    M950 H3 C"!exp.heater3" T3
    M950 H4 C"!exp.heater4" T4
    M950 F3 C"duex.fan3"
    M950 F4 C"duex.fan4"
    M950 F5 C"duex.fan5"
    M950 F6 C"duex.fan6"
    M950 F7 C"duex.fan7"
    M950 F8 C"duex.fan8"
    
    ; Max Temp Protection
    M143 H0 S140                                   ; Set temperature limit for heater 0 to 140C
    M143 H1 S270                                   ; Set temperature limit for heater 1 to 270C
    M143 H2 S270                                   ; Set temperature limit for heater 2 to 270C
    M143 H3 S270                                   ; Set temperature limit for heater 3 to 270C
    M143 H4 S270                                   ; Set temperature limit for heater 4 to 270C
    
    ; Fanmapping
    M106 P0 S0 I0 F500 H-1 C"Tool 0"               ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P3 S0 I0 F500 H-1 C"Tool 1"               ; Set fan 3 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P7 S0 I0 F500 H-1 C"Tool 2"               ; Set fan 7 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P5 S0 I0 F500 H-1 C"Tool 3"               ; Set fan 5 value, PWM signal inversion and frequency. Thermostatic control is turned off
    M106 P1 S1 I0 F500 H1 T55                      ; Set fan 1 value for Tool 0, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P4 S1 I0 F500 H2 T55                      ; Set fan 2 value for Tool 1, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P6 S1 I0 F500 H3 T55                      ; Set fan 6 value for Tool 2, PWM signal inversion and frequency. Thermostatic control is turned on
    M106 P8 S1 I0 F500 H4 T55                      ; Set fan 8 value for Tool 4, PWM signal inversion and frequency. Thermostatic control is turned on
    
    ; Endstops
    M915 X Y S5 H350 F0 R0           	       ; Set Stall detection sensitivity
    M915 U S5 H200 F0 R0			       ; Coupler
    M574 Y1 S3                                     ; Set endstops controlled by motor load detection
    M574 X1 S3                                     ; Set endstops controlled by motor load detection
    M574 U0                                        ; Set endstops controlled by motor load detection
    
    ; Z-Probe
    M574 Z0 C"nil" 		                       ; no Z endstop switch, free up Z endstop input
    M558 P5 C"!zstop" H3 F180 T25000	       ; Z probe connected to Z endstop input
    G31 X0 Y0 Z0.00 P500          	               ; Set Z probe offset + naher ran - weiter weg
    M557 X5:295 Y0:190 S48.33:47.5                 ; Define mesh grid
    
    ; Tools
    M563 P0 D0 H1 F0                               ; Define tool 0, Fan 0
    M563 P1 D1 H2 F3                               ; Define tool 1, Fan 3
    M563 P2 D2 H3 F7                               ; Define tool 2, Fan 7
    M563 P3 D3 H4 F5                               ; Define tool 3, Fan 5
    
    ; PID Settings Tools
    M307 H1 A595.9 C199.5 D4.5 S1.00 V24.1 B0      ; Set PID settings tool 0
    M307 H2 A775.0 C252.4 D8.2 S1.00 V24.1 B0      ; Set PID settings tool 1
    M307 H3 A716.5 C237.1 D8.7 S1.00 V24.1 B0      ; Set PID settings tool 2
    M307 H4 A567.7 C241.0 D6.7 S0.80 V24.1 B0      ; Set PID settings tool 3
    M307 H0 A181.4 C631.5 D4.9 S1.00 V24.1 B0      ; Bed PID Settings
    
    ; Tooloffset
    ;G10 P0 X0.00 Y34.50 Z-15.84                    ; Set tool 0 axis offsets
    ;G10 P1 X0.55 Y34.50 Z-15.83                    ; Set tool 1 axis offsets
    ;G10 P2 X0.16 Y34.50 Z-15.85                    ; Set tool 2 axis offsets
    ;G10 P3 X0.25 Y34.50 Z-15.70                    ; Set tool 3 axis offsets
    M98 Ptooloffset.g
    
    ; Tools Temperatures
    G10 P0 R0 S0                                   ; Set initial tool 0 active and standby temperatures to 0C
    G10 P1 R0 S0                                   ; Set initial tool 1 active and standby temperatures to 0C
    G10 P2 R0 S0                                   ; Set initial tool 2 active and standby temperatures to 0C
    G10 P3 R0 S0                                   ; Set initial tool 3 active and standby temperatures to 0C
    
    ; LED Strip
    M950 F2 C"nil"				       ; Free fan 2 pin
    M950 P2 C"fan2"				       ; create GPIO pin 2 attached to fan 2
    M42 P2 S30				       ; Turn LEDs on 30% PWM
    
    ; Calibrate MCU Temperature
    M912 P0 S-8
    
    ; DAA
    M593 F80
    
    ; Load config override
    M501
    

    Then I created a simple tpre.g (same for T0 and T1, just X0 for T0 and X50 for T1):

    ; tpre0.g
    ; called before tool 0 is selected
    
    
    G1 X0 F5000
    M400
    M98 P"/macros/Toolhead/1. Toolhead unlock"
    G4 P400
    
    G1 Y110 F5000
    M400
    
    M98 P"/macros/Toolhead/2. Toolhead lock"
    G4 P260
    
    G1 Y100 F5000
    

    Then the tfree.g (same X0 for T0 and X1 for T1):

    ; tfree0.g
    ; called when tool 0 is freed
    
    G91
    G1 Z10 F7200
    G90
    
    
    G53 G1 X0 F5000 ;XPOS
    G53 G1 Y110
    M400
    M98 P"/macros/Toolhead/1. Toolhead unlock"
    G4 P320
    G53 G1 Y100 F5000
    M400
    

    tpost.g is completely empty for both.

    the tool offsets are defines as followed:

    ; Tooloffset
    G10 P0 X20.00 Y15 Z-12.0                    ; Set tool 0 axis offsets
    G10 P1 X20.00 Y15 Z-12.0                   ; Set tool 1 axis offsets
    


  • @dc42

    I made some videos:

    First I have just clicked on T0 to pick it up:

    https://photos.app.goo.gl/ipCKj1bHJ15dw8NKA

    After this I picked up T1 by clicking on it in DWC:

    https://photos.app.goo.gl/yqMHUWQt5n7gYiPX6

    Last on I deactivated T1 by click again on T1 in DWC:

    https://photos.app.goo.gl/Nnn5NxX9C4Ph9WFx5

    So do you see this wired diagonal move with XY axis and Z Axis in the second video?



  • I understand why offsets are/aren't applied. They correlate to the "what tool number is currently mounted" status of the printer.

    Therefore, I have G53 in front of the vast majority of the moves, because those moves need to deal with the parking posts in absolute terms.

    I'll see if I can reproduce what happens in the above vids.


Log in to reply