Sample remote record configuration
- Last UpdatedApr 24, 2025
- 2 minute read
Delays and timeouts that apply to a specific remote are configured in the Remote table. Sample configurations are provided to help you configure remote records.
The following table shows the field settings for two remotes described as follows:
-
Remote 1 monitors field devices that change frequently.
-
Remote 2, a slower remote on a poor communication line, monitors values that change infrequently
Field settings of a sample remote record
|
ADE Field |
Remote 1 |
Remote 2 |
Notes |
|---|---|---|---|
|
Timeout for No-reply Alarm (sec) |
0 |
45 |
When you use host poll connection mode, the host polls the remote for the number of times specified in the connection record (Number of Poll Retries field on the Scan Edit tab in the Connection Row Edit dialog box). If no data is received from the remote, it goes into the NO REPLY state. If the remote stays in this state for longer than the timeout, the system issues a NO REPLY alarm. Unlike many of the other values in the Scan Parameters tab in the Remote Row Edit dialog box, this timeout is not affected by the speed of the remote. To eliminate nuisance alarms, the timeout is set higher for remotes that use communication lines with poor transmission quality. The field is typically set to either zero (i.e. not used) or at least 2.5 or 3 times the Min. Poll-cycle Time. |
|
RTU Poll Delay (HH:MM:SS) |
00:00:00 |
00:05:00 |
For multi-drop configurations, this delay reduces the amount of bandwidth wasted by remotes that transfer less important data or data that rarely changes. It can be used to prevent overly frequent polling of battery- operated remotes or to minimize communication charges based on traffic or amount of data sent. Polling for dialed remotes is often scheduled for specific times of the day. In such cases, the RTU Poll Delay may not be used (i.e., it may be set to zero). |
|
No-response Delay (HH:MM:SS) |
00:00:00 |
00:10:00 |
For multi-drop configurations, this delay reduces the amount of time spent waiting on the communications circuit for remotes that are unlikely to respond. When no response is received from the remote over a connection, Omnicomm attempts to poll the remote at an interval that is the greater of the RTU Poll Delay and the No-response Delay. |
|
RTU Turnaround Time (ms) |
100 |
2000 |
This delay applies to poll for data, upload history and other typical poll requests. It is set to the longest time required for the remote to parse a query, process it, and formulate a response. |
|
Overhead Processing Time (ms) |
0 |
500 |
This delay applies to commands only (setpoint, status output). It accommodates remotes that require more time to execute commands than to respond to data queries (i.e., remotes that respond more slowly to commands than to polls).If the remote takes longer to process commands than to process queries, set this delay to the difference between the longest command processing time and the longest query processing time. If the time required to process commands is the same as or less than the time required to process queries, set this delay to zero. |