@T3P3Tony I don't run anything more beefy than a big 3D printer but I know Duet is certainly designed for tasks like running a CNC Mill. How would I have fared if I had a similar error during a milling operation? I understand the default is already set but I do think picking a policy for the event should be enforced somehow for new builds.

@T3P3Tony I don't run anything more beefy than a big 3D printer but I know Duet is certainly designed for tasks like running a CNC Mill. How would I have fared if I had a similar error during a milling operation? I understand the default is already set but I do think picking a policy for the event should be enforced somehow for new builds.

@dc42 You are indeed correct that I previously made my own cable and although it worked at first eventually it gave me trouble from the data pins not being fully seated. Not sure how they get them in there without damaging the wires. I switched to the included cable after having issues and that's when I had the crash. I have redone my toolboard mount(you can find it on Printables) and I think the issue with the connector should now be resolved.

I still think the default behaviour on connection loss should be to stop any moves.

I've been using the Roto Toolboard for a few months now and while I think it's overall a very nice toolboard I do have one very real complaint about it that also has to do with RRF. The XT30 connector used for power+data is far more likely to come loose than the Toolboard 1LC and thus drop the connection. And before anyone asks, yes, I do use strain relief on the cable. This has been enough of a problem for me that I've gotten into the habit of pushing in the connector before i start a print to make sure the connector is fully seated, as even a slight amount of wiggle will cause a disconnect. This would be fine if the default behavior on timeout was to stop any moves/print, however as I found out this morning this is not the case. I forgot to reseat the connector before starting a print and during the Z homing the XT connector must have wiggled just enough to lose connection, causing a nasty crash and a couple of lines to be gauged into my PEI sheet. Luckily I was in the same room as the printer and although I had my back to it I was able to slam my Emergency Stop button after only a couple of seconds.

After looking through the events section on the Duet wiki I see that I can set the behavior on expansion timeout by creating a expansion_timeout.g file under sys, which I've now set to do M112, however if no file is present the printer just issues a warning and continues on, which is exactly what happened in my case. I would consider myself something of a RRF veteran at this point, I've been using Duet hardware and RRF for 5+ years now, and have written bash and python code that connects to the object model and writes to a database, takes photos, etc. My point being; if I was unaware of needing an event.g file to cover this contingency, I seriously doubt the average user would have any idea. I think the default behavior on connection loss if no event.g file is found should be to immediately stop all moves and issue a warning.

I also prefer the VH and ZH connector on the toolboard 1LC to the bulky XT30 connector, and I hope any future Duet toolboards go back to using those instead.

@dc42

Oh, well that's good news! Do you have a list of known bugs somewhere, before I posted I did some searching on this issue and didn't find anything.

Hello,

I saw the 3.4.0b3 fixed the bug with Duet 3 with SBCs not working with M600. I upgraded to 3.4.0b4 and gave this a try tonight but can't seem to get this to work. The printer does run filament-change.g and then runs resume.g, but then decides to restart the print. Looking at the resurrect.g file shows the printer restarting the print(M23). I have included the relative files below.

; File "0:/gcodes/top_dedication.gcode" resume print after print paused at 2021-10-06 01:21
G21
M140 P0 S65.0
G29 S1
T-1 P0
G92 X218.939 Y289.344 Z0.200
G60 S1
G10 P0 S195 R210
T-1 P0
M98 P"resurrect-prologue.g"
M116
M290 X0.000 Y0.000 Z0.000 R0
; Workplace coordinates
G10 L2 P1 X0.00 Y0.00 Z0.00
G10 L2 P2 X0.00 Y0.00 Z0.00
G10 L2 P3 X0.00 Y0.00 Z0.00
G10 L2 P4 X0.00 Y0.00 Z0.00
G10 L2 P5 X0.00 Y0.00 Z0.00
G10 L2 P6 X0.00 Y0.00 Z0.00
G10 L2 P7 X0.00 Y0.00 Z0.00
G10 L2 P8 X0.00 Y0.00 Z0.00
G10 L2 P9 X0.00 Y0.00 Z0.00
G54
M106 S0.00
M106 P0 S0.00
M116
G92 E0.00000
M83
M486 S-1
G17
M23 "0:/gcodes/top_dedication.gcode"
M26 S5589
G0 F6000 Z2.200
G0 F6000 X218.939 Y289.344
G0 F6000 Z0.200
G1 F1080.0 P0
G21
M24

; filament-change.g
M83                  				; relative extruder moves
G1 E-2 F1200        				; retract 2mm of filament
G91									; relative positioning
G1 Z2 F600							; lift Z by 2mm
G90									; absolute positioning
G1 X10 Y10 F10000					; go to X=0 Y=0
M291 P"Swap filament" S2
M83                  				; relative extruder moves
G1 E10 F1200        					 ; extrude 10mm of filament	
G1 H0 E10 F300 						; extruding filament
M291 P"Clean Nozzle" S2 T30
M83                  				; relative extruder moves
G1 E-2 F1200        				; retract 2mm of filament

; resume.g
; called before a print from SD card is resumed
; generated by RepRapFirmware Configuration Tool v3.1.3 on Mon Jun 29 2020 01:54:12 GMT-0400 (Eastern Daylight Time)
;M220 S60							;slow the print down on first new layer
G90			;relative moves
G1 R1 X0 Y0 Z2 F6000 ; go to 2mm above position of the last print move
G1 R1 X0 Y0 Z0 F500        ; go back to the last print move
M83                  ; relative extruder moves
G1 E1 F1200         ; extrude 1mm of filament

This is the console, I ran M122 before I hit resume. After returning to the last position the printer seems to go into resurrect.g and restarts the file.

