advertisement
from the frustrating department...
RS Logix 5000 version issue
PLCs and related questions. topic
Posted by stress911 on 30 September, 2011 - 11:45 am
We tried to upload the current program on a Compact Logix using version 16.2 but it came up as needing to update the firmware. We updated the firmware and the program was gone.

So it won't upload the program without updating the firmware but when you do, you don't have a program to work with any more???

Seems like we stepped on a landmine!!

We have 4 more machines to try and get data from, unfortunately, they're all different.

Any suggestions?


Posted by bob peterson on 30 September, 2011 - 2:46 pm
programs are specific to a version of firmware which also correspond
to a particular version of RSLogix5000.

hopefully you have a copy of the program somewhere. otherwise you are
out of luck

incidentally, you can have different versions of rslogix5000 on your
computer, so there is no need to upgrade all your plcs to the latest
firmware or rslogix5000 version. in fact some cannot be upgraded past
a certain level.
--
Bob


Posted by Joe E. on 30 September, 2011 - 3:56 pm
I believe you're out of luck with the one you already updated. As for the others: does it tell you which firmware version is in the processor? If so, it's easy. If not, you may have to do some guessing. Either way, if you have a TechConnect contract with AB, you can download the appropriate version of Logix. Multiple versions of Logix can coexist on one machine. If you don't have a support contract with AB, your local distributor may be able to help you get the correct version.


Posted by Steve Myres on 30 September, 2011 - 5:54 pm
>Any suggestions?

For retrieving the software for this particular PLC? No. It's gone for good.

The problem is a bad error message. In reality, the problem is that the programming PC and PLC are DIFFERENT, and the message should be phrased accordingly.

Telling you to upgrade the firmware is obviously bad advice when what you really needed was an older version of the programming software. In reality, you should have questioned the firmware upgrade, which on almost any device WILL clear the memory.

I can't fathom the ineptitude of Allen Bradley who after a decade of broken promises has still not managed to come up with one install of the software that's backward compatible with older firmware. Maybe they should get back some of the old guys that did the PLC or the SLC's. They seemed to be able to get it done.


Posted by Dave Ferguson on 1 October, 2011 - 12:40 pm
While agree with a lot of your points, one that I do not is concerning the backward compatibility of the software.

I do agree that it sucks ( to be blunt) but the reason is one I complained about a while back when flash able memory started showing up in all of our control devices. I first noticed issues in 2000 with a drives system we put in and later with a DeltaV I was involved in.

With flash able memory in the controllers, functionality can be added (most of which is not backward compatible) or functionality can be repaired but to say bring back the plc or slc programmers will not work. They could not change the core processor functionality so therefor had a very easy time of keeping things comparable (relatively speaking). The firmware was burned on a chipset that a lot of times was soldered to the boards or required a chipset changeout. (done many).

For instance to add Aoi or udt structures required changing the processor structure, and keeping it compatible would have required 2 sets of internal processor code, not feasible.

I complained to my management years ago and said that now not only did we have to administer and manage software but also now had to manage hardware's "software" also.

I don't like it, but I do like the functionality without throwing away the hardware. Now coming soon is that after version 20, the software will only work with L7x processors and higher. The changes coming to the firmware and software will not be able to run at all on older processors, so you will have to update the processor to use functionality coming, rumored descriptions in the processor and security etc onboard (better).

So now you will be managing multiple machines to troubleshoot multiple equipment.

You will fondly look back on these days as the "good old days" when it was so much easier and cheaper to manage....

Dave Ferguson
Control Systems Engineer


Posted by Brian Cervi on 3 October, 2011 - 9:03 am
Regarding "the good old days"... Using the latest version of software without re-flashing the executive firmware of a controller is entirely possible if you were using Schneider Electric products. The current version of Unity Pro software will connect and provide monitor/edit/control without having to update the firmware in either the Quantum, Premium and M340 controllers. Unity Pro gives you the choice of using the current version and leaving the controller alone, or updating both. You simply don't get the latest features or libraries.


Posted by Dave Ferguson on 3 October, 2011 - 8:08 pm
It is entirely possible with Rockwell also.

Dave


Posted by Steve Myres on 5 October, 2011 - 3:15 pm
With flash able memory in the controllers, functionality can be added (most of which is not backward compatible) or functionality can be repaired but to say bring back the plc or slc programmers will not work. They could not change the core processor functionality so therefor had a very easy time of keeping things comparable (relatively speaking). The firmware was burned on a chipset that a lot of times was soldered to the boards or required a chipset changeout. (done many).

