J
James Ingraham
Dave:
>Please explain to me EXACTLY
>how DeltaV (PAC) and RSLogix (PAC/PLC)
>do not adhere nor have the ability to
>adhere to an object oriented
>methodology. <
RSL5K cannot do encapsulation. Encapsulation lets you describe a THING, as well as the ACTIONS that thing can do. A UDT is a structure. You cannot add an AOI to the UDT. An AOI is a function; you cannot define a data type within the AOI. So if I create a UDT of type "Gun" I can have data like size, muzzle velocity, caliber, number of rounds, etc. But I can't describe its ACTIONS, like "fire" and "clean." You can "instantiate" an AOI; an AOI does not persist the way a tag of type "My_UDT" does. It has ACTION, but no STATE.
As a sub-point of encapsulation, there is no way to hide data. If I pass a UDT to an AOI or JSR, the called routine can do anything it wants with that data. There's no such thing as "private" scope. Which means that a rogue routine could put the data into an invalid state, like setting the "HasFired" field to true without first turning the "SafetyIsOn" field to false.
There is no way to accomplish polymorphism in RSL5K. An AOI can take only the data types defined at design time. You can not create a "function pointer" that allows different AOIs/JSRs to be called depending on which UDT I send it. So I call the AOI "Fire" which takes a "Gun" UDT. If I have a different UDT called "Canon", I will have to create an entirely sepereate AOI that takes Canon as input instead of Gun. I have to do this for each data type.
There is no inheritance. A UDT can CONTAIN another UDT, but it can't EXTEND the UDT. This is one of the reasons there is no polymorphism. If there was a "Weapon" UDT, and Gun and Canon both extend it, I should be able to call any AOI that expects a "Weapon." Of course, since there is no encapsulation inheritance doesn't make much sense anyway. There are already no methods (AOIs) in the UDT, so "extending" the UDT doesn't buy me anything.
>Please detail how DeltaV class based
>objects and dynamos <
I don't know DeltaV, but that much certainly sounds like OOP.
>and RSI's AOI/UDT
>and Global Objects fail to adhere to
>the "norm". <
Well, RSL5K certainly adheres to the "norm." In the USA, it IS the norm. In Europe, Step 7 is the norm, which is comparable for the purposes of this discussion. That doesn't make them object-oriented. Again, I'm not sure object-oriented is particularly useful in the automation world. Whatever success OOP has had does not mean that procedural, functional, aspect-oriented, event-driven, or constraint programming aren't better choices.
>Please include DETAILED explanations of
>projects you have done in both products
>and their failures (using the latest
>versions listed) <
I haven't used RSLogix 5000 v17 yet. Been using v16 since it came out, and RSLogix 5000 itself since version 2.21. It has indeed come a long way, especially adding the AOI instructions. My company makes industrial gantry robots. These are usually 4-axis machines, in a Cartesian systems with a rotating manipulator. We run them off of ControlLogix (or CompactLogix) either with Allen-Bradley's Kinetix 6000 over SERCOS or Rexroth's IndraDrive over Profibus. (Actually, we're doing our first project talking to the IndraDrive's over EtherNet/IP, which will make me a lot happier.) In the past we had to use the analog motion control cards (MO2AE) to run the old Rexroth Ecodrive or A-B 1394. We did a few systems with 1394 or Ultra 3000 on SERCOS. The Logix series was the first viable PLC / PAC we found that could control our machines without our software guys (e.g. me) rebelling. I wouldn't call myself an expert, but I've logged a lot of hours on Logix. Feel free to check out
our website, http://www.sagerobot.com.
"DeltaV (8.5 and higher)"
Haven't used DeltaV, since I don't do plant / process control. Still, does DeltaV really count as an IEC 61131-3 based PAC? I mean, it's got a LOT more to it. In looking over the DeltaV website I can't actually find anything I would call a PAC. This could just be me being an idiot, but I don't see something that roughly equates to a ControlLogix or S7-300.
>I really appreciate
>(in advance) the DETAILED explanations
>you will provide <
<sigh> Detailed I can do. What I can't do, apparently, is "civil." I'm not entirely sure what I said that upset you. It certainly wasn't my intent. I went back, and I actually think my original post is pretty detailed. And my final statement was that there are no PLCs or PACs that have a built in Dictionary class. This is pretty specific. Granted, you can do maps in procedural languages. And maps are really a capability of a LIBRARY, not of a LANGUAGE. Still, Logix doesn't have it. FSC (File Search and Compare) is a good little instruction. It'll take any array, and I can even give it my own expression. That's getting pretty close. But I can't build that expression into a UDT, nor even an AOI. That's a prime example of NOT being object-oriented. Oh, and it's linear only. And SRT (File Sort) will only take primitives, not UDTs.
I know you were being facetious. But I am rather literal. So I'm answering your question literally, because that's what I do, even though most likely I will just upset you more, and all of the other people reading control.com will roll their eyes at how I just keep digging the hole deeper. Sorry. And sorry about the run-on sentences, too.
-James Ingraham
Sage Automation, Inc.
>Please explain to me EXACTLY
>how DeltaV (PAC) and RSLogix (PAC/PLC)
>do not adhere nor have the ability to
>adhere to an object oriented
>methodology. <
RSL5K cannot do encapsulation. Encapsulation lets you describe a THING, as well as the ACTIONS that thing can do. A UDT is a structure. You cannot add an AOI to the UDT. An AOI is a function; you cannot define a data type within the AOI. So if I create a UDT of type "Gun" I can have data like size, muzzle velocity, caliber, number of rounds, etc. But I can't describe its ACTIONS, like "fire" and "clean." You can "instantiate" an AOI; an AOI does not persist the way a tag of type "My_UDT" does. It has ACTION, but no STATE.
As a sub-point of encapsulation, there is no way to hide data. If I pass a UDT to an AOI or JSR, the called routine can do anything it wants with that data. There's no such thing as "private" scope. Which means that a rogue routine could put the data into an invalid state, like setting the "HasFired" field to true without first turning the "SafetyIsOn" field to false.
There is no way to accomplish polymorphism in RSL5K. An AOI can take only the data types defined at design time. You can not create a "function pointer" that allows different AOIs/JSRs to be called depending on which UDT I send it. So I call the AOI "Fire" which takes a "Gun" UDT. If I have a different UDT called "Canon", I will have to create an entirely sepereate AOI that takes Canon as input instead of Gun. I have to do this for each data type.
There is no inheritance. A UDT can CONTAIN another UDT, but it can't EXTEND the UDT. This is one of the reasons there is no polymorphism. If there was a "Weapon" UDT, and Gun and Canon both extend it, I should be able to call any AOI that expects a "Weapon." Of course, since there is no encapsulation inheritance doesn't make much sense anyway. There are already no methods (AOIs) in the UDT, so "extending" the UDT doesn't buy me anything.
>Please detail how DeltaV class based
>objects and dynamos <
I don't know DeltaV, but that much certainly sounds like OOP.
>and RSI's AOI/UDT
>and Global Objects fail to adhere to
>the "norm". <
Well, RSL5K certainly adheres to the "norm." In the USA, it IS the norm. In Europe, Step 7 is the norm, which is comparable for the purposes of this discussion. That doesn't make them object-oriented. Again, I'm not sure object-oriented is particularly useful in the automation world. Whatever success OOP has had does not mean that procedural, functional, aspect-oriented, event-driven, or constraint programming aren't better choices.
>Please include DETAILED explanations of
>projects you have done in both products
>and their failures (using the latest
>versions listed) <
I haven't used RSLogix 5000 v17 yet. Been using v16 since it came out, and RSLogix 5000 itself since version 2.21. It has indeed come a long way, especially adding the AOI instructions. My company makes industrial gantry robots. These are usually 4-axis machines, in a Cartesian systems with a rotating manipulator. We run them off of ControlLogix (or CompactLogix) either with Allen-Bradley's Kinetix 6000 over SERCOS or Rexroth's IndraDrive over Profibus. (Actually, we're doing our first project talking to the IndraDrive's over EtherNet/IP, which will make me a lot happier.) In the past we had to use the analog motion control cards (MO2AE) to run the old Rexroth Ecodrive or A-B 1394. We did a few systems with 1394 or Ultra 3000 on SERCOS. The Logix series was the first viable PLC / PAC we found that could control our machines without our software guys (e.g. me) rebelling. I wouldn't call myself an expert, but I've logged a lot of hours on Logix. Feel free to check out
our website, http://www.sagerobot.com.
"DeltaV (8.5 and higher)"
Haven't used DeltaV, since I don't do plant / process control. Still, does DeltaV really count as an IEC 61131-3 based PAC? I mean, it's got a LOT more to it. In looking over the DeltaV website I can't actually find anything I would call a PAC. This could just be me being an idiot, but I don't see something that roughly equates to a ControlLogix or S7-300.
>I really appreciate
>(in advance) the DETAILED explanations
>you will provide <
<sigh> Detailed I can do. What I can't do, apparently, is "civil." I'm not entirely sure what I said that upset you. It certainly wasn't my intent. I went back, and I actually think my original post is pretty detailed. And my final statement was that there are no PLCs or PACs that have a built in Dictionary class. This is pretty specific. Granted, you can do maps in procedural languages. And maps are really a capability of a LIBRARY, not of a LANGUAGE. Still, Logix doesn't have it. FSC (File Search and Compare) is a good little instruction. It'll take any array, and I can even give it my own expression. That's getting pretty close. But I can't build that expression into a UDT, nor even an AOI. That's a prime example of NOT being object-oriented. Oh, and it's linear only. And SRT (File Sort) will only take primitives, not UDTs.
I know you were being facetious. But I am rather literal. So I'm answering your question literally, because that's what I do, even though most likely I will just upset you more, and all of the other people reading control.com will roll their eyes at how I just keep digging the hole deeper. Sorry. And sorry about the run-on sentences, too.
-James Ingraham
Sage Automation, Inc.