Error checking is an important part of the programming process, as are the testing and debugging processes. There are many possible error situations that must be considered. Error statistics should be examined, and errors recovered from, if possible.
Communication failures are an important issue. They may occur as a result of human error (such as an unplugged cable) or hardware error (such as a power failure or noise in the communication channel). A communication link may not occur on the first attempt, but if the problem is something like distortion in the channel, perhaps after a few retries, a connection may be established. On the other hand, if the problem is a disconnected cable, no number retries will fix the problem. In cases like this, the error should be reported so that the operator can fix it.
When reliable communications are being used, it will be necessary to wait for some type of acknowledgement from the receiver to ensure the message sent was received. In RS-232 serial communications, an echo of data that was received may be sent back, or in Ethernet communications, an acknowledgement (ACK) or a negative acknowledgement (NACK) packet may be sent to indicate whether or not the packet was received. Similarly, when receiving a packet, it may be necessary to let the transmitter know a message has been received.
The protocol for the packet may use built-in error checking, such as a checksum. If this is the case, the validity of the message can be verified upon receipt, and the message discarded if an error occurred on the communication channel distorting the data.
Another potential issue exists if the driver uses a serial port. The mechanism that VTS uses to add and delete read/write commands is such that a read or write that is in progress could be removed from the queue in the middle of processing. This means that it is possible that a read or write command could send its data, but then be removed from the communications loop before the response is received. The next read or write command would then pick up the data if the serial buffer was not emptied. Therefore, it is a good idea to flush the input buffer before any data is sent.