web server dying



  • Happened a few times last few days, after few prints (not very long ones) web becomes unaccessible... Printer still works, paneldue connected and executes commands, but web is not there, not responding at all..

    I replug the ethernet cable and I get info on the paneldue that it got it's IP address assigned (static from dhcp server) but still, web ain't there.

    The only thing that changed since few days ago (this started happening yesteday/today) is that I upgraded paneldue to 1.24 and did something on the paneldue that it actually start turning off the screen after a while and added

    M575 P1 B115200 S1 ; Set auxiliary serial port baud rate and require checksum (for PanelDue)
    M575 P1 B115200 S1 ; Set auxiliary serial port baud rate and require checksum (for PanelDue)
    

    to the config

    before I had no 575 line and paneldue was running @ 57600

    This is diagnostic after restart (I don't see anything useful since everything is reset).

    === Diagnostics ===
    RepRapFirmware for Duet 2 WiFi/Ethernet version 3.01-RC10 running on Duet Ethernet 1.02 or later
    Board ID: 08DGM-9T6BU-FG3S4-6J9FD-3SD6Q-KVRBFUsed output buffers: 1 of 24 (15 max)
    === RTOS ===
    Static ram: 28044
    Dynamic ram: 93412 of which 44 recycled
    Exception stack ram used: 248
    Never used ram: 9324
    Tasks: NETWORK(ready,200) HEAT(blocked,1228) MAIN(running,1840) IDLE(ready,80)
    Owned mutexes:
    === Platform ===
    Last reset 00:00:39 ago, cause: software
    Last software reset at 2020-05-04 06:13, reason: User, spinning module GCodes, available RAM 8860 bytes (slot 0)
    Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
    Error status: 0
    Free file entries: 10
    SD card 0 detected, interface speed: 20.0MBytes/sec
    SD card longest block write time: 0.0ms, max retries 0
    MCU temperature: min 33.0, current 33.4, max 33.7
    Supply voltage: min 24.0, current 24.1, max 24.1, under voltage events: 0, over voltage events: 0, power good: yes
    Driver 0: standstill, SG min/max not available
    Driver 1: standstill, SG min/max not available
    Driver 2: standstill, SG min/max not available
    Driver 3: standstill, SG min/max not available
    Driver 4: standstill, SG min/max not available
    Date/time: 2020-05-04 06:14:34
    Cache data hit count 78332450
    Slowest loop: 8.05ms; fastest: 0.13ms
    I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
    === Move ===
    Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
    Bed compensation in use: none, comp offset 0.000
    === MainDDARing ===
    Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0  CDDA state: -1
    === 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 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
    Daemon is idle in state(s) 0
    Autopause is idle in state(s) 0
    Code queue is empty.
    === Network ===
    Slowest loop: 12.85ms; fastest: 0.02ms
    Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0)
    HTTP sessions: 1 of 8
    Interface state active, link 100Mbps full duplex
    === Filament sensors ===
    Extruder 0 sensor: no data received
    


  • Happened again.

    @dc42 any hint on how to fetch some debug info? I tried M122 from the console on the paneldue when web died but output was not scrolling to record it. Telnet is off attm.



  • M111 for debug



  • @bearer said in web server dying:

    M111 for debug

    cool, I did

    Debugging enabled for modules: Network(1) Webserver(2)
    

    now when the webserver becomes inaccessible, how to get the debug data?



  • hooked up my usb isolator, attached to usb serial, putty logging what's coming out of it .. let's hope this will catch some useful data 🙂



  • @arhi said in web server dying:

    how to get the debug data?

    not sure if its only usb or paneldue port as well, usb for sure. (it'll just print its debug stuff as it happens, so at best you get the last actions and M122 after restetting will give you some stack pointer stuff iirc)



  • @bearer I hooked up the isolator and attached usb of the duet to my main desktop, it's logging now, nothing interesting in the log so far but it never died during print, just after few consecutive short prints (I'm trying to tune in damn stringing for petg and 0.6mm nozzle and after 20 prints and some superbly hard settings it's still stringing, so i'm printing a whole bunch of 5min prints one after another and the web just dies between them fromt ime to time)



  • @arhi sorry, i read isolator and my mind jumped to ttl. anwyays, after the crash the following section from m122 would be relevant to dc42 or anyone else that would decode the mythical stack dump

    === Platform ===
    Last reset 00:00:39 ago, cause: software
    Last software reset at 2020-05-04 06:13, reason: User, spinning module GCodes, available RAM 8860 bytes (slot 0) Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d



  • @bearer said in web server dying:

    i read isolator and my mind jumped to ttl.

    I don't connect stuff to usb lightly 😄 ... normally I plug some orange pi or something in but this was the fastest way attm and risking 30V on my usb connector on 5keur computer motherboard ain't gonna happen so usb isolator is a go 😄 .. these adum boards are great, you do have to manually set the usb speed but since most of the boards I use are full speed anyhow I don't remember last time I touched the jumpers 😄

    Back to the issue at hand, darn thing won't die now 😞 .. 4 string tests done and it's still working ok ?!?!? I just hope it's not one of those bugs one cannot reproduce with debug build, I hate those with all my heart



  • Amen, amen and amen. (I think mine has a dip switch, but yeah, long since forgotten what it does:)



  • @bearer 😄 switch between "low speed and full speed", mine is marked L and F (low is 1.5MHz, full is 12MHz and high is 480MHz). I don't have any high speed isolators but I don't have many 3rd party self powered boards using 480MHz so no worries there :D. Duet works on "full speed" (12MHz) settings. Ideally these isolators should detect and auto configure but those are rather expensive, so these with manual selection are more than enough for me :)... I'm waiting for my nest big order from digkey/mouser to add some adum's there as few months ago I decided I'll actually add isolation on all the usb devices I design myself

    Back to the topic, darn thing still works !!! Died 3 times yesterday inside an hour, and 3 or 4 times today inside 2 hours and now, since I posted to forum and setup debug works like a clock ...


Log in to reply