In Defense of ControlLogix

K

Thread Starter

Ken Roach

Hi guys,

Okay, this might not make it through the moderator, but I wanted to say a couple of things about the ControlLogix after the gripefest of the
past few days. <MODERATOR'S NOTE: No problem with vendors responding to product complaints.--Jennifer Powell>

First: Keep it coming. A-B needs as much customer feedback from the guys who use the Logix system as we can possibly get. It's user opinion that makes features and fixes happen. I have thick skin and I'm not a product manager so I like to hear whatever you have to say.

Second: The Logix system is in its infancy; A-B has only been selling the controllers for about a year. A lot of functions and features that were
present in the PLC5 and SLC aren't in the Logix yet. And functions are being added at regular intervals; that's why the seemingly constant
firmware upgrades. Fortunately, the firmware is FLASH and it's an easy utility; I use my Ethernet module to get to the backplane and it usually takes about 10 minutes to upgrade a system. And the firmware support is included in the RSLogix 5000 support contract. If you want to debate whether warranty support of firmware and software should be eternal and free, forget it. That pays my salary; this isn't a hobby for me.

It is a BIG issue that new editions of RSLogix 5000 can't program older firmware controllers, like you can with PLC and SLC. Because of the
compiled nature of the Logix control programs, it's not practical to roll the old compiler into the new build of RSLogix 5000. In the near term,
the solution will be to support the installation of multiple copies of RSLogix 5000 on a single PC with a single activation. You'll still need to
be on your toes and keep track of which versions are operating in your facilities and equipment.

Third: It's not a plot. I spend all day every day getting people familiar with ControlLogix and Rockwell networking. It's new, it's different, and if I'm doing my job right, the newness won't come bite my customers in the butt.

The fact is, I think the Logix is a great controller. Definitely different from the Five, definitely more powerful than the SLC. I've gotten to really like the transportability of code using tag aliasing, and the CIP protocol and object model is like a super-big tub of colorful Legos to me.

At the risk of ticking off Ron Gage, I'd like to take a shot at answering his rhetorical questions:

RhQ:>>Try explaining to a customer why there is no direct communications route from a PLC-5 to a CLogix.
A: Only early Ethernet versions. DH+, DF1, and ControlNet have been compatible since day one, and the PLC5E and ENET sidecar now support CIP
protocol on Ethernet. The Logix needs to emulate the PLC5 addresses, though, so that's an extra step.

RhQ:>>Try explaining to a customer why downloading a program to a CLogix crashes his VAX.
A: I don't know this one. I don't have any VAXes on my networks so I'm not qualified to guess.

RhQ:>>Try explaining to a customer why the DHRIO module is locking up if you use both channels.
A: I think I know this one; did you configure the DHRIO in the I/O Configuration as a RIO scanner and then change that channel to DH+?
That'll disable the DH+ channel if you don't remove the entry from the I/O list and there's no clear error message to indicate that condition.

RhQ:>>Try explaining to a customer how a program that takes 250k on a Pyramid takes over 2 meg on a CLogix.
A: The 5 and 5/250 use a code interpreter, so the code you write is tight and simple and the method for executing it is stored in the ROM of the PLC.
ControlLogix code is compiled, so it's execution method is included in the program file itself. That's an oversimplification, but the difference
between interpreted and compiled code plus the fact that the Logix stores the actual tagnames of your program variables in the controller are what
make the difference. It's not easy to compare PLC program files to Logix (and less easy still when you're talking 5/250 or PLC3) but I use the
equivalency that the base Logix is equivalent to a 5/20, the L1M1 is a 5/40, and the L1M2 is bigger than a 5/80. And I love it that I can walk up to a Logix without having the offline documentation and still have a fighting chance at figuring out the logic because the tagnames are stored in the controller.

RhQ:>>Try explaining to a customer why he can no longer directly enter the ASCII serial number into the PLC (CLogix).
A: You're right on; not only did the Logix not have ASCII instructions, but it didn't even have an ASCII radix display. Both have been added in
version RSLogix 5000 v2.50, but there still aren't string manipulation instructions. I've taken to using DeviceNet to ASCII gateways for most ASCII applications anyhow (instead of using BASIC modules or tying up the serial port) and that's required that I memorize the ASCII table again.

