So I’m creating a general UDT to represent a set of interlocks on a remote PLC. The interlocks UDT is composed of multiple interlock UDTInstances, each with their own label and status tags. In the interlock set UDT definition I have disabled the interlock UDTInstances which will be re-enabled with an override if that interlock is in use (i.e. status tag is bound to an interlock OPC tag). The interlocks set UDT is structured like below:
Interlock Set
Intlk00 (<- disabled by default)
Label (string:memory)
Status (opc:boolean)
Intlk01 (<- disabled by default)
…
Intlk07 (<- disabled by default)
Label
Status
Intlk OK
I’m running into a problem when I create an instance of the interlock set UDT and enable one of it’s interlock tags with an override. When I enable Intlk00 with an override, the .enabled properties of the tag and its children are set to true (as expected) but their quality remains as “Bad_Disabled”. Trying to write a string to Intlk00/Label from the designer’s Tag Browser then produces the error:
“Error writing to Label.value: Bad_Unsupported”
So far the only fix I’ve found is to restart the ignition gateway. After which the enabled tags no longer have the quality “Bad_Disabled” and are once again writable from the Tag Browser.
I believe this is a bug with how child tags in UDTs are updated when their parent is enabled but any insight would be greatly appreciated.
I wouldn’t bother with the outer UDT. Then in the folder where the outer UDT instance would have been, you can create instances of a single interlock UDT and give them appropriate names.
The goal of having the Interlock set UDT was to make the interlock labels editable from within vision and to encapsulate some logic with the set of interlocks. The interlock set UDT is going to be a base building block for a lot more device specific UDTs in the future. If I remove the outer UDT then the logic would have to be configured separately for each device UDT and my goal is to make UDTs that are easy to duplicate and reconfigure for those not familiar with ignition’s UDTs.
As another point of view, the way I do interlocks is to have an interlock word from the plc where each bit represents an interlock. Then I have a dataset tag with all of the interlock descriptions in there with reference to the bit. Then you can use the lookup expression function to get the description of your interlocks and status from the word
I have overall interlock and non-bypassable interlock statuses that have expression bindings to determine overall interlock status from the enabled tags. The expression uses a qualityOf({tag}) != “Bad_Disabled” condition to determine which tags to include. I also have a DeviceAlarms UDT with a similar structure but for miscellaneous alarm bits. In this case there is also some logic to determine the number of active alarms and highest active alarm priority.
The only problem I’ve had so far is that reenabling a UDT member requires a gateway restart before the members child tags are reenabled. My other though was to have a separate boolean “enabled” tag for each interlock/alarm and use that instead of the built in .Enabled tag property. But I wanted to use the built-in features as much as possible.
The main goal of these general UDTs is to provide site programmers with a standard structure to follow when structuring their PLC tags. Some PLCs will have extra interlock, permissive, and alarm bits that are not present on all PLCs but that they would still want to view from the HMI. The site programmers are not familiar with ignition so the goal of the general interlock is to provide them with an already defined tag space where they only need to enable a new tag and define an OPC source. The rest of the configuration will be done through Vision/Perspective.
@nminchin I like your idea of using a dataset but It would still require individual tags for each OPC source (or changing PLC code to pack bits) and I want to make as little changes to the existing infrastructure as required.
I presume that your plc has individual tags per interlock then? Using a single word for interlocks has lots of benefits, but you’re probably too far down the rabbit hole for that now.
You shouldn’t ever need to restart the gateway for things like this. I’ve found that enabling tags in a udt sometimes takes a few minutes before it comes good. You can speed it up by restarting the UDT tag. If all else fails, you can disable and re-enable the tag provider from the gateway webpage.
Yeah some of the PLCs use a packed word for interlocks but most of them are individual tags. Hence the need for this flexibility .
Oh wow, I didn’t notice the “Restart Tag” option in the context menu. Restarting the tag after editing the UDT instance fixed the problem immediately. Thank you @nminchin for your help!
.