Not entirely valid. I've flashed 5/05's to gain new processor functionality, and still been able to program it with the same software that will program everything all the way back to a SLC 5/naught.

For instance to add Aoi or udt structures required changing the processor structure, and keeping it compatible would have required 2 sets of internal processor code, not feasible.

But UDT's could be implemented as a macro-type functionality that the processor doesn't even know about. In any case, 5000's implementation of UDT's is so weak and incomplete (and contrary to the fundamental paradigm of CLX as I understand it) that to use it to justify ANY sacrifice seems like sleight-of-hand. For example, CLX originally was sold as a general purpose platform but somewhat enhanced for motion control. If so, why can you not put an AXIS in a UDT? (Nor in an array, for that matter)

Besides, the CLX derivatives seem to be the way AB/RS is moving to the exclusion of table-based PLC's like the PLC and SLC. For users who don't care about tag-basis or UDT's, they still have to pay the version-chaos price and get nothing in exchange.


Posted by Dave Ferguson on 6 October, 2011 - 7:43 am
I used some base examples, look at the things changed between version 10 and 20, it goes much deeper. I did not debate how things were or were not changed within the processor or whether they were complete or implemented properly, I debated why firmware was changeable and therefor why software versions were different and not backward compatible not good or bad.

My last comment is something very simple, if you do not like what Rockwell is doing, spend your money elsewhere !

I think you will find with all the MAJOR players, same story.......

Dave Ferguson
Control Systems Engineer


Posted by Steve Myres on 6 October, 2011 - 7:58 pm
From your response, it seems as if you find my posts combative, and if so, I sincerely apologize. This is the way I talk when I'm having a frank discussion of the pros and cons of a product. I'm not trying to trash you, RS, or the CLX per se, but if I say "X is wrong with the CLX" and you defend it but I feel your defense is resting on a poor foundation I'll point it out. It doesn't mean I hate the CLX or think it's a worthless product.

I used some base examples, look at the things changed between version 10 and 20, it goes much deeper.

This almost sounds as if you're blaming me because you picked an example that didn't prove your point. If good examples exist, use them. If they don't, or if you choose not to use them, don't shoot the reader for having the bad manners to notice.

My last comment is something very simple, if you do not like what Rockwell is doing, spend your money elsewhere!

This is a pretty salient point, and of course when purchasing any software, we do just that. We weigh the pros and cons and choose what we feel are the best options. Or at least that's what we'd LIKE to do. As integrators who don't always get to choose what platform we program on, like as not we end up having to buy EVERYTHING customers want, whether we personally think it's any good or not.

I think you will find with all the MAJOR players, same story.......

Not at all. The latest version of Omron CX-ONE programs everything back to the old Cnn processors from the DOS days. This would be equivalent to RS fielding one package that would program every revision of CLX's, PLC-5's and SLC's, but wouldn't do SLC-100/150's. I'm sure no one would beef about that. The latest Siemens S7 software will program any S7-300 or 400, no matter how old or what the firmware, I believe. The 200 is a different package, analgous to having a different package for SLC's from CLX's, but even then they're phasing that out for the S7-1200, which WILL be compatible with the same software as the 300 and 400 (and as I said, wasn't a firmware rev issue in the first place). Automation Direct's software has always been able to program any version of any of their hardware, even though firmware upgrades are sometimes required to implement new features.

In fact, not only is the situation not ubiquitous or nearly so as you suggest, in my limited experience it seems to be almost unique to AB, and in fact, to RS5000-compatible CLX and derivative line.


Posted by bob peterson on 7 October, 2011 - 9:52 am
In fairness to AB, it seems you may have a misunderstanding of how the Clx firmware and RSLogix software revisions work together.

If you have version 10 firmware, you have to use version 10 of the RSLogix software. All versions are back wards compatible and you can support as many versions as you want to on your computer. You just have to select that option when you load the software. So you can support every version from 10 to 18 (for example) if you want to. For some reason I have 10 thru 19 loaded except for 14 and 16. maybe those versions were never actually released or something. Who knows with AB sometimes.

It is true there is some functionality that later firmware versions have that earlier ones do not. That is also true of every other processor family I have ever run across, even if they try to make the different variations more invisible to you like some venders do.

I also find the user defined type handling a little annoying as far as not being able to handle axis types. It seems somewhat inexplicable to me that a processor that is supposed to be designed around integrated motion would not support that. I don't think you can put motion instructions inside of user defined functions either which would be real handy.

