Sign in to follow this  
Followers 0
wildswing

Moving two PLC5 projects into one CLX processor

16 posts in this topic

Hey fellas, I'm aware of the hurdles when migrating a PLC5 project into a ControlLogix processor. How would one go about merging two PLC5 projects into one CLX processor? Is that possible? I have a system that being upgraded by the oem. The upgrade includes changing one of the 5s to a CLX. There is, however, another 5 that runs other related equipment from the same oem. A question has come up asking if they could put both PLC5 projects into the one CLX. If it's possible what happenes to duplicate addressing? I'm just checking with you guys before relaying the Q to the oem. FYI...the first 5 (being converted) was a 5/40L but we changed it to a 5/60L because its memory was full. The other is a 5/40L C with 31.5k words used and 17.5k words free.

Share this post


Link to post
Share on other sites
I have never tried to do what you want and I will be interested in the responses, but I do from experience that you can put 2 CLX CPU's on the same rack.

Share this post


Link to post
Share on other sites
Hmmm. I never thought of that option. I just got off the phone with AB tech support and they said there's no automated way to do it. Both projects would have to be converted separately, then the second merged into the first manually. Sounds like a ton of work.

Share this post


Link to post
Share on other sites
If there is no Analog in your PLC 5's then I'd recommend using ControlNet. You can build a CLGX 4 or 7 slot rack and a CNB card to talk to the PLC I/O. The 1771-ACN15 replaces the PLC 5. What is neat is your OEM can test his softeare on weekends or whenver you're down and if it doesn't pass muster. Drop the PLC 5 back in for another week. Convert each PLC 5 program to either it's own task or it's own program in CLGX and the tags of one will not overlap the other. I've ehard of 5 PLC 5's run on one 1756-L63. Good Luck and post more questions. BTW if you have Analog in your PLC 5 use the 1756-DHRIO card at 230.K and the 1771-ASB adapter. Procedure is same as controlnet just you'll need a 1756-DHRIO for each PLC5 you replace where controlnet will probably only need on CNB.

Share this post


Link to post
Share on other sites
Thanks Bob. FYI neither of the 5s have RIO. It's all local extended IO. The proposed upgrade will use ControlNet and replace all of the exended IO adapters with CNet adapters. Question...why do you recommend using DH+ over Cnet if there's analog involved? Both the 5s in question have a couple of 12 bit analog input and output cards in their local processor racks. The oem has done a number of these upgrades with CNet successfully. Our local Rockwell tech guys also suggested CNet to replace the extended local IO if and when we ever decided to go to CLX. Edited by wildswing

Share this post


Link to post
Share on other sites
Check with AB tech support certain flavors of 1771 analog do not play nice with ControlNet. Time slice and resolution issues. We got burned by this on a big project, but it was so long ago I can't tell you which ones. If all your analog is restricted to one rack you might want to use CNET for all but that rack and use RIO for it. Just finished a 2 PLC 5 to once CLGX conversion and did that very thing about 6 months ago. About the merge. It is not a much headache as you might think once you learn to merge L5K plain text version rather than trying to do it in the windows graphic environment. I actually wrote a complete program using excel and then imported it into RSLogix. KEWL. Edited by BobLfoot

Share this post


Link to post
Share on other sites
Wildswing, As long as you put the I/O for the two PLC5s on two separate networks, you won't have any issues with duplicate I/O addresses. I'd recommend two CNB modules in the CLX processor rack, one for each system. Two programs in the CLX will contain the two PLC5 progams. If you have any STIs, they go into periodic tasks. It's not that big a task. You can work outside the RSLogix5000 environment like Bob suggested (I've done it and it can be very helpful). But you can convert both programs, add a prefix to the tags in each program to identify both systems, and eliminate any possibility of tag duplication. The ability to cut and paste of the entire contents of a program file make the merge pretty easy. I still think you should redo the tag names after conversion, but that's a documentation and support issue more than a functional one. If there was a reason for using L type (extended local) processors in the first place, I'd be very careful about using RIO. Good luck,

Share this post


Link to post
Share on other sites
Just figured I would add my post

Share this post


Link to post
Share on other sites
My experience with converting processors is that it's almost always better to just start over... The CLX is soooo much better than the 5 was ever designed to be. So many better methods of programming, plus our own personal programming skills have evolved over the years. If you just convert the program, you'll be converting any existing "issues" that may have never been exactly right, plus introducing a whole new set of issues. If you start over, you can possibly improve productivity and maintainability.

Share this post