In closing (whew!), if you're using Logix, make sure you're on good terms with your local distributor and keep all your old CDs when you get new software. The "MySupport" notification feature at RSI is a good way to keep up with the release times of the new revisions of Logix.

Cheers,

Ken Roach
A-B Seattle
 
Hi Ken:

On Fri, 24 Mar 2000, you wrote:
> At the risk of ticking off Ron Gage, I'd like to take a shot at answering his rhetorical questions:

Don't worry about this! I changed jobs and am now working in a Modicon plant. Not that I like that any more than the constant travel I was doing as an OEM service rep.

> RhQ:>>Try explaining to a customer why there is no direct communications route from a PLC-5 to a CLogix.
> A: Only early Ethernet versions. DH+, DF1, and ControlNet have been compatible since day one, and the PLC5E and ENET sidecar now support CIP protocol on Ethernet. The Logix needs to emulate the PLC5 addresses, though, so that's an extra step.

Details: was communicating from a CLogix to a Pyramid. Pyramid was driving I/O. 114 station assembly line with 16 bits of inputs and outputs per station. Pyramid was being phased out (gradually) due to it's being dropped (like a hot
potato) by AB and because it was maxed out on the I/O. Only way to share the data into the CLogix (which was taking the place of the Pyramid) was via DH+ at 57k - the Pyramid would support 230k but the CLogix would not. Average data
turnaround time was .9 seconds. This made it hard to do important things like stop the "trolleys" at the right place (+- .5 inches).

> RhQ:>>Try explaining to a customer why downloading a program to a CLogix crashes his VAX.
> A: I don't know this one. I don't have any VAXes on my networks so I'm not qualified to guess.

Details: Vax was used as a data collector for the assembly line. Constant attachment and polling/exchanging. Vax was running Interchange (only available software). If the CLogix went into download mode for any reason (which was
quite often due to RSL5k bugs), the VAX would drop the socket (like it should) but Interchange would lock up. According to plant personnel, they have NEVER had anything like that happen with monitoring the many PLC5's they have *OR*
the Pyramid.

> RhQ:>>Try explaining to a customer why the DHRIO module is locking up if you use both channels.
> A: I think I know this one; did you configure the DHRIO in the I/O Configuration as a RIO scanner and then change that channel to DH+?
> That'll disable the DH+ channel if you don't remove the entry from the I/O list and there's no clear error message to indicate that condition.
>
Nope, but I have been tripped by this one before also...

The problem stems from the 12 message queue in the DHRIO card. It seems that the card doesn't like constant messaging to happen (xio bt16:0/dn btw bt16:0). This plus the fact that the card spends it's internal resources listening to
the traffic on the channels.