I suspect everyone has their own ideas of how to improve upon every product we use. one of the problems with a product like Clx is that they can't really change a lot of this stuff without upsetting a lot of their installed base. When you have as big of a chunk of the market as AB does (at least in the US), changing anything substantial is going to create a lot of pain for a lot of people. And they are pretty sensitive to that.


Posted by Dave Ferguson on 7 October, 2011 - 11:59 am
I agree wholeheartedly with you and that is what I was trying to point out to him also.

Some people seam to prefer you have to buy a new processor when you want new functionality.

Dave Ferguson
Control Systems Engineer


Posted by Steve Myres on 7 October, 2011 - 7:00 pm
Some people seem to prefer you have to buy a new processor when you want new functionality.

Dave, come on. To get to there from anything I've posted requires such extreme mental gymnastics it almost seems intentionally disingenuous.

AND you continue to ignore my counter-examples, which as far as my knowledge takes me, debunk your original claims and examples. If there's something wrong with my reasoning, point it out; I'm a big boy, I won't cry. Wailing, gnashing of teeth, and raising (and subsequent razing) of strawmen doesn't count as discussion.


Posted by Dave Ferguson on 8 October, 2011 - 11:49 am
I have been way to busy actually making a living to have time to really respond to this rant.

My point (which you seam to have missed) was that ALL of the MAJOR players, Rockwell, Emerson and my limited experience Siemens newer S7 do this (flash the hardware to add major functionality) which requires software changes. You can run multiple Sw revs on your development box with RA as opposed to say DeltaV which requires a complete system conversion (up to the zones feature). I do not consider Automation direct or even Omron to be a major player.....for the most part AD is a low end small toy market (low bidder) type of market (fire at will). (go read any of the product user annual usage numbers, small players) This is my point, not tearing apart implementation of UDT's etc. but just the fact that to implement a feature such as AOi's required a structure change and coming soon v21 will only be able to support new functionality on V7x processors because it is a massive rewrite.

You're argument to me comes across as why do I have to buy a new home computer to support Aero, or virtualization etc, why can't I just do everything with my x86 processor or my old Pentium, damn you Microsoft and Intel.......I for one am thankful that I can at least add this functionality to my old L6x er Pentium processor w/o throwing it away......

You seam to think that you HAVE to update the processor to exist, you do not......reread that, YOU DO NOT. But if you do want to do (analogy alert) say XP mode, virtualization, Aero, Internet integration, then you DO have to flash your processor (not buy a new one) and use the new software to talk to it. If you do not want to use these features, then keep using the older version. If you have some processors running one and another new, check the box to support both revisions (now) of hardware. DONE, no big deal....

Dave Ferguson

We can agree to disagree.....

Dave


Posted by Steve Myres on 8 October, 2011 - 7:51 pm
My point (which you seam to have missed) was that ALL of the MAJOR players, Rockwell, Emerson and my limited experience Siemens newer S7 do this (flash the hardware to add major functionality) which requires software changes.

I didn't miss that point, but it's not responsive to my original point, with which you seemed to disagree.

I do not consider Automation direct or even Omron to be a major player.....for the most part AD is a low end small toy market (low bidder) type of market (fire at will). (go read any of the product user annual usage numbers, small players)

Omron is huge in Asia, and you'll find them in a lot of Asian- and European-made equipment. Maybe not an RA or a Siemens but not a bit player. Yes, the AD/Koyo stuff is for small equipment only, not process plants or distributed control, but they sell a lot of them in the small custom machine market. But I know what you mean, they certainly don't have the major player "feel" about them.

You're argument to me comes across as why do I have to buy a new home computer to support Aero, or virtualization etc, why can't I just do everything with my x86 processor or my old Pentium, damn you Microsoft and Intel.....

I never said any of that stuff nor made the analogous PLC complaints. If I'm projecting that opinion unintentionally, I apologize for my lack of precision. I don't mind being given the option of upgrading a processor with new firmware for new capabilities and if that requires running the latest software version, I have no problem with that either. Refer to my earlier posts and the earlier part of this post.

