Could it be that the ControlLogix is the worst concieved product to ever reach the market? After choosing the CL as the base controller for our line of servo controlled products, we came to discover the "firmware compatability" trap. This trap causes the user to flash upgrade the firmware in a processor after installaing later versions of RS5000 before you can go online to the processor. So you wipe out any customer entered data i.e. recipes and go back to the original program as it existed during your last visit to the customer.

After seriously upsetting a couple customers, it was determined that the best bet was to cease software upgrades until a solution could be found. Meantime several other systems are built using old versions of software, at least they are all the same version.

Lo and Behold, almighty Rockwell has found a solution! Version 10 allows you to keep two versions on your PC!! All you have to do is upgrade your operating system to Win2000, and everything is Okay!! Praise Almighty Rockwell!!

A few hundred $$$ to Bill Gates and several fun installation hours later , VIOLA version 10, Windows 2000, and old RS5000 Ver. 2.25. Of course I still had my old DOS partition for the machines dating back to the 80's, and no room for an NT partition, but things were looking up!

Then my euphoria burst. Version 2.25 is NOT SUPPORTED IN WIN 2000!! Several creative phrases from an old sailor followed, and then the light came on. So what you can keep two versions on your PC, If you update from version 10, your back in the same boat!

If only these pesky $100,000 systems were disposed of as frequently as PC's we wouldn't have a problem. Just think what a boost it would be for the automation market! Hey, . . . . maybe I'm starting to get it!
 

I agree with you buddy!

You forgot to mention that you can't just do a firmware upgrade using "serial" connection. EtherNet is preffered over the ControlNet to upgrade! and it can crash in between too.

The worst scenario is when you see a new processor without a firmware in it! I think they don't ship it with the firmware loaded in to it..

Here's another real recent example. One of our customers suddenly has a processor fault. His options: (1) Pay one of our techs to fly there (2) Buy a new processor from us loaded with the original software (3)Get the local A/B guy to come by. Option 3 of course is the fastest and least expensive. This was one of the reasons the CL was chosen in the first place, the availability of local tech help.
Here comes the firmware trap again, he can't get online until he flashes the processor. Guess what!?! Now you have no idea what caused the original problem. Not to mention the customer has just lost the hudreds of recipes he had stored in the processor.
These things may be great for the in-house automation market, where you can get on the LAN, upload, flash, and download everytime a new version hits the street, but for the OEM they are a NIGHTMARE!
 

Wake up guys and get with the new century...keeping your processor firmware versions, your RSlogix version and your Win OS lined up are an essential part of the game with CLogix. Failure to do so on your part...does not constitute a reason for anyone else to take your whinges seriously.

It simply amounts to basic engineering discipline that must be taken into account when using the product. There are many good reasons why CLogix uses this system, but the one most important to you as the user is:

All the language functions you use in your program are NATIVE to the processor. This means that if you upload a program (without the original file on disk) you will get all the original program (minus rung comments in the current versions.)

In order to add/enhance/fix issues Rockwell have to upgrade the processor firmware as well as the Logic editor...and allowing different versions to talk to each other introduces potential unmanageable and untestable stabililty issues.

So to keep it safe Rockwell only lets the the correct version of RSLogix 5000 connect to the processor.

Failure on your part to understand this..or to read the directions...and to sound off childishly "this is the worst product ever" when you suffer the consequences is immature and foolish in the least.

Still using Ver 2.5 ??? I don't even have an install copy of something that old. Grumbling about using Win 2000....only and amateur would be using anything less.

Gents...your comments reveal a lack of professionalism on your part, and say little of substance about ControlLogix.

Philip W

Let's see if I grasp the concept Philip. Everytime A/B updates the programming software, I'm supposed to fly off to various points in the world where our machinery is installed to upload the customer entered data, install my new version of RS5000 software, flash the processor, download the program with the customer entered data, re-install the old version of software on my P.C. and fly off to the next customer sight and repeat the process?
Based on the number of new releases and the number of machines produced I will rack up about 500,000 frequent flyer miles per year.
Who is supposed to pay for this traveling circus?

Let's say we take the breathless pace of product development as a given fact, and not vent our fury on it's inconvenience.

What kind of system feature would serve you, Dave The Motion OEM, best ?

My first guess is a removable CompactFlash card with a flat file structure that was accessible via ladder instructions.   You could store your motion recipes in such a device, and have it's structure unrelated to the ControlLogix firmware and RAM contents.   Then as long as your application program (in successive Versions of RSLogix 5000) treated this memory pool the same, you could slap in new controllers and new firmware all you want, as long as that interface remained the same.

How do you *wish* the ControlLogix platform worked ?    