Details: Both channels set to DH+ at 57kbaud (only choice). Channel A is a dedicated link between CLogix and existing pyramid. Channel B is plant wide (20 node) DH+ link (also talks to Pyramid). CLogix has NO messages going into
our out of channel B. Channel B only connected to allow other future processes to talk to the CLogix. With both channels connected, the DHRIO card would go into what we called "zombie mode" after about 1/2 hour. Once in "zombie mode",
the card would be REAL sluggish to respond, if at all. Above mentioned .9 second data turn around time changed to 30+ seconds. No direct indication of a problem available to the CLogix (aside from the constant error counts from the
BTW's). In some cases, the only way to reset the card was to power the whole system down (not just pulling the card).


> RhQ:>>Try explaining to a customer how a program that takes 250k on a Pyramid takes over 2 meg on a CLogix.
> A: The 5 and 5/250 use a code interpreter, so the code you write is tight and simple and the method for executing it is stored in the ROM of the PLC. ControlLogix code is compiled, so it's execution method is included in the program file itself. That's an oversimplification, but the difference between interpreted and compiled code plus the fact that the Logix stores the actual tagnames of your program variables in the controller are what make the difference ....<clip>
>

No direct argument there, but your sales force needs to be much more clear on this issue. It is not easy to explain to a customer on his plant floor that this "new better platform" can not handle the data that his existing, supposedly out-of-date Pyramid can handle.

> RhQ:>>Try explaining to a customer why he can no longer directly enter the ASCII serial number into the PLC (CLogix).
> A: You're right on; not only did the Logix not have ASCII instructions, but it didn't even have an ASCII radix display. Both have been added in version RSLogix 5000 v2.50, but there still aren't string manipulation instructions. I've taken to using DeviceNet to ASCII gateways for most ASCII applications anyhow (instead of using BASIC modules or tying up the serial port) and that's required that I memorize the ASCII table again.
>

Customer was not happy to learn that ASCII radix wasn't even being thought about at the time (summer 1999). His serial number data in the Pyramid was stored 2 chars per integer and he was used to this method. Everything that used this data in the plant relied on this format. Changing it was not an option. You can imagine the difficulty of retraining their tech staff on the use of a "translation chart" for manually coding serial number data. An example serial number would be: 1LW25645

From what I have understood, the platform is beginning to shape up. The biggest issue now appears to be the constant crashing of RSL5k (as of 2.25 anyhow). Also, now that there is actual documentation of the CIP protocol (from ODVA, not directly from RSI), the ability to write third party translators (CIP <-> CSP/PCCC) is now possible. Unfortunately, I left the project (and job) last December after spending 9 months trying to get things running reliably. Last year was not a good year.

--
Ron Gage - Saginaw, MI
([email protected])
 
A

Anthony Kerstens

Great answers. However, from the way you wrote your response, I gathered that you don't consider ControlLogix to be a PLC.

Am I right in interpreting it that way? If it's not a PLC, then what is it?

Also, if it's compiled, could I walk up to a processor, without the original source, and suck it out to create a new source? If not, retrofits
could be absolute hell.

And what about upgrade paths? Are there any planned methods of bringing SLC and PLC2/3/5 logic in (aside from cut and paste)?

Anthony Kerstens P.Eng.
 
M

Michael Griffin

I'm not writing to complain about the ControlLogix. However your comments which I have noted above I would cause me to like to ask a few
general questions.

I understand that the ControlLogix is a compiled rather than an interpreted system, and AB is not alone in adopting this approach lately. I suspect that these problems may be possible with other makes as well although I am not aware of any particular situations.

In my own applications, the compatability problem would be a very serious concern. I cannot imagine a situation except in very small plants where it would be feasible to keep track of which versions of firmware are present in possibly hundreds of PLCs. Nor can I imagine how it would be possible to check on what software versions various outside contractors have used, or what "flash" upgrades they may have performed without telling anyone.

Suppose we have the following scenario. I have version 1 and version 3. Someone was brought in to perform some changes to a machine (which used
version 1) and they "upgraded" it to version 2 without telling me. Now I can't use version 1 because it is too old, nor version 3 because it is too new. It would only be likely that I would find out about this problem when I was in dire need to be able to connect. Is the preceding scenario unrealistic?

Having many different software versions doesn't sound particularly feasible either. Assuming that they would all fit on my laptop (and they
wouldn't), would I necessarily know which one to use? Could I necessarily be sure that I had all the older versions I needed?

A factory is very different from an office. Long term compatability is absolutely critical. We have been used to a family of PLCs presenting a
consistent face to the outside world for periods of a decade or more. It is simply not economically feasible to "upgrade" PLC firmware on a regular basis the same way we do with PC software. Am I being unecessarily concerned
here?

I'm not trying to pick on ControlLogix in particular. I wouldn't be surprised if another manufacturer has the same problem. The question I have is why long term compatability is not a much higher priority in the product family design criteria. I have in the past assumed that the advantage of buying a proprietary design from a large company was that I would never have these problems to begin with.


**********************
Michael Griffin
London, Ont. Canada
[email protected].ca
**********************
 
Michael;

I've just finished a large project with our electrical utility here in BC. They have an interesting method of keeping track of version numbers. Once a system is installed and "Proven", upgrades to firmware and software are forbidden.
They've refused all the free upgrades I've offered. The old concept of "If it ain't broke, don't fix it" seems to work for them, and greatly reduces their paper trail.

Mark Hill
[email protected]
 
A

Anthony Kerstens

You have a little of that problem now. Older versions of RSLogix5/500 can't read logic files from newer versions. You can always suck the logic out of the processor, but have fun getting descriptors.

Anthony Kerstens P.Eng.
 
R

R A Peterson

[email protected] writes:

<< A factory is very different from an office. Long term compatability
is absolutely critical. We have been used to a family of PLCs presenting a
consistent face to the outside world for periods of a decade or more. It is
simply not economically feasible to "upgrade" PLC firmware on a regular
basis the same way we do with PC software. Am I being unecessarily concerned
here?
>>

Not only that, but the fact that you have to shutdown your plant to do it is a major problem. Most 24/7 plants do not take kindly to this. Its a major problem just adding I/O to an existing PLC (a problem not limited to Clogix). You can't reconfigure I/O online either. Its one of the reasons we tend to use multiple SLC5/04s instead of a single big PLC5. It allows you to add
program and I/O without having to shut down the existing plant. The added robustness of having less of your plant dependant on a single piece of
equipment is just a bonus. In most cases, an slc5/04 and 1747 I/O is less expensive then a 1771-asb and 1771 I/O anyway.

I was unaware of the version hell this system was going through. I could not in good conscience suggest such a disaster to anyone who did not fully understand what they might be getting themselves in to.
 
Upgrades are not necessarily forbidden but discouraged. You are correct about the "if it ain't broke" concept though. The practice is to ARCHIVE everything (even the OS). An upgrade has to be substantial and approved company wide. For example the utility still uses WIN95/Office95 on client workstations. Considering Microsoft's track record on releasing buggy software too soon, this concept has paid off well. But that is for another thread.....

Note: Comments are my opinion only and do not represent the utilities opinion in any way.

Jit Roop
Oceanside Technologies Ltd.
#140 - 8208 Swenson Way
Delta, BC
V4G 1J6
http://www.otl.bc.ca
Tel: (604) 588-5450 Fax: (604) 588-5457
 
Modicon Quantum PLCs and the Concept software have exactly the same non-backwards compatibility you just described.
 
G

George Robertson

I've been watching this thread with interest. One of the earlier comments was made that ControlLogix is compiled rather than interpreted. The literature says that the labels and symbols are stored in the CPU. The question of maintenance is not whether the code is executed after a compilation step, but whether the source code is stored in the controller.
Is it? If you don't have the laptop copy of the original source code, can you not walk up to the controller, upload the source from it, and make
changes?

[email protected]
George G. Robertson, P.E.
Manager of Engineering
Saulsbury Engineering and Construction
 
B
George,

You can, in fact, walk up to a strange (i.e. no current RSLogixs5000 file) ControlLogix plc and download the program including tags. You will not get any comments however (rung, address or instruction). RSLogix can interpret the compiled (p-code) and produce a source file from the download.

As is often the case, with power comes complexity. There is little argument that the ControlLogix 5000 platform is powerful. But it definitely deviates from the traditional PLC architecture. There are pitfalls waiting for the
unweary. One potential snare is the asynchronous nature of the I/O. Another is inter-process communications within the same processor (continuous vs periodical update). Also frustrating is the problem of balancing process
requirements vs communications (processor overhead). Regardless of perception or hype, ControlLogix does not have unlimited resources.

Bill Marsh, Owner
ICD
 
L

Leon McClatchey

Well I'm not really sure what the problem is, what we ran into using RsLogix when we got (I think it is version 3 that we're running). We
wrote some of our programs using the old Dos Version, and when we went to look at the program using RsLogix, it just kept prompting about
importing the descriptors until we saved the program under a new name. After that all the problems as far as accessing the logic and the
corresponding descriptors seemed to have been converted into the new format?

