I am totally new to converting .rss to .acd files for upgrading a plc. I was wonding if it was totally out of line to ask someone on this forum for help? I was tought rslogix500 in collage back in '2000. I have never had to use it since. Everything I've used in the real world has been Studio5000. Not sure how well the conversion tool actually works or if its even worth it. Plus, I don't have rslogix500. I only have the .rss file and the .pdf print out. I do have Studio5000 vn.36

If someone was willing to help me out, this might be enough information for me to figure out how to do it manually in the future. If so, what information would I need to provide?

Thx

 

I've seen the results of the conversion tool in the past and wasn't super impressed. One of the biggest upgrades I've done was from a PLC5 (very similar software to SLC5/x) to ControlLogix. That system had previously been controlled by a PLC2 and upgraded to a PLC5, so there were a lot of relics from bygone eras. Here's my process:
1) Print out the existing code (you have it in pdf, so that's easy) and hand it to someone who knows the system well so they can mark it up and cross off stuff that's gone and/or not used. I knew of a few things that had been removed, but the expert identified several more that ended up simplifying things for me.
2) Transcribe code manually, taking the time to reorganize it in a way that makes more sense (almost certainly a useful step, unless you're starting with that rare unicorn program). The old PLC5 program had subroutines, but not many and the code wasn't subdivided in the best way. I took the opportunity to improve that.
2a) If the original program used symbols for everything, use those as your initial tag names.
2b) If the original program did not use symbols for everything (or used them some but not completely), devise a system for converting memory addresses to tagnames. For instance, I had N7:23 become N007023. B3:7/5 became B00300705. This was a little cumbersome at first, but it worked well for me. Choose a standard and do it every time. When you initially create the tag, give it a good description that you can later use as its final tag name. I did it this way so I wouldn't have to try to maintain a cross reference and keep referring to it. This way, the code could be completely transcribed quickly and cleanly.
3) Once transcribed, go through and rename your tags with meaningful names. This can be done directly in the tag database if you have good descriptions.

Except for waiting for my colleague to review the code, this whole process took a few days at most. There was a lot of code, but I was already used to typing in rung mnemonics. I tried to copy-paste at first and it worked, but it was actually faster for me to type it in straight than to copy-paste and then replace the addresses. Your results may vary.

We were removing some PLC5 racks entirely (for machine functions that were gone) but most of the rest were replaced rack-for-rack and module-for-module so the IO addressing was pretty easy to sort out. If you can't do that, then I would just do the transcription as above, with your tags that refer to IO points being Ixxxyy, Oxxxyy, or whatever so they're easy to find in the tag database. Then you can rename and either map or alias them (I would far prefer map but did aliasing on that project).

 

The file didn't have an extension, so I added .rss and it did open. This program is fairly straightforward. It's a SLC 5/04 which means it would have used DH+ for communication to any remote HMI or SCADA. There are no MSG instructions.

I'm in the camp of re-write it from scratch unless there are compelling reasons to avoid that.

With that said, you may also get good results by using the conversion tool, then going back and editing tags and code to better suit the new platform.

RSLogix 500 now has the conversion capability built in, so I did that, and picked the default compactlogix L330 CPU version 31 and 5069 modules offered by the tool.

I didn't spend any time looking at the (attached) results.

One thing the conversion tool does, that I always change right out of the gate, is create a continuous task containing a single routine with one Event for the original main task. I normally blow that away and make the original main routine a periodic one, and set a period reasonably similar to the old controller.

There will also likely be lots of conversion errors. Since the SLC used analog modules it probably had a bunch of rungs to set up their configuration that won't be necessary in the new CPU. You should be able to just delete those and properly set up the new I/O modules to match the hardware, and edit the scaling as needed to match. Note that if the SLC had SCP blocks, they'll now be CPT instructions. That is another thing I usually replace with an Add-On instruction to get back the readability of the SCP like the SLC had.

You should be able to open this version 31 file in your newer version (unzip it first, then try to open it).

 

I also suggest not to use the transfer utility. Unless it's a HUGE SLC program it will be better to rewrite it line by line in Studio.

At that time you will also think of better, newer, easier ways of doing what was in the SLC.

Plus for every timer call the conversion utility will require that you open the file and go through every call changing the compare of the timer ACC or PRE as the timer will be changed to a ms timer and all the compares will still be for 0.01 or 1.0s timers that you will have to change in every use (GRT,GEQ,LEQ,LES,EQU,NEQ,MOV,MUL,DIV and other instructions.

Then there's the really odd way the transfer utility will change B3:0/0 to a B array that is difficult to follow, integers and floats the same.

 

wow! thanks everyone for your input.