Hi, I’m making my first Scada with Ignition and I’m trying to understand what would be the best and fastest way to link my templates in Ignition to my PLC UDTs and other tags.
I have recreated a PLC UDT structure in Igntion and created a template using this UDT.
When the time come to link my AB PLC UDTs to my Ignition UDTs is it automatically going to recognize the name and structure are the same and then work in the template?
I noticed as well, in a template, if I have a UDT type parameter I’m using it does work even if the UDT I bind to the parameter is not of the same type. Ex: I have a DOL motor UDT and VFD UDT that have the same structure but the VFD UDT obviously have extra information. If my template is expecting a VFD UDT and I bind a DOL UDT it still take it and work. It’s perfect in my situation but is it a normal behavior or is going to change?
Still regardin UDTs in templates I could read that because it loads the entire UDT every time you use it, it can slow down a bit displays when you have big UDTs, even if you use only a few tags of it in your template. So apparently some people prefer working with Tag path rather than UDT.
Tag path and indirect binding is great but how does it work when you want to link you templates to the OPC tags? It seems really long having to copy every OPC tag path and paste them in the template parameter.
Is there a way as well when developing the Scada to pre link our tags to the PLC (like we would with addresses on other Scada) so when the PLC program is done they is no re work to do in Ignition?
Firstly, the structure you use in Ignition is completely independent of the structure in the PLC. These can be completely different. What links your Ignition tags to your PLC tags is the OPC Item Path and the OPC Server properties in your tag config:
The OPC Item path contains these elements:
ns=1;s=[{PLCDeviceName}]{Tag Path}
The PLC you use will determine the Tag Path you need to use, and you can read about the driver you're using in the help. But for AB firmwares above 21, it will just be the same tag path you see in the programme.
This was not always the case, and was changed I believe starting in v8, and makes using UDTTypes more useful. However I'm one of the proponents who still advocate for using a tag path over a UDTType property, despite the alleged significant improvements made to performance in v8 for using UDTType properties. The main two reasons I don't use these are:
you can't use them for templates if you want to use them in a template repeater/canvas
you can't see what UDT is bound to a template without opening the binding.
When using them in a template, I always split them into two properties that you pass into it: the folder path and the actual device name, and then combine these in an internal property to make the full path to the device. You can simply right click a tag and copy its path, which you can then paste into the template properties. And in splitting into the parent/name properties, you can select numerous templates and set their parent paths all at once, then all you need to do it type in their device names.
If you add your OPC Item Paths correctly to your tags, then they will work when you connect your PLC.
An example of how you would address a tag in an AB programme in v32, where the Device in Ignition is named "PLC" is below
OPCItemPath: ns=1;s=[PLC]BufferTanks[0].Volume.ContainsProduct
I guess making sure tag names match exactly between the PLC and the OPC tag path is the tricky part. It seems like I could create my tag list on excel and import them in Ignition as an xml file.
"When using them in a template, I always split them into two properties that you pass into it: the folder path and the actual device name, and then combine these in an internal property to make the full path to the device. You can simply right click a tag and copy its path, which you can then paste into the template properties. And in splitting into the parent/name properties, you can select numerous templates and set their parent paths all at once, then all you need to do it type in their device names."
You did lost me a bit here, I quite didn't get it. When you talk about device name you're talking about the OPC device name or tag provider? The OPC device name can be part of the tag path? I didn't get it as well how you set the folder path of multiple template at once?
With what you've told me regarding UDTs since v8 I created an empty UDT type I use in my template as a parameter. I can then slide what ever UDT type tags on my template and in the template retrieve the tag path and then use indirect tag bindings from it. It leave me the option to drag tags to templates to link them instead of having to copy and paste the tag path and I guess avoid the issue of loading time of the UDT? Hopefully they won't decide to revert to how it was before v8 for UDTs.
Sorry, when I say DeviceName here, I mean the name of the equipment in the field, e.g. Motor 1.
This is one of my pump templates, showing its template parameters and internal custom properties. Note the DeviceName and DeviceParentPath, where these are combined together in the internal custom property 'DeviceTagPath':
To set multiple properties at once, you can just select the components you want and edit the common properties. If you select multiple of the same Template, then you can set the DeviceParentPath for all of them at once. Also, I've noticed that some people name the template parameters for the tag path according to the type of device, for example for a pump: 'PumpParentPath' or for a motor 'MotorParentPath'. I'd avoid doing this, as then you aren't able to use this multi-select method as the property names are no longer common between different Templates.
This method still leaves you with having to click on the binding to see exactly what UDT is bound to it, which I find a bit cumbersome and clunky. But I if that doesn't bother you, then it's of no concern.
Wow I didn’t know you could select multiple templates at the time and set their identical properties at the same time. That’s so good, it’s really handy ! Thanks.
Yes I did the same so far I named all my parameters exactly the same between templates to be consistent so that’s awesome.
Ok I understand so by splitting them you set the folder path to all of them at once and then just give them the device name one by one, that’s pretty good thanks. I’ll play with this a bit and see what is the most convenient and fastest.
So in your templates how do you use the tag path in expressions? I created internal properties with indirect bindings to then use it in expressions. Is there a better way?
I have an other question regarding OPC tags, Is there a way to have your OPC tag link ready and avoid having the red square around all the templates? It doesn’t make it easy to place your templates properly on the screen.
You can disable overlays in the designer from the view menu.
EDITED 5th June
One thing you can also do, when developing offline without a plc, is to convert all of your OPC tags to memory tags. It's not as time consuming nor scary as it sounds - it takes a few second. You can simply export all of your tags, or a handful to XML (you can do to json as well, but Im using 7.9 still at this stage), the do a find and replace of the term: type="OPC"
And replace it with: type="DB" THIS_TAG_IS_OPC=""` <-- this extra striked-through attribute is removed upon import so cannot be used as I thought
Then import it back over the top of your tags. All of the tags' OPC properties are kept intact, so you can simply convert them back as if nothing was changed - KEEP YOUR ORIGINAL XML EXPORT WITH OPC TAGS and use this to import back over the top. As memory tags however, you can now change their values for testing the display of your components. This works on Data Type (UDT) definitions as well. You can even make changes to the tags while they're memory tags, such as engineering ranges, tag name, move them, etc. and these will be reflected when you convert them back to OPC.
Note: the reason to add THIS_TAG_IS_OPC="" to the end in the replace is so that you can convert back only the tags that were OPC tags. If you leave this out and have used memory tags in your project, you won't know which tags should remain as memory tags!
Of course, never do this on a live system, as you will lose tag connections to the plc.
I don't know about v7.9 but on v8.0 I find out you can do it in the designer directly.
I putted all my OPC tags in an OPC folder, then I selected all the tags, click edit and change OPC type to Memory type and it does them all at once. When I revert it, it remember the OPC source and path !
That's amazing.
I tried the export way and somehow on v8.0 all my tags in a UDT would appear as "Atomic" types instead of OPC or Memory. I believe it's because I have nested UDTs, it might not drill down to the child UDT tags parameters?
For a simple OPC tag it does work properly otherwise.
