Flow Control

Flow Control is a way of throttling the rate at which data is received. Under normal conditions the input buffer of a device can hold enough characters to allow buffering while the system is too busy to process the data that's already in. But sometimes data comes in faster than the processor can handle at that time. Under such circumstances we may get a buffer overflow, data is lost, and communication fails.
Flow Control can help prevent buffer overflows by signalling the transmitter to pause the transmission, allowing the receiver to empty its buffer before continuing again.

The SB-Bus can work with two types of Flow Control. You can select the desired mode with the *FLOW system command.

XON / XOFF Flow Control

In communication jargon this is often called software flow control, because it is entirely handled by a software protocol. It is not an SB-Bus specific property, because all terminal emulation programs support it, which makes implementation of the protocol very simple.

When the receive buffer of a device threatens to overflow it will send a special Ctrl Character to the other communication partner, telling it to stop transmitting immediately. Transmission may only commence when the receiving party sends another special Ctrl Character.
Generally speaking the receiver sends the XOFF (transmit off) character to instruct the other side to stop transmitting. And it will send XON (transmit on) as soon as the input buffer can accept a reasonable amount of new characters again.

Ctrl	ASCII	Function
Ctrl-Q	$11	Flow Control XON character. This Character is usually used to resume transmission, when it was paused by an XOFF character. A Slave will always use the XON character to signal the Master that it can resume transmissions. On the other hand, the Slave can accept any character other than ESC to resume its transmissions. ESC will cancel all transmissions, even when they were paused. The resume character (XON or any other character) should be ignored as data.
Ctrl-S	$13	Flow Control XOFF character. This character can be used to pause the transmission from the other side, when the receiver can't keep up with the flow of data it receives. Both Master and Slave devices can send the XOFF character when their input buffer threatens to overflow. The other side is then supposed to pause the transmission until further notice. The device that sent the XOFF character should send a XON character (Ctrl-Q) as soon as its input buffer can accept new characters again.

Under normal circumstances it will not be necessary to pause transmissions because the input buffer of a Slave is usually large enough to hold an entire command. Flow Control is only needed when a Master keeps flooding the Slave with commands without waiting for the Slave's prompts, or during the transfer of large amounts of data.

A newly selected Slave is always in the XON state because its input buffer is always empty.

The XON/XOFF Flow Control is always active, even when the additional Acknowledge Flow Control is selected. By default Acknowledge Flow Control is disabled after a device reset.

Acknowledge Flow Control

Acknowledge Flow Control is an addition to the standard XON/XOFF Flow Control, and is only meant for the transfer of multiple lines of data. The general principle is to send an acknowledge character after receiving each line of data. No new lines are sent until the acknowledge is received. This ensures that the receiving party has received, accepted and processed the received line before the next one is sent.
After a device reset the Acknowledge Flow Control is disabled in which case the device will only use XON/XOFF Flow Control. You can switch the Acknowledge Flow Control on or off with the system command *FLOW.
Please note that the Acknowledge Flow Control is an SB-Bus specific property and thus will not be present in standard terminal emulation programs. So in order to use it you should write your own program to interface with the device.

Commands that return only one line of data don't use Acknowledge Flow Control. The Master can signal that because the data line is immediately followed by a Prompt (usually => or !> ).

Both the Master and the Slave can send multiple lines of data, and both should be able to use Acknowledge Flow Control. The receiving party should send an Acknowledge character after receiving a complete data line. Also the last data line must be followed by an acknowledge to allow the repetition of the last data line in case it was received with an error.
The Slave will send an OK Prompt as soon as all data is transferred.

Three different Acknowledge characters are used:

=	Acknowledge OK. This symbol, followed by a Carriage Return, signals that the receiver has accepted and processed the previous data line without errors. In case the receiver is unable to verify the integrity of the received data line, this symbol is always used as acknowledge character.
!	Acknowledge Execution Error. The receiver has in some way checked the integrity of the received data line and found errors in it. For instance the checksum of a line of HEX data was wrong, or the address field was out of range. Or perhaps the data line contained illegal characters. Any way the line was NOT accepted by the receiver and the sender should retry sending the same line again.
?	Acknowledge Syntax Error. The receiver was unable to recognize any usable data in the data line. Again the sender is requested to resend the last data line in the hope that it will be received correctly this time.

Of course it has no use to keep resending the same data line over and over again when the receiver keeps answering with one of the error characters. Therefore both parties may decide to cancel the data transfer by sending the ESC character.
I would recommend to cancel the transfer if the receiver responded up to 10 times with an error acknowledge on the same data line.
A Slave will respond to the canceled data transfer by sending a final Execution Error !> Prompt. An *ERROR? command can then be used to learn why the data lines were not accepted.