Can't stop printer / can't get updates when printer is busy

[bobc]

This is a problem with the way the GCode standard is misused as a comms protocol. When the printer queue is full, the host won't send further commands until the one that is blocking the queue is completed.

Please see "documents/improved_printer_protocol.odt" for a discussion of the problem and a simple solution. By adding a "Busy" status to the protocol, the host can send commands even when the print queue is full. The printer will process the command if it can, otherwise it returns "Busy", and the host must retry later. In the meantime the host can send any other commands instead, such as Stop or Get Temperature etc.

[casainho]

This is something we must work on.

Maybe we can do something like on USB, using commands that always get priority and answers, like on control end-points.

[bobc]

So this is the dual-band requirement. The problem is that if the host has not received an OK, it will not send another command. If it does send a command and later gets a response, how does it know which command that was a response for?

We would need to have separate data channels, or at least mark "out of band" data (OOB). A simple way to do this within the framework of an ASCII protocol, is to prefix commands and responses. So for example, OOB commands and responses could be prefixed with some escape character like "!".

The host would need to keep track of two asynchronous connection streams. It is harder to manage in the host and firmware, as it breaks the strict command-response sequence, and we have to deal with asynchronous commands/responses. It might be more efficient in terms of throughput over the link. We would need to reject buffered commands that appear on the "immediate" command channel. I will have to think about if there are any other subtle issues.

[casainho]

Bob, maybe we can help/implement on software side, but would be on a specific branch. We are available to help on software side.