Pico Serial Transmit buffer fills up during hold mode

[jattie-ire]

I have read all I could find on GRBL senders and I am no wiser and need help please.

I am running GRBLHal 3Axis on a RPI Pico 2040 controller build with the Web builder and controlling a two axis sandtable. I have created a playlist sender using python and once a pattern was completed and my controller status is idle I send the hold command to the controller and wait for the hardware cycle start/resume button to be pushed to play the next gcode file.

When the controller status changes from hold to idle I can see the sate change and exit my wait loop and this works well if I do not wait too long because eventually the buffer seems to fill up with "ok" that seems to be blocked from being read when in hold. As soon as I come out of hold I get all the ok's responses at one and all is fine as long as I do this in time before the buffer fills up. It still kind of works to come out of hold using the hardware buttons, but I lose all comms to the pico device over usb when the buffer fills up.

In run mode when I send a check command using ? I get this:

['<Run|MPos:205.575,54.588,0.000|Bf:24,1023|F:1414>', 'ok']

In hold mode I do get info back, but only the status, no "ok"

['<Hold:0|MPos:175.587,46.162,0.000|Bf:30,1017|F:0>'
['<Hold:0|MPos:175.587,46.162,0.000|Bf:30,1016|F:0|WCO:0.000,0.000,0.000>']
['<Hold:0|MPos:175.587,46.162,0.000|Bf:30,1015|F:0|Ov:100,100,100>']
['<Hold:0|MPos:175.587,46.162,0.000|Bf:30,1014|F:0>']

And as you can see the second buffer value decreases from 1017 to 1014, by one every cycle until the buffer gets to 0 and all communications breaks down.

Is this behaviour by design or is it a bug? If by design how can I work around this then? I can clear the buffer sending stop, but that also clears hold.

Please point me in the right direction.

Thanks

[terjeio]

My guess it is a bug - you are sending end of line character(s) (CR, LF or CRLF) following the ? when querying the status. This fills up the input buffer until the hold is exited and then you get a 'ok' message for each of them. So only send the ?, nothing else.

[jattie-ire]

Okay will try that.

[jattie-ire]

@terjeio, I can confirm that your proposal solved my problem. I can now get status updates without ok messages filling up the buffer when in hold mode. Thanks for your guidance and support.

I have implemented this note for all real time messages.