So I’m importing tags from a controller (that someone previously designed an Indusoft web studio SCADA for), but am unable to get the tag descriptions for. I need the controller to remain compatible with the old software until we can do a test and switch over to ignition so am avoiding making any logic changes to the controller. It seems the previous integrator took all the data and moved it into arrays to assist with the data transfer performance over the network. In Studio 5000 each element in the array has a description indicating its use. In IWS the array is brought in on a data table which converts it back to individual tags with useful names.
My question: is there a way to bring these tags into ignition including the tag descriptions? My first thought, assuming you can’t, is I would have to use external references or go and create reference tags for each array element and type in the descriptions there. Hopefully there is some automated function to do this?
My first thought would be to export tags to CSV from Studio, then, in Ignition, write a script to automate the creation of one-tag-per-array element with its matching description.
Tag descriptions are not available as meta-data via Rockwell's EtherNet/IP data access implementation. In older versions of studio, they aren't even present in the PLC itself.
Which means an export from Studio and selective import to Ignition are required.
And here one of our big customers is working on replacing all L7x controllers with L8x controllers and is already planning on moving to the L9x series for new plants shortly after they come out.
Thanks. Had a feeling you would say that… One other thing is all the data is available in base tags so I can just bypass his implementation of the arrays and just browse to the base tags which all have proper names. IWS says in their documentation it’s a big issue for performance. Is ignition the same way or is ok to just pull the data this way. None of the IA trainings mention this at all.
Ignition’s array tag cannot be used to read in an array tag from a Logix processor. So, yes - you should create a base tag in Ignition for each element in the array in the PLC. However… there are substantial performance gains by reading data from an array or a UDT (optimization done automatically by the Ignition driver), provided each of the array tags has the same tag group configured.
You’ll need to decide (or provide a lot more information on) how much optimization is needed for your project.
ok so I did a fair bit of reading this article last night as part of my research. I think I will just bring in what I need from the arrays to avoid having to deal with this in the future when the project starts getting bigger and performance actually starts to matter. I guess my last question on this subject is what is your recommendation for re-abstracting the data. What comes to mind is using reference tags that rename each element, or Using UDTs. or anything better?
There are many of my recommendations mixed into that article. The fundamental performance optimization is to try to consolidate information that needs to be monitored together into large single tags (UDTs) or arrays of numeric types, or combinations thereof. This lets external data consumers to ask for the entire tag as a block of bytes. This is then parsed into its pieces inside Ignition, greatly unburdening the class 3 message processor in the PLC. Reading hundreds of bytes at a time is dramatically more efficient than reading 2, 4, or 8 bytes at a time.
Ignition (both the native driver and my alternate) optimize automatically all tags requested at the same group pace and having the same PLC top-level tag (controller or program).
Under no circumstances should an external data consumer ever point at alias tags, nor should a PLC ever have solo atomic numeric tags. These are utterly unoptimizable.
(Single UDTs should aim to be no larger than the connection buffer size, less 12 bytes. So, 488 bytes on older processors, or 3988 bytes on newer processors.)
One thing to keep in mind also is that the arrays in the PLC don't need to be read into an array tag in Ignition. Phil's driver can do it, but the native Ignition driver can't. What matters is that if you're using a bunch of Ignition UDTs and each one only references a single element out of the array of tags, at some point (I don't remember the breakpoint of how many out of the whole array need to be read at the same pace), the driver will read them all at once with a single request vs individual requests even if they're being read by different tags in Ignition.
That’s because Rockwell created an overlap between an old series of hardware and its’ next generation. The old original CompactLogix for example is supported up to version 20, while the 5370 series hardware that came after it is supported down to version 20. So there was a lot of standardization on version 20 because you could drop in those “new” (at the time) 5370 series processors without even having to change the program version. The consequence of that now, of course, is that all these factories have this positively ancient software/firmware combo that is barely even compatible with modern operating systems, but they refuse to upgrade because $$.
Then of course the weirdness with 20.01 and 20.03 came about, but that’s a different story.
Luckily, they acknowledged their mistake with version incompatibility and released 20.04+.
Another off-topic note - I still maintain a MS-DOS VM with PCIS for a client that is still running a SLC-100… that thing might outlive me. Which reminds me, I’ve been digging into my tote of serial cables & adapters much less frequently. I rarely bring them with me anymore. I’m okay with this.
Same…between Yaskawa and AB, I had a cable menagerie in my bag, which invariably got me stopped at security before the newer 3D imaging. Now, a couple of gender changers and a null modem switching cable is all I carry with my catx patch cables.
Same for me. It’s been over a year since I’ve even laid eyes on a SLC (mostly because 90% of my workload has been Ignition ) Probably a decade since I’ve seen a PLC-5. I know they’re out there, but I think a lot of it is just the old hardware is outliving the companies that bought them. The companies shut down, the attached equipment gets liquidated, sits out in the elements, gets damaged, batteries die, programs get lost, etc. The equipment that does manage to get purchased comes in in a state where a controls update is a necessary part of the renovations. Open the panel door, see a PLC-5 with a dead battery and a lost program, call around, find out nobody is looking to do that work cheap, if at all, so it’s to the point of upgrade-or-bust. And that’s even if the old equipment is worth saving. A lot of times, a company is going to opt to buy something new because there will often be considerably higher yields, better quality, etc. anyway.
) Probably a decade since I’ve seen a PLC-5. I know they’re out there, but I think a lot of it is just the old hardware is outliving the companies that bought them. The companies shut down, the attached equipment gets liquidated, sits out in the elements, gets damaged, batteries die, programs get lost, etc. The equipment that does manage to get purchased comes in in a state where a controls update is a necessary part of the renovations. Open the panel door, see a PLC-5 with a dead battery and a lost program, call around, find out nobody is looking to do that work cheap, if at all, so it’s to the point of upgrade-or-bust. And that’s even if the old equipment is worth saving. A lot of times, a company is going to opt to buy something new because there will often be considerably higher yields, better quality, etc. anyway.