RepRapFirmware 3.6.0-alpha.4+3 available for testing

dc42

@curieos said in RepRapFirmware 3.6.0-alpha.4+3 available for testing:

@dc42 Mine was actually around the 3.5-4 hour mark for the print. The print I was doing was around 3.75 hours, and it paused with around 15 minutes left. There may have been a delay in the print start too, my machine is a flying gantry so I need to rerun G32 every time the motors shut off, and I may have waited a bit of time for heat soaking since I was printing ASA, so it could've been 4-4.5 hours after the restart.

Thanks. The bug could also occur at multiples of 47 (38 on Duet 2) minutes after the machine has been powered up or reset.

balajiramani

@Adrian52 Thank you for your copy of bed.g. The one big difference that I saws that the initial move in your file, after homing, is to move the head just above the probe point, where as in the version that I had, I was moving to X0 Y0. When I changed it to go just above the first point, so that the head is vertically above the first probe point, the bed calibration routine worked fine.

So, it looks like there seems to be a difference in the behavior depending on where the head is, relative to the first probe point and it is quite repetable for me. This seems to be a regression as compared to 3.5.2. At this point, I am glad that I found a way to get bed calibration working again on 3.6.0.

@dc42 can you check the behaviour on your end to see if you are able to reproduce this issue on the delta that you have?

Thanks,
Balaji

tas

@dc42
Duet2Wifi print completed after 1 hour 46 minutes without issues.
Thanks for the fix.

dc42

@balajiramani said in RepRapFirmware 3.6.0-alpha.4+3 available for testing:

@dc42 can you check the behaviour on your end to see if you are able to reproduce this issue on the delta that you have?

Thanks, I too had a move to just above the first probe point in my bed.g file, and if I use a move to X0 Y0 instead then I see the issue that you reported.

Adrian52

@dc42 a 1hr print completed for me too - thanks for the fix. Print quality looks very nice too.

dc42

@balajiramani I've fixed that in the new binaries at https://www.dropbox.com/scl/fo/u79134f365jdacqsm0km3/AKMSKB_Fz63WH4hqLkIphuQ?rlkey=bpa9lja4jylkpu9syjfp31rho&dl=0. The main build binaries are now version 3.6.0-alpha.5+1. Expansion board binaries are still 3.6.0-alpha.5.

Notepad

Just doing a simple test print and I noticed the extruder stopped pushing filament after 2 minutes.
After pause and cancelling the print, I manually started extruding some filament to see if it was a nozzle clog and I get the following error

Error: Push(): stack overflow on Aux
Error: Pop(): stack underflow on Aux

I have noticed a few times my PanelDue has seemed slightly unresponsive with delays between button presses and actions happening. This has also appeared during homing where the transition from HomeY.g to HomeZ.g has had a micro delay.

