SCL 500 to Compactlogix

[ALCARA_PLC]

Hi everyone,

I am new to this amazing world of PLC, well... I mean, in practice, since I already knew electronics, programming languages, IT, and some other stuff related. But, just like learning a new spoken language, it's not the same having the theory than applying it to the real practice.

I am currently working at a facility with a lot of old and obsolete equipment, and thank God everything is from Rockwell. My target is to upgrade all these control devices in order to standardize hardware and software.

My old equipment has SCL5/04 or 5/05 controllers and I am looking to replace them for Compaclogix, due to this looks to match what I need.

I already got some documents from Rockwell site, but sometime the information on them are either not clear or incomplete.

Following the recommendations of a former mentor, that used to say all the time 'R.T.F.M.', I won't ask for specific help of how to do something, but I will greatly appreciate your help on sharing some documentation or websites to take a read to it. Any advice is well received as well.

Well... Hope I can become a provider on this site and not only a requestor, one day.

 

[Robb B]

My advice would be if the old equipment is working, do not replace it yet. Make a plan, but you shouldn't replace things "just because" they are old.

 

[joseph_e2]

I agree with Robb B. Have a plan, even start getting some hardware on hand to practice with and to be ready (lead times are better than they were but some components are still pretty rough), but don't take it down until you need a new feature or something big breaks. Do you guys already have a license for RSLogix 500? If so, you can probably keep those running for a very long time to come. The SLC500 is/was a pretty solid platform.


Definitely get the AB manuals and such, but it'll be very helpful to get the hardware and set it up on your desk so you can figure out the differences between the 500 and 5000 platforms. A few other ideas:

1. Find the "product selection toolbox" software from AB. It's free and includes a tool called "Integrated Architecture Builder". That tool will help you when it comes time to figuring out terminal blocks, power supplies, end caps, etc.
2. I would avoid the software conversion tools that translate the SLC to Compact/ControlLogix. Once you get your head around the differences between tag-based and address-based coding, you won't (probably) want all of your new tags to be arrays called "N7" and "B3" like the addresses from the SLC world. I did a conversion of a medium to large system from PLC5 (very similar to 500) with 5 racks of IO to ControlLogix. Having folks familiar with the line help me identify defunct code let me trim out a bunch of code and simplify the rest. Transcription from old to new took a few days with not much debug time needed and left us with meaningful tags instead of address arrays.
3. If presented with the option to use a "wiring adapter" kit that lets you keep the existing field wiring and adapt it to new IO...don't. The ones we looked at had the old wiring arms behind the new chassis, which would leave you with some inaccessible wiring terminations, which makes troubleshooting a bear.
4. It can be a valid intermediate step to replace the SLC processor with an Ethernet module that turns the field IO into a slave rack off of a Compact/ControlLogix CPU. That gives you a quick retreat if something goes wrong (just pop the original CPU back in the rack). One downside is that, in my experience, the most common SLC failures are the power supply and IO modules, not the CPU. You're getting a new platform but leaving the most likely failures in place. It's cleaner to replace the IO at the same time. You also have to be very careful to document clearly how the old IO comes into the new PLC to make troubleshooting easier in the future.

 

[JesperMP]

I am in the other camp.
Make a plan to migrate to a newer platform and implement the plan in a timely manner.
Don't wait until the last minute when 'something big breaks'
You can plan and implement the migration in such a way that downtime is minimized or avoided entirely.

 

[Ken Moore]

I agree with JesperMP. I have worked on many sites, where they upgraded "X" amount per year, in a planned logical way. Some times oldest first, sometimes most critical first. Then the old pulled parts are retained as spares until all systems are upgraded, then dispose of them.

I also recommend re-writing the programs, instead of using migration tools, you want to, take advantage of the new platform. Otherwise, you are just replacing your horse and wagon, with a truck to pull your wagon.

 

[joseph_e2]

I agree with JesperMP. I have worked on many sites, where they upgraded "X" amount per year, in a planned logical way. Some times oldest first, sometimes most critical first. Then the old pulled parts are retained as spares until all systems are upgraded, then dispose of them.

I guess I've never worked in a place where that was really an option. The best I've seen is to have the replacement system on the shelf and ready ahead of time for when catastrophe strikes. We could never seem to find a production window for the install until the machine finally died. That would be a preferred system, though.

I also recommend re-writing the programs, instead of using migration tools, you want to, take advantage of the new platform. Otherwise, you are just replacing your horse and wagon, with a truck to pull your wagon.

I'll definitely have to remember and reuse that one

 

[I_Automation]

One thing you will encounter, and I don't like so much that I stopped using their migrate tool, is tag convention trying to replicate the SLC data files.

N7:0 to :255 becomes an array N and using () and [] without getting them crossed is just weird and problematic.

Unless it's a huge project I just open RSL500 and S5K each on 2 monitors next to each other and type in rung by rung using a better tag name convention, arrays where needed, change DINTs to REALs where needed, etc.

Also at this time I usually think of improvements and safety issues with the older program that might not meet current safety standards, even new IO that should be added, sensor upgrades from analog mA to DeviceNet or Ethernet.


But I'm not saying don't do it. I would take one control at a time and get a program and parts list completed so if it is needed you have 80% of the work done already.


Plus if you no longer work there and are out on your own when they call to have it done you just saved $3,000 in engineering work if you still have the folder.

 

[Robobob]

One thing I would suggest is to download Integrated Architecture Builder from the AB website.
https://www.rockwellautomation.com/...guration/integrated-architecture-builder.html
IAB is a suite of tools for developing Rockwell control systems. You can build your system out in the software. The tool will check your hardware and network configurations and provide a complete BOM of the project. It will also have links to most of the documentation you will need. I have found IAB invaluable over the years.