This is definitely a quicker way to pull them into Ignition, as I only had to browse the device once. I still have to name each one, but I'm not sure how that could be avoided without scripting.
The problem with just browsing is that you're not using UDTs and can't bulk configure things like alarming or history on them, so while it may be faster initially to get the tags into Ignition, you're left with a mess of individual tags.
This is a great way though to create your datatypes as you can import one UDT structure by importing a folder of tags from the browse, then convert it to a data type and switch item paths over to use parameters.
1 Like
Your item path for OPC should look something similar to this:
ns=1;s=[{DeviceName}]{RootInstanceName}.{TagName}
So if you have a UDT tag the DeviceName parameter set to "PLC1" with the following tags:
- Motor1
- Motor2
And the UDT has these member tags:
- Start
- Stop
- Running
The UDT OPC items would automatically point to tags on PLC1 like:
- Motor1.Start
- Motor1.Stop
- Motor1.Running
- Motor2.Start
- Motor2.Stop
- Motor2.Running
And all you had to do to get it to work after setting up the UDT was to create those MotorX tags.
1 Like
Sure, I've got UDTS like this on the motors on the compressors in my Ammonia Engine Room, but for these e-stops that I'm currently slogging through, they are either 0 or 1 so its not really a ton of info on each one, just a lot of them.
Probably in July. The "polishing" is mostly auditing to make sure I prune anything covered by an NDA. Then some packaging and documentation for the Exchange. The client that sponsored this work is happy to have this published as long as it is clean.
The are super happy with how they can deploy a complete site's worth of tags and OPC devices (it does that, too) from a golden master (empty of tags) gateway backup that has a bunch of UDT definitions. From a single workbook. Tens of thousands of tags and UDT instances from a handful of sheets. 
9 Likes
You could also create one tag "normally", then export and duplicate in your favorite text editor, like Notepad ++. You can then import back in. This doesn't require much knowledge at all and will at least speed things up for you.
3 Likes
Before you get too far into it you should consider how many tags you're subbing. The AB Logix driver is built off AB's released OPC framework. It can be slow if you have lots of tags.
If you're working with a pretty large set of tags, look into the driver @pturmel wrote or the Linx Gateway as a remote server because it uses faster backend APIs that Rockwell doesn't release to the public.
Large is relative just as performance is relative. You also want to consider your tag count when you spec your gateway. If you have a lot of tags you should spec more CPU and memory. If you're doing a lot of visualization clients AND a lot of tags you might want to consider scale-out architecture.
There's a lot of things to consider. You can always pivot to a scale out architecture down the road but it's good to consider your expected tag count before you get too far down the road.
1 Like
Also consider using the JSON my alternate driver produces for Logix data types and tag instances for those data types. Not to use as-is, but to be the starting point for your own UDTs. (Pruning is much easier than adding.)
2 Likes
No, it is built on AB's released Data Access instruction manual.
My driver uses the released Data Access manual with reverse engineered knowledge about the stuff that manual says to not touch. IA has a policy against reverse engineering in-house. So my driver can do some things when optimizing that IA's driver cannot. Same situation for Omron NJ/NX, but Omron hides even more details.
5 Likes
@pturmel is an authority on this so take anything he says over anything I say about it. I've only gotten into this at a surface level and I'm aware of when it can be necessary to use a less "out of the box" solution.
I just wanted to mention it so the OP was aware of it so they don't have surprises down the road if they're working with a large amount of tags.
4 Likes
I think that's a good policy to have IMO... show's class.
I guess Rockwell has the same policy, as they don't do anything in-house. 
They just acquire other companies and rebrand. Optix, one of their latest acquisitions, is disturbingly terrible.
6 Likes
We just had a "lunch and learn" for our distributor to go over Optix with us. I went in with a 2+ page list of questions, to which I quickly realized this was a sales presentation, not a hands-on play and ask questions session. They had me email my questions, to which I finally got a response of them just saying "yes" to everything that I asked if it could do it with no link to say here's how. So I question whether it really can or not do most of what I asked.
3 Likes
raises hand as the client here and I am also thrilled to see this packaged up for the Exchange. Phil's re-work of our deployment tooling has been a game changer, allowing us to deploy a constant stream of client sites with large tag structures in the power/renewables space - often over 100,000 tags or tens of thousands of UDT instances.
Phil's script is unbelievably elegant in its flexibility - a simple spreadsheet-based template can have infinite layout possibilities and use virtually any system function to add devices, UDT instances, etc. It has iterator logic, regex, and more to allow you to process a massive custom deployment in a simple template and quick script function. You start with a blank gateway, and end seconds later with dozens of device connections and entire data structure. The single source file for it essentially becomes a version-controlled manifest.
Not shared and remaining proprietary will be all the work my team has done outside of Ignition to automate the build-out of the template itself based on some basic specifications, relationship mappings between different structures and systems in a plant, auto-generating of GeoJSON for dynamic mapping, and some other features in our pipeline. But once you have this base resource, its flexibility allows you to add onto it with whatever your workflow and setup require.
Also not shared - but hopefully demonstrated at Discover Gallery in 2025 - is the capability we're wrapping up which self-configures and auto-deploys an entire large site based solely on the tag structure created by this automation script and some other magic in our UDTs. Let me just say Phil's Integration Toolkit module is one of the pillars of this. And it is lightning fast.
On my Ignition team, we refer to all of this as the Philosophy. Well done, @pturmel.
13 Likes
4 Likes
I can only imagine the possibilities will expand exponentially when v8.3 is released since everything will be scriptable/automate-able at that point through a REST API.
4 Likes
I got a hands on in a demo environment. You can't lift the hood and manipulate things the way you can in Perspective.
You can embed and hue SVGs but you can't manipulate them after embedding them or use CSS. You can drag various elements onto the screen and bind them to stuff but you have a lot less control over the layout and the bindings are really basic.
It is not responsive as far as I saw. This is a BIG downside and I think they architected the downside into the foundation. I was told that they're planning to have it as good as FTView SE by the end of the year. It is not a competitor to Perspective. I don't think that it ever will be.
3 Likes
I don't think they're anywhere near that level yet, but at the same time FTView isn't anything that great. At the most right now, it can probably replace FTView ME, but that's the extent of it.
1 Like
If your python scripting isn't the best you could try the following, it not as quick as using a python script but will save you some time-
- Export your "PLC" tags into a spreadsheet - Most PLCs support this.
- Create an Instance of your UDT you want to use in Ignition.
- Export this with the Ignition Tag tool - probably easiest to work with XML format.
- Open the exported UDT instance with a good text editor (Notepad++ or something similar)
- For each of the tag instances you want to make you can copy and paste the UDT structure and then run a bulk search and replace to change the instance names so they match the exported tag - some text editors will allow you to automate this but then you might as well just bite the bullet and create a python script.
- Re-import the Tag with the added instances back into Ignition.
It's fiddly but will be a lot quicker than doing it from within Ignition or getting up to speed with Python and creating and Import tool. I usually knock up a python script and create an xml import file directly from the PLC spreadsheet - I find it quick and easy but I've been using python for a while and I have a few stock functions so it's much quicker but with a little trial and error you can use the copy and paste of the xml structures in an editor and still save yourself a lot of time. Just ensure you keep the xml structure intact and keep the outer most "Tag" structure intact i.e.
1 Like
We used to do something similar to this, python scripting inside Jupyter notebooks, to build out large tag structures. https://jupyter.org/
1 Like
@Jeff_Muldoon I don't see much code on this thread so I will offer a little.
In a nutshell:
-
gather the data you need together in one concise csv. To do that you need to have a rough grasp of how you want your tags to look, how you will need to use them, and what data is needed. This is also a chance to add in data that may not come in PLC tag exports such as asset names or acronyms. There is a wide variety of possibilities, so this is up to you how to build it. This sheet can be stored as a dataset in your project and combined with scripts can be a way to restore tags in an emergency.
-
Using
system.tag.configure, instantiate all needed instances by looping through the above-mentioned CSV.
Load The Metadata
def loadMetadata(savePath="[tagProvider]tagName"):
"""Loads a prepared CSV file and save as a dataset to a memory tag"""
import csv
path = system.file.openFile("csv")
csvData = csv.reader(open(path))
header = csvData.next()
dataset = system.dataset.toDataSet(header, list(csvData))
tag = {
"dataType": "DataSet",
"tagType": "AtomicTag",
"name": "metadata",
"valueSource": "memory",
"value": dataset
}
system.tag.configure(savePath, tag)
Use the metadata to create UDT instances
def buildMotors(metadataPath="[tagProvider]tagName/metadata"):
"""Scans the imported metadata and creates all motor folders and tags"""
metadata = system.tag.read(metadataPath).value
for row in range(0, metadata.getRowCount()):
if metadata.getValueAt(row, "Metadata") == "Motor":
if int(metadata.getValueAt(row, "BIT #")) == 0:
unitName = metadata.getValueAt(row, "UNIT NAME")
bits = motorBits(metadata, row, unitName)
prefix = metadata.getValueAt(row, "prefix")
unitName = unitName[4:]
unitName = unitName[:unitName.find('_')]
cabNum = metadata.getValueAt(row, "CABINET#")
address = metadata.getValueAt(row, "WORD").replace("%MW", "HR")
data = {
"tagType" : "UdtInstance",
"name" : prefix + unitName,
"typeId" : "Dematic/Conveyor",
"parameters" : {
"plcName" : "Dematic",
"cabName" : cabNum,
"opcItemPath" : "[dematic_master]" + address,
"hasBit100Full" : 1 if 6 in bits else 0,
"hasBit50Full" : 1 if 4 in bits else 0,
"hasBit75Full" : 1 if 5 in bits else 0,
"hasBitEStop" : 1 if 3 in bits else 0,
"hasBitEnabled" : 1 if 2 in bits else 0,
"hasBitEnergyMgmt" : 1 if 8 in bits else 0,
"hasBitJam" : 1 if 7 in bits else 0,
"hasBitMotorFault" : 1 if 1 in bits else 0,
"hasBitPalletPresent" : 1 if 9 in bits else 0,
"hasBitRunning" : 1 if 0 in bits else 0,
"prefix" : prefix
}
}
path = "[provider]vendor/" + cabNum + "/Motors/"
system.tag.configure(path, data)
Again, the key point is gathering all necessary metadata and then utilize system.tag.configure.
Cheers,
NIck
3 Likes