Upgrading GuardLogix Processor

CLanford

Member
Join Date
May 2017
Location
Charlotte, NC
Posts
74
Hello,

I am looking into swapping a L83ES with a L84ES to get some more internal memory for recipe storage.

My local setup is as follows:
13 Slot chassis
Slot 0: L83ES - Primary Controller
Slot 1: L8SP - Safety Partner
Slot 2: L85E - Data Handler PLC
Slot 3, 4, 5 , 6 - EN3TR cards for tons of remote IO throughout the machine.
Other Slots - Dummy Cards
The safety IO is PointGuard located in multiple remote IO panels.

This thing is a monster (over 740k tags :eek: ). All I'm looking to do is swap out the Primary Controller L83ES with a L84ES. However, I'm not as familiar with the 1756 series of GuardLogix so I have a few questions.

Specifically I am concerned about the safety partner balking at the new PLC and what(if anything) needs to be done to make sure everything matches up and is happy. The current safety program is unlocked and there is no safety signature configured.

In the L8SP's module definition, I am seeing Exact Match electronic keying, but Connection: None.

In the L8SP's Module Info:

Configured: No
Owned: No
Module Identity: Match
Protection Mode: None

In Controller Properties, I am seeing Safety Network Numbers for the backplane and Ethernet. Again, no safety signature and the safety app is unlocked.

The machine is currently running no problem in this condition.

Is there anything specific I need to do regarding the safety side or anything else other than typical PLC swap things when changing this out? I am most concerned with the safety side (Copying over Safety Network Numbers, any config I need to update on the Safety Partner?) as I've changed out tons of non-safety-partner PLC's in the past but never a 1756 GuardLogix with Safety Partner. Thanks for any help or guidance you can provide!
 
Last edited:
There is nothing to worry about with regards to the safety partner. It will be updated when you download. It's not bound to your L83ES.

The only thing that I think could be a hang up is safety module ownership. It could be that you have to go through and reset ownership to any safety I/O modules. Not 100% sure though. I've done quite a bit of safety, just not this specific task. You don't really know until you've loaded the new controller and see if it is happy with the I/O modules. Or someone chimes in with this specific experience.
 
The only thing that I think could be a hang up is safety module ownership. It could be that you have to go through and reset ownership to any safety I/O modules. Not 100% sure though. I've done quite a bit of safety, just not this specific task. You don't really know until you've loaded the new controller and see if it is happy with the I/O modules. Or someone chimes in with this specific experience.

I hadn't thought about the individual module safety ownership. Thanks for the tip! All of the config ownerships are set to "Local", so I'm guessing if any of them don't like the new processor I'll reset ownership and hope for the best. Maybe I should copy the old ownership ID's just in case I have to revert back to the old processor.
 
I hadn't thought about the individual module safety ownership. Thanks for the tip! All of the config ownerships are set to "Local", so I'm guessing if any of them don't like the new processor I'll reset ownership and hope for the best. Maybe I should copy the old ownership ID's just in case I have to revert back to the old processor.

I'm not even 100% sure that it will complain about the ownership.

I don't think you would have any trouble going back to the old controller if things go sideways. You have a copy of what you need by the fact that you have a copy of the old program.

I look forward to an update on your experience, this is some good information to have.
 
I look forward to an update on your experience, this is some good information to have.

Oh it's gonna be fun. Included in the 204 ethernet nodes that are connected to this controller are the following safety peripherals and their respective things I'm also concerned about:

- PF527 CIP Safety VFD's - Time Sync tab configured to the controller. Doesn't appear to be changeable so I'm hoping resetting local ownership will sync this to the L84ES

- Fortress Ethernet Guard Doors using a generic Safety Ethernet Module - Each one has a safety network number with a manually configured setting

- 2198-H015-ERS2 Kinetix 5500 Safety Servo with CIP Safe Torque Off - Each one has Time-based Safety Network Numbers and Time Sync'd to the L83ES
- 2198-H070-ERS2 Kinetix - Same as above just different drive
- 2198-H008-ERS2 Kinetix - Same as above just different drive

I have a feeling I'm going to learn a lot. The plan is to make this happen next Saturday (4/30), so once I emerge from the depths of this line I'll provide an update on here with every issue I encounter and how I did (or didn't) resolve it.
 
Oh it's gonna be fun. Included in the 204 ethernet nodes that are connected to this controller are the following safety peripherals and their respective things I'm also concerned about:

- PF527 CIP Safety VFD's - Time Sync tab configured to the controller. Doesn't appear to be changeable so I'm hoping resetting local ownership will sync this to the L84ES

- Fortress Ethernet Guard Doors using a generic Safety Ethernet Module - Each one has a safety network number with a manually configured setting

- 2198-H015-ERS2 Kinetix 5500 Safety Servo with CIP Safe Torque Off - Each one has Time-based Safety Network Numbers and Time Sync'd to the L83ES
- 2198-H070-ERS2 Kinetix - Same as above just different drive
- 2198-H008-ERS2 Kinetix - Same as above just different drive

I have a feeling I'm going to learn a lot. The plan is to make this happen next Saturday (4/30), so once I emerge from the depths of this line I'll provide an update on here with every issue I encounter and how I did (or didn't) resolve it.

Holy tons of nodes batman!

Wish I had some spare hardware to test something like this out. I do have a GuardLogix on our shop floor, just not another one to see what would happen.
 
Holy tons of nodes batman!

This line scared the s*** out of me when I first got online with it. Here are the quick stats:

740k tags
204 Connected ethernet nodes (8 of which are other PLC's)
40 Vision cameras (Cognex, Keyence, IFM)
24 Non-Safety Servos
15 Safety Servos
14 Pick and Place assemblies
13 Fanuc Robots
1 controls engineer

I've done a lot of ControlLogix during my years in controls, but it's taken me the better part of 4 months to really wrap my head around this monstrosity. Never worked on anything that even approaches this level of complexity. So many things are also indirectly addressed within multiple nested UDT's and there are tons of AOI's, so it's really fun trying to track down things when you can't just directly cross reference. The "Find" function has been a life saver for me.
 
Last edited:
Update: So I completed the migration from the L83ES to the L84ES. Overall the migration went well, but a few things popped up during the new controller integration and I wanted to document it on here. I'll lay this all out by the issues I encountered in chronological order.

Issue 1) Installing firmware to controller: The original controller was running firmware version 31, so I wanted to match the L84ES with this same version. I've had plenty of firmware updates cause issues with peripheral devices, and considering I had 204 connected devices I wanted to match everything up. However, neither ControlFlash nor ControlFlash plus had firmware kits for version 31 for the L84ES.
I wound up using ControlFlash, but V31 for the L84ES is "officially" unavailable from Rockwell. Fortunately I was able to request the dmk from the compatibility center and the automatic system accepted my justification. Even after loading the dmk, controlflash did not recognize it. It turns out that firmware versions 30+ are lumped into the catalog number "GuardLogix 5580 Safety (1756-L8)" in ControlFlash, so you would need to select that instead of searching specifically for the L84ES to find the dmk file version you downloaded from the PCD center. The firmware flash went smoothly after that.

Issue 2) Only one type of ethernet node balked at the new controller. We use Fortress Interlocks Amgard Pro CIP Safety door locks to control access into and out of the robot cells. These were the only devices to refuse connection to the new controller. However, after power cycling each one, they reconnected and everything was golden.

Issue 3) Every Kinetix servo lost its home position upon controller swap. Every. Single. One o_O
I guess I should have expected this considering they're all running on incremental encoders. However, I never cycled power to them and had only powered down the one panel that had the PLC in it which was not connected to any of the remote panels with servos in them. I spent the majority of my day rehoming everything. In doing so, I even found out that several of them had never had any type of homing set sequence established by the OEM.
This is my only real question in all of this.
Previously I had downloaded an updated program to the original L83ES and tested everything before I swapped to the L84ES. The servos never lost their home when I did that, so it shouldn't have been related to the download unless somehow downloading to a totally separate PLC causes it to lose its home?

Any ideas here? I made sure to home out every machine and did a full upload of the existing program (including tag values), and then transitioned that program over to the L84ES and let Logix convert everything for me. That was the program I re-downloaded to the new controller after I had it set up. Is there a way to do this without losing home positions on all Kinetix drives?
 
None of these were real issues, just normal stuff. When you changed to a different/new processor, the PLC safety ID changed. All of the devices that were expected to talk to the old PLC with a different ID had to recognize the new PLC Safety ID. Pretty normal to lose Servo home when changing safety processors and to download a "new" program.
 
None of these were real issues, just normal stuff. When you changed to a different/new processor, the PLC safety ID changed. All of the devices that were expected to talk to the old PLC with a different ID had to recognize the new PLC Safety ID. Pretty normal to lose Servo home when changing safety processors and to download a "new" program.

Yea for the most part I agree, except only select safety devices had to be reset. There are 75 CIP safety devices connected to this controller(some of which are the servos in question), but only 13 Fortress interlocks had to be reset and only the AB servos lost their position.
There were other servos from Yaskawa and IAI that were also connected, but kept their positions and didn't need to have their homes set. I just thought it was odd that only the AB stuff did.
 
I don't know of any Yaskawa or IAI devices that support CIP Safety.

The Yaskawas and IAI's are not CIP Safety servos. But not all of the AB servos are CIP safety either, yet they all lost their home. So I just found it odd that only the Kinetix drives lost their homes, yet none of the other servos did. I think I worded that last post incorrectly to imply that all of the servos were CIP Safety.
 
Last edited:

Similar Topics

Hi, I am upgrading a Wonderware SCADA form version 9.5 to version 23. I am able to migrate all the graphic, but when to activate the runtime this...
Replies
8
Views
417
We are in the process of upgrading a controls system. The existing system is a SLC500 with some IO cards and a 1747-SDN module communicating to a...
Replies
5
Views
549
I am looking to upgrade some of our old Servo Drives to the newer kinetix 5700 style. currently we have 4 1394 axis that are all driven by 5kw...
Replies
1
Views
886
Hello, We are currently running a bunch of g310's connected to their SLC5 PLCs through ethernet. I've attempted to upgrade the program from 2.0...
Replies
1
Views
1,125
Hello everyone, My company has an old line for building DC motors. Many machines are from the early 90's and some requests for safety...
Replies
2
Views
1,156
Back
Top Bottom