What exactly do you mean by having "dwc off"? In all of these tests you need to have your rPi running and connected. If you did not that would explain why G28 was not do anything when you typed it from putty. You can't use the SBC version of RRF without having the rPi/DSF connected.

It is getting pretty late here, so I've got to go.

You should probably set the option in the putty terminal settings:
Implicit CR in every LF
makes the output easier to read.

I'd still like to see the directory listing of your /opt/dsf/sd/sys directory.

Please reboot your LPC board. Make sure that DWC is connected and then connect using putty over USB (keep the rPi on and DWC running) then enter:
M111 P3 S1
M111 P16 S1
G28
M122
and post the output.

From DC42's post in the 3.2 announcement. If you using the unstable feed (which it looks like you are) you need to use...

sudo apt-get upgrade duetsoftwareframework=3.2.0 duetcontrolserver=3.2.0 duetwebserver=3.2.0 duettools=3.2.0 duetruntime=3.2.0 duetsd=1.1.0 duetwebcontrol=3.2.0 reprapfirmware=3.2.0-1

@wilriker I look after the LPC port and have a couple of questions if you can spare some time...

1. Is the panelDue causing any extra json requests to be sent to DSF, or is it just likely that having both the panelDue and DSF making requests is putting extra strain on the available buffer space?
2. What are the assumptions made about available output buffers (if any)?
3. It seems odd that a partial response is being sent to DSF. Is that what you would expect if the system runs out of output buffers? I would have thought that it would make more sense to assemble all of a json response before sending it?

The LPC port uses the same mechanism for handling a lack of buffers as does the Duet ports, so it seems likely that if the LPC has problems then in other circumstances (under heavy load or whatever) the Duet versions will hit the same problem. We do have a smaller number of buffers defined (16), but that is the same as number used by some other Duet hardware (that using SAM3XA mcus), but perhaps those Duets will never be used with an SBC?

I assume you are uploading via DWC? If so then this is what happens:

• During upload the new file data is written to a temporary file
• At the end of the upload the CRC is checked
• If there is no error any existing file with the same name is deleted and the newly uploaded file is renamed to the correct name
• If there was an error then the temporary file is deleted (and any previously exiting version is left unchanged).

You can see the code that does most of this here: https://github.com/Duet3D/RepRapFirmware/blob/v3.02-dev/src/Networking/UploadingNetworkResponder.cpp#L79

So it doesn't look to me like there is any way that a file with a detected CRC error caused your problem. Having said that CRC checks are not totally foolproof. Also the CRC check is only performed on the data before it is to be written to the file, it does not read the data back from the SD card, so if there is problem with the SD card the CRC check will not detect that.

I'm a little confused. Isn't firmware retract only triggered by G10/G11 as generated by the slicer? It may be worth posting an example of the gcode that causes the problem you are seeing and a description/video of what happens.

@deckingman The lower limit for Z is defined as -1 in your config.g file. According to https://duet3d.dozuki.com/Wiki/Gcode#Section_G0_G1_Move G1 H1 will set the position to the axis limit. So perhaps that is the cause of your -1 position? I'm surprised that has changed since 3.1.1 though.

I suspect the problem you are seeing is related to the issue reported here: https://forum.duet3d.com/topic/19074/bed-levelling-traming-odd-message-3-2-beta-2

I think it is a general beta2 issue and not specifically toolboard related (though having a toolboard may impact the timing and cause it to happen more often).

If you get the chance you may want to re-run the test with gcode and SBC debug enabled (using m111 p3 s1 and m111 p16 s1). This may provide a little more information as to what is going on.

Oh I'm not arguing after all I didn't use it either, but having said that the direct gpio connection didn't work particularly well for me either! The same pi with a (not particularly good USB) power supply runs without any voltage warnings, I'm not really sure why, dodgy buck converter, dodgy gpio connector, or dodgy wiring (well relatively thin ribbon cable wiring), take your pick!

