3.2beta1 freeze on duet2wifi

Adrian52

Running 3.2beta1 on a stand alone duet2wifi 1.01. Started a new thread beacuse seems to be a different situation from the duet/sbc freezes. Printing stopped with head at the printing position; the M122 readout:

m122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.2-beta1 running on Duet WiFi 1.0 or 1.01
Board ID: 08DAM-999TL-MQ4SD-6J9FD-3SJ6J-K593W
Used output buffers: 3 of 24 (13 max)
=== RTOS ===
Static ram: 23916
Dynamic ram: 99156 of which 44 recycled
Exception stack ram used: 576
Never used ram: 7380
Tasks: NETWORK(ready,148) HEAT(blocked,308) MAIN(running,423) IDLE(ready,20)
Owned mutexes: WiFi(NETWORK)
=== Platform ===
Last reset 02:46:13 ago, cause: power up
Last software reset at 2020-09-22 19:33, reason: User, GCodes spinning, available RAM 7372, slot 0
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0x020
MCU temperature: min 18.7, current 33.4, max 35.5
Supply voltage: min 11.5, current 12.1, max 12.5, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: position 66354, standstill, SG min/max 0/1023
Driver 1: position 64909, standstill, SG min/max 0/1023
Driver 2: position 64418, standstill, SG min/max 0/1023
Driver 3: position 0, standstill, SG min/max 0/1023
Driver 4: position 0, standstill, SG min/max not available
Driver 5: position 0
Driver 6: position 0
Driver 7: position 0
Driver 8: position 0
Driver 9: position 0
Driver 10: position 0
Driver 11: position 0
Date/time: 2020-09-25 15:15:05
Cache data hit count 4294967295
Slowest loop: 78.27ms; fastest: 0.16ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 6.5ms, write time 18.2ms, max retries 0
=== Move ===
Hiccups: 1707612(0), FreeDm: 168, MinFreeDm: 85, MaxWait: 2774376ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 76712, completed moves: 76711, StepErrors: 0, LaErrors: 0, Underruns: 2315, 0  CDDA state: 3
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.4
Heater 1 is on, I-accum = 0.7
=== GCodes ===
Segments left: 0
Movement lock held by HTTP
HTTP is idle in state(s) 20
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: 147.50ms; fastest: 0.00ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8
- WiFi -
Network state is active
WiFi module is connected to access point 
Failed messages: pending 0, notready 0, noresp 0
WiFi firmware version 1.23
WiFi MAC address 5c:cf:7f:2c:24:6b
WiFi Vcc 3.37, reset reason Turned on by main processor
WiFi flash size 4194304, free heap 24504
WiFi IP address 192.168.1.16
WiFi signal strength -52dBm, reconnections 0, sleep mode modem
Clock register ffffffff
Socket states: 0 0 0 0 0 0 0 0
=== Filament sensors ===
Extruder 0: pos -4.72, errs: frame 0 parity 0 ovrun 0 pol 0 ovdue 0

System did not respond to M999 - needed hard reset. Same gcode file printed sucessfully immediately afterwards (with hiccups less than 200). First time this has happened running beta1 for about a week.
BTW, the L parameter in M591 works well for me - excellent.

Luke'sLaboratory

Could you post the gcode lines before and then some after where it paused?

dc42

Unfortunately I can't see anything in that M122 report that suggests a serious problem, which is not surprising if you had to reset the Duet before getting the M122 report.

If it happens again, try connecting via USB and see if you can get a M122 report from there without having to reset the Duet first.

Adrian52

@dc42 I got that M122 from DWC before trying M999. Will make sure I do it via usb if it happens again

Adrian52

@Luke-sLaboratory sorry didnt think to note exactly where it stopped in the gcode. It did print the same file without a hitch immediately after.

dc42

@Adrian52 said in 3.2beta1 freeze on duet2wifi:

@dc42 I got that M122 from DWC before trying M999. Will make sure I do it via usb if it happens again

Thanks, if the M122 report was obtained before you did the reset, then it's accurate and I don't need one obtained via USB.

One odd thing I just noticed is that the report includes "Movement lock held by HTTP". This implies that you sent a movement command from DWC (or another HTTP client), but that move wasn't complete at the time. Is there any chance that you sent a movement command from DWC with such a low feed rate that it looked like the tool wasn't moving?

Adrian52

@dc42 you are right - I sent a pause and then resume, to see if that would get things moving. The only thing I noticed was the large number of hiccups, which I did not see on the subsequent successful run.

Adrian52

@dc42 should have added that the head did not appear to be moving during the freeze, but there was a little bit of motor noise.

dc42

@Adrian52, please try firmware 3.2beta2 and see whether that resolves the issue.