PhilipW
Member
OK I'll concede I was holding forth a little. Yes the functionality is similar, but I would argue the GUI is far better. After all the same SFC language elements exist in both systems, so I have to agree with your point Gerry.
The same could be said of the Ladder language. Pretty much all ladder instruction exist in both systems, indeed PLC5 arguably has a few more, ie the DDT/FBC instructions, but the superior data organisation of CLX makes for much higher programming productivity in that system.
However I would argue the SFC presentation in CLX is a lot friendlier to work with than in PLC5, and I find that it exposes the more advanced aspects of the language in a much more accessible manner. (On the other hand maybe I should stop digging while still above ground level
)
The same could be said of the Ladder language. Pretty much all ladder instruction exist in both systems, indeed PLC5 arguably has a few more, ie the DDT/FBC instructions, but the superior data organisation of CLX makes for much higher programming productivity in that system.
However I would argue the SFC presentation in CLX is a lot friendlier to work with than in PLC5, and I find that it exposes the more advanced aspects of the language in a much more accessible manner. (On the other hand maybe I should stop digging while still above ground level
)PhilipW
Member
Definitely should have stopped digging!! Yes the DDT/FBC instructions are indeed in the CLX. Actually had another look at the CLX instruction set and discovered a couple of others I have yet to use. Still learning something every day.
Moving to ControlLogix
elledge, I've taught CLX courses to lots of PLC/SLC users and the general concensus is that it's fairly straightforward if you're just treating it as a very fast PLC/SLC. (indeed you can import "old" code and CLX will even make you things that look a lot like data tables). The architecture however enables you to do a lot of things that were simply impossible with the older A-B systems and if you want to explore those options then you need to spend some time either with the manuals, on a course or in this forum
Most of the users' questions involve the lack of data tables (there are some faint echoes of the S registers but that's it) and, as other posts have said, the differences in the programming software. Initially, there were no Custom Data Monitors, no Partial Downloads, no file comparisons, no usage......... lots of stuff "missing"; many of these features are now available (albeit not in exactly the same form) but, even without them, you'll feel pretty much at home in Logix5000. You might want someone to explain the Search function though
elledge, I've taught CLX courses to lots of PLC/SLC users and the general concensus is that it's fairly straightforward if you're just treating it as a very fast PLC/SLC. (indeed you can import "old" code and CLX will even make you things that look a lot like data tables). The architecture however enables you to do a lot of things that were simply impossible with the older A-B systems and if you want to explore those options then you need to spend some time either with the manuals, on a course or in this forum
Most of the users' questions involve the lack of data tables (there are some faint echoes of the S registers but that's it) and, as other posts have said, the differences in the programming software. Initially, there were no Custom Data Monitors, no Partial Downloads, no file comparisons, no usage......... lots of stuff "missing"; many of these features are now available (albeit not in exactly the same form) but, even without them, you'll feel pretty much at home in Logix5000. You might want someone to explain the Search function though
akreel
Member
elledge said:
This is probably understating it:
Well, you can write subroutines or use "stage programming" in other PLCs to get similar results. But, the CLX has something "new." You can set up multiple tasks in the processor. Each task is like a separate program with its own subroutines and tags. The programs in one task can't see the programs in another task, unless you use controller scoped tags to pass data between them.
You schedule when each task is supposed run. So if I tell a task to run every 50ms, it will break into whatever task is currently running. After the new task is done, the original program continues where it left off. So, programs run asynchronously, just like your IO scanning.
I can't really tell you what kind of voodoo black magic makes this work. But, it does work well and it can be a useful tool for programs with messaging to other PLCs.
AK
Allen Nelson
Member
Aaron:
The "scheduled tasks" in CLX are really not any different from an STI in PLC-5/SLC. But in a PLC-5/SLC, you only get one. In CLX, you get 16.
The big thing about going from PLC-5 to CLX is that, while you CAN make the CLX work pretty much like a PLC-5, it's not obvious how to do so.
And once you understand how, you aren't so sure you would want to do it that way.
Let's start with tags. In PLC-5, you had a "data file" called N7. You can make that file from the default lenght of 1 to, say, 60. If you need to grab a new word, you just pick one that looks likely (say N7:10). You'd annotate N7:10 appropriately. If you are something of a power-user, you might give N7:10 a "Symbol" name .
In ControlLogix, you start with that symbol name (except it's called a "tag".) Now you could create a tag called N7, and make it a "one-dimensional array" (N7[60]). And you could then just grab one, N7[10], and use it as you want.
But why? You can just as easily give it the same name as your PLC-5 symbol name, and it's a tag all by itself. You don't have to remember if the one you used was 10 or 11, or 20, you just have to remember what you called it.
I agree with Ron, that some of the monitoring features need improving (a CDM would be a huge improvement).
But as others have said, it's the wave of the future.
The "scheduled tasks" in CLX are really not any different from an STI in PLC-5/SLC. But in a PLC-5/SLC, you only get one. In CLX, you get 16.
The big thing about going from PLC-5 to CLX is that, while you CAN make the CLX work pretty much like a PLC-5, it's not obvious how to do so.
And once you understand how, you aren't so sure you would want to do it that way.
Let's start with tags. In PLC-5, you had a "data file" called N7. You can make that file from the default lenght of 1 to, say, 60. If you need to grab a new word, you just pick one that looks likely (say N7:10). You'd annotate N7:10 appropriately. If you are something of a power-user, you might give N7:10 a "Symbol" name .
In ControlLogix, you start with that symbol name (except it's called a "tag".) Now you could create a tag called N7, and make it a "one-dimensional array" (N7[60]). And you could then just grab one, N7[10], and use it as you want.
But why? You can just as easily give it the same name as your PLC-5 symbol name, and it's a tag all by itself. You don't have to remember if the one you used was 10 or 11, or 20, you just have to remember what you called it.
I agree with Ron, that some of the monitoring features need improving (a CDM would be a huge improvement).
But as others have said, it's the wave of the future.
akreel
Member
Allen Nelson said:
Well put.
It sure would be nice to be able to save a watch window.
I noticed the Rockwell forums have a wish-list section. Do you think the guys in charge of software development are watching those threads?
AK
PhilipW
Member
From the RSLogix help file:
"For large programs, you may want to schedule different parts of the process at different times. A task is used to schedule the execution of programs. A task can be scheduled to run continuously, periodically, or when triggered by a specific event. There can be up to 32 tasks in the controller."
In this part of the world we tend to use PLC's for process applications more often than is common elsewhere. Notably we use them in the dairy industry for large hybrid applications. A typical CPU might control 20-50 PID loops, 100-500 valves, have 100 motors on 2-5 Devicenet scanners, and total 1000-4000 IO and quite a lot of logic to handle it all.
But the key feature is that the process itself is reasonably slow. Not much physically happens much faster than 1 second. What we do is have NO logic in the Continous Task, and create tasks something like:
IO Devices 100msec Priority 2
Process 200msec Priority 4
Comms 400msec Priority 6
Reporting 800msec Priority 12
This method groups logic into tasks based on how often it NEEDS processing.
If all this logic was jammed into one long Continuous task, the variation in scantime would be large, by contrast this method is very deterministic and frees up CPU resource. Usually we set the Time Slice value to something > 50% and gain heroically quick HMI comms.
Of course this approach is absolutely inappropriate for high speed machinery, but it illustrates how Periodic tasks are useful. Although the system will allow 32 such tasks, I cannot imagine an application that would ever use more than 4 or 5. It is important to use Periodic Tasks for the purpose of segregrating logic by TIME, not by function.
At Version 13 we also got the ability to create Event Tasks. For some applications it is really useful for an external Input event or Motion control event to interupt the main task and execute a smaller task rapidly in response.
"For large programs, you may want to schedule different parts of the process at different times. A task is used to schedule the execution of programs. A task can be scheduled to run continuously, periodically, or when triggered by a specific event. There can be up to 32 tasks in the controller."
In this part of the world we tend to use PLC's for process applications more often than is common elsewhere. Notably we use them in the dairy industry for large hybrid applications. A typical CPU might control 20-50 PID loops, 100-500 valves, have 100 motors on 2-5 Devicenet scanners, and total 1000-4000 IO and quite a lot of logic to handle it all.
But the key feature is that the process itself is reasonably slow. Not much physically happens much faster than 1 second. What we do is have NO logic in the Continous Task, and create tasks something like:
IO Devices 100msec Priority 2
Process 200msec Priority 4
Comms 400msec Priority 6
Reporting 800msec Priority 12
This method groups logic into tasks based on how often it NEEDS processing.
If all this logic was jammed into one long Continuous task, the variation in scantime would be large, by contrast this method is very deterministic and frees up CPU resource. Usually we set the Time Slice value to something > 50% and gain heroically quick HMI comms.
Of course this approach is absolutely inappropriate for high speed machinery, but it illustrates how Periodic tasks are useful. Although the system will allow 32 such tasks, I cannot imagine an application that would ever use more than 4 or 5. It is important to use Periodic Tasks for the purpose of segregrating logic by TIME, not by function.
At Version 13 we also got the ability to create Event Tasks. For some applications it is really useful for an external Input event or Motion control event to interupt the main task and execute a smaller task rapidly in response.
PhilipW
Member
And for those who haven't seen them yet here is a typical UDT structure. (And a very simple one indeed. This one is only 28 bytes long; I recently worked with one almost 10,000 bytes long!!)
PhilipW
Member
And then a simple fragment of logic using the above UDT. Note ..all the comments have been automatically generated by concatenating the Valve comment which is "Inlet valve" with the UDT member comment.
Last edited:
NorthControl
Member
Thanx for the welcoming!
I see some questions about monitoring..... any ideas about how to monitor the tags you need, and NOT all the ones you don't need (tag list)?
Today as the latest, I was looking for some tags.......eventually I found them, but it wasn't that easy. And I realize the problem with monitoring several tags (spread out) at the same time.
Is there no way to make your own table? We cross-copy the IO to new tags, so the new tags will be grouped together.... but what about the physical IO?
Again I am AB-fresh so I would appreciate hints to give me a good start!
PS! Ron, some expensive toys you have in that bedroom....
I see some questions about monitoring..... any ideas about how to monitor the tags you need, and NOT all the ones you don't need (tag list)?
Today as the latest, I was looking for some tags.......eventually I found them, but it wasn't that easy. And I realize the problem with monitoring several tags (spread out) at the same time.
Is there no way to make your own table? We cross-copy the IO to new tags, so the new tags will be grouped together.... but what about the physical IO?
Again I am AB-fresh so I would appreciate hints to give me a good start!
PS! Ron, some expensive toys you have in that bedroom....
Ron Beaufort
Lifetime Supporting Member
so what did I step into anyway? ...
oh, come on fellows ... this started out as a VERY simple question from our new friend elledge ... who asked:
all I was trying to do was answer this VERY simple question in a VERY simple way ...
now it looks like I’m being drafted into the anti-CLX army ... that just isn’t so ... and please note that I’m not offended in any way ... it’s just that I’m NOT against the ControlLogix platform at all ... and I apologize if I my comments were able to be interpreted incorrectly ...
you need to understand that most of my early exposure to ControlLogix and to RSLogix5000 came during my days of working as the resident “answer man” for an Allen-Bradley distributor ... time and again, the phone would ring with another frustrated and irate customer on the line ... turns out that the guy was VERY familiar with Allen-Bradley PLC-5 hardware and RSLogix5 software ... and VERY familiar with Allen-Bradley SLC-500 hardware and RSLogix500 software ... and so naturally he just ASSUMED that he would have NO problem at all with the new Allen-Bradley ControlLogix hardware and RSLogix5000 software ... wrong answer! ... now he’s got a machine down ... the boss is breathing down his neck ... a deadline is rapidly approaching ... and all the heck he wants to do is track down the condition that’s keeping the “%!#*%!&” pump from working ... “so where the “%!#*%!&” is my trusty old “Find All” search feature?” he wants to know ... and I, the answer man, must bear the full brunt of his verbal abuse when I tell him that the new-and-improved latest-and-greatest whiz-bang RSLogix5000 software doesn’t have a “Find All” search feature ... and now I’ve got to try to calm this frustrated irate customer down enough to explain to him – over the phone – how to go about tracking down a problem that (1) I can’t see, (2) he’s in NO mood to adequately describe, with (3) software with which he is totally unfamiliar, with (4) a pressing deadline, and (5) a boss that can’t understand why his ace PLC technician can’t figure out how to get this new-and-improved latest-and-greatest offering from Allen-Bradley to control the “%!#*%!&” machine so that he can go back to making money again ...
so to sum all of this up ... no, I do not have anything against ControlLogix hardware ... as I said in an earlier post, and I quote:
so actually I’m looking forward to working more and more with the new CLX in the future ... but I’m certainly not alone in wishing that the guys developing the RSLogix5000 software had spent a lot more time researching what was “good” about RSLogix5 and RSLogix500 before they started reinventing the whole darn interface wheel ... (the rumor that I’ve heard is that it’s not even Rockwell software but some third party contractor doing the software development) ...
so cut me some slack, please, fellows ... elledge asked a simple question ... and I offered a simple answer ... my advice to elledge remains the same: if you think that you’re going to take your previous experience with Allen-Bradley’s PLC-5 hardware and RSLogix5 software and just sit down with Allen-Bradley’s ControlLogix hardware and RSLogix5000 software and feel right at home - well, I hate to be the one to tell you so, but that just ain’t going to happen ... it’s going to take some work on your part before you’re going to feel comfortable with this new beast ... and if you’re like everyone else I’ve talked to, even once you get “used to it”, you STILL won’t like the software ...
as for most of you other guys ... remember that you’re approaching this same discussion from the viewpoint of people who design systems, write programs, and in general have adequate time to experiment with this new system and to learn all of the significant improvements and advantages that it offers ...
now I may be wrong, but (based on his original post) I don’t think that our new friend elledge fits in that same category ... it sounds to me like he’s going to be one of those “in the trenches” maintenance techs who are going to have to learn how to live with this new beast as quickly as possible – and often their initial introductions are going to be “under fire” ... I doubt very seriously that guys like elledge are going to be interested in all of the “bells-and-whistles” and “gee whiz” programming capabilities that you guys (and incidentally, I too) find so intriguing ... they just want to know “how do I track down the condition that’s keeping the “%!#*%!&” pump from running” ... they already know exactly how to do that with Allen-Bradley PLC-5 hardware using RSLogix5 ... and with Allen-Bradley SLC-500 hardware using RSLogix500 ...
but now all of a sudden they’re faced with trying to do exactly the same troubleshooting steps using RSLogix5000 ... and it’s not a pretty picture ...
so please keep in mind that the vast majority of guys that I work with on a day-to-day basis are NOT programmers interested the latest “bells-and-whistles” for the new system that they’re designing ... instead most of “my” guys are maintenance technicians who are far more interested in the “nuts-and-bolts” of how to troubleshoot an existing system and get it back working again ...
and I am NOT (I repeat NOT) trying to imply that these maintenance technicians aren’t just as sharp as anyone else that you’ll run across in this trade ... it’s just that they have a LOT of other issues on their minds besides how “elegant” or how “efficient” the PLC’s program can be written ... they’ve got burnt up motors, broken wires, stuck solenoid valves, etc., etc. to work on too ...
oh, come on fellows ... this started out as a VERY simple question from our new friend elledge ... who asked:
all I was trying to do was answer this VERY simple question in a VERY simple way ...
now it looks like I’m being drafted into the anti-CLX army ... that just isn’t so ... and please note that I’m not offended in any way ... it’s just that I’m NOT against the ControlLogix platform at all ... and I apologize if I my comments were able to be interpreted incorrectly ...
you need to understand that most of my early exposure to ControlLogix and to RSLogix5000 came during my days of working as the resident “answer man” for an Allen-Bradley distributor ... time and again, the phone would ring with another frustrated and irate customer on the line ... turns out that the guy was VERY familiar with Allen-Bradley PLC-5 hardware and RSLogix5 software ... and VERY familiar with Allen-Bradley SLC-500 hardware and RSLogix500 software ... and so naturally he just ASSUMED that he would have NO problem at all with the new Allen-Bradley ControlLogix hardware and RSLogix5000 software ... wrong answer! ... now he’s got a machine down ... the boss is breathing down his neck ... a deadline is rapidly approaching ... and all the heck he wants to do is track down the condition that’s keeping the “%!#*%!&” pump from working ... “so where the “%!#*%!&” is my trusty old “Find All” search feature?” he wants to know ... and I, the answer man, must bear the full brunt of his verbal abuse when I tell him that the new-and-improved latest-and-greatest whiz-bang RSLogix5000 software doesn’t have a “Find All” search feature ... and now I’ve got to try to calm this frustrated irate customer down enough to explain to him – over the phone – how to go about tracking down a problem that (1) I can’t see, (2) he’s in NO mood to adequately describe, with (3) software with which he is totally unfamiliar, with (4) a pressing deadline, and (5) a boss that can’t understand why his ace PLC technician can’t figure out how to get this new-and-improved latest-and-greatest offering from Allen-Bradley to control the “%!#*%!&” machine so that he can go back to making money again ...
so to sum all of this up ... no, I do not have anything against ControlLogix hardware ... as I said in an earlier post, and I quote:
so actually I’m looking forward to working more and more with the new CLX in the future ... but I’m certainly not alone in wishing that the guys developing the RSLogix5000 software had spent a lot more time researching what was “good” about RSLogix5 and RSLogix500 before they started reinventing the whole darn interface wheel ... (the rumor that I’ve heard is that it’s not even Rockwell software but some third party contractor doing the software development) ...
so cut me some slack, please, fellows ... elledge asked a simple question ... and I offered a simple answer ... my advice to elledge remains the same: if you think that you’re going to take your previous experience with Allen-Bradley’s PLC-5 hardware and RSLogix5 software and just sit down with Allen-Bradley’s ControlLogix hardware and RSLogix5000 software and feel right at home - well, I hate to be the one to tell you so, but that just ain’t going to happen ... it’s going to take some work on your part before you’re going to feel comfortable with this new beast ... and if you’re like everyone else I’ve talked to, even once you get “used to it”, you STILL won’t like the software ...
as for most of you other guys ... remember that you’re approaching this same discussion from the viewpoint of people who design systems, write programs, and in general have adequate time to experiment with this new system and to learn all of the significant improvements and advantages that it offers ...
now I may be wrong, but (based on his original post) I don’t think that our new friend elledge fits in that same category ... it sounds to me like he’s going to be one of those “in the trenches” maintenance techs who are going to have to learn how to live with this new beast as quickly as possible – and often their initial introductions are going to be “under fire” ... I doubt very seriously that guys like elledge are going to be interested in all of the “bells-and-whistles” and “gee whiz” programming capabilities that you guys (and incidentally, I too) find so intriguing ... they just want to know “how do I track down the condition that’s keeping the “%!#*%!&” pump from running” ... they already know exactly how to do that with Allen-Bradley PLC-5 hardware using RSLogix5 ... and with Allen-Bradley SLC-500 hardware using RSLogix500 ...
but now all of a sudden they’re faced with trying to do exactly the same troubleshooting steps using RSLogix5000 ... and it’s not a pretty picture ...
so please keep in mind that the vast majority of guys that I work with on a day-to-day basis are NOT programmers interested the latest “bells-and-whistles” for the new system that they’re designing ... instead most of “my” guys are maintenance technicians who are far more interested in the “nuts-and-bolts” of how to troubleshoot an existing system and get it back working again ...
and I am NOT (I repeat NOT) trying to imply that these maintenance technicians aren’t just as sharp as anyone else that you’ll run across in this trade ... it’s just that they have a LOT of other issues on their minds besides how “elegant” or how “efficient” the PLC’s program can be written ... they’ve got burnt up motors, broken wires, stuck solenoid valves, etc., etc. to work on too ...
Ron Beaufort
Lifetime Supporting Member
and now I hate to do this but somehow I feel the need to answer a few comments point by point ... and no offense intended here ...
first from PhillipW:
thanks for the “usual high standard” compliment ...
no argument there ...
well ... maybe from your point of view, Phillip, and for other accomplished programmers like you ... but please consider this from the viewpoint of elledge and other maintenance technicians ... all of the advantages which you yourself just mentioned:
are like music to these guys’ ears ... these “in-the-trenches” troops aren’t likely to ever notice the PLC’s “limitations” which you go on to list ...
in fact, all the maintenance technicians care about is: “it does a good job of controlling the machine ... and if it quits working right, I know how to fix it” ... period ...
my point is that we all have different viewpoints ... I was considering the maintenance technician’s viewpoint when I wrote my opinions ... your viewpoint is perfectly valid ... and I certainly wouldn’t argue with it ... but it’s also not the only viewpoint to be considered in this discussion ...
now I can tell from the tone of your post that you meant no offense ... and I can assure you that none was taken ... but I really had no intention of entering into a “which-PLC-is-better” debate ... and I’m quite surprised that the discussion has gone this far down that particular road ... I just know in my heart-of-hearts that elledge wasn’t asking for this type of “feature comparison” from one platform to another ... but it’s all still good stuff to talk about ...
I’m sorry if I gave the impression that this was a “mountain” of an issue ... but you’ll have to admit, in some cases it can cause “issues” ... one case in point:
a customer had a program running perfectly in an SLC-5/04 processor ... but unknown to the customer, someone had inadvertently programmed a “double-coil” situation for one of the machine’s motor starters ... now even though this was an “improper” programming technique, it never caused any problems since the “last rung” in the scan always gave the proper control for the output ... specifically, the incorrect logic of the “first rung” was always overwritten by the correct logic of the “last rung” ... and so the machine worked perfectly for a couple of years ... later it was decided to take the program logic away from the SLC-5/04 and “port it” over to a new ControlLogix system which was controlling a much larger system nearby ... someone “copied-and-pasted” the ladder rungs .. and “searched-and-replaced” the addresses ... and shifted the I/O wiring over to the new ControlLogix hardware ... and turned the system on ...
and the motor starter went totally !nuts! ... because ...
the SLC platform only updated the field output once (at the end of the scan) when the “correct” (last rung) logic had properly controlled the bit ...
but the new CLX platform was able to also update the field output DURING the scan, when the “incorrect” (first rung) logic had driven the bit to its “other” condition ...
now I didn’t personally see this thing “go nuts” ... but the witnesses that I talked to said that you could have read a newspaper by the arcing-and-sparking from that chattering motor starter ... and I can assure you that to these guys “in the field” this little “asynchronous I/O scan” detail did indeed seem to be quite a “mountain” of an issue ...
but no, personally I don’t think that the asynchronous I/O scan is all that big a deal ... and I’m sorry if I somehow gave a different impression ... but elledge DID ask about “differences” ... and this IS indeed a “difference” ... and so I mentioned this particular “difference” and then went on to say:
now that doesn’t sound like a “mountain” issue statement does it? ...
actually I had the specific situation that I’ve just described in mind when I made that statement ... then later jimpad said:
I posted a simple common “workaround” to help jimpad alleviate his headaches ... and again I apologize if anyone thought that I was making a “mountain” out of this particular “difference” ...
and more from PhillipW ...
personally, Phillip, I do too ... but I think that you’ll have to admit that they could look more than a little “bizarre” to someone who’s only been exposed to “old-style” ladder logic ... I didn’t say that there was anything WRONG with them ... but I thought that I’d mention them as just one more of the “differences” that elledge was asking about ...
and on that point, Phillip, we’re on exactly the same wavelength ... personally I’m waiting for some of the same “flexibility” and “navigation features” that I’ve come to love from the older RSLogix5 and RSLogix500 software packages ... if those could just be incorporated into the “latest-and-greatest” RSLogix5000 package, then I’d have MUCH less to complain about when it comes to the ControlLogix system ...
so once again, I’m sorry if anyone got the impression that I’m anti-ControlLogix ... I am not ... and I even said EXACTLY that in response to a question from NorthControl ...
and I still stand by that ... it ain’t “bad” ... it’s just “different” ... and I’ve yet to meet anyone who thinks that the new RSLogix5000 software is anywhere near as polished as the older RSLogix5 and RSLogix500 packages ...
in closing ... a note to PhillipW ... please don't take this as anything like a personal attack ... it's just that your comments make it obvious that I had been misinterpreted ... and actually I feel that I should apologize to you for writing something so poorly that it could be misinterpreted in such a way ... hopefully I've made myself much more clear now on how I actually feel about the ControlLogix hardware ... (but I still don't like the software) ...
first from PhillipW:
thanks for the “usual high standard” compliment ...
no argument there ...
well ... maybe from your point of view, Phillip, and for other accomplished programmers like you ... but please consider this from the viewpoint of elledge and other maintenance technicians ... all of the advantages which you yourself just mentioned:
are like music to these guys’ ears ... these “in-the-trenches” troops aren’t likely to ever notice the PLC’s “limitations” which you go on to list ...
in fact, all the maintenance technicians care about is: “it does a good job of controlling the machine ... and if it quits working right, I know how to fix it” ... period ...
my point is that we all have different viewpoints ... I was considering the maintenance technician’s viewpoint when I wrote my opinions ... your viewpoint is perfectly valid ... and I certainly wouldn’t argue with it ... but it’s also not the only viewpoint to be considered in this discussion ...
now I can tell from the tone of your post that you meant no offense ... and I can assure you that none was taken ... but I really had no intention of entering into a “which-PLC-is-better” debate ... and I’m quite surprised that the discussion has gone this far down that particular road ... I just know in my heart-of-hearts that elledge wasn’t asking for this type of “feature comparison” from one platform to another ... but it’s all still good stuff to talk about ...
I’m sorry if I gave the impression that this was a “mountain” of an issue ... but you’ll have to admit, in some cases it can cause “issues” ... one case in point:
a customer had a program running perfectly in an SLC-5/04 processor ... but unknown to the customer, someone had inadvertently programmed a “double-coil” situation for one of the machine’s motor starters ... now even though this was an “improper” programming technique, it never caused any problems since the “last rung” in the scan always gave the proper control for the output ... specifically, the incorrect logic of the “first rung” was always overwritten by the correct logic of the “last rung” ... and so the machine worked perfectly for a couple of years ... later it was decided to take the program logic away from the SLC-5/04 and “port it” over to a new ControlLogix system which was controlling a much larger system nearby ... someone “copied-and-pasted” the ladder rungs .. and “searched-and-replaced” the addresses ... and shifted the I/O wiring over to the new ControlLogix hardware ... and turned the system on ...
and the motor starter went totally !nuts! ... because ...
the SLC platform only updated the field output once (at the end of the scan) when the “correct” (last rung) logic had properly controlled the bit ...
but the new CLX platform was able to also update the field output DURING the scan, when the “incorrect” (first rung) logic had driven the bit to its “other” condition ...
now I didn’t personally see this thing “go nuts” ... but the witnesses that I talked to said that you could have read a newspaper by the arcing-and-sparking from that chattering motor starter ... and I can assure you that to these guys “in the field” this little “asynchronous I/O scan” detail did indeed seem to be quite a “mountain” of an issue ...
but no, personally I don’t think that the asynchronous I/O scan is all that big a deal ... and I’m sorry if I somehow gave a different impression ... but elledge DID ask about “differences” ... and this IS indeed a “difference” ... and so I mentioned this particular “difference” and then went on to say:
now that doesn’t sound like a “mountain” issue statement does it? ...
actually I had the specific situation that I’ve just described in mind when I made that statement ... then later jimpad said:
I posted a simple common “workaround” to help jimpad alleviate his headaches ... and again I apologize if anyone thought that I was making a “mountain” out of this particular “difference” ...
and more from PhillipW ...
personally, Phillip, I do too ... but I think that you’ll have to admit that they could look more than a little “bizarre” to someone who’s only been exposed to “old-style” ladder logic ... I didn’t say that there was anything WRONG with them ... but I thought that I’d mention them as just one more of the “differences” that elledge was asking about ...
and on that point, Phillip, we’re on exactly the same wavelength ... personally I’m waiting for some of the same “flexibility” and “navigation features” that I’ve come to love from the older RSLogix5 and RSLogix500 software packages ... if those could just be incorporated into the “latest-and-greatest” RSLogix5000 package, then I’d have MUCH less to complain about when it comes to the ControlLogix system ...
so once again, I’m sorry if anyone got the impression that I’m anti-ControlLogix ... I am not ... and I even said EXACTLY that in response to a question from NorthControl ...
and I still stand by that ... it ain’t “bad” ... it’s just “different” ... and I’ve yet to meet anyone who thinks that the new RSLogix5000 software is anywhere near as polished as the older RSLogix5 and RSLogix500 packages ...
in closing ... a note to PhillipW ... please don't take this as anything like a personal attack ... it's just that your comments make it obvious that I had been misinterpreted ... and actually I feel that I should apologize to you for writing something so poorly that it could be misinterpreted in such a way ... hopefully I've made myself much more clear now on how I actually feel about the ControlLogix hardware ... (but I still don't like the software) ...
PhilipW
Member
is obviously the line that has raised your blood pressure Ron. I think this was a trans-Pacific cultural misconnection. Actually I meant it as a kind of back handed compliment. beerchug
The other points you make about maintenance guys running into issues the first time they attempt to use CLX raises some interesting points.
1. Expecting someone to troubleshoot a new system under the kind of pressure you describe without adequate training and resources, reeks of management incompetence and/or pennypinching.
2.
These days I try to write logic which provides diagnostic messages for all devices and sequences. After all most PLC's have some form of HMI attached to them, and it is quite easy to generate a status and fault text message for the above pump. This means our harried maintenance techie doesn't even have to look into the logic.
3.
I guess this illustrates the increasing professional gap between electrical maintenance techs who can read and troubleshoot ladder, and automation engineers who design and create programs. This is often seen when some folk advocate the ladder only KISS style logic, contrasted with those who are comfortable using multiple languages, indirection and subroutines to produce highly efficient and functional programs. This begs some interesting questions about professional development in our industry.
3. Yes I still have a liking for the RSLogix5/500 software, but after using RSLogix5000 fairly intensively now for about four years now I really don't have any major grizzles.
I've just started a new project with the new Schneider Unity software, well I just got to load it, and it too will be a learning curve. Right now I hate it, but that is only because it is going to take me time to figure out how to do simple tasks I can do in seconds with software I am familiar with.
Similar Topics
Why does the controllogix redundancy modules use a single mode fiber vs multimode fiber?
Hello,
I have two 16 point input cards and 1 16 point output card showing module faulted on my IO tree in Logix Designer.
The fault code is...
Hello,
My associate and I are trying to sync up two ControlLogix racks (7-slot chassis) with identical modules. We are able to see the secondary...
Trying to setup a message read via Ethernet.
I have the path setup as 1, 1, 2, 192.168.66.10
I get an error code 1, ext err 315.
I am beating...
I have a redundant ControlLogix being set up. This program reads a value from a remote site which happens to be SLC PLC. Rockwell mentions SLC...