If an I/O device is no longer functioning and is responding with errors to Citect requests, Citect will still consider the I/O device as online if the non functioning I/O device never reply with generic error 12. This may cause the redundancy to fail to operate correctly if the protocol driver does not recognise a particular error as fatal. If you find a fatal error which does not cause a redundancy changeover check to make sure you have the latest driver or check with Citect support or the driver developer.

For most protocols the I/O device will be put offline if it gets a certain number of consecutive timeout errors. The number of consecutive timeouts depends on the number of retry allowed. It is recommended to protocol driver writers that the I/O device must be put offline if the number of consecutive timeouts exceeds (retry + 1) * (retry + 1). The following protocols follows this rule:

ABTCP, IZUMI, BAILEY, TISERIAL, OPTOMUX, MELSEC, MODBUS, OMRON, TICIM, TIDIRECT, RELIANCE, GENIUS, SIEMENS, TXMITTON, TRIODIAG, TOSHIBA, MENTOR, TOSDIC, OMFINS, HITACHI, HR2400, KE, FUJI, SBUS, CCM and COMLI.

For some protocols the I/O unit will be put offline if it gets a specific driver error. By trial and error each protocol must be coded to recognise these special driver error codes. The following protocols recognise special driver error codes that will put the I/O unit offline. This list is not complete and will be updated as they are reported by users.

For some protocols the driver error will be considered to be so serious that the channel that the I/O unit is attached must be put offline to allow Citect to re initialise the whole channel. The following protocols recognise special driver error codes that will put the channel that the I/O unit is attached to offline. This list is not complete and will be update as they are reported by users.