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.

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.

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.

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.

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.

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.

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).