cya l8r
Leon McClatchey
mailto:[email protected]
Linux User 78912 (SuSe62 Box)
 
D
Is anything really backward compatible? Even Word and Excel are not!!! Welcome, Allen Bradley, to the world of real throughput, not just scan time of the application.

You don't have to win, just keep up!
 
M

Michael Griffin

At least one PLC manufacturer has a Grafcet programming package which will not reverse compile. That is, if you lose the original source code, your only option is to re-write the entire program. At least this is what the PLC manufacturer told me.

With the number of third parties and sub-contractors being used in the machine building business, it is not uncommon to be given an incorrect version of the program (or even one for a different machine entirely) after the machine is delivered. I would have to think very long and hard about this issue before I would be willing to use this software.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
Hello A-List,

To set the record straight, YES, you can walk up to a ControlLogix without the source code and upload it's program. You'll have all of the logic, all of the configuration, all of the tag names, all of the alias assignments. What you won't have is the text rung and address comments;
those are saved with offline file only. Long term, ControlLogix will support the same kind of reverse-compatibility as the SLC and PLC. Today, you have to keep on your toes.

Ken Roach
A-B Seattle
 
J

Joerg Jaschke

Hi guys,

I know the original statement is 5 month old by now, but it is just a couple of day's ago I found this forum.

