3.2beta1 freeze on duet2wifi



  • 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.



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


  • administrators

    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.



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



  • @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.


  • administrators

    @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?



  • @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.



  • @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.


  • administrators

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


Log in to reply