My only beef, as I'm sure you can confirm if you reread my original post, is that newer software should support all firmware that's been fielded by the time the software is released, or at least within the preceding decade, and preferably without asking the user to tell the software that's what he wants while he's installing it, and DEFINITELY without requiring multiple full separate installs, either of the user or of his PC. And the NEXT version of the software should do the same thing, support all firmware in the field at the time of ITS release. It actually sounds from one of Bob's posts that the current versions of RSL500 may actually DO this (with the exception of asking the installer if he wants the old firmwares supported -- why even ask this?) and if that's the case, my disdain, while still richly deserved by the old versions, is obsolete. I further stated that contrary to your assertions, that RSL500 was capable of this as are many of the other players in the market (to the best of my knowledge, all of them), so for RA to say "Wah, it's too hard" is simply not credible. That's the sum total of my opinion as expressed in this thread, except for some tangential stuff between Bob and myself about the CLX feature set and date of introduction of UDT's.

You seam to think that you HAVE to update the processor to exist, you do not......reread that, YOU DO NOT. But if you do want to do (analogy alert) say XP mode, virtualization, Aero, Internet integration, then you DO have to flash your processor (not buy a new one) and use the new software to talk to it. If you do not want to use these features, then keep using the older version. If you have some processors running one and another new, check the box to support both revisions (now) of hardware. DONE, no big deal....

Again, not a thing that I actually said, but I agree nonetheless. People don't have to feel obligated to go around flashing PLC's in working applications to the latest firmware just because there IS one.

We can agree to disagree.....

Works for me. I still feel like you're ignoring my actual claims and demolishing claims I never made, but given your responses, perhaps you feel that's what I'm doing to you as well. If so, my apologies.


Posted by Steve Myres on 7 October, 2011 - 12:14 pm
In fairness to AB, it seems you may have a misunderstanding of how the Clx firmware and RSLogix software revisions work together.

Entirely possible, and if so, I'm willing to be schooled!

If you have version 10 firmware, you have to use version 10 of the RSLogix software. All versions are back wards compatible and you can support as many versions as you want to on your computer.

These two statements sound contradictory. I think I know what you mean though. This may be new since I worked with CLX. The way I believe it worked was that you could install v10, for example, and still not be able to program a v6 processor (like the OP) and not just because you didn't check v6 support when you installed v10. You actually had to INSTALL v6, and at one time, I think there were separate directory hierarchies and so on. Ridiculous. And then they improved it to an extent, in that when you started Logix 5000, the same shortcut was used for all firmware versions, and the versions installed were listed at the bottom of the splash screen. Given my previous experience, I assumed that this meant there were N full installs of RS5000 on the computer, and they had just created a unified front end for convenience. If that was a bad assumption on my part at that time, or if they've finally rectified it since then, so that multi-version support is really incorporated in one install, then that IS much better than I was aware.

It is true there is some functionality that later firmware versions have that earlier ones do not. That is also true of every other processor family I have ever run across, even if they try to make the different variations more invisible to you like some venders do.

Well sure, and I haven't objected to firmware upgrades per se, just to Dave saying that firmware upgrades are inherently incompatible with a single programming software package (or seeming to say so).

I also find the user defined type handling a little annoying as far as not being able to handle axis types. It seems somewhat inexplicable to me that a processor that is supposed to be designed around integrated motion would not support that. I don't think you can put motion instructions inside of user defined functions either which would be real handy.

I'm more offended by this than you are. As I see it, if they did it, it would be more than handy, it would be consistent with the CLX concept. It's their paradigm, why not live up to it? Why not wait till it's reached a substantial fraction of its promise before releasing it? I realize that sounds like the whines of a idealist who doesn't have to make money to survive, but it seems like surely after almost fifteen years on the market we shouldn't still be dealing with these kinds of issues.


Posted by bob peterson on 7 October, 2011 - 3:39 pm
>The way I believe it worked was that you could install v10, for example, and still not be able to program a v6
>processor (like the OP) and not just because you didn't check v6 support when you installed v10. You actually
>had to INSTALL v6, and at one time, I think there were separate directory hierarchies and so on. Ridiculous. And
>then they improved it to an extent, in that when you started Logix 5000, the same shortcut was used for all
>firmware versions, and the versions installed were listed at the bottom of the splash screen. Given my previous
>experience, I assumed that this meant there were N full installs of RS5000 on the computer, and they had just
>created a unified front end for convenience. If that was a bad assumption on my part at that time, or if they've
>finally rectified it since then, so that multi-version support is really incorporated in one install, then that IS much
>better than I was aware.

I don't know how it is implemented and don't much care. It is pretty seamless to me as far as what I have to do. I don't recall just how it was done 10 or 15 years ago. The early clunkiness has been improved considerably. I would not be at all surprised if some of the other PLCs that you think have a single structure really have multiple ones and just hide it from you better.

