Error Checking

Error statistics should be examined, and errors recovered from, if possible.

Communication failures 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 may after repeated attempts. If it does not, 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 acknowledgment 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. In Ethernet communications, an acknowledgment (ACK) or a negative acknowledgment (NACK) packet may be sent to indicate whether 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 VTScada 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 collect 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.