If you must use AOIs and not just UDTs, yes.
There’s been a few different strategies discussed around here for isolating the tags needed by Ignition and getting them into a separate UDT. The most recent I can remember was in this post.
@pturmel might have something to say about a particular magic driver he has to get around these issues
It is linked in that topic. Just read the whole topic.
Hi, which is the best way to group data inside PLC to get maximum performance, where I can read about how Ignition/Rockwell is required to be data grouped for best connection performance? I am using udt structure only with different data types inside udt. I trying to create some guidance for my organization of how to do data grouping, but cannot find any proper document of how Ignition or Rockwell doing transfer optimization. I not really like to create arrays of REALs to send analog data to the ignition, because in this case is really a mess to work with this PLC code. Best case for me is grouping data into udt like udt_Valve, udt_VFD, udt_Motor etc, and each udt has all requried data for specific unit. But how to group those udts to have max performance it's is a question for me. (Example program has 200 valves, 100 VFDs and 50 Motors). The best approach be to group them into arrays (VFD[100], Valve[200], Motor[50])? or there any better solutions present?
1 Like
UDTs are very good for performance. Arrays of UDTs are especially good. With some constraints. I recommend you read the topics linked above, because they have a great deal of information about how this stuff works. The best summary is probably this one:
Most importantly, for any given base tag in the controller (a controller tag, or a program tag, at the top level), use only one subscription pace. Optimization can only occur for OPC items that are part of the same tag, and at the same pace.
Things that are less important to your operation, and can operate at slower paces, should be in a completely separate tag hierarchy, preferably another array of UDTs.
If you must use AOI tags, and cannot do any InOut parameters nor tweak AOI locals into a nested UDT, you probably want to use my alternate driver.
2 Likes
Question about udt:
If udt has 5 tags:
- Tag 1 (dint)
- Tag 2 (dint) (not used in ignition)
- Tag 3 (real) (not used in ignition)
- Tag 4 (real)
- Tag 5 (bit)
Tag 2 and 3 are not required in Ignition, how data be called from PLC in this case?
Should i group tags into udt specifically for ignition or there any difference if udt has some tags which is not for HMI?
1 Like
{Terminology note: UDTs in the PLC do not contain tags, they have members. "Tags" are only the top-level names in controller tags or in a program's tags.}
When Ignition is told to get Member 1, 4, and 5 at the same subscription pace, Ignition's driver (and my alternate driver) will read the entire structure in one request, if possible. Members 2 and 3 will be transferred in the response, and then be thrown away.
If you have large UDTs with many such ignored members, it will cut into the performance of the driver.
2 Likes
"#8: Never poll across a WAN. Latency crushes polling protocols."
Curious what exactly gets 'crushed' ? -- our enterprise design is to run Ignition in a regional datacenter to avoid putting server hardware /edge compute at the site. Instead we use L2NATs at the site which forward EthernetIP (port 44818) from plant floor to the offsite datacenter. Our ping times are around 35 ms.
In summary our PLC protocols (mainly Logix drivers with a few legacy) are going over the WAN from plant to datacenter where Ignition is running. What would be the drawbacks of this approach other than a slower latency for Ignition?
I am most interested if there would be any impacts to the PLC comms module? Phil I read over some of your other post you mention OPC drivers for PLC protocols don't buffer streams of requests and reply in streams but handle requests one-by-one. Also, "An A-B driver running over a connection with even 20 ms ping time will have a tenth of the usable capacity as a local LAN connection.
Ultimately, you may not achieve the polling rate you want for as many tags as you want. You may have to settle for slower. Look at the diagnostics for each driver to see where you stand.
2 Likes
On a LAN, where round trip time is tens of microseconds, simple requests to an L81E will be answered in about a millisecond. More complex requests will be answered in 15-20 millis. So, with a WAN round trip of 35ms, the 1ms responses become 36ms, and the 20ms responses become 55ms. So your driver load will be 3x to 36x higher with Ignition in the remote datacenter.
This is true for Modbus TCP, too, fwiw. Using request/response protocols across a WAN is just dumb. You should reconsider your network design and gateway placement. Consider putting Edge in your facilities.
OPC UA and MQTT are both non-polling protocols, and don't have this problem with remote connections.
1 Like
Is there a UDT size or UDT array size limit or best practice in UDT size for fastest comms?
In other words, say I have 100 AB PLC tags (or datapoints) I want to read and write with ignition.
Would it be more efficient to make 10 UDTs with 10 datapoints each or one UDT with 100 datapoints?
Would it be better to make a 10 member array with the 10 datapoints?
Would it be better to make UDTs of same datatype (bool, real, DINT, etc.) or is mix and match ok?
Or am I splitting hairs here?
What if I have 1000 tags? 10,000 tags? 100,000 tags?
Thanks,
Dave
Arrays versus UDTs doesn't make a difference. It is simply packing items together to be read as a contiguous block is what makes reads efficient. The advantage diminishes (a little) after a tag's total size reaches the buffer size of your connection, as the rest will be read with continuations. (Continuations of a single tag do not run concurrently.)
For UDTs, try to avoid unnecessary gaps due to different size elements. Put 64-bit types first, then 32-bit types, etc, and keep all booleans together.
3 Likes
With the modern Ignition Rockwell driver, wouldn't a situation where you are using leased tags be a reason to have multiple connections? My understanding is that when the leased tags change, the whole driver is resubscribed, causing a brief blip/delay in comms. Using multiple connections would then reduce the amount of tags that are being affected, reducing the duration of the blip.
I'm not sure this is still true. Definitely not true for my alternate driver.
It is true that re-subscribing a tag at a new pace can be slow for that tag.
I make it a practice to use the theory behind prime number poll rates in a PLC to minimize the frequency at which tasks "intersect" each other. It shouldn't affect Ignition much. In practice the task rates don't have to be whole prime numbers since rates can also be "real numbers" of milliseconds. The important thing is to make sure you are not using schemes like 5 ms, 10 ms, and 15ms, which will intersect a lot.
Oy! Worse than useless. They will intersect at some point, at which time you absolutely have to have task priorities set right. If task priorities are set right, it doesn't matter if they intersect. Meanwhile, prime number scheduling schemes cause task latencies to be far more random than if they are proper multiples, and random latency is horrible for realtime tasks.
Don't do it. It is a bogus, and usually actively harmful, technique wherever it is used. Really.
2 Likes
Well, we're going to have to agree to disagree here Phil. I have the highest regard for your opinion in all matters, even this one. However, the thing I do best is squeeze performance out of machinery using Rockwell PLCs and this is one of the techniques I use to do it. I would be happy to discuss this further, but I don't think this question is the best place to do it. Maybe we should create a new topic?
Perhaps. I doubt either of us will be persuaded by anything less than hard evidence, and that would take much testing to produce. I have the lab equipment to do that, though, and may putter away at it with my copious free time. How about we table this until either of us has some data and test methodology to share, and create a topic then?
Sounds good. And I suppose I should qualify that reason I use this technique is to get maximum performance out of machinery in a process where milliseconds are worth thousands of dollars a month. Since this topic is about improving communications though, I'm less adamant that the practice is best for improving communications (I suspect it still is though). Also, most processes are not as scan time critical as the ones I control and extreme measures to get minimum scan time are probably not warranted.
One of the most shocking things I heard very early in my career (late 90's) came from another person whose opinion I respect greatly. He said that the real value of PLCs was to give visibility into the process where I had always considered it to be the ease of controlling and modifying the process. Occasionally I have to check my motivations with that in mind. There's no question that my efforts with Ignition have been tremendously valuable to my facility. Improved communications is more important than shaving a few milliseconds off a process that doesn't need it.
I have to agree with Phil here. We've got a customer who with their Wonderware projects has us breaking up the comms into many different prime numbered scan times. Even though they're set all around 1000ms, our update rates are anywhere from 2-3 sec on the screen. Meanwhile I'm in Ignition with just standard non-prime update rates talking to just as many tags with 0-1% overload at 1000ms. When you're breaking things up in a bunch of smaller prime numbered scans, it's going to require more requests to process the same number of tags because you're not packing as much data into each request as possible and optimizing communications.
My understanding from what some of the devs (I believe it was mainly @Kevin.Herron) that all the requests get queued up anyway before being processed/sent so you're not gaining anything by using prime numbers as they'll eventually space themselves out naturally. Ever watch the overload after an edit/save of a driver and watch it spike, then slowly come down as things balance out? That's one of the huge bonuses of the Ignition driver too is that there's transparency and stats/diagnostics that Kepware doens't have.
2 Likes