> I'm more offended by this than you are. As I see it, if they did it, it would be more than handy, it would be
>consistent with the CLX concept. It's their paradigm, why not live up to it? Why not wait till it's reached a
>substantial fraction of its promise before releasing it? I realize that sounds like the whines of a idealist who
>doesn't have to make money to survive, but it seems like surely after almost fifteen years on the market we
>shouldn't still be dealing with these kinds of issues.

I don't know what their real paradigm is. Keep in mind neither of these very useful features (user defined data and functions) were available until fairly recently. They ported over instructions of dubious utility from PLC5 that are rarely if ever used, but did not bother to add in a simple scale with parameter instruction like the SLC has. I asked a product manager why one time. He said because analog values can be scaled inside the analog module they are not needed. The thing is that only works for some analog modules and does nothing for other scaling issues that are not that uncommon. These days you could create your own SCP function but it would only work for a single data type. If you needed multiple data types in and out you would have to create a version for each combination.

Personally, I have never found the way the PLC works with motion to be all that impressive. Too many clunky functions that even 15 years after the fact are sometimes not well documented and still have quirks that have never been resolved. I have to say that I like the servo drive hardware I have used recently. The interface is pretty slick as well. But the coding, not so much.


Posted by Steve Myres on 8 October, 2011 - 1:01 am
I would not be at all surprised if some of the other PLCs that you think have a single structure really have multiple ones and just hide it from you better.

Here's my take on that: (1) I take it as a given that the differential amount of code to support each rev of firmware is, or should be, small in relation to the package as a whole, say 5%. Why should my hard drive space and organization take the hit to save RS programming man-hours? (2) If the differential hit per firmware rev is of an appropriate size, there's no payoff in failing to install support for every version the software can program. (3) If we take it as a given that most people will install compatibility with all available versions (or everybody, if the differential is so small as not to bother even giving them the option), then why bug them later at run time with a recitation of what firmware's they're equipped for? "All" is usually the best answer.

I don't know what their real paradigm is.

Not that anyone inside RS has shared their private thoughts with me, but I'll tell you what I thought it was when I first saw one 12 years ago or whatever: Object orientation in a PLC, and in a PLC somewhat specialized for motion control. UDT's are like structs, and with the addition of member functions, would essentially become classes.

Keep in mind neither of these very useful features (user defined data and functions) were available until fairly recently.

Functions, yes. UDT's, not so at all. They were there when I did that first CLX project in '99 or whenever, initially in v2.6. It was their presence, in addition to flat memory (tag basis) and memory visibility that made me think that about where they were trying to go.

They ported over instructions of dubious utility from PLC5 that are rarely if ever used, but did not bother to add in a simple scale with parameter instruction like the SLC has. I asked a product manager why one time. He said because analog values can be scaled inside the analog module they are not needed. The thing is that only works for some analog modules and does nothing for other scaling issues that are not that uncommon. These days you could create your own SCP function but it would only work for a single data type. If you needed multiple data types in and out you would have to create a version for each combination.

I'm not too exercised about this one. A CPT box will do everything a SCP box will do and then some, albeit not as smoothly. Are you serious, though, that user defined functions aren't type agnostic, like the built-in ones?? You can ADD a float to an integer and store the result in a float, but you can't write your own ADD box that doesn't care what type the parameters are?? Lame.

Personally, I have never found the way the PLC works with motion to be all that impressive. Too many clunky functions that even 15 years after the fact are sometimes not well documented and still have quirks that have never been resolved. I have to say that I like the servo drive hardware I have used recently. The interface is pretty slick as well. But the coding, not so much.

Agree on both counts. [By "PLC" here, I assume we're still talking about the CLX] I never thought the SLC with an HSRV module needed much improvement. You had to use MOV's and COP's and set bits in the I/O image of the card, but so what? It doesn't give me any great whoopies that the CLX equivalent is now NAMED "MAM" or "MAJ" or "MAS". Now bear in mind I didn't do any greatly advanced motion in the CLX, camming or coordinated motion and so on, so maybe that's where it distinguishes itself from earlier processors.

Also agree on the CLX hardware, it seems pretty serviceable. One minor gripe: The left side of the connector is for the higher ordered AXIS. Maybe there's some reason for this.

And again, to belabor the AXIS-in-a-structure issue yet a little more, that first app I did had multiple identical two axis cranes with a bunch of other functions. It would have been slick to create a Crane UDT that had two AXES in it, together with the other stuff, create an array of THOSE, and you could do Crane[this].Z.Position = 0, but NOOOOOO, that would make sense, so we have to do something to make those programmers earn their money! ;-) So on the very apps where one would choose a CLX (motion apps that would benefit from object orientation) are the ones where the platform bails and lets you down.


