The communications establishment and reply properties for each channel define settings such as:
- The number of times the ClearSCADA server attempts to establish communications with an outstation that is not responding
- The maximum number of transaction attempts before ClearSCADA deems an unresponsive outstation to have failed
- The amount of time the ClearSCADA server can wait for a reply from an outstation before recognizing that the outstation is not communicating (Out of Comms.)
- The line speed of the connections
- The amount of time allocated for unsolicited messages
- The amount of time (if any) that the ClearSCADA server waits between messages that it sends to the outstations that communicate via the selected channel
- How often the ClearSCADA server attempts to establish communications with an outstation that is not responding.
To configure these properties for a channel, select the ScanParameters tab on the relevant Channel Form.
The following fields are displayed for both Direct and PSTN channels on many advanced drivers, along with fields for Defining the Communication Statistics Update Rate. In addition, other fields are displayed for channels used by outstations that communicate directly with the ClearSCADA server (see Defining Further Scan Parameter Settings for a Direct Channel). For information on the Reestablishment Interval field, see Establish Communications with Failed Outstations. For fields that are not described in these sections or below, see the driver-specific documentation.
- Comms Retries—Enter the number of times that the ClearSCADA server attempts to resend a message to an outstation that does not respond to the initial message sent via the channel. If an outstation still does not respond to the final attempt to send the message, ClearSCADA deems the transaction to have failed. (A transaction is an operation, such as issuing a control, or polling an outstation to retrieve data. A transaction may comprise one or more messages sent to or from the server.)
We recommend that you set the Comms Retries to 3.
Example:
The Comms Retries for a channel are set to 3. The server uses the channel to send a control to a point on a particular outstation via that channel. The server does not receive a response to the message, indicating that the message has not been received successfully by the outstation.
The message is sent again. The outstation still does not respond to the message. The message is sent a total of four times (initial message plus 3 retries of the same message (as Comms Retries = 3)). The outstation still does not respond to the message, so ClearSCADA deems the transaction for that control to have failed.
The Comms Statistics for the outstation and channel are updated. As the transaction was for a control, a Control Failed alarm is raised.
- Transaction Attempts—Enter the number of consecutive message transactions that have to fail to be sent to an individual outstation on the channel before ClearSCADA deems that outstation to have failed. Each transaction failure involves a message being sent then resent for the number of times defined in the Comms Retries field (see above) and still being deemed to have failed.
We recommend that you set the Transactions Attempts to 2.
Example:
The Comms Retries for a channel are set to 3, and the number of Transaction Attempts are set to 2.
The server uses the channel to send a control to a point on a particular outstation via that channel. The server does not receive a response to the message. The message is sent a total of 4 times (original message + 3 re-attempts to send the same message). ClearSCADA deems the transaction to have failed. As only one transaction has failed for the outstation, the outstation itself is not deemed as failed, but the Comms Statistics for the outstation and the channel are updated, and a Control Failed alarm is raised for the control.
The server then sends a separate message to another point on the same outstation. The server does not receive a reply to that message. The message is resent a further three times, but no reply is received from the outstation. ClearSCADA deems the transaction to have failed. ClearSCADA also deems the outstation to have failed as there have now been two consecutive failed attempts to perform any transaction on that outstation.
The Comms Statistics for the outstation and channel are updated. Additionally, ClearSCADA raises alarms and logs events associated with the changes to the outstation’s comms status.
- Standard Reply Delay—The ClearSCADA server uses the Standard Reply Delay to make allowances for delays caused by the communications media, for example, delays caused by radio transmissions. (It is used by each driver as part of a calculation to determine the maximum amount of time in which an outstation should reply).
For most systems, the default setting of 1000 is suitable.
You may need to increase the Standard Reply Delay if there are a significant number of timeouts (as shown on the Comms. Stats List). For information on using Lists, see the ClearSCADA Guide to Lists.
- Line Speed—Use to specify the speed of the slowest part of the connection, so that ClearSCADA can correctly calculate the transmission time for each message sent/received via the channel.
If the entire connection between the master station and the outstation uses the same speed (the baud rate), you can set the Line Speed to Same as Baud Rate. You can only use the Same as Baud Rate option if the channel has a baud rate (Serial, or Remote Serial). If you attempt to use the Same as Baud Rate option with other types of connection (TCP/IP, or Network), a diagnostic message is displayed. The Baud Rate is defined on the Connection tab of the Channel Form (see Tabs on Channel Forms).
If part of the connection uses a slower speed, you have to specify the speed in the Line Speed combo box (choose from the list of standard line speeds, or type in the required speed). The driver in the master station uses the baud rate and line speed in its calculations to determine the expected transmission time of each message.
On a Serial connection, the line speed is typically the same as the baud rate. However, for some connections, the Data Communications Equipment (DCE) speed is slower than the Data Terminal Equipment (DTE) speed, and so the line speed has to be set to the slower DCE speed.
On a Network connection, such as an Ethernet, LAN, or WAN connection, the speed is often faster than a Serial connection. For Network connections, we recommend a conservative line speed of 9600, but you can set a faster speed if desired.
For most protocols, speeds above 2Mbs provide typical message transmission times below 1ms.
Example:
A ClearSCADA master station is connected to a dial-up modem (we will refer to this device as Modem 1). A channel is configured for the connection between the master station and Modem 1 and the baud rate of the channel is set to 9600 (this is the baud rate that is supported by Modem 1). When the driver in the master station communicates via Modem 1, it sends the data at the defined baud rate (9600).
Modem 1 transmits the data it receives from the ClearSCADA master station to another modem that is connected to an outstation. We will refer to this 'other' modem as Modem 2. The modems communicate via a wireless connection that is slower than the connection between the master station and Modem 1. The wireless connection uses a line speed of 600.
So that the driver in the master station can correctly calculate the transmission time of each message, it needs to know the line speed of the connection between Modem 1 and Modem 2. So the channel is configured to have a baud rate of 9600 and a line speed of 600.
For information about how the driver calculates the timeout periods, see Driver Calculations for Message Timeouts.
- Unsolicited Message Timeout—Specify the amount of time the master station will wait for the remaining part of a partial unsolicited message. Typically, the default setting of 5000 milliseconds is appropriate, but you may need to change this amount if you are getting lots of unsolicited messages timing out.
The purpose of the Unsolicited Message Timeout setting is to allow the driver to cease waiting for incomplete messages and allow other operations to continue via the channel. For example, if an outstation is sending an unsolicited message to the driver and the communications fail during the transmission, the driver will only receive part of the message. The driver uses the Unsolicited Message Timeout setting to calculate how long it should wait for the remainder of the unsolicited message. If the driver has not received the remainder of the message within the Unsolicited Message Timeout, the driver aborts waiting which allows other operations to continue via the channel.
When defining the Unsolicited Message Timeout, you need to consider any latency on the communications link. Latency can affect the amount of time it takes for the unsolicited message to be received by the driver.
For information about how the driver calculates the timeout periods, see Driver Calculations for Message Timeouts.
- Inter Message Delay—Specify a value other than zero if you need to intentionally slow down communications. An inter message delay is useful when you require diagnostic information or when there is a need to prevent an outstation becoming overloaded with messages.
For most systems, the default Inter Message Delay of 0 is suitable.
An Inter Message Delay is applied as follows:
- If a message has a response, then the Inter Message Delay is applied after receiving the response (or timing out). With this scenario, the Inter Message Delay is applied as follows:
Message transmitted, response received, Inter Message Delay, message transmitted, response received, Inter Message Delay, message transmitted,...and so on.
- If a message has no response, the Inter Message Delay is applied after transmitting the message:
Message transmitted, Inter Message Delay, message transmitted, Inter Message Delay, message transmitted,...and so on.
- With a few drivers, a message might have two (or more) responses (for example, DNP3 link layer and application layer messages). With such drivers, the Inter Message Delay is applied after the driver receives the last response:
Message transmitted, 1st response received, 2nd response received,...nth (final) response received, Inter Message Delay, message transmitted,...and so on.
The Inter Message Delay is also applied when the driver detects certain communications problems—for example, following a reply timeout, or a transmission failure.
- If a message has a response, then the Inter Message Delay is applied after receiving the response (or timing out). With this scenario, the Inter Message Delay is applied as follows:
- Idle Poll Interval—Specify the frequency with which ClearSCADA periodically polls an outstation via the channel if it deems communications with that outstation to be suspended via the channel. Communications on a direct channel are suspended, for example, if the direct channel and its link to the outstation are healthy, but the outstation has fallen back to using PSTN communications. While communications with the outstation via the direct channel are suspended, ClearSCADA performs an Idle poll at the interval specified to help prevent the direct connection from timing out due to inactivity. Idle polling ceases once communications with the outstation resume via the channel.
Specify the required Idle Poll Interval in seconds. You can specify an interval in the range 1 to 86400 seconds inclusive (86400 seconds equates to 1 day). The default interval is 10 seconds.
Idle polling is applied to each outstation on a channel individually. So, for example, if a direct channel provides the main multi-drop communications route for 10 outstations, and one of those outstations falls back to using PSTN communications, ClearSCADA will only Idle poll the one outstation that is using PSTN communications.
Idle polling does not apply if fallback to PSTN communications is due to communications via the direct channel failing. In such circumstances, ClearSCADA will attempt to re-establish communications with the outstations via the channel at the frequency specified by the Reestablishment Interval (see Establish Communications with Failed Outstations).