DWC not available while running mesh probe routine

droftarts

@gnydick What DWC version?

Ian

gnydick

@droftarts it's not the dwc. It's the http server that died. Trust me, I did the network diagnostics.

droftarts

@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

gnydick

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

Doestcpdump have any meaning to you? If so, you'll know where I'm coming from.

Danal

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

droftarts

@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

A Former User

This ought be good..

Phaedrux

You've got 3.0 installed. That release comes with DWC 2.0.4. Have you updated to 2.0.7?

A Former User

if you run M111 it'll list he available debug options, pick the code for the webserver and run M111 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.

gnydick

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

gnydick

@Phaedrux I don't use the new interface, it's abysmal.

gnydick

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.

A Former User

and you're still running 3.0?

droftarts

@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

A Former User

@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

droftarts

@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

A Former User

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

gnydick

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.