When you configure the limits for the Maximum Number of Consecutive Read Timeouts and the Maximum Number of Write Timeouts, there are many factors you need to take into consideration:
- The type of channel being used.
If your system uses network attached serial ports, it is possible that there may be transient faults on the network. To avoid intermittent network errors from causing excessive I/O Timeout alarms and unnecessary de-assignment and re-assignment of channels, you should allow for an appropriate amount of timeouts. The amount that is appropriate for your system will vary depending on other factors.
- The number of outstations on your channels. The consecutive timeouts limits apply to all channels, so you may need to compromise when setting the limits. You need to consider the impact that the settings will have on all channels, in particular, the channel that is associated with the highest number of outstations.
- The maximum number of retries per message (configured individually for each channel. Remember that you need to take all of the channels on your system into consideration). Each failed retry attempt will cause the relevant consecutive timeout to increase by 1, so you the timeout limits need to allow for retries as well as the original messages that are sent.
- The way in which the outstations on your channels are polled. Different drivers use different polling methods. For example, one driver may send the messages for the first outstation before sending the messages for the second outstation; another driver may send the messages in sequence, so that the first messages for each outstation are sent to each of the outstations, and then the second messages are sent to each outstation, and then the third and so on.
You need to set the limits so that the channel can still be used if an appropriate percentage of the outstations on the channel are still healthy. For example, let’s say a channel is used to connect to 10 outstations. It is configured to have 5 retries and two transaction attempts and the consecutive read timeout limit is the default amount of 20. This means that if 1 outstation fails, it will increase the timeout count by 12 (the first attempt+5 retries x 2). So, if the first two outstations have failed, the channel will fail (as the consecutive read timeout limit will have been reached) and the remaining 8 outstations will not be contacted, even though the channel may be healthy.
- The reliability of your communications. If you know there are intermittent communication faults, you may wish to change the limits so that ClearSCADA is more/less tolerant of them. (Depending on whether you want the channel to fail quickly for transient communication problems).
- The reliability of your hardware. If you are using outstations that are known to have intermittent faults or unusual characteristics, you will need to bear these issues in mind when setting the consecutive timeouts. Depending on your requirements, you can set ClearSCADA to be more/less tolerant of consecutive faults.
Typically, you would look to increase the consecutive read and consecutive write timeouts if:
- Your channels are incorrectly being deemed as failed (due to one or more outstations on a channel failing and causing the consecutive timeout limit to be reached).
- Your channels have high values (above the default amounts) for the number of retries permitted. A high number of retries will affect the consecutive timeouts counts as if an outstation has failed, a higher number of messages will be sent to the failed outstation (more retries than the default amount).
You may want to reduce the consecutive read and write timeouts if:
- ClearSCADA is taking too long to recognize channels as having failed
- ClearSCADA is taking too long to recognize that outstations have failed over a network (Network channels only).
When you understand How ClearSCADA Uses the Consecutive Read and Write Timeouts, and know about the Considerations when Setting the Maximum Consecutive Read/Write Timeouts, you can proceed to: