SLC503 convert to Control Logix System

[Sleepy Wombat 27]

Just looking at converting / supplying control panels with Control Logix plc system. Have been using SLC as it had been a standard system. New customer now wants to use control logix in stead of the SLC... Could some one please point me in the right direction as to where to start how to convert - easily... and any pit falls... The logic is pretty basic, using counters and timers, latching relays, flashing of lamps, controlling solenoids etc. Have the hard equiv sorted out... just looking at the simplest and quickest way to do the conversion... Happy to RTFM, just tell me which one. Thanks,

[Sleepy Wombat 27]

found the manual, now to RTFM... will keep updated if need further assistance... thanks..

[Ken Roach 194]

The FM in question is, I hope, the "Converting PLC-5 or SLC-500 Controller Logic to Logix 5550 Logic Reference Manual", http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1756-rm085_-en-p.pdf Make sure you have the Revision C (2011) instead of the Revision B (2011) of the manual. There's a Version 2 of the Conversion Utility that you should use if you choose to machine-translate.

[Sleepy Wombat 27]

Thanks for the heads up Ken, couple of glitches, the version of RS I have is version 13.03... and the manual that you ref is for version 19... i did notice a few differences... ie the Status File routine is not automatically generated in the ver 13 with the translation tool but it is with version 19.... in the program it does not ref any S bits so might be ok there.... the translation tool basically created an mcpMain and inserted a jump to sub routine... and the ladder was created as _2_LADDER.... so far looks allright... now as i understand it, i need to create the IO table so to speak, then map the real IO to the generated IO from import funtion... thx...

[BobLfoot 302]

Sleepy the biggest feature / gotcha is the difference in how the two platforms process Real World I/O. Once you understand that and allow for it in your program style all is well. What I mean will become clear I hope as I explain. The SLC had a fixed sequence of operations. It went something like this. Read Real World Inputs to the Data Table. Scan the Program start to finish updating the Data Table as you scan. Write the Real World Outputs from the Data Table to the Output Card. process the Comms Overhead and REPEAT. This means if an input is true at rung 2 it will be true at run 2000. The CLGX on the other hand has a more flexible sequence of operations. The program scanning CPU is scanning the logic of the continuous task from Top to Bottom with interruptions from Periodic Tasks The program scanning CPU reads from and writes to the Data Table, but not Real Wordl I/O. Simulataeous to this the I/O CPU is reading and writing between the real world I/O and the Data Tablce. This means that a Tag can be true in rung 2 and false in rung 3. This is why most programmers read real world I/O tags into internal tags at one point in the program so that "foot races" don't occur. Hope that helps rather than confuses. The CLGX is a sweet animal once you learn to play with it.

[Ken Moore 23]

Just my 2cents, but wouldn't the compact logix be a more reasonable (price wise) replacement?

[Sleepy Wombat 27]

Thanks for the clarification there Bob.. confirmed what I had been reading... Ken, yep compact logix was my orig choice... but they want to standardise on control logix... so that is what they are going to get and pay for.... thx all..

[PLCMentor.com 60]

I gotta say that I despise automated conversion programs. Usually leaves the poor maintenance guy with a mess to sort through. Not to mention I remember the slc to logix conversion converts the slc addresses to something similar in the logix. The user misses out on one of the wonderful things about the logix which is tag names that mean something. Seems that a client that is willing to pay the difference between a compact and control logix just to standardize may be willing to pay for the time to convert the program to a real logix program. Might be worth checking on as it would be better for both of you. Better program for them - more work for you (assuming thats a good thing).

[Ken Roach 194]

Tangentially related: I did the opposite process yesterday. I took a ladder logic routine written for a CompactLogix (v20) and copy-pasted all the rungs from RSLogix 5000 into RSLogix 500 version 8.4. I went to the first instance of each CompactLogix tag, clicked to highlight it, then typed in the replacement SLC-500 data table address. RSLogix 500 automatically applied the Tag Name that had been in that field as an RSLogix 500 Symbol. In turn, I'd highlight each Tag and hit Return, and it was converted into the Symbol everywhere in the program. Yes, I had to change a bunch of array tags, but this saved me a ton of time and probably multiple typographical errors. The gotcha was that when I attempted to enter a COP instruction to replace a GSV instruction (obviously RSLogix 500 didn't know what to do with it) it crashed RSLogix 500 with Visual Basic debugger warning. Since the GSV was the last instruction in the routine, and I hadn't saved.... this happened twice before I got it through my thick head to save, then delete the GSV and insert a COP. Obviously there's not a lot of call to migrate logic backwards to a 20-year-old SLC-500 operating system, but it's neat that the copy-paste format is similar enough that you can.

[Sleepy Wombat 27]

All my Tags/Symbols were easy to determine what they are, also the associated description/comment has always being included as well... So to be honest, in this case the poor maintenance guy / whatever should not be missing out on any thing... Tags should be succinct and not be like reading a sentence... ie would you use Solenoid Valve 1 or SV1 (or SolVlv_1) as a tag name... of a limit switch you could start with LL_.... or in the case of level switches HHL_Brk_Tnk, HL,LL ,LLL .. etc.... the programs i do are also rung commented extensively as well, also, i am a strong believer that the maintenance guy / plc programmer should have a grasp of the controlled process before even going near the controller code... and then if the maintenance guy still can;t work it out then, perhaps it is time to find another job..

[rswolff 9]

the engineering definition is that the I/O update is Asynchronous to the Program scan......and I would say from a programming standpoint that its fairly poor code if a changing I/O bit (at any point in the code) causes a 'foot race'......lots of stuff is not synchronous and coding should be compliant with that. If you need something to be scan dependent it should be coded in that fashion. If you don't, then the code should not be affected by that particular occurrence or condition. bob