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

AVEVA Enterprise SCADA

Configure timeouts

  • Last UpdatedApr 24, 2025
  • 3 minute read

Follow this procedure to configure the timeouts for no-reply, invalid message, and line failure alarms.

The Scan Parameters tab in the remote Row Edit dialog box is opened through the remote table listing in the Advanced Database Editor (ADE). For general information on ADE, and further information on the remote table, refer to the Advanced Database Editor (ADE) Administrator documentation and RealTime tables, respectively.

To configure timeouts

  1. Navigate to the Scan Parameters tab in the remote Row Edit dialog box.

  2. In the Timeout for No-reply Alarm (sec) field, enter the number of seconds the system should wait since the last normal poll cycle before generating a NO REPLY alarm.

    If data is not received from the remote after a specified number of retries, the remote shifts to the NO REPLY state and the system logs an event. If the remote stays in this state for longer than the Timeout for No-reply Alarm (sec) value, the system generates a NO REPLY alarm.

    Note: This is default behavior.

  3. In the Timeout for Invalid Msg Alarm (sec) field, enter the number of seconds the system should wait since the last normal poll cycle before generating an INVALID MESSAGE alarm (refer to Configure invalid message types).

    If a valid message is not received from the remote after a specified number of retries, the remote shifts to the applicable invalid state and the system logs an event. If the remote stays in this state for longer than the Timeout for Invalid Msg Alarm (sec) value, the system generates the applicable invalid state alarm. The alarm message takes the following format:

    Communications on RemoteName - invalid message - InvalidState - unavailable for > TimeSinceProcessingOfLastGoodValue seconds

    Note: Regardless of the type of invalid failure, the hold off continues provided the host does not receive a valid communication. For example, a SECURITY ERROR failure followed by a SHORT MESSAGE failure would not cause the hold off to be reset.

    Example:

    Assume that, for remote "REM01", Timeout for Invalid Msg Alarm (sec) = 30.

    • At 2:31:30, the remote shifts to the SECURITY ERROR state.

    • At 2:32:00, with the remote still in an invalid state, the system generates the following alarm:

      Communications on REM01 - invalid message - security error - unavailable for > 35 seconds

    • At 2:32:15, with the remote still in the SECURITY ERROR state, it suddenly shifts to SHORT MESSAGE state.

    • The system generates the following alarm:

      Communications on REM01 - invalid message - short message - unavailable for > 59 seconds

      In the Timeout for Line Failure Alarm (sec) field, enter the number of seconds the system should wait since the last normal poll cycle before generating a LINE FAILURE alarm.

      If a valid connection is not available, the remote shifts to the LINE FAILURE state and the system logs an event. If the remote stays in this state for longer than the Timeout for Line Failure Alarm (sec) value, the system generates a LINE FAILURE alarm. The alarm message takes the following format:

      Communications on RemoteName - line failure - unavailable for >TimeSinceProcessingOfLastGoodValue seconds

Related Links