rr_reply and http interfaces

[sergio]

I've been struggling a little bit to fully integrate the duet and replace some of our extra hardware to move all our external functionality to the Duet.

This topic is related to this:
https://forum.duet3d.com/topic/5317/api-duet-responses-to-gcode-sent

My main issue is with the transactional mechanism of the webserver to reply to a GCODE command.

I am currently running our server & automatisms in parallel with the DUET web UI. An operator will have the DUET web UI open and maybe someone in a tablet too monitoring some temperature or something simultaneously.

Every command I issue from my system has a chance of getting their reply hijacked by one of the external UIs at /rr_reply, therefore I have to query, check if there is a response, query again after 0.5s if I don't see any response... That doesn't seem very reliable in the long term.

Given the nature of the system, I think a simple queue of transactions that you can query with an ID would solve the issue and make the system more robust in the long term.

A bit more advanced, I would send a GCODE command request and I would get a timestamp from the webserver that I can use to query back to see if there is a response for me. That response queue could just be stored in a simple FIFO, only a few lines long. I guess that would force the pipeline to carry the transaction ID, kind of like a regular execution payload in a kernel and without looking deep into the architecture I cannot evaluate the amount of work required.

I haven't been looking into the code yet to build a PR, only a little bit into the webserver to see how it would fit. Is this something that would be accepted?

Best,
Sergio
https://github.com/sergioamr/

[dc42]

This issue should only occur when you have multiple sessions for the same IP address to the Duet. The Duet tracks sessions from different IP addresses, but it doesn't expect you to use more than one session from the same IP address. So your tablet computer should not interfere with your automation system, but an instance of Duet Web Control running on the same computer as the automation system will.

What commands and responses does your automation system use? If it's just fetching status information, you may be able to use rr_status or rr_model instead of rr_gcode and rr_reply.

@chrishamm may have something to add to this.

[sergio]

The UI has the same IP as the machine running the commands since it has a large touch screen with our HMI and the Webcontrol, that is why i didn't realize about the IP sessions, I normally VNC into that machine for testing too.

I guess I can have a second network interface on the machine and use that to query for the reply, not ideal but it would work.

In terms of commands and automatism. I do a full calibration after each print, so I run G32 and G29 after a platform change and I check that the calibration is in range after it finished calibrating. Sometimes if a platform failed to load, the calibration results are way out of range, so I have to query for the height of the printer and other parameters that came from the calibration to check if they are in range.

But I also want to run the rest of the system, I have PLCs and several systems with a Marlin which run commands, like moving the platforms around, turning conveyor belts, setting chamber temperature, lights on, sensors, turn on air filters, etc.

In the Marlin hardware, I read directly pins and set pins up so I can move something until it hits an endstop. I modified the marlin to get the number of steps that took to hit that endstop so I can do things like calculating the amount of displacement and get extra information for our calculations.

I also normally poll for endstops, to check their state. If an operator opens a door, I want to pause that part of the machine and not only pause the duet. As you see, I kind of use the marlin hardware as a general-purpose state machine/controller.

I guess I am trying to find a way of using the duet the same way. Since in Marlin, I just run the command through USB and wait until the end result I have full control of what is doing, and it works in parallel with the Duet as an industrial controller.

My doubt at the moment is if I can use the Duet to run things in parallel while it is printing, or maybe I will have to have a dedicated duet for the automatism and have a bus.

I guess my architecture is a bit complicated at the moment and I am trying to simplify it.

Any suggestions?

[dc42]

I'll discuss with @chrishamm the possibility of adding a session identifier to HTTP requests so that RRF can distinguish between different sessions from the same IP address. But it will have to wait until firmware 3.02 because 3.01 is close to release.

[chrishamm]

We may consider adding a new HTTP header that holds the session number for RRF 3.02 but I cannot estimate when that will be implemented.

[A Former User]

if its a feature for rrf3 only, wouldn't moving to the existing websockets remove the stateless nature of the normal http calls?

[chrishamm]

@bearer Not trivial because the W5500 of the Duet Maestro/Ethernet provides only 8 sockets.

[sergio]

@dc42

[sergio]

@chrishamm said in rr_reply and http interfaces:

We may consider adding a new HTTP header that holds the session number for RRF 3.02 but I cannot estimate when that will be implemented.

That would be very useful.