I think it would look pretty cool if there was a current layer visualization panel on the web interface. Maybe it could update with what paths it has drawn so far. I was thinking just a simple 2D one similar to the way pronterface displays G-code. I don't know how resource intensive it might be but I think it might be a cool extra feature if Chris or someone has the time to spare.
curieos
@curieos
I aim to be T-shaped. As such, I dive into a lot of things. I hope to share the things I do.
Best posts made by curieos
-
Gcode visualizer
-
DWC becomes sluggish after a few days
I've been noticing that DWC becomes very slow to respond if the page is not reloaded for a few days. This is especially problematic when using an SBC with a display plugged in, since it is not easy to reload the page without a keyboard attached (like in the case of a kiosk mode browser using a touch interface), though it also happens on Windows 10 in Firefox. We are using DWC 2.4.6
-
RE: Save/Recall Heater State
@fcwilt I considered your method, but I foresaw maintaining parity with PrusaSlicer being a massive headache. That and, assuming a good amount of filament presets from multiple brands, the filament selection UI would balloon in size, similar to scrolling through all of the filament Prusa has in PS for their printers. I opted to go a generic route for DWC, which is a compromise to maintain usability. I don't want our customers to scroll through multiple pages of filaments in the UI, only to fat finger the wrong one (or accidentally tap PA6-GF instead of PA6-CF). The primary method of interacting with our machine is a touch screen.
If it existed, I would use it primarily in the pause/resume macros, though it could also be useful for the nozzle change macro.
-
RE: Running filament config.g on IDEX in duplication mode
@curieos I found the answer to my own question. https://docs.duet3d.com/User_manual/Reference/Gcodes#m563-define-or-remove-a-tool I can use the L parameter to set which drive to map filament to.
-
RE: Programming a smart effector
It was the wrong part number, I got the new one installed and avrdude accepted it for programming.
-
RE: 1LC Multiple Disconnects
@dc42 I may have fixed it.
Turns out on this unit, there was a zero impedance connection between DC ground and Earth ground. I found the culprit, the cutout for the ethernet extension plugged into the pi was made upside down. This meant the shielding on the plug was in contact with the aluminum frame panel. The panel is powder coated, but it appears the coating wore away in this area. I flipped it upside down and now the grounds aren't shorted.
I ran a 6 hour print last night and there were no issues. The longest I've seen it go without locking up was 3-4 hours, so I think this means the problem is solved. I'm running a slightly longer print (22.5 hours) now, so that will definitely be definitive.
-
RE: M911, Print not Resuming After Voltage Threshold is Reached
@infiniteloop said in M911, Print not Resuming After Voltage Threshold is Reached:
As @Phaedrux states, you need to check carefully whether it is safe to proceed. If you suffer from frequent power outages, there’s no other way than to install a UPS.
You're not understanding, this is supposed to be a large, industrial machine that offers power loss recovery as a selling point. At our shop we do occasionally suffer from momentary outages, but that's not the point. We can't account for a customer's situation.
For one, most UPSs can't handle the amount of AC power this draws (just shy of 1kW while printing). We got the DC supply buffer to ensure the DC system could remain powered long enough for the Duet to detect it.
Two, this machine is large enough that prints can go on for weeks. If a 2+ week long print using tens of kilos of plastic fails due to a power outage that lasts less than a minute, that could be hundreds or thousands of dollars in material that is now scrap.
@infiniteloop said in M911, Print not Resuming After Voltage Threshold is Reached:
…and the print is left in a paused state
After the power is restored, you can use command M916 to resume the print from where it stopped.It does not say, explicitly, that it won't resume after a full power loss incident. It also doesn't clearly explain the "R" parameter and what the expected behavior is. This is all that I can find in the docs:
Raaa
Resume threshold in volts. Must be greater than the auto save voltage. Set to a high value to disable auto resume.Hence my confusion. I can make a macro to enable this behavior, so it's not a huge deal, but it's not clear from the docs.
Regardless, it doesn't do the 100% expected behavior of resuming after a blip, where AC power is restored before the DC system fully loses power.
-
RE: M911, Print not Resuming After Voltage Threshold is Reached
@Phaedrux said in M911, Print not Resuming After Voltage Threshold is Reached:
The same could likely be achieved with the object model and conditional gcode if you desired.
Yes, I know, that's what I meant by this:
@curieos said in M911, Print not Resuming After Voltage Threshold is Reached:
This logic can be implemented into the resurrect-prologue.g file very trivially.
In fact, I already did.
Latest posts made by curieos
-
RE: M116 Hanging after M568 Error
@dc42 Is there a DSF or DWC release to go with those? I just encountered some very strange behavior retrying that print with those binaries.
I first homed the machine before the print. Then I started the print, and it homed again (as expected), and then immediately it rehomed. It then moved to the "starting position" near the nozzle wiper, skipped over waiting for the tool to heat and wiping in the tool change macros, moved to the print start location, waited for T0 to heat up, and started printing. It then got halfway done with the skirt, retracted, and moved back to the wiping location, then moved back to where it stopped with the skirt, did the extruder priming sequence, and resumed the skirt. I then paused it, and it moved to the park position. I tried resuming, and it then properly ran the toolchange sequence, but then it went to the start of the brim and seemingly randomly extruded a few lines in varying directions, unrelated the print geometry.
The start gcode for this file is:
; Run nozzle diameter and filament check M98 P"0:/sys/System Macros/Config Checks/nozzle_check.g" L0.6 S0.6 M98 P"0:/sys/System Macros/Config Checks/filament_check.g" L"NYLON" S"PVA" ; set extruder temp M568 P0 S275 R170 A1 M568 P1 S210 R120 A1 ; Set and wait for bed temp M190 S80 ; Home all axes G28 ; Enable mesh compensation M98 P"0:/sys/System Macros/Config Checks/load_heightmap.g" ; Move to starting position G0 H2 X{move.axes[0].min} Y50 F6000 ; Select first tool T0 ; Move near start G1 X251.37 Y156.171 Z2.3 F12000 G21 ; set units to millimeters G90 ; use absolute coordinates M83 ; use relative distances for extrusion T0 M116 P0 S5 ; Filament gcode M572 D0 S0.006 M107 ;LAYER_CHANGE ;Z:0.3 ;HEIGHT:0.3
The macros called can be found here:
https://github.com/HartSmart-Products/HSP1-I-SD-Image/tree/mainedit: Attached is the version report for all duet components
-
RE: M116 Hanging after M568 Error
@dc42 This is in SBC mode, can I just upload these to the FW directory and send the update commands?
-
M116 Hanging after M568 Error
I was able to break out of it by sending an M108 command, but I got an error in the console for an M568 command in this file to set the second layer temps.
The errors:
Error: CAN response timeout: board 20, req type 6013, RID 971 Error: at column 2: Error: CAN response timeout: board 21, req type 6013, RID 969 Error: at column 2: M568:
The code from the file at this line:
; stop printing object SECTIONED HULK BBC CARBON FOR MACHINING TEST.STL id:2 copy 0 ;LAYER_CHANGE ;Z:0.6 ;HEIGHT:0.3 ;LAYER:1 G1 E-1 F2400 ;WIPE_START G1 F19200 G1 X256.922 Y240.201 E-1 ;WIPE_END G1 Z.6 F450 M568 P0 S280 ; set temperature M568 P1 S215 ; set temperature M140 S60 ; set bed temperature ; printing object SECTIONED HULK BBC CARBON FOR MACHINING TEST.STL id:2 copy 0 G1 Z1 G1 X297.189 Y413.826 F24000 G1 Z.6 F450 G1 E2 F1800
M122 outputs:
M122 === Diagnostics === RepRapFirmware for Duet 3 MB6XD version 3.5.0-rc.3 (2024-01-24 17:59:29) running on Duet 3 MB6XD v1.01 or later (SBC mode) Board ID: 0JD2M-999AL-D25SW-6JKD0-3S06R-95ZB1 Used output buffers: 12 of 40 (40 max) === RTOS === Static ram: 153600 Dynamic ram: 92880 of which 184 recycled Never used RAM 93072, free system stack 112 words Tasks: SBC(2,ready,23.8%,407) HEAT(3,nWait 6,0.4%,322) Move(4,nWait 6,13.9%,213) CanReceiv(6,nWait 1,44.1%,770) CanSender(5,nWait 7,0.3%,325) CanClock(7,delaying,0.1%,346) MAIN(2,running,17.0%,444) IDLE(0,ready,0.4%,30), total 100.0% Owned mutexes: Telnet(MAIN) === Platform === Last reset 25:02:31 ago, cause: power up Last software reset at 2024-03-07 09:55, reason: User, Gcodes spinning, available RAM 95784, slot 0 Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x04 Aux0 errors 0,1,0 MCU temperature: min 29.4, current 46.7, max 50.4 Supply voltage: min 25.7, current 25.8, max 26.2, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 99/40, heap memory allocated/used/recyclable 4096/2644/1884, gc cycles 11 Events: 0 queued, 0 completed Driver 0: ok Driver 1: ok Driver 2: ok Driver 3: ok Driver 4: ok Driver 5: ok Date/time: 2024-03-20 11:35:37 Slowest loop: 1226.17ms; fastest: 0.04ms === 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 === DMs created 125, segments created 56, maxWait 51691952ms, bed compensation in use: mesh, height map offset 0.000, max steps late 1, ebfmin 0.00, ebfmax 0.00 no step interrupt scheduled Moves shaped first try 33337, on retry 20333, too short 109285, wrong shape 349661, maybepossible 18667 === DDARing 0 === Scheduled moves 7070, completed 7070, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 17], CDDA state -1 === DDARing 1 === 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, chamber heaters -1 -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 "M25" in state(s) 0 Telnet* is doing "M122" in state(s) 0 File* is doing "M116 P"{state.currentTool}"" in state(s) 0 0 19, running macro USB is idle in state(s) 0 Aux is doing "M25" 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 doing "M116 P1 S5" in state(s) 0 Queue2 is idle in state(s) 0 Q0 segments left 0, axes/extruders owned 0x80000003 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === check 0 clear 0 Extruder 0: no data received, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1: no data received, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 === CAN === Messages queued 1547554, received 122035323, lost 0, errs 1, boc 0 Longest wait 3ms for reply type 6013, peak Tx sync delay 765, free buffers 50 (min 47), ts 450758/450757/0 Tx timeouts 0,0,0,3,0,0 last cancelled message type 6013 dest 21 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 41823/41823 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2600c Buffer RX/TX: 2220/3712-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.0-rc.3 (2024-01-26 12:34:19) File /opt/dsf/sd/gcodes/Jarvie/Sectioned Hulk Modifier Test_0.6n_NYLON_22h34m.gcode is selected, processing HTTP: Buffered code: M25 Buffered code: M568 P0 A1 Buffered code: M568 P1 A0 Buffered codes: 104 bytes total File: Buffered code: M116 P{state.currentTool} ; wait for tool 0 heaters to reach operating temperature Buffered codes: 52 bytes total > Suspended code: M116 P0 S5 > Suspended code: M572 D0 S0.006 > Suspended code: ; printing object SECTIONED HULK BBC CARBON FOR MACHINING TEST.STL id:2 copy 0 > Suspended code: G1 X389.242 Y468.798 F24000 > Suspended code: G1 Z.6 F450 > Suspended code: G1 E2 F1800 > Suspended code: M204 P1000 > Suspended code: G1 F4800 > Suspended code: G1 X332.27 Y468.798 E3.95326 > Suspended code: G1 X332.27 Y171.202 E20.65005 > Suspended code: G1 X389.242 Y171.202 E3.95326 > Suspended code: G1 X389.242 Y199.689 E1.9767 > Suspended code: G1 X389.242 Y468.708 E18.6671 > Suspended code: M204 P4000 > Suspended code: G1 X389.242 Y468.708 F24000 > Suspended code: M73 P2 R1314 > Suspended code: G1 X389.828 Y469.383 > Suspended code: M204 P1000 > Suspended code: G1 F4800 > Suspended code: G1 X331.684 Y469.383 E4.03459 > Suspended code: G1 X331.684 Y170.617 E20.73124 > Suspended code: G1 X389.828 Y170.617 E4.03459 > Suspended code: G1 X389.828 Y199.689 E2.01729 > Suspended code: G1 X389.828 Y469.293 E18.7077 > Suspended code: M204 P4000 > Suspended code: G1 X389.828 Y469.293 F24000 > Suspended code: G1 X390.414 Y469.969 > Suspended code: M204 P1000 >> Doing macro tpost0.g, started by T0 >>> Doing macro 0:/sys/System Macros/Tool Change/tpost.g, started by M98 P{"0:/sys"^"/System Macros/Tool Change/tpost.g"} >>> Number of flush requests: 1 File2: Buffered code: M116 P1 S5 Buffered code: M572 D1 S0.04 Buffered code: ; printing object SECTIONED HULK BBC CARBON FOR MACHINING TEST.STL id:2 copy 0 Buffered code: G1 X274.174 Y310.448 F24000 Buffered code: G1 Z63.3 F450 Buffered code: G1 E2 F1800 Buffered code: G1 F4800 Buffered code: G1 X274.623 Y311.463 E.06673 Buffered code: G1 X275.389 Y312.452 E.07521 Buffered code: G1 X276.265 Y313.197 E.06914 Buffered code: G1 X276.876 Y313.561 E.04276 Buffered code: G1 X277.353 Y313.744 E.03072 Buffered code: G1 X275.617 Y316.744 E.2084 Buffered code: G1 X271.225 Y316.744 E.26407 Buffered code: G1 X269.493 Y313.744 E.20828 Buffered code: G1 X269.225 Y313.744 E.01611 Buffered code: G1 X269.227 Y313.208 E.03223 Buffered code: G1 X269.493 Y313.208 E.01599 Buffered code: G1 X271.225 Y310.208 E.20828 Buffered code: G1 X274.055 Y310.208 E.17015 Buffered code: G1 X273.852 Y309.672 E.03446 Buffered code: G1 X271.225 Y309.672 E.15795 Buffered code: G1 X269.493 Y306.672 E.20828 Buffered code: G1 X269.26 Y306.672 E.01401 Buffered code: G1 X269.263 Y306.137 E.03217 Buffered code: G1 X269.493 Y306.137 E.01383 Buffered code: G1 X271.225 Y303.137 E.20828 Buffered code: G1 X274.923 Y303.137 E.22234 Buffered code: G1 X274.135 Y304.532 E.09633 Buffered codes: 1404 bytes total Code buffer space: 2220 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 7 Full transfers per second: 42.11, max time between full transfers: 121.4ms, max pin wait times: 74.9ms/23.6ms Codes per second: 28.78 Maximum length of RX/TX data transfers: 5128/3328
M122 B20 Diagnostics for board 20: Duet TOOL1LC rev 1.1 or later firmware version 3.5.0-rc.3 (2024-01-24 17:55:14) Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25) All averaging filters OK Never used RAM 1544, free system stack 55 words Tasks: Move(3,nWait 7,3.0%,79) HEAT(2,nWait 6,4.8%,91) CanAsync(5,nWait 4,0.0%,49) CanRecv(3,nWait 1,1.8%,65) CanClock(5,nWait 1,0.4%,59) ACCEL(3,nWait 6,0.0%,53) TMC(2,delaying,66.4%,53) MAIN(1,running,34.2%,315) IDLE(0,ready,19.3%,27) AIN(2,delaying,90.5%,112), total 220.5% Owned mutexes: Last reset 25:10:52 ago, cause: power up Last software reset data not available Driver 0: pos 0, 404.7 steps/mm, standstill, SG min 0, read errors 14, write errors 0, ifcnt 35, reads 59693, writes 35, timeouts 31, DMA errors 0, CC errors 0, failedOp 0x71, steps req 0 done 53253485 Moves scheduled 605288, completed 605288, in progress 0, hiccups 1669, segs 57, step errors 0, maxLate 2 maxPrep 562, maxOverdue 164274, maxInc 132515, mcErrs 0, gcmErrs 0, ebfmin -1.00 max 1.00 Peak sync jitter -1/15, peak Rx sync delay 260, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 22.9, current 26.0, max 45.4 MCU temperature: min 23.9C, current 69.5C, max 98.7C Last sensors broadcast 0x00006002 found 3 86 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 115277228, send timeouts 0, received 2151698, lost 0, errs 1, boc 0, free buffers 18, min 17, error reg 20000 dup 0, oos 36/0/0/18, bm 0, wbm 0, rxMotionDelay 380, adv -164096/108406 Accelerometer: LIS3DH, status: 00 I2C bus errors 0, naks 3, contentions 0, other errors 0 === Filament sensors === Interrupt 4 to 134us, poll 8 to 2564us Driver 0: pos 2196.91, errs: frame 308 parity 0 ovrun 0 pol 0 ovdue 0
M122 B21 Diagnostics for board 21: Duet TOOL1LC rev 1.1 or later firmware version 3.5.0-rc.3 (2024-01-24 17:55:14) Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25) All averaging filters OK Never used RAM 2192, free system stack 55 words Tasks: Move(3,nWait 7,0.1%,79) HEAT(2,nWait 6,3.7%,91) CanAsync(5,nWait 4,0.0%,49) CanRecv(3,nWait 1,1.0%,71) CanClock(5,nWait 1,0.4%,59) ACCEL(3,nWait 6,0.0%,53) TMC(2,delaying,65.6%,53) MAIN(1,running,41.8%,315) IDLE(0,ready,19.0%,27) AIN(2,delaying,88.9%,112), total 220.5% Owned mutexes: Last reset 25:10:53 ago, cause: power up Last software reset at 2024-02-01 11:32, reason: HardFault, available RAM 2016, slot 0 Software reset code 0x0060 ICSR 0x00000003 SP 0x20002f08 Task MAIN Freestk 813 ok Stack: 200048c8 00000000 00000001 4aa36799 00000000 0000f3cb 4aa36798 21000000 20001488 0000f00d a5a5a5a5 0080bdc1 00000089 000001f4 20001ce0 0001285f 00000000 00000000 20004370 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 Driver 0: pos 0, 404.8 steps/mm, standstill, SG min 0, read errors 0, write errors 0, ifcnt 16, reads 40538, writes 16, timeouts 8, DMA errors 0, CC errors 0, failedOp 0x41, steps req 0 done 1013751 Moves scheduled 4732, completed 4732, in progress 0, hiccups 8, segs 31, step errors 0, maxLate 1 maxPrep 396, maxOverdue 3553, maxInc 2672, mcErrs 0, gcmErrs 0, ebfmin -0.93 max 1.00 Peak sync jitter -1/7, peak Rx sync delay 243, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 24.9, current 26.5, max 26.8 MCU temperature: min 27.9C, current 75.6C, max 81.4C Last sensors broadcast 0x00018004 found 3 32 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 7715520, send timeouts 0, received 1546216, lost 0, errs 1, boc 0, free buffers 18, min 17, error reg 20000 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 352, adv 35330/100443 Accelerometer: LIS3DH, status: 00 I2C bus errors 0, naks 3, contentions 0, other errors 0 === Filament sensors === Interrupt 4 to 85us, poll 6 to 1313us Driver 0: pos 13983.05, errs: frame 21 parity 0 ovrun 0 pol 0 ovdue 0
-
RE: 1LC Multiple Disconnects
@dc42 I may have fixed it.
Turns out on this unit, there was a zero impedance connection between DC ground and Earth ground. I found the culprit, the cutout for the ethernet extension plugged into the pi was made upside down. This meant the shielding on the plug was in contact with the aluminum frame panel. The panel is powder coated, but it appears the coating wore away in this area. I flipped it upside down and now the grounds aren't shorted.
I ran a 6 hour print last night and there were no issues. The longest I've seen it go without locking up was 3-4 hours, so I think this means the problem is solved. I'm running a slightly longer print (22.5 hours) now, so that will definitely be definitive.
-
RE: 1LC Multiple Disconnects
@dc42 The grounding wire is connected to earth ground, and it screws into an aluminum toolhead plate. The grounding wire connected to the 1LC via one of the mounting holes is also connected to the toolhead plate. I can see if there's a low impedance connection between DC ground and earth ground when I get into work today, I assume this would be an issue.
The extruder motor body is physically touching said toolhead plate, and the mounting screws go through the toolhead plate. The toolhead plate is anodized, so it's not the most solid connection, but I've checked with a multimeter and there is continuity. The extruder is an LGX Pro, so the hotend mount is made of anodized aluminum, and the hotend metalwork is connected to the toolhead plate through the extruder mounting. I've checked with a multimeter and it detects continuity. If this isn't good enough I can run a discrete grounding wire from the toolhead plate to the coldside of the hotend.
-
RE: 1LC Multiple Disconnects
@dc42 I'm reporting in that this issue is still occurring. I have changed out the CAN data and power cable runs to this toolhead yet again, in fact the run is a little different this time. The tool distribution board is now mounted to the gantry, so the power and data cables are shorter than before.
The same toolboard locks up at around the same point in any print I've tried, typically around the 1 hour mark. It's been replaced once already. The board does not recover until a full power cycle of the machine is performed.
I have an M122 output from this latest event:
=== Diagnostics === RepRapFirmware for Duet 3 MB6XD version 3.5.0-rc.3 (2024-01-24 17:59:29) running on Duet 3 MB6XD v1.01 or later (SBC mode) Board ID: 0JD2M-999AL-D25SW-6JKD0-3S06R-95ZB1 Used output buffers: 1 of 40 (40 max) === RTOS === Static ram: 153600 Dynamic ram: 92392 of which 0 recycled Never used RAM 96400, free system stack 122 words Tasks: SBC(2,ready,14.4%,407) HEAT(3,nWait 6,0.2%,322) Move(4,nWait 6,8.7%,213) CanReceiv(6,nWait 1,28.2%,770) CanSender(5,nWait 7,0.1%,325) CanClock(7,delaying,0.1%,346) MAIN(2,running,47.7%,444) IDLE(0,ready,0.6%,30), total 100.0% Owned mutexes: HTTP(MAIN) === Platform === Last reset 03:30:24 ago, cause: power up Last software reset at 2024-03-07 09:55, reason: User, Gcodes spinning, available RAM 95784, slot 0 Software reset code 0x6003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task SBC Freestk 0 n/a Error status: 0x04 Aux0 errors 0,0,0 MCU temperature: min 30.9, current 48.1, max 49.9 Supply voltage: min 25.8, current 26.0, max 26.1, under voltage events: 0, over voltage events: 0, power good: yes 12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0 Heap OK, handles allocated/used 99/38, heap memory allocated/used/recyclable 2048/1388/712, gc cycles 4 Events: 3 queued, 3 completed Driver 0: ok Driver 1: ok Driver 2: ok Driver 3: ok Driver 4: ok Driver 5: ok Date/time: 2024-03-14 14:58:02 Slowest loop: 1000.79ms; 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 === DMs created 125, segments created 31, maxWait 3494446ms, bed compensation in use: none, height map offset 0.000, max steps late 1, ebfmin 0.00, ebfmax 0.00 no step interrupt scheduled Moves shaped first try 9729, on retry 4260, too short 16445, wrong shape 17913, maybepossible 1481 === DDARing 0 === Scheduled moves 59311, completed 59311, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 4], CDDA state -1 === DDARing 1 === 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, chamber heaters -1 -1 -1 -1, ordering errs 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 0x0000000 Code queue 0 is empty Q1 segments left 0, axes/extruders owned 0x0000000 Code queue 1 is empty === Filament sensors === check 0 clear 0 Extruder 0: no data received, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 Extruder 1: no data received, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0 === CAN === Messages queued 189586, received 21212642, lost 0, errs 586337, boc 48 Longest wait 208ms for reply type 6033, peak Tx sync delay 1409, free buffers 50 (min 47), ts 63121/63096/0 Tx timeouts 0,0,0,0,0,0 === SBC interface === Transfer state: 5, failed transfers: 0, checksum errors: 0 RX/TX seq numbers: 57670/57670 SPI underruns 0, overruns 0 State: 5, disconnects: 0, timeouts: 0 total, 0 by SBC, IAP RAM available 0x2600c Buffer RX/TX: 0/0-0, open files: 0 === Duet Control Server === Duet Control Server version 3.5.0-rc.3 (2024-01-26 12:34:19) File+ProcessInternally: > Busy Failed to deserialize the following properties: - Board -> BoardState from "timedOut" Code buffer space: 4096 Configured SPI speed: 8000000Hz, TfrRdy pin glitches: 1 Full transfers per second: 39.34, max time between full transfers: 73.4ms, max pin wait times: 69.8ms/18.6ms Codes per second: 13.12 Maximum length of RX/TX data transfers: 5088/3144
I'm going to try disconnecting all connections to the board except for the endstop required for homing, and then I'll run another print. Let me know if there's any additional steps I should try.
edit: Here's the M122 for the board that locked up after a restart
Diagnostics for board 21: Duet TOOL1LC rev 1.1 or later firmware version 3.5.0-rc.3 (2024-01-24 17:55:14) Bootloader ID: SAMC21 bootloader version 2.8 (2023-07-25) All averaging filters OK Never used RAM 2936, free system stack 104 words Tasks: Move(3,nWait 7,0.0%,135) HEAT(2,nWait 6,0.2%,127) CanAsync(5,nWait 4,0.0%,51) CanRecv(3,nWait 1,0.0%,71) CanClock(5,nWait 1,0.0%,59) ACCEL(3,nWait 6,0.0%,53) TMC(2,delaying,3.4%,53) MAIN(1,running,91.7%,315) IDLE(0,ready,0.0%,27) AIN(2,delaying,4.6%,112), total 100.0% Owned mutexes: Last reset 00:02:17 ago, cause: power up Last software reset at 2024-02-01 11:32, reason: HardFault, available RAM 2016, slot 0 Software reset code 0x0060 ICSR 0x00000003 SP 0x20002f08 Task MAIN Freestk 813 ok Stack: 200048c8 00000000 00000001 4aa36799 00000000 0000f3cb 4aa36798 21000000 20001488 0000f00d a5a5a5a5 0080bdc1 00000089 000001f4 20001ce0 0001285f 00000000 00000000 20004370 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 a5a5a5a5 Driver 0: pos 0, 404.8 steps/mm, standstill, SG min 0, read errors 0, write errors 0, ifcnt 12, reads 2957, writes 12, timeouts 0, DMA errors 0, CC errors 0, steps req 0 done 0 Moves scheduled 0, completed 0, in progress 0, hiccups 0, segs 0, step errors 0, maxLate 0 maxPrep 0, maxOverdue 0, maxInc 0, mcErrs 0, gcmErrs 0, ebfmin 0.00 max 0.00 Peak sync jitter 0/4, peak Rx sync delay 207, resyncs 0/0, no timer interrupt scheduled VIN voltage: min 26.7, current 26.8, max 26.8 MCU temperature: min 34.8C, current 41.4C, max 41.4C Last sensors broadcast 0x00018004 found 3 35 ticks ago, 0 ordering errs, loop time 0 CAN messages queued 2530, send timeouts 0, received 2038, lost 0, errs 0, boc 0, free buffers 18, min 18, error reg 0 dup 0, oos 0/0/0/0, bm 0, wbm 0, rxMotionDelay 0 Accelerometer: LIS3DH, status: 00 I2C bus errors 0, naks 3, contentions 0, other errors 0 === Filament sensors === Interrupt 5726621 to 0us, poll 6 to 542us Driver 0: no data received, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0
-
RE: 1LC Multiple Disconnects
@Phaedrux Yes, all of the 24V system is connected to one supply.
-
RE: 1LC Multiple Disconnects
@dc42 I tried updating that machine to 3.5 rc3 and the issue persists. What physically can cause a 1LC to lock up until a full power cycle?
-
RE: 1LC Multiple Disconnects
@dc42 Any other suggestions? I just replaced the power cable for the toolboard with brand new wire and this issue is still occurring.
-
RE: 1LC Multiple Disconnects
@dc42 Correct, IO_0 is not connected. You said OUT0 earlier, which was confusing.
The hotend metalwork and toolboard are connected via the toolplate. The hotend has continuity with the plate, and the toolboard has a connection to the toolplate via the green wire in the upper right corner.
I put the heatsink on the MCU because I noticed the previous toolboard's MCU was very hot to the touch before I swapped it out. I put it on that toolboard, and then transferred it to the new one when I swapped it out. Originally I thought it was just an overheating issue. The heatsink has preattached thermal adhesive. Not shown is a thin ceramic heatsink on the rear of the toolboard, mounted with some 3M thermal transfer adhesive. That covers the MCU and stepper driver.