Recent versions of Prusa Slicer (I'm using version 2.2.0) insert the estimated print time in the form of a comment that looks like this:

; estimated printing time (normal mode) = 38m 31s

dsf 2.1.0 contains the following regular expression:

"estimated printing time = ((?<h>(\d+))h\s*)?((?<m>(\d+))m\s*)?((?<s>(\d+))s)?"

but this does not work with recent versions of PS (because of the extra "(normal mode)", not inserted in earlier versions). A modified version that does match (and that should still match older strings) is:

"estimated printing time .*= ((?<h>(\d+))h\s*)?((?<m>(\d+))m\s*)?((?<s>(\d+))s)?"

Note the additional ".*" just before "="

In addition it is common for the start up gcode used with this version of PS to contain the following line:

M221 S{if layer_height<0.075}100{else}95{endif}

This line gets included in the gcode file (as a comment) by PS, but it causes a false match against the DSF layer height matching regular expression:

"\slayer_height\D+(?<mm>(\d+\.?\d*))"

and results in the layer height being shown as 0.07mm rather than the correct 0.20mm. The following modified version seems to avoid the false positive and returns the correct layer height:

";\slayer_height\D+(?<mm>(\d+\.?\d*))"

Note the extra ";" at the start of the string.

I've tested the above modified expressions with a number of versions of PS (going back a year or so) and it seems to match values correctly in generated files.

The firmware is only configured for 3 heaters (since there is typically only 3 suitable MOSFETS on LPC based boards and we are pretty tight for memory). I assume you are using H1 somewhere else in your config?

What is it you are building that needs 3 beds?

In some situations the firmware will keep the connection open if the client requests it. In particular when sending Json responses it does this. I'm not sure if DWC makes use of this feature but I suspect it may for some of the more frequent operations. (for more details see: https://github.com/Duet3D/RepRapFirmware/blob/dev/src/Networking/HttpResponder.cpp#L448).

It is worth remembering that this is not "most servers" in the stand alone case the server is running on a small mcu with (in the case of the LPC) only 64Kb of RAM. So it's not just a case of turning an option on, changes will be needed in the code (see above) and as you can see from some of the existing comments juggling with memory buffers is already fairly complex.

As I mentioned previously in the case of the LPC we can only support 2 sockets open at once. So keeping both of those open for a second (just in case) will mean that if any other client attempts to open a connection it may be refused, or at best will have to wait for that one second to timeout. In the worst case (if the client keeps sending requests) the socket may never get closed and so other clients will be unable to connect. Things are a little better on the Duets, but they only have a relatively small number of available sockets.

I'm not saying don't do it (though I think the consequences need to be worked through), I'm just asking that this is not made a requirement (either explicitly or through a particular level of performance being required). Because I suspect that doing so will move the LPC port into being unusable, which will probably mean that someone will fork DWC (with a consequent reduction in testing of the Duet version which I think does have some value for Duet users).

In the case of the SBC version of course things are very different as that does not have to deal with the same limitations.

I realise this may not be important to the majority, but I just wanted to raise the issue (and you did ask for comments).

I assume that using keepalive would mean that the http connections to the server would have a longer lifetime. One potential problem with this may be that RRF can only support a relatively small number of connections (and that some versions like our LPC port the number is lower still). Increasing the lifetime of these connections may make it more difficult to support additional clients.

At the moment due to the short life of a connection it is possible for several clients to share the small pool of connections (with perhaps some delay) even though over some period of time there may be more total connections than there are available server sockets. However if the lifetime of those connections is longer this sharing may no longer be possible.

I would ask that if this feature is introduced that the server should be able to refuse to allow it (hopefully in a way that does not cause problems for the client side) and that client code should not depend upon it.

Looks like your heater may be introducing noise into the Duet/SBC connection. Obvious things are to check how the various cables are routed. How long is the cable between the rPi and the Duet? Perhaps some photos of how you have things set up?

Can you check your rPi syslog file (/var/log/syslog) and look for warnings/errors from duet control server. if there are any do they match up with when you had the lost connections?

Actually on TMC2209 they have changed the range as well... it runs 0..255 with 255 being most sensitive.

@Alucardi I realize this sounds like madness, but can you try setting the stall detection threshold to +63 (so S63 on the M915 for both motors) and see if it detects the stall then.

Do you have any other Duet3D boards connected to the same WiFi network?

Enabling WiFi debug using M111 may provide a little more information as to what is going on.

Did you also update DWC to the latest version?

Also see https://forum.duet3d.com/topic/19967/3-2-beta-3-2-unexpected-token-in-json-at-position-0?_=1610891955515

For some possible next steps.

Do you have the www folder (and the correct DWC files in it) on the SD card? That error looks more like a problem with opening the requested page rather than a network/router error.

What version of PrussaSlicer?
Do you have the same problem when using DWC 3.2?