Link to post
Share on other sites
We did exactly what you are asking about 2 years ago. A PLC5/15 and PLC5/25 running similar processes in an automotive paint shop. We mounted a Control Logix Rack with a 1756-L61 processor an ENBT card and a pair of DHRIO modules for the separate RIO paths. Both processors were running similar but not identical processes. I/O addresses were mapped with SYS1_* and SYS2_* as preceding characters for the tags. Heavy on the Analog I/O as well. We had 32 separate stand alone process controllers between the two original PLC5's and we brought all of the input and output signals into the PLC to take advantage of PIDE function blocks. All of the original I/O remained in place (some of it dating back to when the 5/15 was a PLC3) and we added flex I/O blocks to handle the addition analog signals. We are controlling oven temps, air house temps and humidity and some level controls for liquid filled tanks. This was all done with version 13. The only thing I would do over is the addressing of the real I/O. Our integrator aliased all of the real I/O tags and then used a COP function to new tags that retained the Octal addressing scheme. This was fine for making the addresses similar to what it was before but eliminated the ability to force an input or output in the ladder. Back tracking through the COP and alias function to get to the original controller tags is a pain. I did make it a little easier by showing my guys how to find tags that can be forced and then doing some extensive labling of the tags to show what they were in the original drawings. We were also using a Cimplicity HMI project to talk to both of the PLC5's and it was converted rather painlessly as well. We had about 2K tags in the HMI and maybe 20 screens.

Share this post


Link to post
Share on other sites
The biggest word of warning that I've gotten from AB is to watch out for bandwidth issues on RIO, especially with analog cards. Above 10-12 cards, there are apparently some bandwidth/speed issues. They also recommend cutting back to 56Kbps for similar reasons. I haven't done a conversion yet. The first one is coming in August. Both existing PLC 5/40E's have essentially no local I/O. The remote I/O for one is 31 nodes, all old 1791 cards. The other is about 8 cards, again all 1791. Just in case, we planned on 2 DHRIO cards which gives us a total of 4 ports to play with. So if bandwidth becomes a problem, we can just split the RIO busses down.

Share this post


Link to post
Share on other sites
Paul if you have the budget replace the CPU's and ASB's with 1771-ACN modules and go controlnet. You won't regret the extra bandwidth and funtionality CNET gives over RIO.

Share this post


Link to post
Share on other sites
What mellis is warning you about is the significant difference in I/O update time between extended local I/O and RIO - especially if you have block-transfer modules in the extended local racks. Each 1771-ASB adapter will only service one block transfer per I/O scan. I/O scan time depends on the number of adapters on the channel and the amount of data being transferred. A chassis with several BTX modules will have significant degradation in update time when switching from extended local to RIO.

Share this post


Link to post
Share on other sites
1791 is block I/O - no adapters to replace. You definitely should split the I/O between the 4 available channels. The DHRIO spec says you can have 32 adapters per channel, but even at 230K the I/O scan would be a minimum of 96 msec.

Share this post


Link to post
Share on other sites
I did a conversion plc5 to clx and used the DHrio cards in the clx rack to control the plc5 rio I am not sure if this was a clx v16 feature but be aware of this setup of 1756-DHRIO card if using dh+ on channel a, if channel b is RIO then the baud rate can only be set to 57kbaud if only using rio then use only channel a, then RIO baud rate can be set for 57 or 213kbaud rate

Share this post


Link to post
Share on other sites
No point in doing so. There's essentially no local IO. This is a cupola melt shop so the IO consists of small clusters of sensors and outputs all over the place strung out over about 1500 feet of RIO cabling. We're just going to stick a remote chassis right about where the PLC-5 chasses are (they are all in one room!), move the RIO lines over to DHRIO cards, and remove the entire 1771 rack. One PLC contains a single resolver card (upgrade to 1756...no more chassis needed). The other contains about 80 IO's, all push buttons and lights, that are more or less defunct anyways. We have no intention of keeping this system because it won't work with the new process configuration. There are 7 local IO's. These are more easily moved directly onto a digital IO card in the local chassis. The third chassis has 6 analog ins, 6 digital ins, no outputs (it was for monitoring only), and turns out to be less expensive to switch to Flex IO than putting a full chassis in it's place. The 4th one has about 25 total IO's in the local chassis. This is the only chassis where it makes sense. But again, it just so happens that all the PLC's are in one room together and I already need a local chassis there for the DHRIO cards and the resolver card, so a couple more IO cards in the local chassis is significantly less expensive (and much nicer) than trying to finangle ASB modules and such.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0