m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-alpha.5 (2024-08-31 12:38:17) running on Duet 3 MB6HC v1.02 or 1.02a (SBC mode)
Board ID: 0JD4M-958L1-M2NS0-7JTDD-3S06P-1KHKX
Used output buffers: 1 of 40 (40 max)
=== RTOS ===
Static ram: 135136
Dynamic ram: 97412 of which 3300 recycled
Never used RAM 86680, free system stack 125 words
Tasks: SBC(2,ready,1.0%,809) HEAT(3,nWait 6,0.0%,325) Move(4,nWait 6,0.0%,221) TMC(4,nWait 6,2.9%,351) CanReceiv(6,nWait 1,0.0%,790) CanSender(5,nWait 7,0.0%,329) CanClock(7,delaying,0.0%,348) MAIN(2,running,95.9%,101) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 01:19:54 ago, cause: software
Last software reset at 2024-08-31 22:12, reason: User, Gcodes spinning, available RAM 92152, slot 0
Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0043c000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 37.0, current 38.3, max 38.4
Supply voltage: min 24.9, current 25.0, max 25.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.0, current 12.2, max 12.4, under voltage events: 0
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/116/116, gc cycles 0
Events: 1 queued, 1 completed
Date/time: 2024-08-31 23:32:12
Slowest loop: 77.45ms; fastest: 0.05ms
=== Storage ===
Free file entries: 20
SD card 0 not detected, interface speed: 37.5MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
Segments created 257, maxWait 1753400ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0 (0.00/0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 16320.00/16320/0.00 0.00/0/-0.00 46359.00/46360/-1.00
next step interrupt due in 137 ticks, disabled
Driver 0: standstill, SG min 0, mspos 152, reads 19611, writes 49 timeouts 0
Driver 1: standstill, SG min n/a, mspos 8, reads 19649, writes 11 timeouts 0
Driver 2: standstill, SG min 0, mspos 136, reads 19611, writes 49 timeouts 0
Driver 3: standstill, SG min 0, mspos 696, reads 19579, writes 81 timeouts 0
Driver 4: standstill, SG min n/a, mspos 8, reads 19649, writes 11 timeouts 0
Driver 5: standstill, SG min 0, mspos 408, reads 19579, writes 81 timeouts 0
Phase step loop runtime (us): min=0, max=29, frequency (Hz): min=1139, max=8241
=== DDARing 0 ===
Scheduled moves 4187, completed 4187, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters 2 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.2
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File* is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue* is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x80000007
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 47342, received 96210, lost 0, ignored 0, errs 1, boc 0
Longest wait 1ms for reply type 6042, peak Tx sync delay 229, free buffers 50 (min 49), ts 23971/23970/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
Transfer state: 5, failed transfers: 0, checksum errors: 0
RX/TX seq numbers: 57990/57990
SPI underruns 0, overruns 0
State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x284f0
Buffer RX/TX: 0/0-0, open files: 0
=== Duet Control Server ===
Duet Control Server version 3.5.2 (2024-06-12 07:12:47, 64-bit)
HTTP+Executed:
> Executing M122
Code buffer space: 4096
Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 0
Full transfers per second: 39.48, max time between full transfers: 37.2ms, max pin wait times: 34.4ms/1.2ms
Codes per second: 0.85
Maximum length of RX/TX data transfers: 4436/1260

So far the test has been on 3.6.a5 next is to test a5+1

Edit:

A5+1 same extruder stopping behaviour, no pop/push error
Reverted to 3.5.2 and behaviour is identical. I think the roto extruder cannot push more than 30cubicmm/s with my current setup as it is stalling

As I am exceedingly fresh with SBC equipped duets, If there is a recommended process on how to update the SBC (pi5) instead of me dropping in the new 3.6.Ax .bin files, I would very much appreciate the advice.

Edit 2:

Something is up with my config.g or my roto as its stalling at relatively normal speeds regardless of firmware versions. The actually motor stalling is probably a red herring of a new machine (never used a roto before) but the Push/Pop error is definitely something out of the ordinary.

balajiramani

@dc42 Thank you! Verified that this version workes, irrespective of what the starting point for the bed calibration is.

o_lampe

@balajiramani Thanks for being so persistent, posting your calibration issues. It's a huge relieve for me, @dc42 found a solution.
I wondered if it was related to the, IHMO pretty huge endstop differences?

8/31/2024, 5:58:57 PM	M666
                        Endstop adjustments X-1.26 Y-1.03 Z2.30, tilt X0.00% Y0.00%

dc42

@Notepad I think the Push and Pop errors are happening because you are still running version 3.5.2 of Duet Control Server.

balajiramani

@o_lampe I think how @dc42 interacts with the community and listens to each one of us, is what makes the whole Duet ecosystem amazing!

While the endstop values are high, I don't think it is related to that. @dc42 what do you think?

Thanks,
Balaji

dc42

@balajiramani it wasn't relayed to the endstop adjustments. The code to segment automatically-generated moves didn't always work.

Aurimas

@dc42
got this error
Error: Movement halted because a step timing error occurred (code 3). Please reset the controller.

here is M122

=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.6.0-alpha.4+3 (2024-08-28 10:03:49) running on Duet 3 Mini5plus WiFi (standalone mode)
Board ID: 44BBP-1N6KL-K65J0-409N2-1BW1Z-RD9N1
Used output buffers: 3 of 40 (40 max)
=== RTOS ===
Static ram: 92328
Dynamic ram: 91792 of which 12 recycled
Never used RAM 37808, free system stack 121 words
Tasks: NETWORK(2,nWait 7,11.6%,183) HEAT(3,nWait 6,0.0%,325) Move(4,invalid,0.1%,247) TMC(4,nWait 6,0.9%,65) CanReceiv(6,nWait 1,0.1%,771) CanSender(5,nWait 7,0.0%,327) CanClock(7,delaying,0.0%,348) MAIN(1,running,86.4%,639) IDLE(0,ready,0.1%,29) AIN(4,delaying,0.8%,255), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 19:56:34 ago, cause: software
Last software reset at 2024-08-03 12:45, reason: HardFault imprec, Gcodes spinning, available RAM 12036, slot 0
Software reset code 0x4063 HFSR 0x40000000 CFSR 0x00000400 ICSR 0x00489803 BFAR 0xe000ed38 SP 0x200120a0 Task NETW Freestk 544 ok
Stack: 00000000 000aff28 200014ec 2000dfe0 ffffffff 0009e9c7 00012156 210f0000 00012179 2000dfe0 00000000 000afea8 00000083 e000e000 2001e880 a5a5a5a5 000121ed 200355f8 00000000 563bc5f2 00031c25 2001e880 2001ce00 00000001 200355f8 00000000 00033dd7
Error status: 0x04
Aux0 errors 0,0,0
MCU temperature: min 22.3, current 30.3, max 31.2
Supply voltage: min 24.3, current 24.4, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/420/316, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-09-03 09:16:25
Slowest loop: 246.24ms; fastest: 0.09ms
=== Storage ===
Free file entries: 18
SD card 0 detected, interface speed: 22.5MBytes/sec
SD card longest read time 12.1ms, write time 94.0ms, max retries 0
=== Move ===
Segments created 667, maxWait 66447882ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0 (0.00/278.36ms), max steps late 1, ebfmin 0.00, ebfmax 0.00
Pos req/act/dcf: 34659.00/34449/0.28 -5056.00/-4998/-0.90 15480.00/15286/0.68
no step interrupt scheduled
Driver 0: standstill, SG min 0, read errors 0, write errors 1, ifcnt 33, reads 42543, writes 20, timeouts 0, DMA errors 0, CC errors 0
Driver 1: standstill, SG min 0, read errors 0, write errors 1, ifcnt 33, reads 42543, writes 20, timeouts 0, DMA errors 0, CC errors 0
Driver 2: standstill, SG min 0, read errors 0, write errors 1, ifcnt 37, reads 42540, writes 22, timeouts 0, DMA errors 0, CC errors 0
Driver 3: standstill, SG min 0, read errors 0, write errors 1, ifcnt 37, reads 42540, writes 22, timeouts 0, DMA errors 0, CC errors 0
Driver 4: standstill, SG min 0, read errors 0, write errors 1, ifcnt 25, reads 42551, writes 12, timeouts 0, DMA errors 0, CC errors 0
Driver 5: not present
Driver 6: not present
=== DDARing 0 ===
Scheduled moves 113330, completed 113290, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 0 is on, I-accum = 0.0
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 3
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is doing "M106 P5 S0.1" in state(s) 0 0, running macro
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 1, axes/extruders owned 0x0000807
Queue 0 has 'M106 P5 S0.1' for move 113291
Queue 0 has 'M106 P5 S0.1' for move 113293
Queue 0 has 'M106 P5 S0.1' for move 113299
Queue 0 has 'M106 P5 S0.1' for move 113300
Queue 0 has 'M106 P5 S0.1' for move 113303
Queue 0 has 'M106 P5 S0.1' for move 113308
Queue 0 has 'M106 P5 S0.1' for move 113309
Queue 0 has 'M106 P5 S0.1' for move 113311
Queue 0 has 'M106 P5 S0.1' for move 113312
Queue 0 has 'M106 P5 S0.1' for move 113314
Queue 0 has 'M106 P5 S0.1' for move 113317
Queue 0 has 'M106 P5 S0.1' for move 113325
Queue 0 has 'M106 P5 S0.1' for move 113328
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 755848, received 2872555, lost 0, ignored 0, errs 0, boc 0
Longest wait 5ms for reply type 4014, peak Tx sync delay 282, free buffers 26 (min 25), ts 358975/358974/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 223.95ms; fastest: 0.00ms
Responder states: MQTT(0) HTTP(0) HTTP(1) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 2 of 8
=== WiFi ===
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notrdy 0, noresp 0
Firmware version 2.1.0
MAC address c4:5b:be:ce:9c:81
Module reset reason: Power up, Vcc 3.36, flash size 2097152, free heap 36344
WiFi IP address 192.168.1.131
Signal strength -52dBm, channel 6, mode 802.11n, reconnections 0
Clock register 00002001
Socket states: 5 0 3 0 0 0 0 0

jay_s_uk

@Aurimas see the above links for alpha 5+1

MaxGyver

@dc42

I just tested 3.6.0-alpha.5+1 on our 5meter printer. The "homing jolt" on our CAN-connected Servo Drives is strong enough to make the servo drives go into fault mode Reducing the homing speed by 50% did help, but it still produces a loud "clonk"

Everything else is working as expected
Setup: Duet MB6HC+ 3xEXP1XD+ EXP3HC

My small printer is flawlessly printing since an on our under 3.6.0-alpha.5+1
Setup: Duet MB6HC+ 3xEXP1HCL+TOOL1RR

four screw bed tramming and mesh probing with the SZP seems to be working as expected, I only had to reduce the pressure advance value by 50%.
I have noticed some short movement pauses during printing, these were also present in RRF 3.5.2, maybe increasing the movement queue length can help here?

dc42

@MaxGyver thanks for your report. Fixing the homing jolt is one of the remaining things we need to do before we release beta 1.

You can lengthen the movement queue yourself using the M595 command.

edsped

@dc42 I'm starting to get random tool drops when picking up and when parking tools, maybe once every 20 or so toolchanges. Attached are what I believe to be pertinent files... It happens with all tools and has never happened prior to this alpha and have hundreds of hours on the printer. No other code changes were made other than the alpha update.

9/5/2024, 8:21:22 PM	M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.6.0-alpha.4 (2024-08-13 15:11:47) running on Duet 3 MB6HC v1.02 or 1.02a (standalone mode)
Board ID: 08DJM-9P63L-DJ3T8-6J1F2-3SS6J-KA6VB
Used output buffers: 3 of 40 (29 max)
=== RTOS ===
Static ram: 133840
Dynamic ram: 128776 of which 24 recycled
Never used RAM 53240, free system stack 120 words
Tasks: NETWORK(1,ready,33.0%,171) ETHERNET(5,nWait 7,0.2%,316) HEAT(3,nWait 6,0.0%,323) Move(4,nWait 6,1.8%,209) TMC(4,nWait 6,8.5%,53) CanReceiv(6,nWait 1,0.1%,769) CanSender(5,nWait 7,0.1%,325) CanClock(7,delaying,0.0%,348) MAIN(1,running,56.1%,103) IDLE(0,ready,0.0%,29), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 01:14:12 ago, cause: power up
Last software reset at 2024-08-16 08:29, reason: User, Gcodes spinning, available RAM 62232, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0044a000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 10.2, current 31.1, max 31.2
Supply voltage: min 24.1, current 24.2, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 11.9, current 12.2, max 12.5, under voltage events: 0
Heap OK, handles allocated/used 99/4, heap memory allocated/used/recyclable 2048/304/256, gc cycles 0
Events: 0 queued, 0 completed
Date/time: 2024-09-05 20:21:21
Slowest loop: 219.48ms; fastest: 0.07ms
=== Storage ===
Free file entries: 20
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 42.0ms, write time 10.7ms, max retries 1
=== Move ===
Segments created 534, maxWait 908262ms, bed comp in use: mesh, height map offset 0.000, hiccups added 0 (0.00ms), max steps late 0, ebfmin 0.00, ebfmax 0.00, mcet 0.024
Pos req/act/dcf: 0.00/1/-0.93 0.00/-1/0.98 157600.00/157599/1.00 0.00/0/0.00
no step interrupt scheduled
Driver 0: standstill, SG min 0, mspos 532, reads 42260, writes 26 timeouts 0
Driver 1: standstill, SG min 0, mspos 452, reads 42260, writes 26 timeouts 0
Driver 2: standstill, SG min 0, mspos 672, reads 42260, writes 26 timeouts 0
Driver 3: standstill, SG min 0, mspos 136, reads 42257, writes 30 timeouts 0
Driver 4: standstill, SG min 0, mspos 600, reads 42257, writes 30 timeouts 0
Driver 5: standstill, SG min 0, mspos 760, reads 42257, writes 30 timeouts 0
=== DDARing 0 ===
Scheduled moves 142683, completed 142683, LaErrors 0, Underruns [0, 0, 0]
=== DDARing 1 ===
Scheduled moves 0, completed 0, LaErrors 0, Underruns [0, 0, 0]
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Movement locks held by null, null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
File2 is idle in state(s) 0
Queue2 is idle in state(s) 0
Q0 segments left 0, axes/extruders owned 0x0000000
Code queue 0 is empty
Q1 segments left 0, axes/extruders owned 0x0000000
Code queue 1 is empty
=== CAN ===
Messages queued 317944, received 356576, lost 0, ignored 0, errs 959, boc 0
Longest wait 2ms for reply type 6031, peak Tx sync delay 61219, free buffers 50 (min 49), ts 22265/22264/0
Tx timeouts 0,0,0,0,0,0
=== Network ===
Slowest loop: 176.15ms; fastest: 0.03ms
Responder states: MQTT(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
Interface state: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== WiFi ===
Interface state: disabled
Module is disabled
Failed messages: pending 0, notrdy 0, noresp 0
Socket states: 0 0 0 0 0 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0[tfree3.g](/assets/uploads/files/1725582328191-tfree3.g) [tool_unlock.g](/assets/uploads/files/1725582328225-tool_unlock.g) [tpost3.g](/assets/uploads/files/1725582328253-tpost3.g) [tpre3.g](/assets/uploads/files/1725582328279-tpre3.g) [TOOL-PICKUP (1).g](/assets/uploads/files/1725582328303-tool-pickup-1.g)

TOOL-PICKUP.g

M98 P"/macros/tool_lock.g" 		; Lock the toolM98 P"/macros/tool_lock.g" 	
;G92 E0

if state.currentTool = 0
	M150 E0 U0 R0 B0 W255 S2 F0 P255 ; TURN ON LED
elif state.currentTool = 1
	M150 E1 U0 R0 B0 W255 S2 F0 P255 ; TURN ON LED
elif state.currentTool = 2
	M150 E2 U0 R0 B0 W255 S2 F0 P255 ; TURN ON LED
elif state.currentTool = 3
	M150 E3 U0 R0 B0 W255 S2 F0 P255 ; TURN ON LED

if state.currentTool = 0
	M116 P0 S6
elif state.currentTool = 1
	M116 P1 S6
elif state.currentTool = 2
	M116 P2 S6
elif state.currentTool = 3
	M116 P3 S6
G4 S2

M302 P0  		          		; Prevent Cold Extrudes, just in case temp setpoints are at 0
G1 E12 F800	 				; Unretract to nozzle
G1 E6 F200      	            ; Pebble Purge
M106 S255			    	   	; Cooling 100%
G4 S3                           ; Wait 3 seconds
G53 G1 Y305 F30000              ; Retract the entire tool and wipe Backwards.
G1 R2 Z0 F24000                 ; Restore prior Z position before tool change was initiated.
                                ; Note: tool tip position is automatically saved to slot 2 upon the start of a tool change.
                                ; Restore Z first so we don't crash the tool on retraction.
G1 R0 Y0 F24000                 ; Retract tool by restoring Y position next now accounting for new tool offset.
					    		; Restoring Y next ensures the tool is fully removed from parking post.
G1 R0 X0 F24000                 ; Restore X position now accounting for new tool offset.
M106 R2                         ; restore print cooling fan speed

tpre3.g

; Runs after freeing the previous tool if the next tool is T3
; Note: tool offsets are not applied at this point!
G90                              ; Ensure the machine is in absolute mode before issuing movements.
M150 E3 U0 R255 B0 W0 S2 F0 P255 ; TURN ON LED
G1 X0.0 Y295 F24000              ; Rapid to the approach position without any current tool.
G60 S0                           ; Save this position as the reference point from which to later apply new tool offsets.

tpost3.g

; runs after firmware thinks Tool3 is selected
; Note: tool offsets are applied at this point!
; Note that commands prefixed with G53 will NOT apply the tool offset.
G90                                ; Return to absolute   
M150 E3 U255 R255 B0 W0 S2 F0 P255 ; TURN ON LED
G53 G1 Y325 F18000                 ; Rapid move to a safe Y-line when no tool is locked.
G53 G1 Y337 F1000                  ; Move to the pickup position with tool-1.
M116 P3 S4                         ; Ensure hot end is to temperature prior to pulling away from tool post.
M98 P"/macros/TOOL-PICKUP.g"       ; Lock the toolM98 P"/macros/tool_lock.g"

tfree3.g

; tfree3.g
; Runs at the start of a toolchange if the current tool is tool-3.
; Note: tool offsets are applied at this point unless we preempt commands with G53!
; ################# Tool 3 Free Prep ##################
G91                           	;Relative to move bed down
G1 Z.2 F18000                  	;Move the bed further from the nozzle prior to any tool moves. 
G90                           	;Return to absolute
; ################# Tool 3 Free #######################
G53 G1 X0.0 Y275 F24000       	;Rapid to the back of the post. Stay away from the tool rack so we don't collide with tools.
                            	;This position must be chosen such that the most protruding y face of the current tool
                             	;(while on the carriage) does not collide with the most protruding y face of any parked tool.
G1 E-12 F400						;Retract 18mm of filament to minimize oozing
;G53 G1 Y337.5 F18000        	; Controlled move to the park position with tool-0. (park_x, park_y)
G53 G1 Y335 F24000        	; Controlled move to the park position with tool-0. (park_x, park_y)
M98 P"/macros/tool_unlock.g" 	;Unlock the tool
M150 E3 U0 R0 B0 W255 S2 F0 P0  ; TURN OFF LED
G53 G1 Y300 F18000            	;Retract the pin.
M106 P6 S0						;Turn off part cooling fan

edsped

@dc42 If it occurs when picking the tool up the twist lock doesn't fully engage then the tool either falls off as it pulls away from the parking posts or flops around when printing. When dropped off it's as if the twist lock doesn't fully disengage then the tool moves with the carriage then drops as the carriage pulls away from the parking posts.

Printer is Jubilee with (4) tools MB6HC with (4) Fly-RRF's driving the extruders.

gloomyandy

@edsped What version of RRF did you have installed before you tried 3.6.0-alpha.4? I'd recommend that you do the following:

Switch back to whatever you had before and run for a while to confirm that your toolchanging is still ok. You would be surprised how often a mechanical issue shows up when you make a change to the firmware (maybe because folks do more, or something else changes).
You install the latest alpha5+1 version (see: https://forum.duet3d.com/post/344094) and test again with that.

If the old version of RRF works and the latest alpha still does not work, please post your config.g file and your tool_lock.g file.

edsped

@gloomyandy I'm thinking the same thing or the stepper is failing. The issues happen so fast and infrequently that I don't actually see it happen, only the after effects. I did see one park attempt where it looked like it attempted to pick up the tool about 2cm in front of the tool plate. I have pretty high travel speeds for my tool changes and will try lowering them first and will revert back to 3.5.2 if I still have issues and will go from there. I do have to say in the 3+ years I've been running this machine I've never had tool drop issues.