The com break will work with your own driver as error status is returned from the driver via the I/O Server to the Citect client. When you write a driver you should make sure you always set the ErrDriver to the correct status of the read from the physical device. This error code will be passed back up to Citect to become the com break.

Citect will read blocks of data from the I/O Device so the error status and so the com break will be associated with the entire block of data. For example if the I/O Server requests the driver to read digital addressees 1 to 2000 in one read and digital 1000 is bad the driver would set the error status. This will mark the entire 2000 digitals as bad and all the digitals will be displayed in com break. This is not normally a problem as with PLCs the only time some of the data would be bad is if you read off the end of the memory range. This would be a user configuration error and so the user must fix this problem.

You may however get a mix of good and bad data in the one request if the driver is communication to some types of DCS systems. These DCS have a status associated with each data point, so if you combine the status in your driver you will lose this detail. You may retain this information by forcing Citect not to block optimise the requests to the driver. This way the driver will get individual requests for each data point and the unique error status can be maintained. This is not recommended as you lose the massive performance improvement of Citect optimisations. You may however use this solution while commissioning a plant to find any bad data points and then re-enable the blocking to give the required performance.