web server dying

arhi

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

arhi

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.

A Former User

M111 for debug

arhi

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

arhi

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

A Former User

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

arhi

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

A Former User

@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

arhi

@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

A Former User

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

arhi

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