The main Devices page lists out all OPC UA devices, as well as how many currently have a valid connection. Note: this will only show the devices connected through an Ignition device connection. For information about devices connected through other OPC Servers, see those programs.
Number of devices connected out of configured devices.
|Name||Name of the device.|
|Driver||Name of the device driver.|
|Status||Current device status.|
Clicking the Details button to the right will display a diagnostics page for that device which provides metrics for the device configuration. The page contains an Aggregate Statistics table that provides an overall summary of the
The Device Details page also lists statistics to help determine if the device is overloaded with requests. There are values for each subscription (such as those created by Tag Groups or Transaction Groups using OPC items) from the specified device, as well as aggregate statistics which pull from all subscriptions to get an average for the device.
The table below summarizes the statistics available on the Device Details page.
Tracks the number of requests that are coming in from the device, A request is a group of tags/items that the driver has grouped together to be read at the same time. Each driver forms these groups based on the protocol being used and occasionally configuration settings in the driver.
Represents the average amount of requests that come through per second since the device was last started.
If the device connection is edited and saved, this will cause the device connection to reinitialize and this value will be reset.
|Throughput (1 min)||Represents the average amount of requests that come through per second for the last minute.|
|Mean Response Time||The average time it takes for Ignition to get a response from the device. This number is an average based of the graph on the right of the page.|
Based on the statistics above, we can determine if we are overloading our device by requesting too many Tags too quickly. We simply need to take the throughput and use that to determine how many total requests come in per Tag Group execution. If this is at or above the request count, then our device can keep up with the numbers we are requesting. If it is below the request count, then the number of requests we are making to the device aren't coming in as fast as we want them, which can lead to poor device performance or bad values.
For example, take the image below. Scheduled at 2000ms, we have 81 requests. Our average throughput is about 40.8 requests a second. This means that every two seconds, we get 81.6 requests. Since we are making 81 requests every two seconds, this is exactly what we would expect to be getting from this device.
However, if we altered the Tag Group on the same device to 500ms, we see a very different picture. The request count is still 81, but because we are requesting values every 500ms, we should see about 162 requests coming through every second. The throughput values only show us getting about 87.5 requests per second, which is about half of what we actually are asking for. This would indicate that our device is overloaded, which can also be seen in the Load Factor. Our Tags would not be updating as quickly as we would like, which could lead to bad Tag values.