I was wondering if theres a way to setup the enable of a tag based on another tag? With object oriented design this can lead to some critical performance improvements by removing some tags from the scan (such as alarming or trending, etc.) Especially for big projects
Creates Tags from a given list of Python dictionaries or from a JSON source string. Can be used to overwrite a current Tag’s configuration.
When utilizing this function, the tag definitions must specify the names of properties with their scripting/JSON name. A reference of these properties can be found on the Tag Properties and Tag Alarm Properties pages.
String collisionPolicy - The action to take when a tag or folder with the same path and name is encountered. Possible values include
** o - Overwrite and replace existing Tag’s configuration**
Enabled enabled Whether the Tag will be evaluated by the Tag Group. If false, the Tag will still be present, but will have a bad quality.
You'll need to encase that in the tag() function but as Nader pointed out in his post, you'll be adding a lot of extra tags and bindings to accomplish that by reading a tag's value for the disable. Better off using a custom parameter for it instead, or even creating different associated UDTs which are all based on a parent udt but extend the parent
How would i achieve the enabled/disabled through scripting? Specifically i want it to either be easily changeable for other developers so that they dont have to go through any scripting, And I’d like to make it auto apply without any additional work in a UDT structure.
For example the accumulator of an alarm would auto enabled/disabled based on the enable logic of the alarm, all part of the same DT
Another example would be a valve DT, all of its tags should auto enable/disable based on another tag such as “backwash valves exsist” or something along those lines
How many variations do you have? I do work in wineries and there are a few different types of tank, but a common set of devices that each tank can have. I have multiple UDTs that all have different combinations of these devices. This way:
I don’t have disabled tags everywhere
I know exactly what type each tank instance is without going into the tag level to see what’s enabled/disabled
it makes bulk tag creation easy as you can just supply the right UDT path
Might be worth considering if it makes sense for your application
Too many, I work with water treatment plants, and we are currently going for a giant modular design, so there might be 50-100 analogs 50-100 valves, 20-40 motors/chemical pumps all in the same project, each with 5 or 6 alarms a piece. And with this modular design we want to link everything to exsists/enable bits including equipment visibility. Which is why auto enable/disable because a priority because we can easily do visibility on the screen, but tag polling is another thing where the alarms always on the scan or analog values for trending always being pulled becomes a concern
I just tried various methods, and forgot that tag configuration bindings don’t accept the expression language, they only accept parameters and some verrry basic expressions within those ({param + 1} for example).
I think you’re going to have to develop a tool that will configure the udt instances using system.tag.configure or alternatively, processes tag json, in order to set up your instances. You could certainly add the config that you want as memory tags into the UDT definition which your tool would then read and then configure accordingly, but I don’t think you’re going to be able to do this automatically with bindings (and I don’t think you would want to either, as this would place more burdon on the cpu)
Sometimes a UDT is not the right choice. If you anticipate “infinite” variability, just make UDTs for the inner elements and script the creation of instances and top level tags in a regular tag folder. Otherwise your “modular” UDT will be a nightmare consuming far more development resources than it saves. If it saves any effort at all.
By modular I mean from a project perspective, theres alot of reusability with components of the treatment skid. Such as if a valve exists on the skid or not
