@dc42 Thanks

I have updated the firmware to 3.1.1

I am using rr_status to get the status object and will have to read the head temp (which I already have) and compare it with the requested temperature.
I accept that the machine will not execute commands until the temperature is reached but I don't want to send any commands to the machine via a web interface until the head is up to temperature.

I am running Duet Maestro with 3.01 RC12 firmware

I am monitoring the machine response object for the (I)dle situation.
Am I correct in believing that whilst the machine is waiting for the temperature to get to the set point the machine is still stating that it is (I)dle?
ie once M109 S260 is sent I still get (I)dle before that temperature is met
I know that I can monitor the current temperature and check against the requested temperature, but was checking to see if there was a status that told me that the machine was not up to temperature.

Thanks
Clive

@dc42 Thank you, fully understood and will solve the problem.

@chrishamm Thank you for the response, it will make life a lot easier

At present the only way to find out if there is space in the gcode buffer to send another command is by sending a rr_gcode command.

	NetworkGCodeInput * const httpInput = reprap.GetGCodes().GetHTTPInput();
	httpInput->Put(HttpMessage, GetKeyValue("gcode"));
	response->printf("{\"buff\":%u}", httpInput->BufferSpaceLeft());

would it be possible to add the "buff" value into an existing rr_status or to create another one?

Would the buffer just be read and not otherwise be affected by
NetworkGCodeInput * const httpInput = reprap.GetGCodes().GetHTTPInput();
response->printf("{"buff":%u}", httpInput->BufferSpaceLeft());

I do not wish to move away from a standard build otherwise I would have a go at implementing the idea.

Thanks

@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.

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?

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.

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

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