Posted by stress911 on 8 October, 2011 - 9:01 am
> If you have version 10 firmware, you have to use version 10 of the RSLogix
> software. All versions are back wards compatible and you can support as many
> versions as you want to on your computer.

If that was true we wouldn't have had to update the firmware in the first place. We were signaled by the RSL5K that in order to communicate with the PLC we needed to update the firmware. It did tell us the version was 15.4 and we were using 16.2. There was no warning it would wipe everything out either.

We only found out once the deed was done that there was nothing left to work with.


Posted by Dave Ferguson on 8 October, 2011 - 12:40 pm
I am not implying anything with the following.......as we are all doing more with less and less, and no time for training or mentoring or details and companies like RA short staffed and rushed as well.......

So you were presented with a box that said you needed to update a processor, and you are surprised that it had to clear the processor to do it?

I guess I can agree that the dialog box should have probably said "Are you sure you know what you are doing before doing this" or just refused to open it at all.....

I guess I blame your company's training program and your Engineering/IT group for not reviewing the release notes and explaining to you how Rockwell software works.

In my plant if someone encounters a message like this, they say "cancel" and go get more information. Apparently (sorry) your training is done on the fly, both ways work, one is just a little more expensive than the other

; )P

Sadly these results are happening more and more and I blame everyone including myself, we are all greedy and want ROI so we are Walmarting the world. Less people, less training and more shortcuts. If RA stock goes down in my 401k, dump them and lay off more people. No time to train we must do it faster, cheaper. Results like these WILL be repeated.....

Dave Ferguson
Control Systems Engineer


Posted by Bob Peterson on 8 October, 2011 - 1:10 pm
The message is misleading and I could understand why someone with little experience in Clx and RSL5000 might proceed.

There was nothing wrong with the firmware in the PLC. It just was not compatible with the version of software you had on your computer. If you had more experience with Clx you would probably have installed as many versions of Rslogix as you had versions out on the floor, and you might never have even noticed there was a difference in versions.

I think there actually is a warning before you start downloading the firmware that it will wipe out any existing programs in the PLC.

All previous software and firmware versions are backward compatible but you have to install support for those versions to get that compatibility.

I am not sure if you can upload an older version program out of a PLC into a newer version RSL5000. I don't know that I have ever tried it. Some of the messages in RSL5000 during up and down loading can be very confusing even to someone with a lot of experience.


Posted by sastry on 14 October, 2011 - 12:48 pm
I would like to share my experience on the CLX.

We had around 7 to 8 systems of ControlLogix PLCs - all L61/62/63 series controllers.

1. What i did is: I installed the PLC software on my laptop - all versions from 10.3 to 17.x

This enabled me to communicate with all the controllers & upload the logic from them.

My experience is - if you have a PLC with 13.0 firmware & you have a CLX software on laptop without 13.0 version (but having 14.x, 15.x, 16.x, 17.x installed on the laptop), then also you will not be able to communicate with the controller.

2. Recently i replaced the ControlLogix PLC CPU. The new PLC came with a firmware 10.3. the moment i put it onto the backplane, it did not come into run mode. So, tried communicating with the same through the laptop. It asked for upgradation of the flash memory with the software "control flash"... I run the utility & upgraded the firmware. Then i was allowed to download the logic onto the CPU. The entire process of upgradation, download of logic went on smoothly without any trouble.

My experience is little with the automation products - 15+ years with AB, Siemens, DeltaV, Honeywell EPKS. I found every product one & the same in terms of ease of use, programming & commissioning, flexibility of operation. However, i found AB PLC - a little bit tricky in terms of compatibility issues - firmware version visa vis PLC software version.

I still remember my earlier days with siemens PLC ---> just burn the logic onto a flash memory card & remove the same & keep it as a cabinet spare. Whenever there is a problem, just insert it into the slot of CPU, the program gets loaded in a jiffy.

Sastry MRKS
mrkssastry@yahoo.com

Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2014 Nerds in Control, LLC. All rights reserved.

Users of this site are benefiting from open source technologies, including PHP, MySQL and Apache. Be happy.


Fortune
They also surf who only stand on waves.
Advertise here
Advertisement
our advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive