I Made my first UDT. It is an OPC-browsed Definition. It inherits elements from a CompactLogix group of tags. Some elements work, some display the message: Error_Configuration("Bad_NodeIdUnknown: The node id refers to a node that does not exist in the server address space.")
If I use the Tag Editor and swap node number from 1 to 0, click Apply, THEN change node back to 1, click OK, the error goes away for that instance. The OPC item paths differ only by the tag at the end of the path, and the said tags are all correct.
Upon inspecting the UDT structure in notepad, I found a difference in notation. Despite the "Bad Tag" moniker I labeled, that "EnableOut" is actually one of the few that are working. Most failerd tags are the same syntax.
If I export the tag, there is a difference in the .json: Preformatted text
//BAD TAG
{
"name": "EnableOut",
"tagType": "AtomicTag"
},
//GOOD TAG {
"opcItemPath": {
"bindType": "parameter",
"binding": "ns\u003d1;s\u003d[MCP]P{MotorNum}_VSD.Alm_FailToStart"
},
What step am I missing? I would like to create a UDT for a "thing", Motor in this example, and be able to do Tag History and Alarms on each motor. Is this the right way? (Very first post)!
When you create an instance of your UDT, expand the tags with the error and look at the OPC Item Path. Most likely it's invalid. I have seen once where this was a valid string, but it wasn't passed to the OPC client properly. This only happened if I had my parameter left blank in the UDT definition, so now I always put something in there as a default, otherwise it uses NULL and it causes problems randomly.
This is where I was led by the error message. Briefly modifying the path to something incorrect, saving, then going back to correct, saving... fixes it.
In the above path, If I modify a character, then save, then modify back, then save, my issue is corrected. My JSON will show different syntax. I am happy.
What I am concerned about, is I now have to do this weird step to every tag that mysteriously "needs the fix" when I create the UDT. I am unsure what I am doing wrong during creation is what bugs me!
It looks to me like you entered in the text directly rather than clicking the binding icon (link) and entering it there. If you enter it in the text box without using the binding icon, it enters it as static text and not a bound property.
Are you creating this binding in the UDT or on individual instances?
I thought I could get away with exporting, find/replace, then importing. I didn't like that I have to go to each tag, edit, paste the bound property. Caused myself a headache
So are you getting it figured out? A simplified approach I like to take is like this (modified from your example):
ns=1;s=[{DeviceName}]P{MotorNum}_VSD.{Tagname}
As long as you name your UDT member tags the same as the PLC tag, you can copy/paste that tag over and over and only modify the name, data type, etc and the OPC item path binding is the same between them all.
One other thing to note is that it looks like you're using PlantPAx. If that's so, then you'll also need to modify your AOIs by exporting all of them to L5X, then doing a search/replace for:
ExternalAccess="None"
with
ExternalAccess="Read Only"
Then re-import and overwrite the AOIs. (Do this with all your AOIs actually even if not PlantPAx).
Then you'll need to buy the Ethernet/IP Class 3 Generic Client driver from @pturmel. Set all of your tags to read at the fastest rate you want (like 1000ms) - Don't break them up with leased tags or different tag groups running at different rates. (This sounds counter-intuitive, but trust me on this).
If you don't use Phil's driver, then you're going to only want to read the bare minimum required, and you will want to use leased tags for anything on faceplates, and read all strings at 60,000ms or slower to help with communication load on the PLC.
How do I know this....I'm currently in the process of helping a customer who was handed a PlantPAx programmed PLC with Ignition running at a whopping 8-second update rate for tags. With optimization of tag groups, I was able to get the HMI updating at a 2-second rate, but the PLC Class 3 comms were still maxed out at 100%. Switching to Phil's driver and setting everything to update at 1 second direct (no leasing/driven tags) and all 70k+ tags are reading at 1.1-1.2 seconds consistently. Our client instantly wanted to buy the driver for all of their plants, and I literally just bought it.
Understood, and yes, it's PlantPAX and there are way too many tags. Yes, I was given the ignition task, on top of other integrators using PVP and Weintek HMI's...
The sheer PAX tag volume is precisely why (among obvious re-usability reasons) I am creating these UDT tag groups.
Unfortunately, I have zero control of the code, so I cannot do an AOI "anything".
Can I eliminate tags from the browser when I'm done with my development to speed things up, or is there anything I can do to not put such a load on my lone PC?
Michael, this is my very first Ignition rodeo. I'm glad I attended the class last year, because the workbook and online content got me very far to where I have a respectable HMI with trends and alarms that email recipients. Things are going well, and I love what I'm able to accomplish so far.
Ask whoever is responsible for the PLC code to look at these forum resources. (And perhaps the application notes in my alternate driver's user manual.)
These modifications don't affect the functionality of the logic in any way, but only makes it so that communications can be optimized to the tags in the PLC. If there's absolutely no way anyone will change these or allow them to be changed, then you're going to be stuck breaking down comms into multiple tag groups and eliminating any tags you don't really need anywhere.
Depending on the size of the project, if you're talking to a lot of tags, the speed will be noticeably slow and that's where you'll have to put your foot down and tell them what needs to be done to make it faster.
You can do this, but it's not quite so straight forward. If you type the opcitempath in the tag editor instead so that it works properly and then export the json of that UDT definition and look at the tag, you'll see why a simple find replace doesn't work. The designer converts' "opcItemPath" : "{test}" ' into' "binding": {...} '
I use a python script to run over my find replaced tag json and make the necessary replacements of assignments to static strings that contain {} to wrap them in a binding
I will ask the devs to update their AOI's, if necessary.
I do have the ability to read the code, and thank goodness, there are only 20 custom AOI's.
I exported one of the AOI's and the External Access Output fields were all "Read Only" While the Input fields were all "Read/Write". Nothing was set to "None". I'll go through the rest.
Does this issue also affect the pre-built Rockwell Data types?
As long as the field is not set to "None", I am OK?
One last thing, to take a load off the controller, may I delete or disable (that would be better but I don't see where) tags from the OPC tree?
I can always add them back individually if I need them?
But only if you use Phil's EtherNet IP driver module. IA's Logix driver will not optimise this regardless of AOI parameter external access settings, as these methods are not publicly documented. Phil spent the time reverse-engineering the protocol to allow this
The Rockwell AOIs are the ones that cause the most problems because they are so big and have lots of tags set to None for external access. On all of my custom AOIs, I have everything that doesn't need write access set to ReadOnly so that if I am using Phil's driver that it can be optimized. What I have done in mine though is I've put all of my AOI tags that I need from the HMI into a single UDT that can be read optimally using the Ignition built-in driver because it's treated as a single tag.
What I've done in the past for these built-in ones like an entire IO card is to just replicate the built-in UDT in my own UDT and then just do a COP to replicate that data into my own nice clean UDT. I don't really use the built-in ones anymore, but you do have to be careful with them as they'll have members like a Status that then below it has all the individual bits. What you have to do to replicate this is to only use the Status INT/DINT as the other bits are only broken out for display purposes and not actually separate bits in the UDT. (You can do this yourself by manipulating a UDT and renaming the hidden members to something useful and changing them to not be hidden, but once you do that, the UDT is no longer editable via Studio 5000 like standard UDTs).
Yes, highly recommended. If an AOI uses I/O types, this should be done inside the AOI, too. (Those usually use a COP or CPS to populate the AOI data.)
My driver's probe results in the JSON types document the precise placement of everything, so you make the UDT exactly match the original type's bit layout.
I am working with my customer now to determine what level of effort by their programmer is do-able at this point.
For now, the PLC network seems to run fine, though Ignition shows an "alarmingly high" tag count, using up a lot of memory.
Anyway, I have about a week to finish to the 90% level, so I may be asking a few other questions on the forum, but for the most part, everything is intuitive to me, I love it.
Thanks for the deep-dive with PlantPAX issues, I'm looking into the driver cost and relaying that to my customer.
