Allen-Bradley PLC upgrade

I just learned that six of the Allen-Bradley PLCs on my system are being upgraded from an older firmware to v32. Is it possible to modify the existing connections to use the new Allen-Bradley Logix driver instead of the Legacy Allen-Bradley ControlLogix driver?

Failing that, is it possible to rename the old device connections and make new ones with the same name but the new driver? Or do I need to modify all of my existing tags to use new connections?

You can delete or rename the old ones and then make new ones with the correct name.

Unfortunately if you’re going from the legacy ControlLogix/CompactLogix driver to the newer Logix driver you’re going to find the OPC Item Path syntax is a little different.

I was afraid of something like this.

Is it a fairly simple difference that I could take care of with a regex replacement in an export?

Hmm, maybe. I do think that an export, modify, import is the approach a lot of people take to fix it but I don’t know if it’s as simple as a regex.

Basically what changed is that instead of having all the pointless duplication in the item paths that the legacy driver has the paths now look pretty much the same as they do in Studio 5000.

So if the current OPC Item Path is

[avlProleit 1]Global.DiTSystemData.ClassObjects.C573.C573[66].sStatus.sActualValue

I would have to change it to

[avlProleit 1]Global.DiTSystemData.ClassObjects.C573[66].sStatus.sActualValue

As long as it’s only the repeating name of the arrays, I think that shouldn’t be too difficult.

Thanks!

The Global. is implicit in the new driver (so no prefix for controller scope tags) and tags from programs will have a Program:Foo. prefix.

Okay, so the example above would change to

[avlProleit 1]DiTSystemData.ClassObjects.C573[66].sStatus.sActualValue

And existing path of

[avlProleit 2]_003_CIP_Loop_3.P_UTTankLoops

would change to

[avlProleit 2]Program:_003_CIP_Loop_3.P_UTTankLoops

Is that about it?

Yeah I think that’s about it, assuming “_003_CIP_Loop_3” is the name of a program.

Oh, there’s one more weird thing about Bool arrays… this one wasn’t intentional, just something we screwed up and couldn’t fix without breaking backwards compatibility…

Bool arrays are modeled how they exist in the controller: as an array of one or more DINTs. I think you can browse underneath each DINT in the array to get 32 bools, but because of this addressing tags from a BOOL array is annoying and complicated :frowning:

Oof. I’m having a hard time picturing it, so I might have to hold off until the new firmware’s in place to see how the path looks with the new driver.

Yeah I think that’s about it, assuming “_003_CIP_Loop_3” is the name of a program.

Is there a third option, besides Global and a program? How else would you address a path that’s at the same level as Global in the current browser?

No 3rd option, tags are either controller scope (global) or program scope.

1 Like

Thanks for the quick response, Kevin. This would have been (more of) a nightmare to wade into blindly when everything stopped working tomorrow afternoon!

If you can get a copy of the PLC code in L5X format, you can load it into my Ethernet/IP module. My module will expose the tags to Ignition with an address format compatible (well, 99%) with the Logix driver. Which you can play with offline to prepare for your upgrade. See this topic:

Suitable for trial mode–won’t cost you a thing.

1 Like

Unfortunately this was sprung on me at the last minute, and I was not able to get the PLC code. But I did come up with a trio of sed calls which I was able to run on exports to get the affected PLCs into the correct state.

sed '/avlProleit [2-5]/{/Global/!s/\(\[avlProleit [2-5]\]\)/\1Program:/g}' originalInternalTags.xml | sed '/avlProleit [2-5]/s/\(\<\S*\>\)\.\<\1\>/\1/g' | sed '/avlProleit [2-5]/s/\(\[avlProleit [2-5]\]\)Global\./\1/g' > newInternalTags.xml

The first sed added the “Program:” prefix to all of the tags for the PLC, except for the global control tags.
The second sed found all the OPC Item Paths with duplicates, like folder.arrrayFolder.arrayFolder[23], and removed the duplicate and the separating .
The last sed just strips out the Global. from the control tags of the four PLCs.

I haven’t found any problems with Bools yet, so fingers crossed!

1 Like

The new firmware doesn’t use Global. in the item path, you just need to remove this. In my udt definitions, I include a parameter called “Global.” which I add into the OPCitempath binding. Then in the instances if it’s below fw 20.19? where you need it, I set the “Global.” parameter to exactly that, “Global.”. Otherwise I leave it blank for fw 21 and above. Of course it doesn’t solve the double array name issue, but I don’t tend to use this very often anyway

So, since I just saw this thread, is there an Ignition change coming that will discontinue the Legacy Driver?
Also, what functional change is seen or experienced from the Legacy driver to the newest Allen-Bradley Logix driver?

No, it will pretty much always be there in its current state.

Aside from what’s already been discussed the only other functional difference is the overall performance of this new tag access provided by Rockwell is worse.

And though the new driver will work with both older and newer firmware versions, it’s much worse when used with older (20.x and prior) versions.

As in the Newest Allen Bradley Driver is worse in performance?
I have 3 fw V32 machines that are on the legacy driver and it doesn’t give me any issues. I have other machines with fw V29 and 30. All are on Legacy and i don’t have any issues. So I don’t see the need for me updating. Just wanted to make sure I wasn’t going to have to change all my machines and paths to the data.

Sorry but I find this hard to believe. The legacy driver does not work with firmware v21+. It will browse but any attempt to read results in an error at the protocol level.

The new driver connecting to any v21+ PLC will generally perform worse than the legacy driver connected to a v16-v20.11. The new L8x with a dedicated CPU for comms do alright though. The performance loss isn’t a limitation of the driver, it’s the device and new protocol.