@jay_s_uk yup, that worked, thanks!

@dc42 It may have been a signal issue the first time, however I don't think it is anymore when it won't stop crashing despite rebooting itself. I see when it gets stuck - I had the usb console hooked up hoping to see some output on it, which means that the duet wasn't completely power cycled even when I attempted to hard power cycle it. Anyway, there is some left-over state maybe in the lis3dh itself that causes this crash even after it reboots, and there is no longer a signal issue, at least temporarily.

To reproduce in console:
M955 P0 C"spi.cs4+spi.cs3" I25
M955 P0
Accelerometer 0 type LIS3DH with orientation 25 samples at 1344Hz with 10-bit resolution, SPI frequency 2000000
M956 P0 S1000 A0
<crash>

Was intermittently working (I captured many traces) and crashing, but now consistently crashing for some reason.

config-3.g

M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.5.0-beta.4 (2023-06-08 23:39:39) running on Duet WiFi 1.02 or later
Board ID: 08DGM-956GU-DJMSJ-6J9FG-3SD6J-9UPHG
Used output buffers: 1 of 26 (24 max)
Error in macro line 56 while starting up: Heater 0 not found
=== RTOS ===
Static ram: 23236
Dynamic ram: 77116 of which 12 recycled
Never used RAM 9924, free system stack 164 words
Tasks: NETWORK(1,ready,15.4%,219) HEAT(3,nWait,0.1%,329) Move(4,nWait,0.0%,364) MAIN(1,running,84.0%,743) IDLE(0,ready,0.5%,29), total 100.0%
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 00:03:23 ago, cause: software
Last software reset at 2023-06-18 18:55, reason: HeatTaskStuck, Gcodes spinning, available RAM 7780, slot 0
Software reset code 0x0143 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x20004770 Task ACCE Freestk 4294946641 ok
Stack: 20005958 2000412c 20000150 e000e000 006af974 0045f435 0045ddf6 6100f000 00000001 e000e000 0045f435 2000d0e0 00023264 2000d110 0043104b 2000d0e0 a5a5a5a5 a5a5a5a5 20004bb4 a5a5a5a5 004310ef a5a5a5a5 0045dd1d a5a5a5a5 00000000 00000000 00000000
Error status: 0x00
Aux0 errors 0,0,0
MCU temperature: min 30.5, current 32.2, max 32.7
Supply voltage: min 24.3, current 24.4, max 24.6, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/2, heap memory allocated/used/recyclable 2048/32/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min n/a
Driver 1: standstill, SG min n/a
Driver 2: standstill, SG min n/a
Driver 3: standstill, SG min n/a
Driver 4: standstill, SG min n/a
Driver 5: 
Driver 6: 
Driver 7: 
Driver 8: 
Driver 9: 
Driver 10: 
Driver 11: 
Date/time: 2023-06-18 18:59:03
Cache data hit count 4294967295
Slowest loop: 133.66ms; fastest: 0.19ms
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: 20.0MBytes/sec
SD card longest read time 0.7ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, segments created 0, maxWait 0ms, bed compensation in use: none, height map offset 0.000, ebfmin 0.00, ebfmax 0.00
no step interrupt scheduled
=== DDARing 0 ===
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, chamber heaters -1 -1 -1 -1, ordering errs 0
Heater 2 is on, I-accum = 0.0
=== GCodes ===
Movement locks 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
Q0 segments left 0
Code queue 0 is empty
=== Network ===
Slowest loop: 61.46ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
HTTP sessions: 1 of 8
= WiFi =
Interface state: active
Module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
Firmware version 1.27
MAC address 5c:cf:7f:76:6c:93
Module reset reason: Turned on by main processor, Vcc 3.36, flash size 4194304, free heap 21968
WiFi IP address 192.168.1.188
Signal strength -48dBm, channel 0, mode 802.11n, reconnections 0
Clock register 00002002
Socket states: 0 0 0 0 0 0 0 0

@gloomyandy The moves that do not trigger stall detection are manual moves from DWC, or issuing gcode to the console like G91; G1 X25 F5000 to move the toolhead (or Z platform) past the physical stops so the motor hard stalls.

Machine is a FlashForge Creator Pro with Duet2Wifi 3.4.5

An additional experiment I tried was setting the motor stall up as an axis endstop. That didn't work either. Although I haven't been able to gather from the documentation if two endstops on a single axis are supported (microswitch and one end and stall detection at the other).

Config attached. config-2.g

I have stall detection successfully triggering during prints if I turn the S value down 2 notches to S17 or below during print:

M915 X Y S19 F0 R3

driver-stall.g executes here and displays a message and rehomes.

However, when doing moves to hard stops with the axis limits removed, it detects no stall and the steppers skip, no matter how low I make the S value (-63) or how fast the move is? I also tried changing H and motor torque during the test, nothing has made it trigger even once here.

@jay_s_uk yup, that worked, thanks!

@jay_s_uk said in PanelDue 7.0i erased and USB com port won't appear?:

@r3cvr just update it from the duet itself https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_PanelDue#firmware-update-via-duet

It was on 1.x, I don't think it will work. That seems like a new feature "From RepRapFirmware version 3.2 (beta 4.1), you can flash the PanelDue firmware from the Duet itself, provided you have a V3/5i/7i PanelDue running firmware 3.2.2 or later"

Tried updating my PanelDue 7.0i after many years over USB, the USB com port will not appear - tried 3 cables and 4 machines (Mac and Windows). I figured the port would detect after it was erased but that does not appear to be the case. Now it just boots with a white screen with grey lines. What do I do now?

I kind of remember it was tempramental the last time I updated years ago too, but it did work eventually last time.

@dc42 said in Heater Fault debug facility:

A falling temperature may be caused by the heater or the thermistor falling out of the heater block. Either could cause a fire.

But false positives lead to effectively disabling the feature?

Is there any way to measure the resistance/power consumption of the heater? Could try and use the resistance as a secondary temp measurement and set thresholds for disabling. I'm assuming most heaters have some positive coefficient of resistance.

@dragonn said in Heater Fault debug facility:

@r3cvr and what is wrong with that? One step of setting up a new printer is always do a PID tune.

Print fails with no extrusion after heater fault shuts down heater. That's how my first dozen or so print attempts on DuetWifi went. I actually have several PID tunes, done at different model fan settings. No surprise it comes up with different parameters. Doesn't help this issue that much.

With default settings, I was getting a heater fault whenever the model fan came on, as it would cause a dip in extruder temperature until the PID caught up. Had to greatly relax the fault detection. Should detect on temperature direction instead of anomaly from set temp?

Dive height has a huge impact on the time to probe the bed. However one point that's too high will abort the calibration with an error. Why not simply dive again until it's not triggered, and try again? This would let you set dive heights approaching 0 as it would always automatically find the trigger point.