"Be perfect with all features on the first release" is not a valid answer.

Are your recipes arrays of DINTs and INTs, or are they stored complex motion data types?    How are they entered?  Are they "taught" like a robot, or put in from an HMI screen ?

Lets see then if we can grasp the opportunity inherent in the problem here (and I won't speculate further on what else, any of us may be gripping ...I think Dave you hit the nail on the head when you ask ...who is to pay?  As an OEM of significantly expensive systems (>$500,000 ??) its my guess that your equipment is usually a critical part of your customer's production line for whom unplanned downtime is unpleasantly expensive.

These same customers probably run expensive business IT systems too, and they think nothing of employing expensive people to ensure that their IT systems are maintained, up-dated, patched and audit trailed to minimise the risk of downtime.  And inevitably as automation technologies follow the same evolutionary path as IT technology, the revenue flow moves it's focus from selling hardware, to selling software and services. Where is the opportunity for you guys here?

1. Do you have service contracts with your customers? Can a routine firmware update be included in the offer? By keeping all your installed base no more than one or two versions old you will minimise the risk of a major "gotcha" like the one you describe.

2. Assuming you already have enough frequent flyer miles, how about getting the local Rockwell GMS tech boys in the loop on a proactive basis. It's much easier to get them in to do the work before the proverbial hits the fan.

3. I've used RSLinx Gateway very successfully for a US based OEM to remotely access an SLC system in a bakery literally on the other side of the planet, and they reported that it was just like having it in their own workshop. By itself this doesn't solve your problem, but is does illustrate the potential.

4. Is there the possibility of developing a VPN connection to the system accross the Internet? This way you could have remote alarming, diagnostics, perform patches and updates...create an on-line database for your on records, maybe give access for your help-desk guys. Is there an HMI PC in the system?... if so the possibilities are obvious.

5. Expanding on Ken's idea, maybe a 1756-PCMCIA module that allowed user to plug-in PC memory would be an interesting possibility. (Another application that comes to mind would be to use GPS cards to get access to accurate global time sysnchronising that would be very useful to customer with widely distributed  netwotks such as power uitlities.)

6. Or how about some software that allowed the Logix engine to directly access utility data files located on a PC server accross the Ethernet card?

I too have arrived on site with the wrong RSLogix version installed, its aggravating in the extreme, but ControlLogix is NOT just PLC or SLC in sexier plastic...it is a whole new ball game. Amazingly enough, it is possible to program CLogix just like a PLC, but that is to miss 50% of the possibilities. I've been using it intensively since it was launched, and I'm still learning new tricks and uncovering new potential...and along the way I've had to re-calibrate some of my expectations to keep up.

Dave,

What OS were you using before Win2K?

Phil Covington
http://www.vhmiautomation.com

The OS we currently use is Win 2k, before that Win 95, for about 18 months and then we migrated to NT 4.0 on our laptops (along with some 3rd party PCMCIA software) for about 3 years until Win 2k came along. Never used Win98, or Win ME. Basically we are quite happy with Win 2k.  I'm not keen to move to XP...too many fishhooks for not enough gain.

That said we recently changed to Suse Linx 7.3 on our white box PC’s and StarOffice. Just downloaded a copy of OpenOffice 1.0, haven’t tried it yet. Still learning how it use Linux, but I would be keen to see RockSoft actually release some Linux based software, but they won’t until the industry itself makes the change, AND they can see the possibility some cash flow from the exercise. This must be the downside of a free OS... people then expect the apps to be free (or near to free) as well…and well I charge for my time, don’t you?

As for the current fad for BillG bashing…sure I've had my moments banging the desk in frustration with Micro(beeeping)soft, but I guess that if Linux had 90% plus desktop marketshare it would also have plenty of unhappy folks out there trying to tear into it..no product is a perfect match for all the people all the time. Most of the time when I get into trouble with technology it's cos I'm screwing with it, not the other way round.

Overall I figure a PC has a life of about 2 years and I budget to replace them that often. As Ken Roach said the pace of innovation sometimes creates inconvenience, but at the end of the day I've yet to have a customer ring up and ask "please to stop improving your product/service."

Can I know if any one of you have really replaced a 1394 - Legacy Servo System with the new generation ControlLogix 2 0r 8 Axis Servo system?

The reason I am asking is, because the programming techniques in 1394 is lot different than the PLC programming methods.

I think, ControlLogix also offer the multi-tasking. Do you know if that is limited to 32 or some other number? I know the 1394 wouldn't allow you to have more than 10 tasks.

I would really appreciate if some one can share a demo - multi tasking - multi Axis motion program..

Thanks
Amit

Two replies in one here:

Dave…the good news is that Ver 10 (or better) will be the “stake in the ground”, that all future versions of RSLogix 5k will be backward compatible with. i.e. the “firmware trap” will be going away. I guess that this means that the software/firmware guys feel the product has evolved to the point where any future compatibility issues will be manageable and testable.

Version 11 is very close to release and now has the long awaited Sequential Function Chart, and Structured Text languages for routines. Plus we also get on-line editing for Function Block.  Other goodies will include more hardware support and faster upload/download (it’s pretty good now I thought.), more processor redundancy support and enhanced motion capabilities…sorry no details yet.

Regarding CLX Motion. For some time I quietly mourned the move away from GML…it just looked so sexy and was so much fun to use…although it was still perfectly possible to write junk logic with it

However, GML simply isn’t one of the IEC languages, and perforce to comply with this standard, GML pretty much had to go, (although I am aware that at an early stage of ControlLogix development it was in the plan). Also GML was always a just the front end to a complier; so adding the ability to on-line edit would have been a major effort, and not justified by the lack of IEC compliance.

The good news is that the CLX implementation of motion instructions in ladder is pretty good. Plus of course you can inherently on-line edit the stuff!! Another plus is that because CLX allows multiple output instructions on a single rung, it is possible to create “threads” of sequenced instructions not too much unlike the way GML did. Of course the format is not so pretty as GML, but the result is very workable. I won’t claim to be a CLX motion expert, but from what I have seen and done the ladder implementation is a lot better than I had expected.

CLX inherently multitasks. In addition to the “continuous task” which run just like File 2 does in an SLC, the processor can run up to 31 other “periodic” tasks, just like the STI file in the SLC. But whereas the SLC only had one STI rate; the CLX can a different rate and priority set for each of the tasks you define.

In a motion context though what you are really asking is: can the CLX handle more than one motion instruction and axis at a time? The answer is that the 1756-L55 processor can have up to 32 axes defined, all of them coordinated. The next question is what kind of performance do you need?

The motion modules themselves do the fine motion planning and loop closure at 200uS, so that is not the issue; the real question is how often can the CLX processor update the motion module(s) with coarse position planning? The coarse update period needs to be about 10 times faster than the quickest accel/decel rates to avoid overshoot so this will set the maximum value it can be.

The minimum coarse update rate is calculated by summing all the motion tasks being simultaneously run for all the axes…typically 3 axes doing S-curves, jogs, gearing and some position camming might require a 5mS coarse rate….more axes and more complex motion instructions will take longer. If the L55 processor isn’t quick enough to handle all your axes, then the L63 processor is about 4-5 times faster than the L63 and should handle all but the most demanding applications.

Motion axes can now be “produced/consumed” between processors so if you need to… just add another processor, and it is easy to pass motion axes data between them.  After all the cost of another processor is peanuts compared to the total machine cost if you got to 10 to more axes all doing complex motion!

Even adding another processor will not loose the coordination between all the axes; one of the CLX processors will remain the “CST Master” (Coordinated System Time) for the whole system. This is as easy as ticking a box!

Finally…if you need more than 2 axes I would most certainly be using the 1756-M08SE Sercos module and any of the newer Sercos drives, or the 1394_Sercos versions. The total installed cost will be much lower, the functionality much higher and the control cabinet a lot tidier.  Only thing to watch is that Sercos is not a completely defined open standard and each supplier has high level versions of their own (they had no choice, in the absence of a complete standard) and so it is best to put only A-B Sercos drives with A-B motion controllers.

Hope this helps…I know 1394 was a nice system, but CLX is even smarter, despite the loss of GML.

Wow-
This thread went from I hate Controllogix to I love Controllogix.

I agree, it is very nice to have the motion control and the PLC logic in the same package-- 1 PC, 1 cable, 1 software--

I see this thread got onto the subject of L55, sercos, and coarse update rate after the s/w version debate.

So, can any of you offer an explanation for a problem I am experiencing? The system in question is an L55 with 4 axes on a 1394 sercos/MO8SE, 2 Reliance GV3000 on a MO2AE, and 2 virtual axes. Recommended coarse update rate is 1 msec per axis. The rate is set at 10 msec (2 more than recommended). Of the 8 axes, 7 are geared or cammed to one of the MO2AE axes (call it master). From monitoring the motion group tag - when master is stationary, the motion scan is approx 5.5 msec; when the master is moving, the scan is approx 6.5 msec. However, every other day we get a group overlap fault - maximum scan reported to be up to 14 msec! And it seems that the MGSR instruction doesn't clear the fault as advertised. Seems to require the old "cycle the power" type of reset.

These faults started occurring approx 1 week after upgrading from ver 9 to ver 10

Any ideas?