Posts made by chrishamm

@T3P3Tony Perhaps it was the GET request, not the POST request? I'm not sure.

@rero What DSF version are you using?

@T3P3Tony Here: https://github.com/Duet3D/RepRapFirmware/blob/3.6-dev/Developer-documentation/OpenAPI.yaml#L174 and here: https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests#post-rr_upload

@cnc65 @T3P3Tony is right. name specifies the target filename (e.g. /gcodes/foobar.gcode) and the body must contain the file content. I don't know why the generated API does not provide an extra parameter for the file content, though - it's there in the OpenAPI definition.

@taydin Please share your configtool.json file

@timschneider Do you have any more details about this bug, i.e. what G-code triggered it? Can you easily reproduce it?

@davidjryan I just implemented a change in DSF to avoid that re-racking problem.

@rero Your custom data needs to be registered using the data property and since you seem to be able to see it using the DWC OM browser, that should be alright. How are you trying to read your custom data keys?

@MaxGyver @droftarts Looks like Chromium-based browsers don't like plain http links, I replaced them again with https and that appears to fix it.

@stuartofmt It is NOT possible - or at least not safe/recommended - to use the same compiled JS chunk for multiple DWC versions. But you can target DSF 3.x.x by specifying only "sbcDsfVersion": "3".

@timschneider Did you have a look at our latest firmware improvements? The culprit was the fact that buffer->cat(reply); could use up all available remaining buffers which has been changed. Hence I'm no fan of your extra check there. Even if it "overflows" in the latest build, there will be enough spare output buffers available to send out the G-code reply with an HTTP header to waiting clients, which was not the case before.

@davidjryan In order to use M997 S2, you must be on the latest Bookworm-based SBC image and the DuetPiManagementPluigin must be loaded. If the latter is the case, that suggests your SBC image is outdated. In that case, I'd propose to flash it again and check if the problem persists.

@davidjryan Please try again with the new beta 4.

@stuartofmt I've got a fix ready for the upcoming v3.6.0-beta.4. In SBC mode, sometimes DWC wasn't informed about updates of state.messageBox.choices. That could only happen when state.messageBox wasn't changed to null before another message box with choices was opened. I guess if you add a delay of 250ms or more between the M291 calls, the problem doesn't show up.

@stuartofmt Thanks for reporting this, I could reproduce it. I'm going to fix this before we release 3.6.0-beta.4.

@davidjryan The required fix will be in DSF 3.6.0-beta.4 which we're still testing internally. Upgrading only RRF will not fix the issue.

@timschneider Thanks, I've logged this one at https://github.com/Duet3D/WiFiSocketServerRTOS/issues/50

chrishamm created this issue in Duet3D/WiFiSocketServerRTOS

open [Bug]: Duet2 WIFI SPI timeout #50

@darylprice That's quite odd. In order to replicate this issue I got an original BLTouch and that one works well with the PWM values generated by the configtool.

@timschneider said in [3.6.0-beta.3] DWC connection issues Duet2 / Duex5:

It is maybe worth to consider if RRF is low on OutputBuffers not to concat the gcode replys of multiple requests but instead drop the previos reply.

That's what happens. For the same reason the last M122 output is likely truncated if you send multiple M122s at once.

@timschneider said in [3.6.0-beta.3] DWC connection issues Duet2 / Duex5:

I stumbled over the MinimumBuffersForObjectModel and the rr_model request is checking if there are free buffers available, but what will happen the other way around? Like, query a rr_model and then from another socket a rr_gcode with large response in rr_reply?

rr_model waits half a second if it cannot allocate enough memory for the response and if it fails, HTTP 503 is returned. In that case a client should request the reply to free up the buffers again ASAP. I still think it would be good to add a new parameter to rr_connect to make RRF discard G-code replies for particular clients.

@timschneider Please give it a try then. Do you need a firmware binary for testing?