RSlLogix5000 backwards compatibility

T

Thread Starter

Troy Stearns

Could someone on the list explain why the RSLogix5000 programming software is NOT compatible with older versions of the ControlLogix firmware? In the past it has been the AB/RS modus operandi that new versions of a PLC programming package shall handle all firmware versions of all PLC's handled by earlier versios of the PLC programming package, as well as new firmware versions and/or PLC's that have been added. This is apparently not the case with RSLogix5000. Each revision of RSLogix5000 is only compatible with a particular revision of ControlLogix firmware. If it is necessary to work online with an older revision of CL firmware, only a particular version of RSLogix5000 may be used successfully. Currently, to handle multiple CL firmware revisions, it is necessary to: 1) Uninstall and reinstall between different RSLogix5000 revisions. 2) Swap between hard drives containing different revisions of RSLogix5000. or 3) Configure your computer for multiple boots of NT 4.0, each with a different revision of RSlogix5000. The current worst case scenario requires access to ten different revision levels of RSLogix5000 software to properly deal with the various revision levels of the CL firmware (per AB publication 9324-AP001A-EN-E - December 2000 http://www.ab.com/manuals/cl/9324-ap001a-en-e.pdf). This will apparently continue to get worse with each new release, unless they change their approach. AB GTS indicated to me that a fix, or workaround, for this situation is in the works, but could not tell me when to expect it. From what I know, it could be weeks or years away. If I am incorrect in my assessment, please let me know. I would rather be wrong than have to deal with things as I have described them. If I am correct, AB/RS erred when they chose not to use their traditional backwards compatibility approach, IMHO. I have been an advocate of AB PLC's in the past but am disappointed by the state of affairs with the CL. I might be more understanding if I knew the reason why they created this situation. Speaking for myself, not my employer, Troy Stearns Controls Engineer Martin Automatic, Inc.
 
Troy et al, Troy asks a very important question: *WHY* RSLogix 5000 software doesn't support earlier versions of the controller firmware. [trying not to trigger a semantics festival] As I understand it, it's because the ControlLogix, unlike earlier controllers, is running a compiled program instead of an interpreted one. When the firmware changes, the compiler changes too, and it would be a huge effort to attempt to separate the compiler and the user interface and database functions of the software so that multiple compilers could be run. [Caveat: Not An RSI Manager Speaking] The long-range plan is to have the compilers change very little between versions, so that functionality like RSLogix 5 or 500 will be possible, where the user interface just has to reject instructions or datatypes not supported by earlier controllers (remember that controller firmware 2.25 and 2.27 were both supported by the same 2.27 version of Logix 5000). I do not expect this functionality until next year, because big leaps in functionality (like the new FBD language and the Soft, Flex, Compact, and DriveLogix controller types) are scheduled in 2001. In the shorter term, there is the method in the technote you linked to; install multiple NT copies on multiple partitions. I have found that maintenance personnel are the users most likely to require more than one version of RSLogix 5000, and also the most likely to do little else with their PC's, therefore having enough hard drive space to accomplish this. The worst case scenario that I have encountered in real life is a paper mill that runs three different versions of RSLogix 5000: 2.27, 2.51, and 6.0 (remember there never were Versions 3, 4, or 5). Only one controller runs 2.27, and it has been running for two years and is scheduled for a 4-hour rebuild downtime in June (the processor should take five minutes). The newest controllers are running 6.0, and this plant is successfully supporting them all, without using the multiple-OS method. Yes, they have expressed their desire to have revisions unified as soon as possible, too. Most discrete manufacturing factories that I support (including Boeing Commercial Aircraft Group) have enough scheduled maintenance downtime to do two or three upgrades per year; they just upgrade the controller if it turns out to be older than the software they are running. A-B is planning to start shipping controllers without firmware in them; RSLogix 5000 will integrate the ControlFlash utility to load the newest version of firmware the first time it encounters the controller. So far, the only module in the Logix family that can't be totally forward and backward firmware updated is the 1756-CNB ControlNet bridge, because of the new ASIC processor in the Series D module. I have 1756-L1 Logix processors that don't have labels on the front because they're early marketing samples, but are running v8 beta firmware. The motion cards have been updates as much as the processors, and they're still totally forward and backward flashable. It's definitely a big challenge for Logix users to support multiple installations of ControlLogix firmware. The ease of flash upgrading makes it relatively painless when the time to upgrade can be found, and (in my always-humble opinion) the power and flexibility of the Logix platform makes it worth doing. Ken Roach Technical Specialist Rockwell Automation / Seattle
 
M

Michael Griffin

At 16:56 16/01/01 -0600, Ken Roach wrote: <clip> >As I understand it, it's >because the ControlLogix, unlike earlier controllers, is running a compiled >program instead of an interpreted one. When the firmware changes, the >compiler changes too, and it would be a huge effort to attempt to separate >the compiler and the user interface and database functions of the software >so that multiple compilers could be run. <clip> Rockwell isn't the only company to take this approach (compiled), and it isn't the only one receiving complaints about it. I'm not convinced that it is simply a matter of "compiled vs. interpreted". There must be some other more involved system architecture reason as there is nothing inherent about a compiler that would introduce this problem. I don't know what the situation is at Rockwell, but I understand that the sales and marketing and technical support people (i.e. the people who talk to the customers) at certain other companies are less than pleased with their situation. <clip> >It's definitely a big challenge for Logix users to support multiple >installations of ControlLogix firmware. The ease of flash upgrading makes >it relatively painless when the time to upgrade can be found, and (in my >always-humble opinion) the power and flexibility of the Logix platform >makes it worth doing. <clip> This brings me to my major question. I am not very familiar with the ControlLogix product in particular, but several other companies are using what they call the "compiled" approach. I haven't seen any advantage to the customer but I have seen the problems created. Perhaps this results in cheaper hardware, but other than that, I haven't seen any benefit to it. Contrasting "compiled" to "interpreted" is I think misleading. I realise that this "interpreted vs. compiled" explanation is probably supposed to be short hand for something else, but I am wondering what this new approach is. As I understand it, the standard approach taken before was not something which could really be considered "interpreted". Rather it was to create a virtual machine architecture, and then to compile (normally as each rung was entered - incremental compiling) the program to run on this virtual machine. The close correspondance (one to one with instruction list) of user program to virtual machine instructions made this compile operation simple. The virtual machine could be implemented in several ways, depending upon the particular price/performance trade off desired. A low cost, but slower processor could be built by implementing it in software on a low cost 8 bit microcontroller. A faster but more expensive one could be built by implementing the processor in actual hardware. Something in between could be achieved by implementing some features in hardware (typically boolean operations), and some in firmware (complex operations). I remember the early PLC-2 processors using several AMD 2900 bit slice processors. What was great about a virtual machine was that it allowed a stable machine architecture to be implemented on a variety of hardware to suit changing needs and component availability. A complete product re-design could take place without the customer being affected. What is it about the so called "compiled" approach that is different from the above? I don't want to know any company secrets, I am just curious what the general approach is. I admit to being a bit puzzled as to where the compatability problem can be arising. All I have been able to think of is that the firmware is the source of the problem. If different versions of firmware are presenting different interfaces to the user program, then a re-compile would be necessary to align the program to the firmware (it may not actually be the firmware per say, - it may also be a loadable library attached to the program). Still, I thought that this general class of problem was solved on micro-computers at least 20 years ago, so I don't know why it would be a problem with PLCs today. <clip> >Most discrete manufacturing factories that I support (including Boeing >Commercial Aircraft Group) have enough scheduled maintenance downtime to do >two or three upgrades per year; they just upgrade the controller if it >turns out to be older than the software they are running. <clip> They do? Is that "two or three upgrades per year" *per processor*, or did you mean two or three processors need firmware upgrade per year? If that is per processor, then in a medium size factory with say 200 PLCs of this type, that would mean 400 to 600 firmware upgrade operations per year! ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
Top