RTU turnaround time and overhead time delays

Remote turnaround time and overhead processing time are difficult to estimate without some background research. There are some checks analysis that you can perform to help you make more accurate estimates.

In order to make a reasonable estimate, check to see if the remote manufacturer publishes figures for the response time of queries and commands. Take the time delays that represent the worst-case delays for the remote in question. It may also be necessary to take into account such parameters as I/O count or installed CPU speed. Ensure that the figures that you use do not include the time required for the response bits to be transmitted. This bit transmission time is already taken into account by relying on the correct setting of the Default Signal Configuration field. For more information, refer to Remote Row Edit: Main tab.

Alternatively, it may be necessary to measure these time delays using either a serial-line analyzer with a time-stamping feature or a storage oscilloscope. This technique is preferred, since the documentation for a given remote may not take into account firmware customization, or may not be able to predict dependencies on field devices that affect the remote’s response delays. The time to be measured is the delay between the end of the query/command bits and the start of the response bits.

If it takes more time to process commands than to process queries:

• Set the remote turn-around time to the longest time required to process a query.

• Set the overhead processing time to the difference between the longest query processing time and the longest command processing time.

If it takes the same amount of time (within tens of milliseconds) to process commands and queries:

• Set the remote turn-around time to the longest time required to process a query/command.

• Set the overhead processing time to 0.

If it takes less time to process commands than to process queries:

• Set the remote turn-around time to the longest time required to process a query.

• Set the overhead processing time to 0. This should not be set to a negative value as the results will be neither predictable nor consistent.

It is acceptable to set these fields for all similar remotes using the worst-case delays for the slowest type of remote. While such a practice may hinder communication throughput, it entails less effort than attempting to measure or calculate delays for every remote.

Keep in mind that some remotes do not respond to a command until the command is actually completed. If a command to close a valve cannot be completed until the valve has made a full transit, the response might not return until after two minutes or more. This drastic difference between responses to queries (for example, dozens of milliseconds) and responses to commands (several minutes for remotes controlling slow devices) underscores the need to tune the remote turn-around time and overhead processing time fields accurately. Under such extreme cases, it is wise to tune these two time parameters on a per-remote basis rather than use the same values for each remote.