Anyway, I have to work with the ControlLogix as well as with PLC5's and Siemens S5 and S7 Systems. And anyway, I'm always suffering from the problem, that whenever a new system is comming up, it is much worse than what we had before and all the expectations we had from the presales information are totaly dissapointed.

ControlLogix is nice in a lot of ways. I really like the easy communication, I like the PLC / SCL like instruction set etc. and I like to work with the ControlLogix. But there are a lot of things which I think are much below my expectations.

1) When a new system is comming up, I usually expect it to be better or more advanced as the old system. RSLogix5000 is worse than RSLogix5 (for example no libraries, no partitial downloads) and just fullfills minimum requirements. (not thinking about multi user programming etc.) CL5k does not know SFC, CL5k does not know ST programming. My expectation that it is at least as good as a PLC5 was wrong. So I have a problem how to explain that to the other programmers in my company and to the customer.
When I'm talking about better, I was thinking of real function block programming, of fast and powerful math-processing, high speed binary processing etc. I finished thinking about it! Compared to an S7, it is ultra slow (where is the advantage of my compiled code????) Additionally I have to program Input and Output scans to synchronize my real world IO with my program. I have no use for cyclic tasks and I can say bye bye to all my nice tag symbols, as I do need DINT arrays for my boolean tags as I need extensive file instructions (and I do not want to end up with 15000 single controller tags which I cannot handle).
2) When a system is new, it is comming up with a lot of oh so modern features. If I could just make any use of those. Where is the point in using alias tags? AB itself says, they are slow and this is something which is the last I can need. (Our usual PLC5-80 programs have somewhat like 55-65k of program and 20-20k of data and have to perform with a cycle time less than 20ms!!)
3) As long as you can stay in the AB world, life is fine. If you have to communicate with VME-Bus System, 5 Motorola CPU's running under RTOS PEARL, you have a problem, as all your ethernet communication is lost. So a complete new CIP Driver has to be developed. (Why can CL5K not just add a PLC5 compatible Ethernet Interchange protocol?)
4) Building user defined Data types is fine, but you cannot use them with file instructions, you cannot display them in the MMI. It does not make me happy, when RSLinxs one day is abley to supply an access to tags build of user defined data types. I do not want to rewrite my MMI and my PLC Program each year. I want to do it right one time (the rest of the time I spend upgrading my PC, my NT4.0, my RSLogix, my RSView32 (or whatever it will be called in the future), impletent a new MMI system as it was the custumers holiest whish etc.....).
5) I can understand, that using cyclic tasks my require fast asynchronous IO update, but I want to switch it of!!!!!! I don't want that in a PLC!
(may be because I'm lazy and I dont like synchronizing about 2500 I-O's by an Input and Output Scan task, additionally I tend to make a few typing errors during programming these tasks)
6) Once we started the first ControlLogix project we also had to puzzle out a new way how to name the IO's as there were no adresses left. I assume, that all other companies are puzzling as well and all of a sudden I cannot read the wiring diagrams of the other vendors, so how is my customer supposed to read them?
7) Ethernet and ControlNet, DeviceNet and DHRIO. So many communication systems, but not a single tool for clear, understandable diagnostics. Each VFD with his own DeviceNet connection, ControlNet for usual I/O, Ethernet for MMI communication and DHRIO to talk to the old PLC's from the customer. Has somebody got a good idea how to start up these systems, troubleshoot them? NO! No active X to integrate in my MMI, telling me what's going on, on RSLogix Tool, nothing. Just thousands of datawords which I cannot possibly all handle in my PLC and MMI and create my own troubleshooting screens. By the way - does somebody know about all these tags and what they are good for? I tried, but I gave up. (at that point we do not talk about minor system glitches and bugs, just assuming everything at least in the PLC is fine.)


