![SWTB_logo_rgb_color_mode-wPadding-2000x961.png]](https://help.softwaretoolbox.com/hs-fs/hubfs/SWTB_General/Images/Press_Kit/SWTB_logo_rgb_color_mode-wPadding-2000x961.png?height=50&name=SWTB_logo_rgb_color_mode-wPadding-2000x961.png){kind=logo}
TOP Server Polling Behavior
What factors affect the way TOP Server polls devices for data?
Polling is done based on a combination of factors- the client requests, the device protocol, and the TOP Server configuration. If all of the devices are configured under a single channel in the TOP Server project, the server will poll the devices in a round robin fashion. Once all of the devices have been polled, TOP Server will check the client's requested update rate to determine the next poll time. This may change the order of the devices polled if it is time to update one device, but not another. If the devices are on separate channels in the TOP Server project, each device will be polled based on the client's requested update rate. We recommend this method when possible, because the ability to meet the client's requested update rate is improved.
When you configure a device in the TOP Server, there is a timeout setting that controls the connection and message timeout as well as the number of retries before a failed response is logged in the server and the device _Error bit goes high. When devices are under the same channel and the _Error bit goes high, the server attempts to poll the next device.
Regardless of the TOP Server configuration, the PLC protocol and network can affect the ability to return data at the client's requested update rate. For example, if the client requests a 100 ms update rate while the tags being read from the device take 200 ms to read, there is no additional read queue built up. There is simply a flag indicating that the device needs to be polled again. The actual polling rate in this case is determined by the network and protocol instead of the client. When a client requests data at a rate greater than the network and protocol can deliver, the client will receive the best available rate without causing a request build up. Writes take priority over reads depending on the write optimization used in the TOP Server channel settings. Designing a system that can move the data required has to involve the protocol and network limitations.
When you configure a device in the TOP Server, there is a timeout setting that controls the connection and message timeout as well as the number of retries before a failed response is logged in the server and the device _Error bit goes high. When devices are under the same channel and the _Error bit goes high, the server attempts to poll the next device.
Regardless of the TOP Server configuration, the PLC protocol and network can affect the ability to return data at the client's requested update rate. For example, if the client requests a 100 ms update rate while the tags being read from the device take 200 ms to read, there is no additional read queue built up. There is simply a flag indicating that the device needs to be polled again. The actual polling rate in this case is determined by the network and protocol instead of the client. When a client requests data at a rate greater than the network and protocol can deliver, the client will receive the best available rate without causing a request build up. Writes take priority over reads depending on the write optimization used in the TOP Server channel settings. Designing a system that can move the data required has to involve the protocol and network limitations.