Duet3 crashes on connect with Firefox and other issues...



  • Is anyone noticing any problems with their Duet3s that when you connect with Firefox to it midprint?

    I started noticing issues with my board almost immediately after I installed it. Once a print is running, each time I connect to the web ui with Firefox - my printer immediately stops and it gets reset.
    If I use Chrome - this doesn't always happen, but if I keep the tab open - prints will always fail midprint - although the time the reset happens is random (even for the same file).

    I ran diagnostics and one part does seem indicative of a problem.

    M122
    === Diagnostics ===
    RepRapFirmware for Duet 3 MB6HC v0.6 or 1.0 version 3.01-RC1 running on Duet 3 MB6HC
    Board ID: 08DJM-956L2-G43S4-6JKDA-3SJ6T-1B6GH
    Used output buffers: 1 of 40 (7 max)
    === RTOS ===
    Static ram: 153800
    Dynamic ram: 160652 of which 32 recycled
    Exception stack ram used: 504
    Never used ram: 78228
    Tasks: NETWORK(ready,440) ETHERNET(blocked,456) HEAT(blocked,1128) CanReceiv(suspended,3820) CanSender(suspended,1440) CanClock(blocked,1432) TMC(blocked,212) MAIN(running,4392) IDLE(ready,76)
    Owned mutexes:
    === Platform ===
    Last reset 00:01:31 ago, cause: software
    Last software reset at 2020-02-26 21:24, reason: Memory protection fault, spinning module none, available RAM 78132 bytes (slot 2)
    Software reset code 0x4171 HFSR 0x00000000 CFSR 0x00000082 ICSR 0x04427804 BFAR 0x000017bc SP 0x20411874 Task 0x45485445
    Stack: 204117bc 00408876 01090000 000001f4 00000001 00000000 00000036 20411b24 20411919 20418d68 00408ecd 
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 25.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 45.0, current 45.3, max 45.6
    Supply voltage: min 23.7, current 23.9, max 24.0, 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
    Driver 0: standstill, reads 54964, writes 19 timeouts 0, SG min/max 0/140
    Driver 1: standstill, reads 54965, writes 19 timeouts 0, SG min/max 0/144
    Driver 2: standstill, reads 54970, writes 14 timeouts 0, SG min/max 0/0
    Driver 3: standstill, reads 54966, writes 19 timeouts 0, SG min/max 0/57
    Driver 4: standstill, reads 54967, writes 19 timeouts 0, SG min/max 0/88
    Driver 5: standstill, reads 54967, writes 19 timeouts 0, SG min/max 0/78
    Date/time: 2020-02-26 21:26:01
    Slowest loop: 6.57ms; fastest: 0.07ms
    === Move ===
    Hiccups: 0(0), FreeDm: 375, MinFreeDm: 371, MaxWait: 22328ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 5, completed moves: 5, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
    === AuxDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0
    === Heat ===
    Bed heaters = 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
    === 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
    serial is idle in state(s) 0
    aux is idle in state(s) 0
    daemon is idle in state(s) 0
    queue is idle in state(s) 0
    lcd is idle in state(s) 0
    spi is idle in state(s) 0
    autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 6.81ms; fastest: 0.03ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
    HTTP sessions: 2 of 8
    - Ethernet -
    State: 5
    Error counts: 0 0 0 0 0
    Socket states: 5 2 2 2 2 0 0 0
    === CAN ===
    Messages sent 367, longest wait 0ms for type 0
    === Linux interface ===
    State: 0, failed transfers: 0
    Last transfer: 91420ms ago
    RX/TX seq numbers: 0/1
    SPI underruns 0, overruns 0
    Number of disconnects: 0
    Buffer RX/TX: 0/0-0
    

    The other issues I have with the board is being unable to get stealthChop to run regardless of how I tweak the settings with M569 and M915... Anything above 5mm/s produces exactly the same noise level (even if I tweak the V and H params on M569). Sometimes, when the board does get quiet (but only after I use M915), I keep getting errors for saying Motor 1 Phase B may be disconnected.
    I changed cables, changed the motor, problem persists.

    Setup info:
    Hypercube Evolution
    XY motors are LDO 42STH47-1684AC - X is Motor 0, Y is Motor 1
    Extruder motor is generic Nema 17 (Motor 2).
    Triple Z motors (generic Nema 17 don't think they matter here) - Motors 3-5.

    This setup is what I used with Duet 2 Wifi (with one motor added for extra Z, but the motor was running fine on another printer with Duet Maestro).

    Commands to use stealthChop:
    M569 P0.# S0 D3 V100 H150
    M915 P0.# S3 R0 T1 (this gives lower noise level, but causes the Motor 1 Phase B may be disconnected thing).

    I tried updating the firmware - problem persists regardless of version (RC1 and RC2 show the same with the resets and stealthChop not working).

    Anyone else with these problems? Or is my board shot?


  • administrators

    Thanks for your report. I use FireFox with my Duet 3 in standalone mode all the time. However the software reset data that you posted indicates it has crashed in a memory management function of the Lwip network stack. I just checked and there have been some updates to Lwip, so I'll upgrade RRF to use the new version in the forthcoming RC3. I'll let you know when we have a preview of that.

    Regarding stealthChop, it may be that we need to disable the motor open-load detection when stealthChop is used.



  • Awesome! Thanks for the answer 🙂

    I'll look forward to RC3 and for now I'll resort to just using the PanelDue midprint.

    Regarding stealthChop - I'll recheck with RC2 (based on the other thread on the same topic).



  • Just to confirm - RC3 solved the problem with crashing lwip and now the printer is indeed MUCH quieter without the M915 workaround.

    Thank you for the help 🙂


  • administrators

    Thanks for confirming!


Log in to reply