We have a system that we install at customer sites that has much of the configuration and status for the underlying PLC AOI exposed to the HMI. We are now looking at way to try and optimize that data flow from the PLC AOI up to Ignition.
Currently we have all the non configuration tags in the default tag group, and most of the configuration tags on a leased tag group.
Much of this data is a boolean data type. What I’d like to do is try and utilize derived tags to read and write to a single DINT to move from 20 individual boolean tags to one DINT tag.
Has anyone done something similar? Is there another option that I’m missing?
The underlying PLC is an AB Logix PLC.
What I think we ultimately want to do is to reduce the total amount of tags flowing between the PLC and the OPC-UA server in order to keep the PLC load factor down. On smaller systems we don’t have an issue, but on larger systems sometimes the tag count can get pretty large… like 100K tags plus.
Thanks for any recommendations…
Not really going to help much. The logix driver already optimizes most such access. (bits in words)
A better approach would be to not bring AOI content into a scada package. AOI data types have permanently hidden members that inhibit optimizations for the tags as a whole and for any elements sharing the underlying bytes.. Instead, define and use additional data types for operations and configuration elements (separately) and use InOut parameters to supply these to your AOIs. Input, output, and local elements of your AOI should be just the "black box" implementation details that stay in the PLC.
In larger installations, use arrays of those operations and configuration types to give drivers large consecutive optimizable blocks.
2 Likes
Makes sense.
So bits in a udt will out perform a similar structure using bitwise operations on a don’t?
The industries that we are in tend to need the configuration at the hmi level so im not sure we will get to love that away, but if we can move things to udts and optimize comms that way we may not need to.
Are there any good resources with understanding how to structure things for optimizing opc reads and writes? I’d like to read up and understand the differences.
It bits of a DINT addressed individually in Ignition will be satisfied automatically with a read of the underlying DINT–no extra packet travels on the network. Named booleans in a UDT are actually part of special hidden but accessible SINT members, and the optimization is similar, particularly for contiguous runs of such bits.
I would normally link to Rockwell’s Data Access Programming Manual, but that link has been hijacked (by Rockwell) for a different document. (PM002 is delivered instead of PM020).
Rockwell may have withdrawn that manual from public use. /:
Thanks @pturmel. We are going to be talking internally and testing out a couple of the things talked about in this post. Thankfully converting from an AOI to a UDT isn’t the end of the world.
I’ll have to push my contact and see if I can get my hands on that programming manual.
Thanks again
Just curious, but what are the effects you are seeing with large tag counts? I’ve hit close to 100k tags and haven’t noticed an issue on the plc side (L81, I could see CpLX or pre L8). Some clients were a little on the slow side but having the driver read after a write solved that for me.
Load factor is the biggest thing, and overall OPC response seems to be sluggish at times. This all comes from a client system that is overall slow so we are trying to squeeze out as much performance as possible.
To note… if we drop the default tag group to 2000 ms then the load factor goes way under 100%. We are just trying to understand if there is a better way of doing things.
Nothing on the PLC side for sure
Gotcha. Thanks the the response.