SLC vs ControlLogix

rsdoran

Lifetime Supporting Member
Join Date
Apr 2002
Location
Birmingham, AL
Posts
7,371
This isnt meant to be a debate issue. We have a flexographic press that was designed using ABB proconti plc's that actuall use C programming for most of the machine control, there is a very small IL program that can be viewed but overall the programming is beyond using to troubleshoot by me or most maintenance personnel, even the OEM service tech.

The company has looked at doing modifications using AB plc's, the original OEM only made 2 of these machines with ABB and the rest with AB SLC 500.

For maintenance and troubleshooting needs I would prefer something besides ABB and the use of C programming. I am familiar with AB SLC ladder programming.

The machine may be upgraded soon using either AB SLC or ControlLogix. Is there a major difference or learning curve between the 2?

Being familiar with the SLC 500 would it be more prudent to recommend it for the reason of familiarity and cost?
 
Since you already have 2 with a SLC, I'd just stick with a SLC on the upgrade.

Although, it might be nice to have a ControlLogix to fool around (er.. I mean LEARN) with!... ;)

beerchug

-Eric
 
If you stick with SLC, your learning curve will be zero and if you're getting the OEM to do the retrofit then their recurring engineering effort is much lower.

Unless you think that a faster controller will improve the operation of the press, this doesn't sound like a particularly good opportunity to do a Logix refit.

But then, I agree with Eric..... :D
 
The machine may be upgraded soon using either AB SLC or ControlLogix. Is there a major difference or learning curve between the 2?
Short answer - yes. But far less than the difference between ladder and 'C'. The ladder programmming is very similar - it's the addressing that's really different. No more T4, N7, F8, etc. Instead of programming timer T4:23 and (perhaps) assigning a symbol name to it, you simply program timer 'delay_stereo_roll_in' (for example), without having to worry about where in PLC memory it will actually end up or having to create space for it.

No doubt you've read or heard of horror stories from some early adopters of ControlLogix, but getting into it now is not so painful. The major gripe was having to update PLC firmware in order to use new versions of RSLogix with no backward (or forward) compatibility. Since version 10 it's become more user-friendly.

Being familiar with the SLC 500 would it be more prudent to recommend it for the reason of familiarity and cost?
Obviously, the ControlLogix hardware will be more expensive. And RSLogix 5000 is more expensive than RSLogix 500 (which you no doubt already have anyway). As for prudence - this is probably a low risk application for learning. By that I mean nothing too complex - I don't mean to presume anything about the commercial implications. If there's a likelihood of future projects using ControlLogix, then it's probably advisable to get your feet wet as soon as possible.
 
If someone else, OEM, does the initial configuration and programming of the controllogix, the learning curve from SLC will be short. Logix 5000 software looks and acts much the way a SLC does, as far as viewing and troubleshooting is concerned.

The main difference between the two systems that I see, as far as initial programming goes, is that the controllogix has no structured or "canned" data file system. That is, all data files have to be created and defined by the programmer (he may "invent" his own data type, even). There are specific methods to doing this that save processor memory that are not at all apparent. Such as, if you create one bit address, the processor allots a 32 bit word--for one bit. The other way is to create a double word data type, then use the 32 bits (double/0 thru double/31) in the program as bits. The memory usage is the same in both cases.

But again, if the OEM does the up front stuff, the thing is like a SLC to troubleshoot, as far as ladders go.

Then there is the control block language. This is an evolution of the Reliance Automax block language and used for drive type functions (PI, lead, lag, pulse multipliers, etc). IF you use the help screens, this is easy to learn and understand.

There are also motion coontrol blocks--I have no experience with these, but I guess they could be understood as easily as the other control blocks.

We have a controllogix coordinated drive system configured and written by the rockwell field modernization group. I have had no trouble discovering what I want to know about how things work there--but starting from scratch would be another thing. The learning curve would be much greater.

Another thing about controllogix is rockwell software's "version" fiasco. Newer software won't work with older processor firmware. If you upgrade software, you have to flash the firmware, where possible, or replace the processor. It's a big mess.

If we were to get another controllogis system, we would have to specify revision 8 (our existing system revision). Or flash our existing revision 8 to the newer version. Or run 2 versions of the Logix 5000 software for the two processors. What a mess.

You know what can happen when you try to run software written for older versions of things on newer versions of the same things--sometimes some things don't act the same. It's better to leave well enough alone. I wouldn't dare flash our rev 8 to the latest unless the guy who wrote the code was standing directly to my left--ready to fix the new "bugs".

The revision thing alone is enough to make me go to the SLC. We could have done the drive upgrade with SLC. 95% of the fancy drive algorithms are done in the drives anyhow--not controllogix. We did it because that's what rockwell reccommended. The only advantage of the controllogix that I see is the speed of the controlnet. We could have found a way around that, I guess. Maybe ethernet--who knows. If I had it to do again, I'd go SLC.

Well, that's more than I planned to say, but I hope it helps.
 
Caught in the middle

I am not sure I am qualified to do what is being asked of me but I am giving it my best shot.

Because of the issues and problems this machine has had since I became employed at this company when/if the upgrade is done I wont have time with learning anything new so I think the best bet is stick with SLC, if possible.

The system has 10 ABB 40 I/O brick style plcs(Proconti CS31 , Master, Slave and 1 for each deck. There are approximately 30(I havent counted exactly) Remote I/O (12 binary or 8 analog), which means at least 300 remote I/O. There is also 8 communications plc's beside the deck units to communicate with the Bergher Lahr stepper drives, 6 motors per deck with rack mount control unit that communicates via ASCII (I think). The plc's are using a network called ArcNet. The main drive is a Eurotherm 620 Vector Drive (http://www.eurotherm.ie/drives/guideac.htm
which I am not sure how it communicates or if it does (more I have to know), their are 5 more DC drives(Eurotherm 590), chill roll, rewind(x2), and unwind(x2) that do communicate with each other, the chill roll provides the speed reference for the unwind and rewind but an encoder is on the drum/main drive to provide a reference (again I think).

The CNC/HMI computer is using Wonderware (with some form of a C program) to provide setpoints and parameters for the automation part of the decks action..registartion, print position etc. The Eurotherm and ABB software runs in the background of windows to be used with the HMI. This is a big area where I get lost, that and the fact that I can not monitor I/O in any fashion except lights on the units or remote units. The stepper motor encoders are positioned in a way I can not connect a scope to watch them so it would be nice if I could monitor them in some way via the plc or drive system (another thing I will have to find out).

Here are my thoughts, this system was designed to be fully automated. This doesnt work at this plant ( I know it should), thats another issue that I have no control over nor is likely to change.

I was thinking of using an SLC5/04 Master system in the deck cabinet that would work with the deck drive systems, a large portion (maybe 20 units) are located in the Main/drive cabinet. I was looking at using maybe Flex I/O, possibly on DeviceNet (I am kind of familiar with this), with more remote I/O blocks at the other remote locations and the control console. Or would it be more prudent to use a PLC system in each cabinet and just a few remote I/O? Would there be a cost factor that make using remote I/O a better solution? I was looking at using the plc in the main/drive cabinet for communications with the drives (maybe this would allow faster processing? As it is now everything is terribly slow to respond after initiating an action). The deck unit has 2 handheld manual controllers that allows manual control of the deck movements (the operators use this now to actually set the print instead of using the automatic positioning). I think this would be prefered overall because of past issues. I was hoping to use a Panelview to turn on/off decks when not needed. To replace plates one side of the plate holder has to move away with rest at home, as it is now if any deck isnt HOME then it wont extract/move away properly, for that matter if not at HOME nothing will work. I was hoping to eliminate this issue, if a deck failed to work it could be removed from the sequence regardless of position. Also use the Panelview to create Home position and print off position set points, so it could be taken almost to print or back home in an automatic process. I would also like to monitor things like encoder and I/O via the Panelview. Naturally have alarms. Would it be more prudent to stay with a HMI/SCADA software package like Wonderware or Fix DMACS for process/variable settings? The way the machine is now it uses the same settings all the time, the operators just choose what decks they want to use. Its partially a personal preference but I would like to do away with the computer and HMI software, I may find its needed but at this point I dont.

I know I tend to ramble on. Does any of this sound viable, like I am at least looking in the right direction? I had AB, local distributor and an integrator in today to look at it. The integrator was pushing Controllogix but I cant afford the learning curve time that may be needed once its back online, I may change my mind on this before its over with though.

Alot of this tells me the areas I need to study more and organizes some of this in my head (and on paper).

Any thoughts or opinions on this will be highly appreciated.
 
An afterthought

This system is now using brick style plc's so maybe I could look at using MicroLogix1500 with Compact I/O, the only issue I am not sure about is communication with the drives. More to learn. This may require the HMI software.
 
Re: Caught in the middle

rsdoran said:

There is also 8 communications plc's beside the deck units to communicate with the Bergher Lahr stepper drives, 6 motors per deck with rack mount control unit that communicates via ASCII (I think). The plc's are using a network called ArcNet. The main drive is a Eurotherm 620 Vector Drive (http://www.eurotherm.ie/drives/guideac.htm
which I am not sure how it communicates or if it does (more I have to know), their are 5 more DC drives(Eurotherm 590), chill roll, rewind(x2), and unwind(x2) that do communicate with each other, the chill roll provides the speed reference for the unwind and rewind but an encoder is on the drum/main drive to provide a reference (again I think).

How do you interface the SLC or any other PLC to all of this? I think this is the MOST important question. ArcNet is just a data link layer and there is no common application layer in use so chances that the ArcNet can talk to another companies ArcNet card is slim.
The C and IL were probably there for speed. Will the SLC be fast enough? Is this a speed critical application?
 
Hi rsdoran
I work at a plastic film manufacturing plant we have upgraded several winders to Control-Logix with good success. We have made extensive use of the motion instructions which save a great deal of code. I do agree with some of the other posts that the version issues before V10 were a pain in the A**. Since Version 10 there is forward and backward compatibility. It seems to me that you have quite a few coordinated drives and communication. I think that properly configured a C-Logix system would be better than a SLC. My reasoning is that the C-Logix is a lot easier to set up communication its backplane runs on control buss which is basically Control-Net. I think you would find setting up Control-Net or Device-Net to be fairly painless. You can also configure a Ether-Net module and tie it into the plant network (I have done this setting up a C-Logix gateway). I am able to access our network from home via a VPN client and trouble shoot machines the are at the plant which is only a mile away but also the machines in our WI plant that is a couple of thousand miles away!
I hope some of my rambling helps if you have specific questions drop me a line.
Rich
 
OK, now ya got me R-E-A-L-L-Y confused Ron... :confused:

WHO will be doing the retrofit?!?! You? The OEM? Another integrator?

If it's not you, then, aside from getting your approval on what PLC to use (SLC or ControlLogix), THEY should be the ones worrying about the local vs. remote I/O, etc. issues, no? It's always nice if they get your opinions before continuing, but it would scare me if they're relying on the customer to lay out the system for them... :eek:

You said the OEM is using SLCs on their new equipment. Do these perform well?

In the end, I think as long as you remove all traces of ABB stuff, you'll be a happy camper!... ;)

beerchug

-Eric
 
How do you interface the SLC or any other PLC to all of this? I think this is the MOST important question. ArcNet is just a data link layer and there is no common application layer in use so chances that the ArcNet can talk to another companies ArcNet card is slim.

I want to remove the ABB units entirely, they use ARCNET, there arent any ArcNet cards. The comm units are used to communicate with the Bergher Lahr drives with ASCII from what I can see in the manuals. This is part of what I have to learn about, exactly how the plc's communicate with associated drive cards. I believe its just an RS232 or RS422/485 connection.

The PLC units also connect to the remote units via bus system, another aspect I need to understand but I think is along the lines of RIO or DeviceNet type connections, basically 2 wire.

The C and IL were probably there for speed. Will the SLC be fast enough? Is this a speed critical application?

I dont think speed was the issue as much as they were going for precision and possibly the programmer was more into high level programming. Overall the press runs around 600 feet per minute on average, I am not sure what top speed is but I know it cant match the gravure units. As is, response for most actions initiated seem to take forever. Push start then speed increase, it takes what seems forever. The worse part is working with the stepper drives in manual, push a button and it never seems to move so you push it again then it goes too far. The way things are now I am hoping to make the process faster in response...ie closer to real time response.

Appreciate the response Peter.
 
WHO will be doing the retrofit?!?! You? The OEM? Another integrator?

NOT ME, this is way over my head, I wouldnt have time to do this either.
If it's not you, then, aside from getting your approval on what PLC to use (SLC or ControlLogix), THEY should be the ones worrying about the local vs. remote I/O, etc. issues, no? It's always nice if they get your opinions before continuing, but it would scare me if they're relying on the customer to lay out the system for them

The integrator did scare me/us in a sense so I was asked (by the engineering dept, which has no EE) to look into directions to be taken. I may be going overboard but I have to understand the system so I am looking at cost vs performance vs familiarity. This is probably another waste of time but I have to do what is asked of me.
You said the OEM is using SLCs on their new equipment. Do these perform well?
I have no idea, never seen one, thats the problem. I think it may be more of the same just using AB. The system is too proprietary and difficult to troubleshoot. The quote they gave us doesnt offer much detail and they upped their price about the time I got them to allocate it in the new budget.
In the end, I think as long as you remove all traces of ABB stuff, you'll be a happy camper!...
You could never know how happy.
 
OK, the fog is slowly clearing... Thanks for the clarification!

The first thing I would do is see if the OEM is interested in performing the upgrade. They (should!) know the machine the best. If they are interested, go see their new SLC equipped units and make your own judgement. Hopefully they've improved over time and you'll wind up with a new version of the machine (that actually WORKS!)... :cool:

If this is ruled out. Start REALLY looking at you integrator!!! Lots of integrators say "Sure, we can do that" just to get the job, then worry about actually DOING it after they get the deposit... :rolleyes:

You know enough about the machine to be the one asking THEM questions on how THEY plan to accomplish different aspects of the process. I realize it's still quite early in the project, but it seems like you plan on using this integrator. They should be able to spell out the general approach they plan on taking.

As an OEM and and integrator, I would love to have someone knowledgeable like you ask me about these things. A lot of times it brings up issues that may have been overlooked! It's never a bad thing to continually confirm you're on the "same page" as the customer!... :D

beerchug

-Eric
 
Well it sounds like this job is a lot more complex than the impression I got from your initial post. My concern, now, would be whether a SLC would have the capacity (I/O and program) to handle the job.

I would recommend RIO over DNet for FLex I/O because, in my opinion, DNet just adds an unnecessary layer of complexity requiring additional programming and mapping, not to mention RSNetworx s/w. The I/O capacity ceiling may well be lower with RIO though.

Using DNet is less of a hassle with ControLogix, but if you go with CLX you have the option to use ethernet for the Flex I/O (UTP or fibre). This option configures much the same as RIO - no mapping or RSNetworx required. And of course, its faster. And, if you add a wireless access point and a card for your notebook PC, you can program and troubleshoot from anywhere around the machine without worrying about leads.
I'm just now beginning a retrofit using this approach but also including DNet for interfacing to drives. Only MMI is a PanelView (also ethernet) and some old dataliners. SLC was never considered.

After-thought:
There's a commissioning-time plus when using CLX in that more than 1 person can be on-line at the same time with full edit capability allowing simultaneous testing and debugging of different areas where feasible.
 

Similar Topics

Hi all, if I remember correctly, there is some way in a ControlLogix (or CompactLogix) where you can sort of map tags into SLC addressing format...
Replies
8
Views
1,107
A new Forum member resurrected an old post with a variation that I think should be done in a new thread to get the best attention and advice...
Replies
11
Views
2,221
We are updating A few older Aveva Wonderware InTouch applications from a SLC PLC to a new ControlLogix PLC. What is the best way to deal with the...
Replies
2
Views
1,065
Hello, is it possible to read a message using a controllogix L61, from a SLC, that is connected to a PLC-5 that already is sending data to the...
Replies
7
Views
2,111
Hello, I inherited a control system one of my predecessors thought it was a good idea to put logic for cant optimization and Kinetix motion...
Replies
15
Views
3,454
Back
Top Bottom