How to change Firmware on a 16 Axis Serco's Servo Module 1756-M16SE

Rob S.

Member
Join Date
Sep 2008
Location
Maryland
Posts
739
Good Evening ,

We have a number of Kinetix 6000 Servo drives ( fiber ) that fault out from time to time . I would like to change out the ControlLogix 16 Axis Serco's Module . The one that is in there is firmware 15.32 , but the replacement is firmware 15.37 , and it does not want to talk with ether the drives or the processor. How would I change the firmware on that card ? Also , the processor is ver. 16 . Would I change the firmware on the Serco's module to 16.0 ? With the new Serco's module , According to the plant electrician , the CP indicator is Flashing Red ( Looking for active nodes ) , Ring Status ( O ) Flashing Green ( The Ring , Drive , or Axis are not configured , but at least one has been identified ). The OK indicator is Flashing Green ( The module has passed internal diagnostics , but has not established communication)

Is this something you would ControlFlash for ? If so how would it be done ?

Thanks so much for your help.
 
I've not used a sercos module on a Control Logix system before, but I do know that on a 1768 Compact Logix system, when updating the CPU firmware I also had to update the SERCOS module firmware to the same major revision before communications would resume. And since the SERCOS module gets it's configuration from the CPU, if it couldn't talk to the CPU to get it's configuration, it couldn't talk to any of the drives.

This is not quite the same as your problem, obviously, because the old SERCOS card had a different major revision to the PLC as well, and still worked. But I'd definitely be squinting suspiciously at firmware incompatibilities. My first move would be to take backups of everything and flash both PLC and SERCOS up to the highest possible revision. They both use ControlFlash for firmware upgrades.
 
In general, you will want to run compatible versions of 1756-L55 or -L6x controller firmware and 1756-M16SE SERCOS motion module firmware, though it's not a "lock step" equivalency requirement or a narrow specific tested set like the Redundancy system.

I would use ControlFlash to put v16.023 firmware on the CPU and v16.002 firmware on the SERCOS module.

Both the 1756-L55 and 1756-L6x controllers had a stable firmware release at version 16.023. That's the one you want.
 
Thanks for the information. I just received this email from the plant concerning
the issue we are having

" Josette checked the alarm history and it shows all the servo motors faulted out individually at the exact same time. Josette was able to see that the drives were showing a E-38 fault. On both incidents it required the power to killed and brought back up to get the wrapper to reset and run. "

This is the random E38 Ring we have been getting . I was going to replace the fiber optic cables , but seems to be a deeper problem to fault all the drives out.

Thanks,
 
E38 faults on all the servos at the same time ? Almost definitely a damaged fiber-optic cable.

It can't hurt to upgrade your firmware to a nice stable release, but you're going to need to go after the fiber cables if you want a reliable system.

Note that you might not see in other places; when you upgrade motion modules, remove the CPU from the chassis. That keeps the CPU from interfering with the upgrade process by attempting to connect to the motion modules while they're rebooting between firmware chunks.
 
Note that you might not see in other places; when you upgrade motion modules, remove the CPU from the chassis. That keeps the CPU from interfering with the upgrade process by attempting to connect to the motion modules while they're rebooting between firmware chunks.

That's an interesting point. Would putting the processor in Program mode achieve the same end, or does it still try to connect in Program mode?

I only ask because while it's easy to do this with a Control Logix chassis, it's a bit tricker with a Compact Logix chassis like the one I mentioned before. Still doable, of course, but not just as easy as unplugging it from the chassis!
 
I'm sorry Ken and ASF. Can you rephrase this. I don't understand what you mean .

"Note that you might not see in other places; when you upgrade motion modules, remove the CPU from the chassis. That keeps the CPU from interfering with the upgrade process by attempting to connect to the motion modules while they're rebooting between firmware chunks."

Thanks again for your help ,
 
What Ken means (if I may take the liberty of assuming for a moment) is that your CPU is configured to look for, connect to and configure a SERCOS module. If you CPU is in the chassis and powered up, it'll do that continuously.

When you begin to flash the firmware to the SERCOS module, it will break the connection to the CPU. I'm not sure exactly how the CPU handles this, I should hope that the CPU gets some sort of message to say "I'm doing firmware now, stop trying to talk to me", and that it would do just that. But whether or not that happens, as part of the firmware upgrade, the SERCOS module will reboot at least once. When it reboots, the CPU will see it come back up and try to re-establish a connection to it. This could potentially interfere with the firmware upgrade process, as the module may need to re-boot several times during the procedure, and may not be finished updating when the CPU tries to connect to it and send over new configuration data.

As evidenced by the fact that I just recently performed a SERCOS module upgrade without removing the CPU, and it worked just fine, it's not a do-or-die requirement, but I can definitely see that it's a good idea to do it. Just like the way that when I'm flashing firmware on a CPU, I always remove it completely from the network so that no other PLC's, HMI's, drives, or anything else out there tries to butt in while I'm doing the upgrade and causes issues.
 
That's an excellent explanation.

"Modern" ControlLogix and motion modules probably don't have this problem, but I encountered it enough in the L1 and M02AE days that disabling the CPU's ability to connect with the motion modules (by removing it or by flashing it first and not reloading the user program) is my standard operating procedure.

A couple of years ago I had to replace all the fiber optic cables on a SERCOS based v16 system because somebody had ordered ones that were too long, so they coiled them up and mashed down the cabinet door until it latched. All the cables easily passed optical attenuation tests, but there must have been one or two of them that attenuated too much when they were bent.
 

Similar Topics

Friends, I have existing CNBR Series. E, Firm ware Rev: 11.002 running in a redundant system, now I received new CNBRE with F/W 11.005. As our...
Replies
1
Views
1,094
I have written a PLC program using RSLogix5000 v. 19.11. But the customer has now requested that I convert it to v. 17.01, which is the version...
Replies
12
Views
8,587
We had one go down. we have a new one. Their emergency Number don't work. The Model is TLSA046AAH-330N01-007 A catalog says we need software TET...
Replies
2
Views
136
“The HMI files we cannot open—they were saved in V13—we do not have that—I cannot restore file –please have them save in V11 and send them back to...
Replies
4
Views
135
Hi guys! I'm working in Studio 5000 and have a bunch of armorstarts there (+- 40). I need to set up parameters for each of them, mostly just same...
Replies
0
Views
75
Back
Top Bottom