TinyG Planner buffer

This page may be helpful, particularly the part on flow control. I don’t have time for a full answer right now – read this then I have some other ideas that might help.

https://github.com/synthetos/TinyG/wiki/Tinyg-Communications-Programming

Working on my more complete answer. I have gone back and revised these 2 pages – which you have certainly already seen, but for the benefit of this thread are:

https://github.com/synthetos/TinyG/wiki/Tinyg-Communications-Programming
https://github.com/synthetos/TinyG/wiki/Flow-Control-and-Footers

I think you might want to implement some form of queue-report based flow control. In particular, triple queue reports may help. See here:
https://github.com/synthetos/TinyG/wiki/Flow-Control-and-Footers#wiki-triple-queue-reports

Set {“qv”:2}

I’d recommend reading the header comments (and code) in report.c for behavior. In essence, if you can keep the planner queue at about 20 buffers (plus or minus) then you will have at least 100 milliseconds to react to queue depth changes, and in most cases way more. You want to monitor the qr variable for absolute queue depth (it’s backwards, so keeping the queue at 20 is really 28-20 = 8). You also want to look at the qo (queue out) and qi (queue in) variables. Once the queue is at your preferred depth these tell you how many more blocks you should send. Roughly speaking it’s qo-qi. So 4 out and 1 in means you should send 3 new blocks. Please experiment with this, though, as you may find ways to fine fine tune this behavior.

Lastly, one of our users is using UI interpreted XON/XOFF as a “last resort”. They do not enable XON on the host, but do enable it on TinyG. This means the XON/XOFF characters make it through the OS to their application. If they receive an XOFF they cease transmission then wait until receiving and XON (or perhaps until the planner queue calms down – I’m not sure which) before resuming transmission.

It is possible to increase the planner queue size but I’d rather leave it where it is for memory reasons. However you are welcome to set to whatever size you need. But 100+ mS should be enough for a UI to react, I’d think (and that’s worse case).

If you want to change the values look in planner.h, here:
/* PLANNER_BUFFER_POOL_SIZE
* Should be at least the number of buffers requires to support optimal
* planning in the case of very short lines or arc segments.
* Suggest 12 min. Limit is 255
*/
#define PLANNER_BUFFER_POOL_SIZE 28
#define PLANNER_BUFFER_HEADROOM 4 // buffers to reserve in planner before processing new input line

Oh, and even though the limit is 255 (due to indexing, the practical limit is when you run out of RAM and that’s way less than that (I don’t know the exact number but each queue slot takes about 200 bytes)

• This reply was modified 10 years, 9 months ago by alden.

Arcs are a special case, and you are right – they flood the planner. Arcs are actually run as a “cycle”. The arc planner generates many short line segments and sends them to the planner. No new commands are accepted until the arc is complete, which may have thousands of lines.

One possibility if you did not want to fill the planner buffer would be to set the XOFF_RX_HI_WATER_MARK to something lower than 80% full. The RX buffer is 254 bytes, so each 10% is worth 25 bytes. I don’t know if this helps.

Another way to do this w/o XON/XOFF would be to detect the arc motion mode by installing “momo” in a filtered status report. In an arc this will set to either MOTION_MODE_CW_ARC or MOTION_MODE_CCW_ARC. You can use this – along with queue reports – to stop transmission until you see the motion mode move to something else. You can install qr, qo and qi variables in the status report as well, so you =don;t need to enable or parse queue reports, picking these variables up from the status report instead.