Originally shared by Mathias Dietz What is the right behaviour from a reprap host

Originally shared by Mathias Dietz

What is the right behaviour from a reprap host software perspective in regards to timeouts ?
Some background:
When sending gcodes to a reprap printer (Marlin, Sprinter,…) its not easy to decide how long the printer response can take and if a slow response is a problem or not.
I think in general, one must differ between buffered and unbuffered gcodes.
Unbuffered gcodes are straight forward because they have a mostly deterministic response time (e.g. M104 takes long but does send intermediate responses).
But the buffered gcodes caused me some headache.
A simple G28 command can take many seconds and even (long distance) G1 commands can take multiple seconds.
So, why not just wait longer for long distance G1 moves ? Because the printer buffers a particular number of gcodes which makes it hard to predict what the response time will be.
When you send a buffered gcode to the printer, the response just means “yes I have put it into the buffer”, but if the buffer is full the response will wait until the gcode on buffer position #1 has been executed. This means even if the move is very small, the response time might be high because the printer must wait for completion of gcode on buffer position 1 to free up space in the buffer for the next command.
Example (see picture)

In GCodeSimulator&Printer I tried to predict the response time by calculating the gcode time and the current buffer position, but there are too many unknowns.
I concluded that the host software cannot really predict the response time because it does not know the current buffer size and more importantly the current fill level of the buffer.

Octoprint seems to use a default communication timemout of 5 seconds and if the time exceeds it just sends some M105 codes and forces a “ok” response. This can cause duplicate oks when the printer finally answers. I think for this reason a swallow-OK feature has been implemented to swallow duplicate OKs. Sounds like a hack but seems to work.
Printrun has a very low serial timeout of 0.25 seconds but to be honest I don’t understand why/how this works.

Any idea how to do this correctly ?

7d0582d7d7f8de792a2aaddce2070949.png