CLX to IA "tag path conversion" code available?

I am writing a routine to import thousands of alarm tag messages from Wonderware CSV exports into ignition tags that were dragged and dropped into an ignition gateway tag structure. Most of the code is done for one specific scenario, but I have a bit of "semi-hard-coded" manual tagname build logic therein to match the WW tag item (the plc tag location) to the corresponding ignition tag,

I can build the path programmatically, but I am basically replicating a portion of the code that IA uses when I do the drag and drop.
Is the tagname conversion portion of that code available so I don't have to replicate it and possibly leave something out?

e.g.
CLX controller tag...
Alarms.Cur.Lance[1].Mot.PosSwConflict

Ignition tag...
< 1st part of path irrelevant to this discussion>/Global/Alarms/Cur/Lance/Lance_1_/Mot/PosSwConflict

Global = Controller level tag
1st instance of "Lance" due to being an array of UDTs
2nd instance "Lance_1_" is one of the UDTs in the array

I think you can use com.inductiveautomation.ignition.common.TagPathUtils.sanitizeName.

All it does is replace a bunch of "problematic" characters with underscores.

Thank you Kevin. I'll check it out.

Nope. I'm sure there is a function somewhere that builds an ignition tag path to a ControlLogix OPC tag.

If I use the OPC Browser to drop the CLX controller tag...

Alarms.Cur.Lance[1].Mot.PosSwConflict

.. into an Ignition tag for a given provider, the following tag path gets constructed (ignoring the 1st part of path )...

.../Alarms/Cur/Lance/Lance_1_/Mot/PosSwConflict

Notice that an extra "/Lance" was added because it knew about the UDT array.

I think you'll have to better explain what you're talking about. The behavior you describe doesn't make sense. If you browsed to that PosSwConflict tag and dropped it into the tag browser you would get one tag named "PosSwConflict".

I'm sorry. The "tag path conversion" actually happens at the OPC browser level.
Here's what the tags look like in the PLC...

And here's what they look like in the OPC browser...

They look the same, but...

Wonderware resolves the tag path as ...
Alarms.Cur.Lance[1].Mot.PosSwConflict

Ignition resolves the path as ...
Global/Alarms/Cur/Lance/Lance_1_/Mot/PosSwConflict

Ignition prepends "Global/" (no problem)
Ignition changes the brackets to underscores (no problem)
Ignition adds the extra "Lance/" item in the path (that's my problem)

There isn't a direct conversion from OPC to tag path, the "Tag Path" you see there is just a concatenation of each level with the sanitization function above applied to it.

The difference you see between Logix/Studio5000 and the OPC Browser is just a quirk of how the legacy ControlLogix driver structures its tags. There's nothing you can do to change that, and if you dragged and dropped some root folder into the Ignition Tag Browser then the tag structure is going to mimic that. This is how it works when you drag and drop any folder/object from any OPC server.

I haven't yet used wireshark to look at the traffic, but it appears that the 2 drivers get to the same tag slightly differently. That makes it difficult to construct the ignition path using the path extracted from the WW .CSV.

When I extract the path and alarm info from the WW .CSV, I have to find the corresponding tag in ignition in order to apply the alarm information. I can do it, but I must simply know to ...

itemNameConv = alarm_tag_item_name
itemNameConv = itemNameConv.replace(".", "/")  # No problem
itemNameConv = itemNameConv.replace("[", "_") # No problem
itemNameConv = itemNameConv.replace("]", "_") # No problem
itemNameConv = itemNameConv.replace("/Lance_", "/Lance/Lance_") # Just have to know to do it.

Yes, that's pretty much what you're dealing with here. There's no function responsible for this, you just have to know that the legacy ControlLogix driver has an extra tag level when dealing with arrays. If all your tags were created with a big drag and drop from the root then that level is going to be there in your tag structure.

Thank you Kevin.

If this is a legacy driver issue (embedding the extra node in the path), then it sounds like if the controller is updated to a model with newer firmware, and the "modern" CLX driver is used instead of the Legacy CLX driver, that code will break.

If all your tags were created with a big drag and drop from the root then that level is going to be there in your tag structure.

Wait. I think I need a clarification. We only selected a subset of the PLC tags to drop into the ignition tag structure, the Alarms being one of those that we chose.
It doesn't seem like the addressing would change as long as the driver didn't change whether I dropped the entire PLC, or just a portion of the PLC or created the tags manually. Is that correct?

You seem to be confusing Ignition tag naming and folder structures with the Ignition driver representation of OPC Item Paths. They only correspond where drag and drop is used, and it is highly discouraged to drag and drop whole folder trees. Simply because drivers (and other OPC servers) are not necessarily consistent with how they expose a target PLC's names.

Changing from a legacy driver to a modern driver will break your OPC Item Paths where already established. Whoever did the drag and drop in the first place did you a disservice. Ignition tag and tag folder names should be structured for maximum window/template/page/view parameterization, regardless of PLC naming.

Thank you for your response.
Virtually every tag in the controllers are based on UDTs in the PLC, including the Alarms. We need all of the alarms at the HMI so we need to create that tag structure in ignition. What would be superior to drag and drop for creating the alarm tag structure in ignition?

I would create Ignition UDTs that substantially replicated the PLC UDTs. Selectively instantiate just the parts of the tag hierarchy you need.

(I would autogenerate the Ignition UDTs with my alternate EtherNet/IP driver--the resulting Ignition UDTs would be compatible with IA's v21+ driver, too.)

It is worth noting, too, that both the v21+ driver and my alternate driver use OPC Item Paths that are the Studio5000 names with just the namespace and bracketed Ignition device name as a prefix.

This in the PLC

Alarms.Cur.Lance[1].Mot.PosSwConflict

Becomes either of these OPC Item Paths in an Ignition tag, no matter what Ignition-side tag name or folder is used:

[someDevice]Alarms.Cur.Lance[1].Mot.PosSwConflict
ns=1;s=[someDevice]Alarms.Cur.Lance[1].Mot.PosSwConflict

Thank you. Where can I find out more about and/or test your alternate EtherNet/IP driver?

Most of the information you would want is here:

The documentation is here:

https://www.automation-pros.com/enip1/UserManual.pdf

Thank you. I'll check it out.