Fairly new ignition user looking for optimization advice.
I created a UDT for every data type I’m pulling from a PLC so I can add or remove SCADA tags as needed without having to manually add/remove tags from every instance, as is the point of UDTs. However I am now finding that I have very large tag counts, close to 200K for a smallish project. I need to understand if the way I have created my UDTs is fine or if the tag count is going to cause performance problems or not. For example:
This is a UDT for a bool indication from the PLC. The value is an OPC tag from the PLC and the rest are memory tags used to display various perspective views that are attached to the UDT ‘Value_bIND’. This approach is great because it allows the use of generic views without having to manually enter Labels, descriptions etc in every view that the UDT instance is used. The problem is however that what was just a single tag is now 5x bigger, leading to a 5 fold increase in tag count.
So the question is:
1 - Is this a sensible way of storing SCADA configuration data or is there a better way?
2 - Will this approach lead to performance issues, should I be worried?
One thought was to replace these configuration tags with a single document tag like this:
This significantly reduces tag count but come at the price of reduced functionality. For example maybe I want configuration to be writable by admins only but decide later that SparklineSpan needs to be modifiable by an operator. Write permissions can’t be set individually. I could create 2 document tags one for admin and one for operators but this defeats the object of reducing tag count.
It also makes setting these values from another tag awkward for example:
Here is an extreme example of a UDT definition for a real value indication. I have included memory tags for all values needed to show the typical ranges on a moving bar or gauge indicator. In most applications these range values would stay as memory tags that a process engineer could use to set up visible desirable and undesirable ranges on graphics for a given process. Putting these values in a JSON document would work just fine. However in some applications the setpoint and alarm active values would take reference from another tag source, in my case I have an error UDT that would provide these values. Burying values in a JSON document prevents the use of the reference data source normally present on atomic tags. I could add change scripts for this but this also comes with performance problems.
As always there are 1000s of ways of doing anything, databases come to mind but I’d rather not go here. I’m interested to hear your thoughts on how others store SCADA configuration data.
Another thought is to create UDT types containing data that is needed for specific views, like a range UDT that can be added to any tag that needs to show ranges on moving bars and gauges. As apposed to adding range data to all tags just in case they are needed.
It seems to me you are re-creating properties that IA naturally has available for tags. For anything else, consider using custom tag properties, and only where needed.
The PLC has 200k tags and you imported them all to Ignition is that correct? Does your project actually need to see all of them? If not I would not be importing things that aren’t relevant to Ignition ie if they don’t need to be seen, written to, or recorded into a database.
The PLC has around 25k tags and many of these are PLC configuration tags that are setup in ignition as leased and only polled when they are in view. Values that do not need to be displayed under normal conditions but are useful to occasionally see, for example, maintenance are swapping out a sensor and want to see scaling SPs to reconfigure the new sensor.
I started breaking out some values from tag properties because I wanted to be able to set read/write permissions separately from tag value definitions. I think might have to backpaddle a little here and return as much as possible to inbuilt properties and deal with read write permissions in views.
Tags have permissions that are applied to the value of the tag but is there a way of setting different tag permissions for other tag properties?
For example a tag value that was used as a process setpoint would have read/write permission set to ‘operator’ but I would want the documentation property to be set to ‘process engineer’ so that a process engineer can update notes for the setpoint.
No, tag permissions apply to the entire configuration. However, an operator can’t change something that isn’t exposed to them. Standard user security roles account for that.
If you don’t want an “operator” to be able to change the documentation property on a tag, don’t give them access to a way to change it.
I would recommend not to make the system more difficult to maintain for yourself and others in the name of accomplishing something that is already available by other means.
As for optimization, I have found that tag count by itself is not a great metric to measure performance by. In my experience a small number of tags that are set up improperly can be far worse that a huge amount of tags which have been set up with OPC subscriptions and usage in mind.
Taking steps to insure that the driver can optimize OPC reads and that only tags which are needed are being scan will go much further than decreasing your tag count. IMO.
I’ve moved allot of my configuration properties now into tag properties rather than having separate Atomic tags, this has reduced the tag count to a more reasonable 60k total, 40k of which are tied to the controller and probably only 1-2k polled frequently.
If I need to attach different security level to these properties then I can always create additional Atomic tags as needed to read/write to tag properties or do it with views, show/hide tag properties based on the users logged in level.
I couldn’t pull myself away from using UDT even for single tags. It far too convenient to configure a tag in a UDT and have changes roll out to every instance. They also work well with the drop view tag config and open up options to add extra tags if needed.
I’m already using tag groups extensively and can see from the gateway status that the number of subscribed tags is very small.