I think, that ControlLogix was on the market too early, too many ideas which are not finished, priorities on items which are away from the everyday use. A new system should at least be as good as the old one and a new software should at least have the features as the old one.

Now I'm sitting here with my ControlLogix5500 and have to redesign the old PLC5 programs (and please, do not suggest using the conversion tool!) and have to implement additional PID loops (which were running on the VME Bus system when using PLC5) and get rid of one out of two VME-Bus systems we use in our woodlines. I wish, one day some design people would ask, what a PLC must be capable of.

J.Jaschke
System per-Design and development
ATR Industrie Elektronik
Viersen - Germany
 
B

Barb, Manufacturing Programmer, Hewlett-

Hi, Ken,
thanks for your comments.

I am just getting started learning RSLogix5000 and the ControlLogix controller, and I have to admit I have been disappointed to find the deficits that posters above have mentioned. The main thing for me is the lack of good ASCII string support in this controller.

We are coming from a factory full of SLC5/04's linked via DH+, many of which must talk to subsystems via RS-232 strings. We have a good system going here where we program BASIC modules to act as serial ports and are thus able to pass strings in and out of the PLC... not so with the ControlLogix. You can't even type the string into the datatable like you could with a SLC-- you have to enter it one character at a time. Kloodgy! A-B has made a small start by giving us the "String_80" 'datatype' (really a user-defined datatype/structure which I could have written myself) and the subroutines for manipulating them, but this is an *extremely* small start, and the functionality is not nearly up to SLC standards. This needs to change, and fast; else I am going to recommend that we not be very hasty to upgrade to ControlLogix, but stay with SLC5/04's for a while longer. We just have too great a need to talk to other components (barcode readers, etc) with RS-232 strings.

And don't even get me started on the lack of a BASIC module with D-shell ports, which is (sort of) replaced by a 1756-MVI module for which you have to buy the special A-B serial cables...which will so easily get lost/grow legs/etc.

As far as the tags, I like the idea that the name is stored inside the controller so you can at least kind of tell what you have if you have to upload the code from scratch. Also, I see the I/O points have fairly descriptive global tags automatically generated for them, and you can create alias tags to these whose names tell what they do. So you should still be able (at least to a point) to see on the rung what physical I/O point you are examining.

This controller shows a potential for great power. But 64K is way too small a base memory for it. Our SLC5/04's have 64K memory, and are already stuffed to the gills. It kind of stinks to have to buy additional memory modules separately just to fit in the same amount of ladder logic functionality you could with an off-the-shelf controller of another model.

In summary, please fix the strings. Now!
 
B

Barb, Manufacturing Programmer, Hewlett-

Correction...

With further study of the Logix5000 literature, I have learned that you can indeed enter the entire string into the .data member of the String_80 tag (enter the entire string into array item [0] and it will fill in the subsequent array items as required.) So I stand corrected on that point. However, the .Len member does not automatically update when I do so. I would like to see the .len automatically updated as it is in a SLC5/0x.

I really would like to see the functionality that is currently contained in the String Handling routines in \RSLogix 5000\Samples\ASCII_Manipulation.ACD, instead incorporated into globally available commands, in the same manner that TON, NEQ, etc are now available. I like the functionality available in the routines, I just don't like the tedium of copying and pasting every tag and every routine into each program that will need to manipulate strings. Due to the scope issues, I would have to duplicate the routines in several places and that's not desirable.
 
Keep up the good work Ken.

Re CLX ASCII instructions. The latest versions of CLX has a pretty comprehensive set of ASCII instructions, I don't know about early editions. I'm the guy who wrote the 5250 to Logix conversion program and every 5250 ASCII instruction can be converted to Logix although the mnemonics were different.

There is one ContolLogix omission that drives me nuts. There is no ABS instruction as in the 5250 which makes checking deadbands a chore, conversions to CLX bang their shins against this lacuna. (Ken isn't the only one who knows fancy words.)

I've seen it written that 5250s cannot be converted to ControlLogix; not so, if anyone needs help with conversions contact me.

Pete Jack, [email protected].
 
Top