Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA Enterprise SCADA

Connection Row Edit: Scan Edit tab

  • Last UpdatedJan 17, 2026
  • 7 minute read

The Scan Edit tab in the connection Row Edit dialog box is used to configure details of a connection record. The fields in this tab help determine the communication mode and time limits associated with the connections, pole-cycles and delay times.

Refer to the table below for field descriptions and instructions on how to configure the editable fields in the Scan Edit tab in the connection Row Edit dialog box.

Items

Description

Comm. Mode

Select the communication mode used by your system. Choices are:

  • Host Poll. In host poll mode, communication is initiated and controlled by the host. This is the common primary-secondary polling mode. A communications poll cycle is a series of requests.from the host computer to each of the on-scan remotes for data gathered from telemetered devices.

    The system typically does round-robin polling where the entire list of remotes for a given connection is scanned in sequence.

    In certain instances, the communications poll cycle time may need adjustment. You can do this by adding delays either to certain remotes or to the entire connection. You can also set up delays to compensate for the inherent deficiencies in the communication process.

  • Remote Poll. In remote poll mode, the remote initializes normal communications with Omnicomm. Instead of Omnicomm requesting updates, the remote sends the update. Remote poll mode carried out over a dial connection is referred to as cry-out mode.

  • Listen Only. In listen only mode, the host interprets data, but neither exerts control nor polls for data. This mode is often used when one AVEVA Enterprise SCADA system is being replaced by another. The old AVEVA Enterprise SCADA system still controls the system, but the new one listens to the connections and accumulates data. The new system’s data can then be compared with the data from the old system to ensure that they are identical.

  • Cry-Out. Cry-out mode is used in conjunction with a cry-out connection. The actual methodology of this mode varies with the protocol and the behavior expected by the protocol driver. Cry-out mode is typically used with installations that have periodic communication with a field device that "dials in" when a significant event or alarm condition happens.

Notes: Communication modes are configured on a project-by-project basis. You can only select the modes used by your system.

Changing the communication mode of a connection while there are active alarms may cause those alarm records to be unclear. If this happens, a manual alarm record cleanup is required.

Important: For ICCP, the Communication Mode must always be set to Remote Poll. This is because the connection is established between Omnicomm and ICCP DSCADA Adaptor and Omnicomm does not distinguish between the Adaptor and a physical Remote Terminal Unit (RTU) device.

Important: For the Open Platform Communications (OPC) Client protocol, Comm. Mode must always be set to Remote Poll. The OPC Client uses Report By Exception (RBE), and the server will call back into Omnicomm when data is to be transferred.

No communication timeout (sec)

Enter the value in seconds.

This field is dependent on the Comm. Mode selection.

If the Comm. Mode field is set to Host Poll, Remote Poll or Listen Only, the value of this field is one factor in determining the maximum time that is given to a remote to respond via the connection in question. If any polled remote using this connection fails to respond within the configured time, a No-Reply alarm is generated against the remote.

Reasonable settings for this field are 30 to 60 seconds on a leased line, and 90 to 120 seconds or more on a dial-out circuit. Some remotes may take several minutes to reply to the host. For Remote Poll and Listen-only, if no data has been read on this connection for that time period, all the active remotes on the connection will be marked as NO REPLY.

When Comm. Mode is set to Cry-Out, this field is used for a different purpose. In cry-out communication mode, remotes dial in (or cry-out) to the host. The fact that there are no remotes dialing in does not indicate a failure condition. To ensure that the dial-in modem on the connection is not in a confused state, which might prevent remotes from dialing in, the modem is initialized if no incoming calls are received within the time period specified in this field. The No Communication Timeout field is set to a time interval wherein the host waits for a remote to dial in before the attached modem is initialized (for example, the modem is sent a connect command sequence). The Administrator-configurable initialization command (the connect command sequence) typically forces a hangup followed by auto-answer reconfiguration. A typical setting for this field is 3600 seconds (one hour). It is not recommended to set this field to a value over 32000 seconds.

Maximum time to Connect (sec)

Enter the maximum time (in seconds) required to establish a connection. The connection is between the Omnicomm process and the terminal server's TCP/IP port. It does not include modems or remotes. If the indicated time has expired and no connection has been established, the system generates an alarm and declares the connection failed. A typical setting is 10 seconds.

Reconnection- delay Time (sec)

Enter the delay time (in seconds) before attempting the next connection. This delay only applies to temporary connections. A permanent connection should always be connected unless it has no remotes.

Maximum Reconnect Tries

Enter the number of times that Omnicomm will attempt to open the same connection before failing over to another connection. Omnicomm will try to reconnect after the Maximum time to Connect (sec) time has expired. Typical Maximum Reconnect Tries are 2 and 3.

Minimum Poll- Cycle Time (sec)

Enter the minimum time delay between the beginning of one poll cycle and the start of the next poll cycle. The system will wait if a Minimum Poll Cycle Time delay is configured and the actual Omnicomm poll cycle completes before the minimum poll cycle time expires. This time delay is specified to:

  • Reduce the load on the central processing unit.

  • Minimize phone line charges that are based on traffic or the amount of data sent.

    In the figure below, A, B and C represent different remotes, if you set the minimum poll cycle time to 60 seconds and the poll cycle takes only 10 seconds, then there is a 50 second wait at the end of the cycle.

Number of Poll Retries

Enter the number of times the system should retry obtaining data from a remote if the initial query fails. For example, if you enter 3, the system sends up to three additional queries to the remote. If the system has not received any data after the configured number of retries, it continues to poll at intervals defined in the No Response Delay field within the remote record. For more information, refer to Remote Row Edit: Scan Parameters tab. This applies to poll attempts only–not to other types of command requests.

Delay Between Remotes (ms)

Enter the delay time between polling remotes on a round-robin basis. This delay only takes effect between remote records on a single communication line and does not impact between poll cycles. Use the field as required, as some field devices require "dead" time between requests before they listen for the start of the next message. The field indicates the delay time between successive polls. This delay before the next poll:

  • Allows the host to receive and ignore any garbage bytes, which may have been placed on the line when a remote dropped the carrier.

  • Reduces the load on the host by preventing retires (for example, repeated queries from the host in a single poll).

  • Minimizes telephone line charges if they are based on the amount of data transmitted.

  • Allows radios to change into transmit or receive state.

  • Reduces the load on the central processing unit.

Communication Delay Time (ms)

Enter the delay time you want to allow for additional overhead required by the communications media (radio keying times or VSAT delays). The field specifies the maximum expected delay for communication media that have inherent delays (for example., slow remotes, slow modems, poor communications lines, or satellite transmissions). This delay:

  • Allows for propagation delay, such as satellite transmission time.

  • Allows for slower-than-optimal communication rates by certain communication lines.

  • Allows radios to change into a transmit or receive state.

    Some typical delay values are:

  • Slow remote delay: 20-200 milliseconds.

  • Slow modem delay: 150 milliseconds.

  • Satellite delay: 5000 (depends on the type of satellite link).

  • Poor line delay: depends on line quality.

Persistent Socket

Select the Persistent Socket checkbox to indicate that the connection is connected and the socket is active regardless of whether this connection is the primary connection for a remote.

If this checkbox is not selected, the connection's socket is closed and the connection is disconnected by Omnicomm once it becomes a non-primary connection for a given remote.

Notes: For a host poll connection type, the connection is established and remains open after the AVEVA Enterprise SCADA host sends a first poll (for example, as test poll).

If the Protocol field on the Main tab of the connection Row Edit dialog box is set to OPC Client, this checkbox must be cleared.

Related Links