10/6/2021, 1:18:10 AM M24
Printing resumed

10/6/2021, 1:17:10 AM m122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.0beta4 (2021-09-27 11:31:18) running on Duet 3 MB6HC v0.6 or 1.0 (SBC mode)
Board ID: 08DJM-956L2-G43S4-6J9D6-3SJ6M-KA6AG
Used output buffers: 1 of 40 (24 max)
=== RTOS ===
Static ram: 151080
Dynamic ram: 63236 of which 24 recycled
Never used RAM 135612, free system stack 138 words
Tasks: SBC(resourceWait:,0.6%,322) HEAT(notifyWait,0.0%,321) Move(notifyWait,0.6%,246) CanReceiv(notifyWait,0.0%,772) CanSender(notifyWait,0.0%,366) CanClock(delaying,0.0%,339) TMC(notifyWait,9.0%,58) MAIN(running,89.7%,921) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 02:00:04 ago, cause: software
Last software reset at 2021-10-05 23:17, reason: User, GCodes spinning, available RAM 136116, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a
Error status: 0x00
Step timer max interval 154
MCU temperature: min 47.2, current 47.5, max 47.6
Supply voltage: min 23.8, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.1, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Driver 0: pos 3200, standstill, SG min/max 0/147, reads 52949, writes 0 timeouts 0
Driver 1: pos 0, standstill, SG min/max 0/134, reads 52949, writes 0 timeouts 0
Driver 2: pos 3962, standstill, SG min/max 0/1023, reads 52949, writes 0 timeouts 0
Driver 3: pos 0, standstill, SG min/max 0/665, reads 52949, writes 0 timeouts 0
Driver 4: pos 0, standstill, SG min/max n/a, reads 52949, writes 0 timeouts 0
Driver 5: pos 0, standstill, SG min/max n/a, reads 52949, writes 0 timeouts 0
Date/time: 2021-10-06 01:17:08
Slowest loop: 43.27ms; fastest: 0.03ms
=== Storage ===
Free file entries: 10
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 ===
DMs created 125, segments created 30, maxWait 3245ms, bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves 916, completed 916, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 2], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by 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
Code queue is empty
=== CAN ===
Messages queued 1770, received 3305, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 8, free buffers 49 (min 47), ts 825/825/0
Tx timeouts 0,0,0,0,0,0
=== SBC interface ===
State: 4, failed transfers: 0, checksum errors: 0
Last transfer: 2ms ago
RX/TX seq numbers: 17824/17824
SPI underruns 0, overruns 0
Disconnects: 0, timeouts: 0, IAP RAM available 0x2c488
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.4-b4
Code buffer space: 4096
Configured SPI speed: 8000000Hz
Full transfers per second: 38.81, max wait times: 43.5ms/5.7ms
Codes per second: 1.39
Maximum length of RX/TX data transfers: 5824/1828
File /opt/dsf/sd/gcodes/top_dedication.gcode is selected, paused

10/6/2021, 1:17:05 AM M600
Printing paused for filament change at X280.5 Y286.5 Z0.2

10/6/2021, 1:16:57 AM Resume state saved

Can you elaborate on why the accelerometer support is for standalone mode only?

@dc42

Upgraded from 3.2 to 3.3b. Only issue I ran into was the upgrade created a firmware directory but didn't move the firmware files from the sys directory. Pretty easy fix for me to move the files but wanted to make sure you were aware of it.

Update seems to have fixed the issue. I did the same M122, M122 B21 during the print and it shows no lost CAN messages. Doing M122 B21 did hiccup the print but no error message and it was much less noticeable than before. toolboard_good.txt

The print also came out similarly to when the extruder is wired to the mainboard. I was getting worried that the problem was my mainboard, thanks for the help!

@dc42 Is the CAN fix in the most recent beta? If so I'll upgrade now and try it out.

Re: minimum extrusion amounts

So I had an issue a few months ago with my toolboard where it suddenly decided it didnt want to extrude properly. This was really never fixed to my satisfaction and I got by with a workaround where I didn't use the toolboard's extruder motor connection and just ran the wires to my Duet 3, which really nullifies much of the usefulness of the toolboard.

I recently updated my board to the newest released firmware(3.2.2) and in the changes I saw CAN diagnostics were further developed. I figured now I might be able to properly diagnose my issue and maybe get it resolved.

A quick recap.

When the extruder motor is wired to the toolboard the extrusion is very uneven and the extruder motor seems to slow down and stop/start as if it were printing a different segment of the print. This leads to some very ugly prints with lots of zits and stringing and over and under extrusion. You can see the previous thread for pictures.

For hardware I have a Duet 3 Mainboard 6HC connected to a Raspberry Pi 4 SBC, a Tool Distribution Board, and a Duet Toolboard, all running on 24 volts(except the Pi of course). The printer is a Core XY with a Hevort XY and a modified HEVO Z axis.

I have tried replacing the extruder motor, replacing the toolboard, adding in the tool distribution board, replacing the CAN wiring between the toolboard and the distribution board, replacing the wiring between the toolboard and the extruder motor.

@Phaedrux has already gone over my config and scripts and didn't find an issue there.

During my most recent print with the extruder motor wired to the toolboard I ran m122 and m122 b21, 21 being the toolboard's address. Here is what I got:

bad_toolboard_m122.txt

And with the extruder motor running to the mainboard:

mainboard_m122.txt

I don't know enough about CAN bus to draw conclusions but I did think it was interesting the amount of lost CAN messages when the extruder is wired to the toolboard.

Any help would be appreciated.

@dc42 Would be more for fun I suppose