Posts made by crpalmer

@chrishamm I have a syslog that has the same gcode run twice in a row, once with no errors and then once with the errors. Hopefully the syslog is the "journal" that you were referring to. Either way, it's good to know that the error still occurs with the debug logging enabled.

@chrishamm Thanks.

I changed the log level to debug and reboot the PI to be sure everything was restarted. I see debug messages from the DuetControlServer and DuetWebServer in /var/log/syslog. If the error happens again (I fear the debug logging is going to change the timing that causes this to happen) should I attach the output of running "grep -i duet /var/log/syslog" to the github bug report?

(Let me know next week when you're back)

@chrishamm This problem is most definitely not fixed. Yesterday I had the error occur twice. FWIW, random and explained behaviour by the software used to control industrial machines is something that I think should still be investigated -- even if it's difficult.

Whenever I get the random error message, I click "Emergency Stop" in the interface and restart the job. I do so just to be on the safe side and since I know I'll have to click emergency stop eventually anyway because the print never terminates, and the interface fails to let me cancel it.

Yesterday, the error occurred in 2 prints jobs in a row (with an emergency stop in between). Memory corruption, while still a possibility, sounds very unlikely.

I did try to find a reproducible example by having macros running macros running macros, but I was not able to reproduce anything that doesn't involve actually running print jobs. One difference in my tests and the actual print jobs is that some macro invocations are generated by M401 / M402 gcodes. I see in the RRF code that when system macros are run, it takes not of that (runningSystemMacro). Is there any difference there that could be part of the problem?

@chrishamm Thank you but unfortunately I think that's not the (entire?) fix. Was it this commit that you were hoping fixed the problem?

I find that the error occurs more frequently on one of my machines so I upgraded it to 3.5.3 to test. I just had the error occur when starting a print. FYI:

I have 3 machines that were running 3.5.2 and I'm seeing errors with very different frequencies on these machines. The one I upgraded to 3.5.3 has the error occur 10% of the time. That machine has a EXP3HC board that runs a Y motor an U motor and an extruder. The second machine runs a toolboard and I see the error here less frequently (I don't have a percentage estimate but definitely less frequently). The last machine has yet to report an error and it doesn't use any CAN expansion boards.

I don't see anything interesting in the differences in the SBC. All three machines are running Raspberry PI 4 boards (the two that have had the errors are Rev 1.5 and the one that hasn't is 1.4). The most machine that most commonly has errors and the one that has never had an error are running Raspbian 10 and the one other is Raspbian 12.

9/21/2024, 4:12:58 PM	Error: in file prepare-to-print.g line 32: unknown variable 'probing_temp'
9/21/2024, 4:12:58 PM	Error: in file prepare-to-print.g line 34: unknown variable 'probing_temp'
9/21/2024, 4:12:43 PM	Warning: Macro file has been started on channel File but none was requested

@chrishamm I was just browsing the "random restarts on mini" thread and wondered if my problems could be related. However, both of my machines are running Duet 3 Mini 5+ (Ethernet not WiFi).

Both machines have CAN boards attached. The one that encounters this error more frequently is using a EXP3HC and the other a TOOL1LC.

@chrishamm Here's a gcode file that I was running at around the time I last saw the error. I can't be sure it's the one I was running but the exact object probably doesn't matter given that the error happens before the print itself starts.

YACS - PLA - 0.6mm.gcode

@chrishamm / @dc42 The two machines I am running 3.5.2 configs are:

https://github.com/crpalmer/3d-printing/tree/master/veho
https://github.com/crpalmer/3d-printing/tree/master/ender5

