HTTP API for Standalone Duet 3 Mini and Duet 2

poofjunior

Hi folks,

I wrote a python driver to interact with a Duet 3 in SBC mode. Most of the interface is wrapped around sending data to POST /machine/code like this:

# cmd is some GCode in string format.
response = requests.get(f"http://{self.address}/machine/code", data=f"{cmd}", timeout=timeout).text

Source code link

This works on a Duet3 with an attached SBC. You can interact with the machine in Python on the Pi itself like this, or through an external PC running python and connected in a closed network connection like this.

I'm currently checking that it works on a Duet3 Mini in Standalone mode (no Pi), and it does not.

My questions are...
Does the /machine/code http endpoint only exist in SBC mode?
If yes, are there other endpoints through which I can send Gcode in such a way that invokes the motion planner (smooth transitions between moves)?

My high level plan is to adapt my code to offer the Duet 2 and Duet3 Mini as cheaper routes for folks building up Jubilee for non-3d-printing applications (think: ad-hoc lab automation.) If folks need to buy an SBC for this endpoint to make use of the existing code, that's honestly not so bad. If there are other standalone options from which I can stream GCode in a way that invokes the motion planner though, I'm all ears too!

Cheers!

dc42

@poofjunior said in HTTP API for Standalone Duet 3 Mini and Duet 2:

My questions are...
Does the /machine/code http endpoint only exist in SBC mode?

Yes.

If yes, are there other endpoints through which I can send Gcode in such a way that invokes the motion planner (smooth transitions between moves)?

Yes, use the http APi documented at https://github.com/Duet3D/DuetWebControl/blob/legacy/README.md. An extra API call rr_model is available that is not described in that document. It performs similar functions to M409.

We don't recommend streaming GCodes over HTTP unless the stream is short. Better to upload the GCodes to a file on the SD card and then run them from there.

poofjunior

@dc42 Thanks for the heads up. And, aye, the plan is only a few snippets rather than long moves.

I actually did try the format you mention above for sending gcode, and I seemed to get inconsistent behavior from what gets returned via DSF.

Namely,
(1) for commands where I'm extracting data (M409), I need to follow up with rr_reply to actually collect it. Versus with DSF, it's part of the response when posting to /machine/code.
And (2) after sending a small sequence followed by "M400," I couldn't find a way to tell my code to wait until the machine was actually done. Versus, with DSF, sending M400 causes the http response to hang until the moves have actually finished.

For all the quirks I've noticed, I may opt for putting Pis on all the machines I want to do non-printing things with and call it good.

dc42

@poofjunior said in HTTP API for Standalone Duet 3 Mini and Duet 2:

(1) for commands where I'm extracting data (M409), I need to follow up with rr_reply to actually collect it. Versus with DSF, it's part of the response when posting to /machine/code.

Use rr_model in preference to M409, than you will get the reply as part of the response

And (2) after sending a small sequence followed by "M400," I couldn't find a way to tell my code to wait until the machine was actually done. Versus, with DSF, sending M400 causes the http response to hang until the moves have actually finished.

You can use rr_model to query state.status and watch for it to change from Busy to Idle.