rr_gcode flow control

[CliveB]

I am writing a javascript system to control bespoke probing and creation of print commands on the fly using the DWC interface.

This is all part of https://forum.duet3d.com/topic/15113/rotational-printer

I am running the Duet Maestro board and version 3.01 RC6 software
I can control the printer using rr_gcode and rr_status but I get long delays between command operation.

If I concatenate my commands together and send them as one, they perform perfectly.

I have tried two methods of control but using a javascript stack.

1. Send the command when the machine status is 'I'
   or
2. Send the command when there is enough space shown in the 'buff' response from the previous rr_gcode command.

I can concatenate commands but would need to know how much space I have for this, I have assumed that it is the 'buff' response.

I could write a macro file or gcode file and upload it using rr_upload - I have not looked at how this works yet ie can it take a memory image, is there a files size limit.

Any suggestions would be welcome

[dc42]

Method #2 is correct. However, to ensure good throughput, you must also pick up the replies using the rr_reply call, otherwise the system will run out of output buffers until the responses time out. Each command will generate a response.

The 'buff' response does indeed tell you how much buffer space is available.

You can also send multiple commands on a single line of GCode, subject to the line length limit of 160 characters.

HTH David

[CliveB]

Thanks for the prompt reply.
I will rework the code now.

[CliveB]

I am monitoring the returned 'buff' value and sending concatenated gcodes to the Duet board when there is space.
I am also following this up with a rr_reply message immediately on getting a response back from the original rr_gcode message.
I am sending the codes faster than they are consumed so that the 'buff' figure runs down until it hits my safety low level, all seems fine. However, how does the 'buff' figure then recover?
Is there anything I can send which will not consume the buffer space but report back on it's value?
There is nothing in rr_status, rr_gcode or rr_reply that I can see will do the trick.

Software now v3.01 RC10 DWC 2.1.5

Thanks.

[CliveB]

Following on the experiments, I did some timings (mS).
I have two HTTP streams, one a heartbeat every 300mS (The main Loop) and the other reserved for the main commands.

0: Sent to machine gcode=G0%20X150%20G0%20X300
1: Sent to machine gcode=G0%20X150%20G0%20X5
25: Answer OK = {"buff":241}
25: Request machine response
26: Answer OK = {"buff":239}
27: Request machine response
48: Answer response OK =
58: Answer response OK =
149: main Loop status=B (asynchronous to 0 point )
17859: main Loop status=I

As far as I can see, the machine does not go idle until the whole command line is processed and, in this case, all moves are completed.

In reality, I will not be sending the second set of gcodes until the answer back from the first.

So after sending the commands and the buffer being reduced, the only change I can detect is the status code 17 seconds after the first transmission.

Am I missing something?

[Danal]

It is a pretty strong diversion from your current path... but... I believe the Maestro has a serial interface that accepts G-Code. Certainly the Duet2 and up have it, to support the PanelDue.

Have you considered interfacing there? It is 3.3V TTL serial, and there are a lot of threads about the request/response pattern.

And/or the USB port.

If network control is essential, an ESP32 for the serial, or a Pi for the USB, could be an "interface".

Again, pretty far off of your path, but these should all be very stable, flow controlled, ways of getting to the printer.

[CliveB]

@Danal Thanks for the ideas.
For the previous prototype, I used Marlin and the 8bit 1.4 Board and I took the suggestion to move to the Maestro board and had to do quite a bit to reconfigure everything (I don't regret the decision). I considered then offloading the calculations to an Arduino communicating over the serial ports.
When taking on the Maestro and finding it had a web interface over a network it seemed a good idea to me (I had used the ESP8266 to create other web based applications) and have invested a lot of time in this new interface.
I seem so close to a good working solution that I am pretty loathe to take another rework step.
It does work using a combination of the returned "buff" value and using the status flag, but is not as good as hoped.
I am sure that there must be a gcode that I can fire at the Maestro to return the buffer figure without consuming even more of it or that the rr_reply or rr_status could provide the figure as it appears to be essential for the efficient working of an external pre-processor.
Once again, thanks for your thoughts.

[Danal]

@CliveB said in rr_gcode flow control:

I seem so close to a good working solution that I am pretty loathe to take another rework step.

Perfectly understood, and it does sound like you are very close.

Keep us posted!