For whatever reason, it happens much more frequently on "ender5" (don't be confused by the name, all that is left of the original ender-5 is the frame). It doesn't happen all the time and I'm starting to wonder if it happens more frequently when it has been running for awhile (perhaps some kind of subtle memory corruption?). It did happen again yesterday:

9/10/2024, 6:27:28 AM	Error: in file prepare-to-print.g line 32: unknown variable 'probing_temp'
9/10/2024, 6:27:28 AM	Error: in file prepare-to-print.g line 34: unknown variable 'probing_temp'
9/10/2024, 6:27:12 AM	Warning: Macro file has been started on channel File but none was requested

and like before after the print finished (including M2 in the end.gcode) the machine thought that the print was still running and it was impossible to cancel the print. I end up just doing an Emergency Stop when this happens.

@gloomyandy Yes, I normally use active-low endstops. The ones I bought recently were wired as active high and I just left them as-is. I just rewired them to make them active-low and that does indeed seem to have solved the problem (not that I understand how it was a problem...). Thanks!

I have successfully used dual independent y motors on multiple printers and just verified that one of these really is working correctly (homes each motor to the corresponding endstop).

A new printer that I've been commissioning looks to me to be configured equivalently doesn't work correctly. This printer homes and to whichever endstop is triggered first and never triggers the second one. I can verify that it's only using one endstop either by manually triggering it or even just by making the gantry very offset which then homes to the very offset gantry position.

Both the machine that is working and the one I'm having trouble with are running RRF 3.5.2 and both are based on Duet 3 Mini 5+ boards. The one that is working has the endstops and motors on a CAN connected board and the one that is not working is connected directly to the Duet 3 Mini 5+ (using the 2 stepper expansion board for these 2 motors) with the endstops also connected to the main board.

Given that I know the software works and I have verified it works, that only leaves the fact that I'm being stupid. Can someone tell me what I've done wrong here?

The output of M574 M584:

Endstop configuration:
X: high end switch connected to pin !121.io2.in, min interval 30ms
Y: high end switches connected to pins !io5.in !io6.in
Z: none
Driver assignments: X0.0 Y0.5:0.6 Z0.1:0.2:0.4:0.3 E121.0, 3 axes visible

and the full config.g is:

global includeDuplication = 0

global xMin = 0
global xMax = 625
global yMin = 0
global yMax = 600
global zMax = 600
global xCenter = 300
global yCenter = 300
global zprobe_x = 0
global zprobe_y = 75

global klicky_is_manual = true
global klicky_pre_x = 113.8
global klicky_pre_y = 180
global klicky_dock_x = global.klicky_pre_x
global klicky_dock_y = 220
global klicky_release_x = global.klicky_dock_x - 50
global klicky_release_y = global.klicky_dock_y
global klicky_servo_up = 1660
global klicky_servo_down = 575
global klicky_n_deploys = 0

global in_filament_error = false

G4 S2 ; wait for expansion boards to start

; General preferences
G90                                                    ; send absolute coordinates...
M83                                                    ; ...but relative extruder moves

; Drives
M569 P0.0 S0 ; D3                                        ; x
M569 P0.1 S0 ; D3                                        ; z1 (front left)
M569 P0.2 S0 ; D3                                        ; z2 (back left)
M569 P0.3 S0 ; D3                                        ; z4 (front right)
M569 P0.4 S1 ; D3                                        ; z3 (back right)
M569 P0.5 S0 ; D3                                        ; y2 (right)
M569 P0.6 S0 ; D3                                        ; y1 (left)
M569 P121.0 S1 ; D3                                      ; e

M584 X0.0 Y0.5:0.6 Z0.1:0.2:0.4:0.3 E121.0               ; set drive mapping

; Z leadscrew positions
M671 X-100:-100:680:680 Y70:530:530:70 S5

M92 X53.33 Y53.33 Z600 E680                            ; set steps per mm (recommended; 690 orbiter)
M350 X16 Y16 Z16 E16 I1                                ; Configure microstepping with interpolation

M566 X600.00 Y600.00 Z240.00 E300 P1                   ; set maximum instantaneous speed changes (mm/min)
M203 X24000.00 Y24000.00 Z600.00 E7200                 ; set maximum speeds (mm/min)
M201 X1000.00 Y1000.00 Z500.00 E5000                   ; set accelerations (mm/s^2)
M906 X1200 Y1200 Z1200 I30
M906 E900 I10                                          ; set motor currents (mA) and motor idle factor in per cent
M84 S30                                                ; Set idle timeout

; Axis Limits
M208 X{global.xMin} Y{global.yMin} Z0 S1                ; set axis minima
M208 X{global.xMax} Y{global.yMax} Z{global.zMax} S0    ; set axis maxima

; Endstops
M574 X2 S1 P"!121.io2.in"                               ; configure active-high endstop for low end on X
M574 Y2 S1 P"!0.io5.in+!0.io6.in"                       ; configure active-high endstop for high end on Y

; Z-Probe
;M950 S0 C"io1.out"                                     ; servo pin definition
M558 P8 C"^121.io1.in" H5 F200 T24000
G31 X{global.zprobe_x} Y{global.zprobe_y} Z6.55 P25
M557 X100:500 Y100:500 P9                               ; define mesh grid
M376 H3

; Filament sensor (BTT SFS 2.0)
M591 D0 P7 C"121.io0.in" L3.024 R90:110 E9 S1
;M591 D0 P7 C"io4.in" P1 S1

; Accelerometer (toolboard), input shaping and pressure advance
M955 P121.0 I10                                        ; Z+ -> Y+ and X+ -> X+
m593 P"zvd" F38.5 S0.1
M572 D0 S0.05

; Fans (tool 0)
M950 F0 C"121.out1" Q250                               ; create fan and set its frequency
M106 P0 S0 H-1 C"part"                                 ; set fan value (off). Thermostatic control is turned off
M950 F1 C"121.out2" Q500                               ; create fan and set its frequency
M106 P1 S1 T45 H1 C"hotend"                            ; set fan value (on). Thermostatic control is turned on

; Fans (board cooling)
M308 S10 Y"mcu-temp" A"MCU"                            ; defines sensor 10 as MCU temperature sensor
M308 S11 Y"drivers" A"Duet stepper drivers"            ; defines sensor 11 as stepper driver temperature sensor
M950 F2 C"out5" Q500                                   ; create fan and set its frequency
M106 P2 S1 H-1  C"board"                               ; set fan value (on).  Thermostatic control is turned off
M106 P2 H10:11 T32 C"board"; set fan 2 value

; Bed Heater
;M308 S0 P"temp0" Y"thermistor" T100000 B4734 C1.153746e-7 ; configure sensor
M308 S0 P"temp0" Y"thermistor" T100000 B3950 ; configure sensor
M950 H0 C"out0" T0                                     ; create bed heater output and map it to sensor 0
M307 H0 R0.212 K0.115:0.000 D9.15 E1.35 S1.00 B0
M140 H0                                                ; map heated bed to heater 0
M143 H0 S120                                           ; set temperature limit for heater 0 to 120C

; thermistor (e3d)
M308 S1 P"121.temp0" Y"thermistor" T100000 B4725 C7.06e-8  ; configure sensor
M950 H1 C"121.out0" T1                                     ; create nozzle heater output and map it to sensor 1

; revo 40w
M307 H1 R3.488 K0.464:0.226 D1.62 E1.35 S1.00 B0 V24.1
M563 P0 S"E3Dv6" D0 H1 F0                              ; define tool 0
G10 P0 R0 S0                                           ; Set initial tool 0 active and standby temperatures to 0C

; Servo for klicky
;M950 S1 C"out6" ; assign GPIO port 1 to out9 (Servo header), servo mod
;M280 P1 S{global.klicky_servo_down}

; Miscellaneous
M912 P0 S0
T0

and homey.g:

G91               ; relative positioning
G1 H2 Z5 F6000    ; lift Z relative to current position
G1 H1 Y+650 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 H2 Y-5 F6000   ; go back a few mm
G1 H1 Y+10 F360   ; move slowly to Y axis endstop once more (second pass)
G1 H2 Z-5 F6000   ; lower Z again
G90               ; absolute positioning

Also, if anyone has done this themselves, are there any suggestions/tips/best practices to accurately measure the offset between the two endstops?

All I was coming up with was printing a large square, measuring it as best I can and then doing some math to get the skew angle and therefore the correction. And then obviously repeat until it seems close enough because all the measurements and printing itself are approximate...

I have a printer with a Y axis that has 2 independent motors, each with an endstop at the high end. The endstops aren't perfectly aligned and I want to apply an offset to the two sides when homing to make the x and y axis actually square. Is this the general approach that I want to take?

In config.g define addition axes to allow independent movement/homing of the two motors and apply the skew value to the axis maxima:

M584 ... Y0.6:0.5 ... U0.6 V0.5
M208 ... Y600 ... U600.x V600   ; The .x is the skew correction offset

and then to home Y I would do something like:

G91
G1 H1 Y+650 F1800    ; Coarsely home y to high end
G1 H2 Y-5 F6000      ; Back off the endstops
G1 H1 U+10 F360      ; Accurately home U (y left)
G1 H1 V+10 F360      ; Accurately home V (y right)
G90

; To finish homing Y, move the two independent motors to the same position
; (they will currently be at different positions due to the skew offset)
; and then set Y to that position:
G1 U599 V599 F12000
G92 Y599

@dc42 sbc for both machines.

My PrusaSlicer start gcode is:

M83          ; Relative Extruder mode
M98 P"/sys/prepare-to-print.g" H{is_extruder_used[0] ? first_layer_temperature[0] : 0} B{is_extruder_used[0] ? first_layer_bed_temperature[0] : 0}
T{initial_tool}

and the macro prepare-to-print.g is:

if exists(param.H) == false or exists(param.B) == false
  echo "Missing required parameter (H and B)"
  M99

var bed_temp = param.B
var probing_temp = min(var.bed_temp, 60)

;echo "Hotend temperatures: ", param.H
;echo "Probing temperature: ", var.probing_temp
;echo "Bed temperature: ", var.bed_temp

M220 S100     ; clear any speed changes
M290 R0 S0    ; clear any baby stepping
M106 S0       ; disable fans

M568 A1 P0 R{param.H} S{param.H}
M190 R{var.probing_temp+10}    ; Wait to get up (or down!) to the right temperature

M561
M98 P"/sys/homexy-if-needed.g"
M401
G28 Z
G32
G32
G28 Z
G29 S1

M98 P"/sys/retractprobe-forced.g"

if var.probing_temp < var.bed_temp
   M140 S{var.bed_temp+10}

M116

Since upgrading to 3.5.2 on one printer and a new deployment of 3.5.2 on another printer, I'm sporatically seeing errors on both printers when this macro is invoked while starting a print. Both printers are running Duet 3 Mini 5+ control boards.

The most common error I get is:

Error: in file prepare-to-print.g line 31: unknown variable 'probing_temp'

where probing_temp is used extensively thoughout the macro and line 31 (I assume really line 30 but reported as 31) is always executed and therefore if it was an error in the macro then it should always report the error. I just recently also saw this warning:

Warning: Macro file has been started on channel File but none was requested

Possibly related to these errors I am getting situations where clicking Pause Print in the web interface hangs and does nothing (a page reload shows the print still running) and when I received the warning, my filament sensor didn't trigger which makes we think that the warning / error is causing RRF to think that the print is not running even though the print is running.

Note that on the machine I upgraded to 3.5.2, the prepare-to-print macro has been running for a long time without any changes without ever reporting an error until version 3.5.2.

Am I doing something incorrect in how I use macros inside of macros? Is something that I'm doing venturing into undefined behaviour? Note that the macro prepare-to-print will invoke the macro homexy-if-needed which will invoke the macro homexy. Prepare-to-print also invokes the macro retractprobe-forced which will invoke the macro retract-probe.

(edit to add that I looked at the 3.5.3-rc.1 changelog and git diff 3.5.2 3.5.3-rc.1 and nothing appears to be related to me)

I am adding a revo + tool board to a new build and I wanted to know whether or not it was safe to power the E3D revo 5V hotend fan from the tool board? Specifically, I was thinking of using the IO_0 port to do so. Is this advisable or not advisable? Should I just use the E3D 24V->5V converter instead?

Thanks!

@dc42 FWIW, I don't even need to home the printer, just move any axis, wait and then move any other axis. Doing this now, my MCU Temperature was around 25C and, as best I can measure with an infrared thermometer, the drivers themselves never went above around 23C. When I'm not trying to measure temperature, the board has a 120mm fan blowing on it with exhaust holes out the side which seems to very effectively cool the drivers (as reported by the MCU as a proxy).

@phaedrux When I said "all stepper drivers", I meant that I will get short-to-ground for whatever motor I have just driven. For example:

• G92 X100 Y100
• X +10
• wait a minute
• Y + 0.1
• short-to-ground: y drivers
• X + 0.1
• short-to-ground: x driver, y drivers

I just added this on to the end of it:

• G92 Z100
• Z +0.05 (a bunch of times to see if I really had to wait any appreciable amount of time)
• wait a minute (I did have to wait)
• Z +0.05
• short-to-ground: x driver, y drivers, z drivers

This made me think it was related to idle hold, so I commented out the M84 line of my config.g but that didn't seem to change the behaviour. With that line removed, I can still replicate the same behaviour.

I do find it strange that this is affecting all stepper drivers, not just the one that was partially unplugged. Originally, I was trying the x axis but this is also the case:

• G92 Y100
• Y +0.1 from the dashboard
• wait 30 seconds
• Y +0.1

causes it to start reporting short-to-ground for both of my y steppers.

@phaedrux I don't see any obvious damage to the drivers (or anything else) on the board. To rule out somehow having damaged the stepper that was partially unplugged, I connected a different stepper in its place. That didn't change anything. Here's the M122 output after successfully moving an axis:

=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 3.3 (2021-06-15 21:47:01) running on Duet Maestro 1.0
Board ID: 08DGM-95762-FD3TD-6J1F8-3S86S-KS8MF
Used output buffers: 3 of 24 (22 max)
=== RTOS ===
Static ram: 23556
Dynamic ram: 67012 of which 144 recycled
Never used RAM 21928, free system stack 178 words
Tasks: NETWORK(ready,28.1%,270) HEAT(delaying,0.1%,345) Move(notifyWait,0.1%,343) TMC(notifyWait,2.2%,117) MAIN(running,69.5%,493) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:31 ago, cause: power up
Last software reset at 2021-12-06 19:06, reason: User, GCodes spinning, available RAM 21752, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 484
MCU temperature: min 21.0, current 22.0, max 22.3
Supply voltage: min 24.2, current 24.3, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/4/4, gc cycles 0
Driver 0: position 16000, standstill, read errors 0, write errors 0, ifcnt 9, reads 5227, writes 2, timeouts 0, DMA errors 0
Driver 1: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 5229, writes 0, timeouts 0, DMA errors 0
Driver 2: position 0, standstill, read errors 0, write errors 0, ifcnt 9, reads 5226, writes 2, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 5228, writes 0, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, read errors 0, write errors 0, ifcnt 9, reads 5226, writes 2, timeouts 0, DMA errors 0
Driver 5: position 0, standstill, read errors 0, write errors 0, ifcnt 9, reads 5226, writes 2, timeouts 0, DMA errors 0
Driver 6: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 5228, writes 0, timeouts 0, DMA errors 0
Date/time: 2021-12-07 05:03:34
Slowest loop: 3.89ms; fastest: 0.13ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest read time 0.5ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 20325ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 6, completed moves 6, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 7.39ms; fastest: 0.04ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex

And after letting it sit and then moving the axis 0.1mm with stepper errors:

Error: short-to-ground reported by driver(s) 0
12/7/2021, 5:06:45 AM	m122
=== Diagnostics ===
RepRapFirmware for Duet 2 Maestro version 3.3 (2021-06-15 21:47:01) running on Duet Maestro 1.0
Board ID: 08DGM-95762-FD3TD-6J1F8-3S86S-KS8MF
Used output buffers: 3 of 24 (23 max)
=== RTOS ===
Static ram: 23556
Dynamic ram: 67012 of which 144 recycled
Never used RAM 21928, free system stack 178 words
Tasks: NETWORK(ready,27.8%,270) HEAT(delaying,0.1%,345) Move(notifyWait,0.1%,343) TMC(notifyWait,2.2%,117) MAIN(running,69.9%,493) IDLE(ready,0.0%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:03:41 ago, cause: power up
Last software reset at 2021-12-06 19:06, reason: User, GCodes spinning, available RAM 21752, slot 2
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Step timer max interval 548
MCU temperature: min 21.8, current 24.0, max 24.4
Supply voltage: min 23.9, current 24.3, max 24.5, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/4/4, gc cycles 0
Driver 0: position 15984, short-to-ground, standstill, read errors 0, write errors 0, ifcnt 11, reads 51996, writes 2, timeouts 0, DMA errors 0
Driver 1: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 51998, writes 0, timeouts 0, DMA errors 0
Driver 2: position 0, standstill, read errors 0, write errors 0, ifcnt 10, reads 51998, writes 1, timeouts 0, DMA errors 0
Driver 3: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 51999, writes 0, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, read errors 0, write errors 0, ifcnt 10, reads 51998, writes 1, timeouts 0, DMA errors 0
Driver 5: position 0, standstill, read errors 0, write errors 0, ifcnt 10, reads 51998, writes 1, timeouts 0, DMA errors 0
Driver 6: position 0, standstill, read errors 0, write errors 0, ifcnt 7, reads 51998, writes 0, timeouts 0, DMA errors 0
Date/time: 2021-12-07 05:06:45
Slowest loop: 7.99ms; fastest: 0.16ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 15.0MBytes/sec
SD card longest read time 4.8ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 186941ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 7, completed moves 7, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 1], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
Heater 1 is on, I-accum = 0.0
=== GCodes ===
Segments left: 0
Movement lock held by 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 6.02ms; fastest: 0.04ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
Interface state active, link 100Mbps full duplex

Sounds like I've probably killed something related to the stepper drivers. It just occurred to me to try using only the y axis to see if the problem was specific to the x axis or just a general problem with the board. I homed the printer and then periodically kept moving just the y axis and had something similar happen after a few minutes.

While working on my printer (with the power off), I accidentally partially unplugged the cable from a stepper. It was about 50% plugged in and 50% unplugged.

I homed my printer with no problems and then started a print. After waiting for the bed and hotend to reach temperature, the job tries to home the printer causing that motor to stutter and I see "short-to-ground" errors on a bunch of drivers. If I power the printer off for a while (not just a few seconds), I can home that axis and drive it just fine. If I then let the printer sit for several minutes then homing that axis now causes the stuttering and a flurry of short-to-ground errors. Between the time that homing succeeded and the time that it failed, the printer didn't move and nothing was touched. In concrete steps, I did:

• Power on
• Home X
• G1 X200
• Home X
• G1 X200
• wait for a bit
• Home X
• bad things happen!

These steps seem to be reproducible. I've repeated the procedure three times in a row now and the couple of times when I homed and then started the print.

I'm guessing that this is a sign that I should upgrade to a Duet 3 board, but I wanted to check that there isn't any obvious reason why I would be seeing this behaviour?

Thanks!
Chris