DWC not available while running mesh probe routine
-
Title says it all. I feel like I've seen this in other threads.
Duet 2 Eth, rrf 3. I will post exact versions when it starts responding again.
-
Long running Gcode commands will cause DWC to not issue any further gcode commands.
It should update things like coordinates and temperatures.
What releases?
-
@Danal no, no. It's D E A D... dead. I was able to telnet and ftp in.
While telnet'd in the HTTP server showed as enabled, but port 80 was "connection refused". So I disabled and re-enabled the HTTP server and it came back.
Here are the diagnostic messages while it was dead. These were retrieved via telnet.
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.0 running on Duet Ethernet 1.02 or later + DueX5
Board ID: 08DGM-917DA-G4MS8-6J9DJ-3SD6M-KVSVA
Used output buffers: 2 of 24 (24 max)
=== RTOS ===
Static ram: 30516
Dynamic ram: 92740 of which 0 recycled
Exception stack ram used: 608
Never used ram: 7208
Tasks: NETWORK(ready,640) HEAT(blocked,1240) DUEX(suspended,160) MAIN(running,1048) IDLE(ready,156)
Owned mutexes:
=== Platform ===
Last reset 21:18:09 ago, cause: software
Last software reset at 2020-03-30 23:23, reason: User, spinning module GCodes, available RAM 7364 bytes (slot 1)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 4
Free file entries: 9
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 25.0ms, max retries 0
MCU temperature: min 35.7, current 38.5, max 43.8
Supply voltage: min 23.9, current 24.1, max 24.2, 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 0/1023
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max 0/1023
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max 0/1023
Driver 6: standstill, SG min/max 0/1023
Driver 7: standstill, SG min/max 0/1023
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-03-31 20:42:03
Cache data hit count 4294967295
Slowest loop: 117.48ms; fastest: 0.09ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 128, MaxWait: 45255360ms
Bed compensation in use: mesh, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 1765, completed moves: 1765, 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, chamberHeaters = -1 -1 -1 -1
Heater 0 is on, I-accum = 0.1
Heater 1 is on, I-accum = 0.7
=== GCodes ===
Segments left: 0
Stack records: 3 allocated, 0 in use
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
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 144.41ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(2)
HTTP sessions: 0 of 8
Interface state 5, link 100Mbps full duplex
-
@gnydick What DWC version?
Ian
-
@droftarts it's not the dwc. It's the http server that died. Trust me, I did the network diagnostics.
-
@gnydick said in DWC not available while running mesh probe routine:
Trust me,
You haven't been infallible in the past! Please just tell me what DWC version you use.
I did the network diagnostics.
If you could supply the network diagnostics, that might help either @dc42 or @chrishamm diagnose the issue. I can't replicate the issue, at least not with 3.01-RC5.
In your M122 response:
Error status: 4
Equates to 'Output buffer starvation'.
Ian
-
@droftarts I did. I described it in the post. I know nobody is perfect. But if I say I've diagnosed network connectivity, you can assume what I'm saying is as reliable as the person that invented networking. It's that much a part of what I do for a living.
Does
tcpdumphave any meaning to you? If so, you'll know where I'm coming from.
-
@gnydick said in DWC not available while running mesh probe routine:
it's not the dwc. It's the http server that died.
Is there a possibility that a given release of DWC might provoke the HTTP server into failing, and a different release might not?
-
@gnydick you still haven’t said which version of DWC you’re using. It’s a simple question, and may be useful information. It’s not reported in M122; only the firmware version is.
Ian
-
This ought be good..
-
You've got 3.0 installed. That release comes with DWC 2.0.4. Have you updated to 2.0.7?
-
if you run
M111it'll list he available debug options, pick the code for the webserver and runM111 Pn S1to enable debugging for the webserver and log the serial console leading up to the next event. although if you're planning on saying "it looks good trust me" then don't bother.
-
@droftarts it doesn't matter what version of dwc is installed. DWC runs entirely in your browser and makes steady queries of your duet for status updates.
The HTTP server runs in the hardware on the board. It is what responds to DWCs requests.
Since the HTTP server dies, the DWC just behaves as if there was a firewall blocking your traffic. The DWC won't even load because the printer is actively rejecting the TCP connection. It is still reachable via TELNET and FTP.
I'm trying to make it clear without being rude that you most likely don't understand the subject matter. I'm providing concise information that cannot be misinterpreted unless you don't understand it.
Please stop pressing this issue.
-
@Phaedrux I don't use the new interface, it's abysmal.
-
I issued "G29" via the TELNET interface and the HTTP immediately locked.
It generated a large list is points to be skipped, I'm guessing that payload was too big to be bundled into one message and POOF.
-
and you're still running 3.0?
-
@gnydick so you’re using DWC 1.22.6 with RRF 3.0. Since you have now explained what might have caused the crash, we now need your config.g and bed.g if used to see bed and machine limits, probe offset and M557 command it uses to generate probe points. This should show how many points were generated, spurious or not, that probably caused the error seen in M122, and possibly the web server crash. Or just say how many probe points you were trying to measure. Need this information to replicate the issue, so we can see why the web server crashed.
FYI you should run G29 S2 and/or M561 before G29, to clear any existing compensation, otherwise you’re doing a compensation on top of an existing compensation.
Ian
-
@droftarts said in DWC not available while running mesh probe routine:
using DWC 1.22.6 with RRF 3.0
is there really any point in debugging old code?
@droftarts said in DWC not available while running mesh probe routine:
so we can see why the web server crashed
tbh we don't actually know if the server crashed or is just busy
-
@bearer there was an error in the posted M122, and now he’s explained a bit more about what he was doing, I’m inclined to think that there may not be sufficient error trapping to stop G29 commands using too many probe points, particularly if there’s a lot of messages about skipped ones. So probably not related to DWC. I’d expect the G29 code to still be the same in current firmware versions, so worth following up/trying to replicate.
Ian
-
@droftarts said in DWC not available while running mesh probe routine:
I’d expect the G29 code to still be the same in current firmware versions, so worth following up/trying to replicate.
was thinking about the 3.0 part, have been more than one change to z-probe stuff since then afaik (admittedly pending a new duet 3 I haven't been paying close attention), but its pretty standard to be debugging the latest code in any case.
-
Correlated it was an overflow due to too big of a message. I fixed my config so it won't miss any points and it works perfectly now.
