I'm currently in the process of adding 100s of tags into Ignition, and I'd be lying if I said it wasn't a little tedious. I've created a UDT for the ones that are the same, but ultimately creating a new instance for a tag and then manually navigating to the device and selecting the tag just seems like it takes more time than it should. I've looked at multi-instance wizard but it doesn't seem quite what I need as many of these tags aren't necessarily in order.
Is there some feature that I'm missing or is this just the way it must be?
Yikes. Thats what I was afraid of. My scripting knowledge is so minimal it might as well be non-existent. Ignition is part of my role, but isn't my primary job function, so looks like I'm behind the 8 ball on this.
Appreciate the quick response. Like I said, Ignition is only a portion of my role and I've been using it for less than 6 months, so lots to learn still.
I guess I'll look into some Python learning resources then.
If you haven't done so already, I'd start by checking out the Scripting In Ignition section of Inductive University. This will cover both the version of Jython we use in Ignition, but also some of the specifics of working in the Ignition environment.
Other sources can be great for learning more about Python (or coding in general), but remember that those sources will be geared towards C-Python, and probably Python 3, which are not the versions used in Ignition.
Thanks I'll go through that part of IU again now that I'm more familiar with Ignition.
Is there another source for learning that would be appropriate for learning Python as used in Ignition? I'd like to learn, but would like to optimize my time.
Can't wait to see this tool Phil! I've created a couple myself for internal use that aren't very polished, but get the job done. The problem I have is that I have customers who provide spreadsheets of I/O in various styles and formats, so it's been hard to make a one-size-fits-all script dynamic enough to handle everything.
I'm working through PLCs created by our OEMs and everyone programmed them completely differently, so I'm in a situation in which I need to find the tags in the PLC program, then go into Ignition and add them one by one.
One of my current tasks is bringing in all of the E-stops in all of our machines so that I can monitor them and alarm when pressed, so every single program has a bunch that then needed to be added in. Its not necessarily hard work, just tedious.
If the thing you're creating tags for supports tag browsing you can drag/drop tags from the OPC Browser into the Tag Browser. Just don't sub a bunch of tags you aren't using or you will create headaches for yourself.
You can access this from the designer "View/Panels/OPC Browser".
They are mostly Allen-Bradley Logix drivers. As it is, I'm creating the tag then scrolling through all of my devices and into its tag structure in the OPC Item Path. I'll definitely look into your method.
IMO time spent to understand the tag creation/editing/deletion scripting is time well spent. I use this everyday and has made life much easier and faster.
You say you're using UDTs, but are you using parameters on those UDTs or are you manually setting the item path on each tag inside the UDT. If you're not using parameters, you're missing the efficiency of using UDTs.
I think I am, but for example, I'm adding these e-stops and really they are just Integers, so I set up that portion of it, but then I'm just looking at its state and alarming it so that when pressed it sends out an alert as we have an issue with people using e-stops as stop buttons which is causing an issue with some of our machines and can cause unsafe conditions that we'd like to avoid if its not actually an emergency. I do have others for compressors that have a bunch of the same parameters.
I agree. In any situation where you have a common structure on a lot of things you should be using UDT definitions and creating instances of the UDT instead of tags. Basically, if you have a UDT in the PLC you should be able to make an Ignition UDT that maps to the relevant pieces of the PLC UDT. Then you can create the tags you care about by simply creating UDT instances and mapping them to PLC UDTs through a parameter.
I feel like it's most efficient to have your UDTs indirectly bind as many of the UDT properties (tags) as possible. If you have a couple of oddball devices that take the same data points but get them from different tags you can always override that tag on the UDT instance to point to a different place.
Also, paths to tags within UDT work the same way as tags in folders so your templates designed for a UDT will also work for folders of tags that have the same names of tags within the folder.