I am working with Ignition 8.3 and am having trouble properly configuring the tag update frequency, especially for Modbus tags. In previous versions, I was able to configure the Scan Class to set the update frequency for tags, but I cannot find this option in Ignition 8.3.
Here are my questions:
In Ignition 8.3, where can I configure the update frequency (Scan Rate) for tags (especially Modbus tags)?
Should I use Scan Groups to manage the tag frequency, and if so, how do I correctly associate a tag with a Scan Group?
Where exactly is the frequency property located in the Ignition 8.3 interface? I’ve looked through the tag properties and Scan Groups, but I can’t find the exact location.
Are there any resources or practical examples for configuring Scan Groups and tag update frequencies in Ignition 8.3?
Thank you for sharing the documentation; it was really helpful!
I’ve configured the Scan Rate (Rate) for my tags in Ignition to 200 ms, but my equipment actually has an acquisition time of 300 ms instead of 200 ms. The protocol used for data acquisition is Modbus TCP/IP.
My question is:
Can adjusting the Rate for all tags to match the equipment’s acquisition time improve data acquisition when handling large volumes of data?
Are there any performance concerns when setting a fast scan rate (e.g., 200 ms) for multiple tags if the equipment requires a longer acquisition time (300 ms)?
Is there a recommended strategy for configuring the Rate when collecting large datasets, considering the equipment’s acquisition time?
Yes. Attempting to poll faster than the device is internally generating values is pointless and hurts performance.
Yes. Attempting to poll faster than the device is internally generating values is pointless and hurts performance.
Yes. Poll slower or fewer. Attempting to poll faster than the device is internally generating values is pointless and hurts performance.
(You didn't ask a fourth question, but...) Attempting to poll faster than the device can respond and deliver the values is pointless and hurts (write) performance.
#4 is the bottleneck for most devices.
There's no magic wand in Ignition if the device is the limiting factor.
I have a device that centralizes all field data and it receives ModBus TCP/IP requests no less than every 200 ms. I’m wondering if this device can handle 700 continuous requests at a rapid pace. Additionally, if I were to send 200,000 requests to this device, would it be able to manage this load without any issues?
Also, considering that, unless I’m mistaken, tags in Ignition typically make requests every 1000 ms, would it be useful to configure the tag Rate to optimize this, or should I leave the default setting as is?
Create a tag group at whatever rate you want, assign the tag to the tag group. If you need the poll rate faster than 1000 mSec it is an easy change.
Whether it works or overloads if highly dependent on non-Ignition variables such as network performance and device performance. There are MODBUS devices out there that perform very poorly, anything too fast is just a waste of resources
....but I think you already know that.
In 8.3 you can go to Connections....OPC....Connections....View Details....Client Diagnostics to see some limited information about the tag connections.
In 8.1 you used to be able to see some really good diagnostic information sorted by tag groups in status...connections....devices, it seems to have disappeared in 8.3. I think this information is what you really need. I know I have found it very useful in the past.
My modbus simulator is responding at over 2.28ms, so for sure that is the limit for the 618 tags I'm requesting.
I still trying to grasp why you are asking US this question. The Modbus TCP protocol can certainly do hundreds of thousands of requests per second (typically requiring concurrent request support on both ends), and there's no limitation in Ignition that would impede this. This is a question for the maker of the device doing the data centralization. And might not be answerable without testing that device under load.
I was having trouble importing tags from another gateway, so I increased the subscription rate to reduce the network load, which was too aggressive, and improve overall stability.
