Control.com - Nerds in Control

I have been out of the PLC programming field for a couple years now, and was wondering what's happening in the field lately. Specifically, I wonder if anyone's made any advancement towards a more "object-oriented" paradigm in PLC control software, especially the concept of "inheritance".

I checked out some threads here at control.com, some of them pretty dated. Some of the comments really struck me, in that the posters simply couldn't imagine the benefits of object-oriented programming techniques in control system integration. I think that we've already seen the benefits of the implementation of some of the concepts of OOP in PLC control software, and just haven't seen the rest of the concepts effectively implemented yet. When they do, I think that they will appear to be facepalm-slappingly obvious.

Some of the most important programming concepts addressed by OOP are:

* encapsulation
* modularity
* polymorphism
* inheritance

We've had encapsulation and modularity in PLC programming ever since the first PLC came out which supported multiple program "files" and data storage whose access is limited by specific program "files". I think the A/B PLC-5 used to do (does!) that. RSLogix does it with program files and local variables whose scope is restricted to that file.

What PLC programming seems to be lacking is real inheritance. Today, using RSLogix, for example, you need to create a program module and copy-paste it once for however many instances you need in a particular project. With Modicon, you can create program modules (UFBs) which can be plugged in where you need them. We're almost there, there's no real inheritance -- yet!

Using PC programming languages which implement inheritance, one can choose to inherit the implementation of a function from a parent class, or override that function in the child class. Applying this to PLC programming, what I imagine is a PLC programming suite which allows you to create a "base class" which can be customized for a particular instance when necessary. In PC programming, base class (or "parent class") *functions* can be overridden in derived classes. In the PLC environment, it makes sense for individual *rungs* of ladder logic to be overridden in child classes.

This would be massively convenient. Imagine that you were writing a program to control 12 conveyors that behaved in practically the same way. You could write one base class "conveyor", and then implement it with 12 instances of the class, each tied to a different input structure and output structure. But let's say one of the conveyors has a special case which needs to be addressed -- one rung needs to be changed. Just create a new class inherited from the base class. In the new class, inherit all the rungs of the parent class, but override the rung(s) you need to override for this particular implementation.

The cool thing about this is when you get to the factory floor and start debugging your application. When you find that the base class needs to be modified a little bit, you can do it in one place, and have the programming software change it in every instance. Those instances with customized rungs overriding the base class implementation should still override them.

Your programming software should indicate when browsing the ladder logic whether a rung is defined in the parent class or overridden in the derived class, in instances which have been derived from a parent class.

I don't know exactly how this would be implemented for IL, ST, and FBD routines. I've done my share of programming with these languages, but mostly for things that ladder couldn't do well. The issue here is the granularity of the program. In ladder logic, each rung is separable. In FBD, not so much.

Does anyone know of a PLC product that allows this? I did a little research this afternoon, and found ABB's Sattline program (http://www.abb.com/product/seitp334/e3d927acb567331bc12571e100335b3e. aspx). Wading through their techspeak gobbledygook, I get the impression that they actually did succeed in implementing object-oriented programming principle in a control system. Anyone here have any experience with Sattline? Can you share your experience and let us know if Sattline implements what I am talking about?

Thanks!

RSLogix 5k does this today in version 16 and above with something called an AOI (Add On Instruction). Basically (and this is the short version), you build a custom instruction which can be built for either ladder of function block languages (that I have done). It can be programmed inside in any of the 61131-3 languages (only 4 in RSLogix) inside itself. You put the "parameters" that you desire inside of it. You can either make it view only, or locked down or wide open. You can view "instances" of it that each stand on their own.

A month later, you can come in and modify the "master" (the class object) and all of the "children" will get that property (inherit) or code change if you desire.

I have not used it for 20 years because it has only been there for a few but the time I have used it shows that we are there. They also have a "sister" function in the HMI (RSView SE/ME) to create "class based" graphics (called global objects) that can be tied to these instances and work relatively the same way.

On a side note, I also believe that Siemens has this ability although I have not used it. Also DeltaV which is not considered a PLC but a DCS although I would argue that they are all now PAC (Programmable Automation Controllers) also has this ability. They call it Custom Function Blocks and Dynamo's which since the graphics engine is Intellution, leads me to believe they can do it also (for Graphics).

So the answer is YES, there are PLC/PAC's doing this today and yes it is very, very helpful.

For instance I built standard valves and motor logic (2 state with no limits, 2 state with one limit, 2 state with 2 limits, 2 state with motor feedback etc.) I included every "property" that I could think of for a valve or motor. Inside the "block" I wrote it in ladder so that technicians could diagnose easily, and then I just punch them out as needed, and each stands as its own instance of the parent.

Just skimmed the surface..............and could talk about for hours................(and have).

Dave Ferguson

Check out Codesys, an object oriented development platform that is device independent (specific hardware 'targets' are loosely 'driver files' are needed for specific hardware platforms.)

It is mostly, as far as I can tell, used as at the OEM level, because of support issues at the end user level.

I'm told the development software is free (two hour run time, can be restarted without difficulty); one pays for the run-time license(s)

http://www.3s-software.com/

David

Thanks. Just for clarification, though:

I wrote: "Those instances with customized rungs overriding the base class implementation should still override them."

Part of the convenience of inheritance in PC programming languages is the ability to override functions, and only those functions you wish to override. I'm still not clear if that's what you are talking about in existing PLC languages.

Part of the issue is the ease of implementation. For example, Modicon has something like "classes" using UFBs. But the implementation is horrible. You have to exit the programming editor in order to start the UFB editor. Why? Seems kind of silly, you know?

When RSLogix came out, they introduced a new paradigm in working with data, including I/O, because the new software made that paradigm central to the way things work. Is what you are talking about essential to the way you work with those programming suites? Or just an after-thought?

Since you have addressed a large number of different issues, I have interspersed my replies with your original statements.

ZMS: I have been out of the PLC programming field for a couple years now, and
> was wondering what's happening in the field lately. <

MG: Very little has changed. This is a slow moving field.

ZMS: Specifically, I wonder if anyone's made any advancement towards
> a more "object-oriented" paradigm in PLC control software, especially
> the concept of "inheritance". <

MG: No.

ZMS: I checked out some threads here at control.com, some of them pretty
> dated. Some of the comments really struck me, in that the posters
> simply couldn't imagine the benefits of object-oriented programming
> techniques in control system integration. <

MG: Most people working in this field are not "computer programmers". They are automation / control / maintenance people who do some PLC programming as part of their jobs. Some people do a bit of VB programming - which is not exactly a good introduction to modern programming techniques.

ZMS: I think that we've already seen the benefits of the implementation
> of some of the concepts of OOP in PLC control software, and just haven't
> seen the rest of the concepts effectively implemented yet. When they do,
> I think that they will appear to be facepalm-slappingly obvious. <

MG: You can do Object Oriented Programming without using an OOP language. Object orientation is more a way of looking at things than a specific language. In PLC programming, you would apply object oriented principles by dividing your program up into blocks which relate to parts of the machine. You don't need an OOP language to do this though.

ZMS: Some of the most important programming concepts addressed by OOP are:
>
> * encapsulation
> * modularity
> * polymorphism
> * inheritance <

MG: The first two (encapsulation, modularity) are also addressed by structured programming. OOP simply addresses them in a different way. The second two (polymorphism, inheritance) are what more or less defines an OOP language.

ZMS: We've had encapsulation and modularity in PLC programming ever since
> the first PLC came out which supported multiple program "files" and data
> storage whose access is limited by specific program "files". I think the
> A/B PLC-5 used to do (does!) that. RSLogix does it with program files and
> local variables whose scope is restricted to that file. <

MG: What you have described is simply structured programming, not OOP. An even better example of this is Siemens S7.

ZMS: What PLC programming seems to be lacking is real inheritance.
> Today, using RSLogix, for example, you need to create a program module
> and copy-paste it once for however many instances you need in a particular
> project. With Modicon, you can create program modules (UFBs) which can
> be plugged in where you need them. We're almost there, there's no real
> inheritance -- yet! <

MG: If a PLC supports subroutines with parameters, the code for a single instance of a subroutine can be called multiple times. Many if not most modern PLCs can do this. Even if the PLC does not support subroutine parameters directly, you can often store the parameters on the accumulator stack. Only the simplest of PLCs do not have this feature today.

ZMS: Using PC programming languages which implement inheritance, one
> can choose to inherit the implementation of a function from a parent class,
> or override that function in the child class. Applying this to PLC
> programming, what I imagine is a PLC programming suite which allows you
> to create a "base class" which can be customized for a particular instance
> when necessary. In PC programming, base class (or "parent class")
> *functions* can be overridden in derived classes. In the PLC environment,
> it makes sense for individual *rungs* of ladder logic to be overridden in
> child classes. This would be massively convenient. <

MG: I can imagine relatively few actual applications for this.

ZMS: Imagine that you were writing a program to control 12 conveyors
> that behaved in practically the same way. You could write one base
> class "conveyor", and then implement it with 12 instances of the
> class, each tied to a different input structure and output structure. But
> let's say one of the conveyors has a special case which needs to be
> addressed -- one rung needs to be changed. Just create a new class inherited
> from the base class. In the new class, inherit all the rungs of the parent
> class, but override the rung(s) you need to override for this particular
> implementation. <

MG: However, PLC technology has been moving in the direction of each of those conveyors having a separate small PLC with its own program. This is why I said I don't see a lot of application for this idea. You would need a large machine with multiple similar but slightly different complex devices. There aren't a lot of these today, except perhaps large conveyor systems and a few other applications.

ZMS: I don't know exactly how this would be implemented for IL, ST, and FBD
> routines. I've done my share of programming with these languages, but
> mostly for things that ladder couldn't do well. The issue here is the
> granularity of the program. In ladder logic, each rung is separable. In
> FBD, not so much. <

MG: IL is the same thing as ladder, just displayed in a different way in your programming software. FBD is similar to ladder. The PLC itself executes IL. With many Siemens programming editors you can often toggle between the different representations with the same code. If your idea will work with
ladder, it will work with IL and FBD.

ZMS: Does anyone know of a PLC product that allows this? I did a little
> research this afternoon, and found ABB's Sattline program
> (http://www.abb.com/product/seitp334/e3d927acb567331bc12571e100335b3e. aspx).
> Wading through their techspeak gobbledygook, I get the impression that they
> actually did succeed in implementing object-oriented programming
> principle in a control system. Anyone here have any experience with
> Sattline? Can you share your experience and let us know if Sattline
> implements what I am talking about? <

MG: I don't know much about Sattline, but it appears to be strictly a SCADA system. I doubt their concepts would translate well to a PLC. Also, the use of "OOP" acronym in marketing literature doesn't mean much. Before OPP became trendy, companies used to love to claim their products had "AI" (Artificial Intelligence) until that phrase got flogged to death.

A more productive line of development would be the creation of application frameworks. This would be the automatic generation of a lot of the routine
MMI, recipe, alarm handling, manual control, mode transfer, etc. features which seem to take up the bulk of a typical PLC program today. Actually making the machine move in auto is often a fairly small part of the job. Application frameworks are popular in custom web development where people
have to create a lot of similar-but-different programs.

The biggest obstacle to advancement in automation seems to be the lack of genuine standards and the dominance of proprietary PLC language dialects. I
doubt we will see real progress until that changes.

Nice response Michael. Your expanded shared view is very welcome!!

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesign.com
Manufacturing Automation www[.]automationmag.com

I do not know what other people are doing, but yes it is built into the program. And for me it is fundamental to what I do.

I try to write all of the code in a reusable form and have tried to identify "equipment modules" that I can standardize and built as "objects".

It is not built as an "after thought" it is internal to the structure. By creating your own data types and your own AOI (add on instructions) you basically build your own objects.

I can write crappy code and objects or good code and objects. I try to break out equipment modules and procedural logic and build objects for the equipment modules. If I have 10 identical conveyors, I will build a conveyor object and punch them out.

Now as with anything, it takes a paradigm shift in the way you code and as I always say on this list. It is the PAINTER not the paint set although you do need the paint set to be a painter.

What is the difference between a painter and an artist....................one paints houses.

Dave Ferguson

Not sure how the reply below got copied twice but it did.

One other item, Not sure how the reply below got copied twice but it did.

One other item, yes in ControlLogix you can make changes to the "master" object and the others "inherit" the change. I have not tried to separate
so they will not inherit, I will look into it.

As for DeltaV which is just an Emerson PLC (PAC) with HMI software on top...yes you can do this so that "instances" can inherit or not.

As to MG's comments... I disagree, there are people doing this, he may not have met any but they are out there. The entire movement of the CLogix team is towards this mindset... as well as going after process by hiring a gaggle of former DCS gurus.

And yes as I said S7 also has some of this ability.

Dave Ferguson

In reply to Dave Ferguson: To deal with your comments a bit out of order, Siemens S7 is based on classic structured programming principles. All IEC style PLCs that support subroutines with parameters are. It is probably inherent to any PLC that uses ladder logic and has a data table. Some of the confusion in this discussion comes from the original poster conflating several different unrelated things.

One of Nicolas Wirt's books was titled "Algorithms Plus Data Structures Equals Programs" (or something similar to that). That probably defines structured programming as succinctly as possible.

Inheritance is a concept from Object Oriented Programming. OOP blurs the distinction between code and data. This is why they have a special name for it. Many pure OOP languages don't even have complex data structures (such as simple arrays) because it is foreign to the way they are used.

Inheritance is something a bit different from having the programming software just copy code from a library. The code and the data have to be inextricably bound together in a single unit. If they are separate, then it isn't inheritance. What happens (invisibly to the programmer) is all methods (functions) are actually addressed by function pointers. Generally, data is treated the same way. These pointers can be changed at run-time, since they are themselves data. This is why "real" OOP generally has inheritance, dynamic typing, polymorphism, and garbage collection all together.

While OOP is popular in some applications today, it often isn't the best solution. Structured programming is still a very valid approach to many programming problems. In fact, most practical OOP languages allow the programmer to use both structured and OOP techniques as appropriate.

GUI code is something that is probably a good example of where OOP can be applied to advantage. Therefore, things like SCADA systems are a place to look for this. We were however talking about conventional PLCs and ladder logic.

I get that...

I said I understood S7 adhered to OOP but not sure, I had been told it did.

But... RSLogix 5k V16 and higher and DeltaV DO support this concept for programming. You create a "Class" of object and all of the "children" inherit from the parent class. Also DeltaV you create class based objects and the instances inherit. In both cases if you change the parent class, the children inherit the changes.

P.S. I understand the difference, but thanks for the explanation.

Dave

I think AutomationX is written to adhere to OOP-speak. IMHO the advantages for any but the largest systems are outweighed by the complexity. One of the practical benefits of a simpler model is that you can operate on a small part the program without having to know much about the rest of the system. This isn't very important to the author, but when a machine you don't know is down and you're tossed into someone else's abstract thinking, it can be a nightmare of jumping around and learning bits and pieces until the rationale comes into focus. Maybe this is the future, and I, as a general computing and programming type should embrace it, but the experience of slogging through dozens of disjointed blocks and interfaces during expensive downtime, with the plant at a standstill and several levels of management tapping their feet in unison tends to make a Luddite out of even me. Still, it might be worth the pain, if there were clear and obvious advantages that suddenly, after the toil, paved the way toward nirvana. But, in my experience, it just makes it harder to diagnose and next time, it's still harder to diagnose. Once the whole is grasped, it might be that I would shout "Yes!" when I see the purity and beauty in form, but some of these are 10,000 networks and I'll probably never get there. From the creator's viewpoint it may well be beautiful.

Regards

cww

Not true.
It was true with Concept but not with the new Unity software.

While at my former job with a large PLC supplier, we implemented the structured programming you describe to satisfy the requirements of the S88 and FDA in a bio-tech plant. The individual devices (solenoids, motor controls, etc.) were all implemented as standard code that could be validated once and used many times.

By doing this we got to the 80% point of validation for the plant quite quickly. We generated a user defined tag for each type of code which held all of the parameters and called the routine repetitively using a For... Next loop. Since the UDT could be configured as an array, we simply called the routine using a pointer incremented to solve the logic with new data each time. This was done about 4 years ago so it isn't "cutting edge" any more (if it ever was).

Yes, it did take extra time at the start of the project but the time savings especially during commissioning paid for the time many times over.

Regards,
Russ

I've complained about this before; maybe some of the old posts you found were my whinings on the backwardness of PLCs.

There are virtually no OOP capabilities in any current PLC / PAC. Modularity is pretty doable. Polymorphism is completely impossible. (Unless you count a gigantic switch statement, which is what we were trying to avoid in the first place.) Inheritance is unheard of. The basic concept of OOP (that the characteristics of a the behaviors of a thing travel around together, i.e. encapsulation) is non-existent. You can have data structures. You can have routines. But you can't have a CLASS.

I'm not sure that OOP is the right way to go for PLC programming. (I'm not sure it's wrong, either.) C can do a lot stuff without introducing the concept of a class; function pointers for polymorphism, as an example.

One thing I AM sure of; hand-writing ladder logic to bubble sort by barcode an array of structures representing products, then hand-writing the binary look-up code is even more painful than reading my run-on sentences.

I'll happily be corrected, but there are no PLCs out there with a built-in dictionary (map, whatever) capability.

-James Ingraham
Sage Automation, Inc.

Hi James,

I quite agree that reinventing the wheel is no fun (unless you like that sort of thing). But, and it's the part that people miss about using an OSS platform, I can get the source for a bubble sort (many, many implementations) and almost any other conceivable construct or method and avoid much of the pain. Here is where it's easier to add PLC capability to a computing platform than to add computing capability to a PLC platform. PLC capability is straightforward cookbook stuff and of pretty small scope. So get a $65 PC2500 SBC and write your procedural stuff in comfort with storage, IPCs, networking, etc. And add a simple solver and remote IO. Use any of at least 50 languages available and Linux and _own_ all of the code.

Regards

cww

You are wrong... obviously you have not used some of the NEWER PLC/PACs.

Dave Ferguson

Dave Ferguson: "You are wrong..."

About what, specifically? I'm not just trying to win an argument here. If there's something out there I'd like to know.

---

Stipulations:
A PLC/PAC, using any one of the 5 IEC 61131-3, i.e. relay ladder logic, instruction list, structured text, sequential function charts, or function block diagrams. This counts out Control Technology and National Instruments. (I'm pretty sure LabView wouldn't count anyway, but it has been a while since I've played with it.) And running C on the same platform as 61131 doesn't count.

---

My points again:

---

1) No polymorphism.
What 61131-3 PAC can sort a table of structures by barcode, and use the same calling convention for sorting an array of reals? Heck, in Step 7 I can't even have a function take an int and/or a real!

---

2) No encapsulation.
This is a gimme. Classes? Hah! And no, the fact that a Rockwell AOI or Siemens FC has local storage does not count. That's a function with local variables, not a class.

---

3) No Inheritance.
Another gimme. How can you possibly override a function when you can't even associate a function with ANYTHING?

----

Naturally, I assume your post was directed at me due to my large ego. :-) If, however, you were directing it at Curt I'll back his point up too.

4) (from Curt): "it's easier to add PLC capability to a computing platform than to add computing capability to a PLC platform."

Just look at all the PACs that are PC with PLC functionality added. B&R, Beckhoff, ICP DAS USA, Phoenix Contact (more PC than PLC, really), etc. Notice he said "easier" not "the only possible way." Logix, S7, and RX3i/7i are PACs that aren't really PCs. But those guys are a LOT bigger than B&R or Beckhoff.

----

5) I suppose you also could have meant that, contrary to my statement, writing sorts and searches in relay ladder logic is far better than having to have read my inordinately long run-on sentences, a point which I will concede if you stipulate that Herman Melville's "Billy Budd" is overrated. :-)

---

-James Ingraham
Sage Automation, Inc.

Have you ever USED either product? Have you used RSLogix 16 or 17, have you used DeltaV V 8.5. Specifics... explain to me specifically (with specific examples of these products) how these (that you have used) do not adhere.

Dave Ferguson

I must be terribly mistaken, with all of your vast experience in programming RSLogix V16/17 and DeltaV (8.5 and higher). 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.

Please detail how DeltaV class based objects and dynamos and RSI's AOI/UDT and Global Objects fail to adhere to the "norm". I eagerly await all of the wisdom that you can expand to the rest of us who do not understand.

Please include DETAILED explanations of projects you have done in both products and their failures (using the latest versions listed) since we are all mistaken and there are NO PACS nor PLC's that adhere. I really appreciate (in advance) the DETAILED explanations you will provide as I apparently am so completely in error in my assumptions and working knowledge.

Thank You in advanced for enlightening the rest of us, it is very, very much appreciated.

Dave Ferguson

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.

See comments below..........realize that I am not going to take any where near the time expanding on this...........................

On August 9, 2008, DAVE FERGUSON wrote:
> >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.

DF: Between the combination of UDT, AOI and AOI internal variables why cannot I do this very thing ? The upper level UDT is for a class of Weapon including a "type" variable, the AOI with internal embedded ST uses if then for "Type" of weapon and between internal variables and logic, what the AOI does dirres depending on the "type" of weapon. Or Type of weapon is embedded in an AOI within Weapon.

I do not claim to be a 100% expert but what is the difference here. But the combination of UDT, internal variable within an AOI and AOI allow you to describe things as well as actions for those things.

> > 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.

DF: I can hide data within the internal variables of the AOI

> > 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.

If internal variable type = gun then UDT = x , else UDT = y ? I am not sure the entire point, if I build an object in a class based system I still at some point have to write the function pointers internally at design time. The software does not have the embedded AI (Artificial Intel) to just morph itself unless I am missing something here (entirely possible)

> > 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.

DF: Think this was covered above..not sure your point and being Saturday not willing to expend any more brain cells on it (being honest)

> > >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.

DF: Not sure that I said anything about DV being a 61131-3 based PAC, may have said that it contains some of the languages of the standard but here again (see points below) there have been numerous articles written and discussed on this list about which softwares even adhere to 61131-3 so not sure I would reopen this endless rant of who adheres to 61131 any more than the fact we are discussing what adheres to object oriented thinking.

> > >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.

DF: I do not think you are being anything but yourself, I am not upset nor mad. My point is that sometimes these terms are interpretations of the author. There are many out there who interpret whether something adheres or doesn't to certain "models" as they understand them based on their perceptions of the "standard". I have sat in many a discussion about symantecs and it usually boils down to perspective and interpretation. I think that if I create an object "valve" describe its "properties" and define it's actions and create instances of them that will "inherit" structure from the parent combination of UDT and AOI and internal tags, there is no way for me to them claim that it doesn't function as an object "final control element" unless I have had the forsite as a programmer to create the object "final control element" first and defined all of that structure to include the type "valve", "motor" and "hydraulic ram" etc.

Without having that forsite unless I am missing something (again entirely possible), in any language to have in some place created that class structure, will the software whether "object oriented" of not to "morph" into something I did not program.

I think that a better way of saying it is that there are NO PLCS that adhere to your interpretation of what you understand object oriented progamming to be. But I will fill a room with 100 "computer science experts" and not only will we not be able to all agree on the semantics of this discussion, but we could never all agree on what kind of donuts to buy if we all have to agree on one definition of what a donut is (we would all starve first). PS: Must have jelly, must have jelly.

I think just like we cannot get IT programmers to agree about which developement software adheres to all the "perfect" programming rules PERL, vs JAVA versus .NET etc, we will never agree on the abilitities of PAC/PLC programming tools, they are all interpreters. I have never had an issue with adhering to some form of "norm" by getting really creative but you must admit (and have) that they are much closer to the BUZZ than before and with some creativity can adhere to the "model".

Hell I sit on the ISA HMI and alarms standards committee's and we can take 11 months talking about what color an "object" should be when on and what color when "off".

Wasted enough brain cells for a Saturday.........................We can agree to disagree on some points in the discussion, I say that conceptually there are PLC/PACS out there that adhere to the jist of ORP, you say there are NONE.

Dave

> "DF: Between the combination of UDT, AOI
and AOI internal variables why cannot [we implement OOP]?" <

The AOI is tied to the UDT, but the UDT isn't tied to the AOI. If I export the UDT and use it in another project, I don't get the AOIs with it. That's the whole point of OOP. This isn't just semantics; putting data and code together is what makes it object-oriented.

DF: "The upper level UDT is for a class of Weapon including a "type" variable..."

Again, this is what OOP is designed to avoid. Now you have a big switch statement. "If weapon==1 else if weapon==2 ..." If I add a new weapon type I have to change the AOI.

DF: "I can hide data within the internal variables of the AOI."

No, you can't. If you have a field for "SafetyIsOn" in the AOI, the value goes back to the default as soon as the AOI finishes. The data doesn't persist from one call to the next. If the field is in the UDT, I can edit it from anywhere. Can't be done.

DF: "If internal variable type = gun then UDT = x , else UDT = y ? I am not sure the entire point, if I build an object in a class based system I still at some point have to write the function pointers internally at design time. The
software does not have the embedded AI to just morph itself unless I am missing something here
(entirely possible)."

Yes, you're missing something here. The whole if..else is what OOP can get rid of. True, I have to write the function somewhere. (Unless inheriting the default works.) But, and this is the key point, I DON'T MODIFY ANY PRE-EXISTING CODE. Suppose you've given me a Gun class, and code which calls myWeapon.fire(). And I write a BowAndArrow class, including writing a fire() method. The code that calls myWeapon.fire() doesn't change. I didn't add a "if type==BowAndArrow" line anywhere. It just works.

"DF: Not sure that I said anything about
DV being a 61131-3 based PAC"

No, but I did. My original comment: "There are virtually no OOP capabilities in any current PLC / PAC." After you said, "You are wrong," I clarified: "A PLC/PAC, using any one of the 5 IEC 61131-3 [languages]." And I listed three things that are lacking that counts them out; polymorphism, encapsulation, and inheritance.

DF: "I am not upset nor mad."

Glad to hear that. Because the language in your previous post was rather belligerent.

DF: "My point is that sometimes these terms are interpretations of the author."

Sure. Always an issue. But there are clear-cut cases. Smalltalk is an object-oriented language. Period. No current implementation of IED 61131-3 is. Period. The definitions may have some wiggle room, but not enough to count a UDT (a classic structure) or an AOI (a classic sub-routine) as object-oriented.

DF: "...many a discussions boil down to perspective and interpretation."

Yes. But there are things we can say for certain. It's one of the things I like about my job, actually. I know my machines have functioned because product is put on a truck and sent somewhere. The work is measurable. Argue all you want, but if an 18-wheeler full of boxes didn't pull away from the dock we didn't do our job.

DF:
>I think
>that if I create an object "valve"
>describe its "properties" and define
>it's actions and create instances of
>them that will "inherit" structure from
>the parent combination of UDT and AOI
>and internal tags, there is no way for
>me to them claim that it doesn't
>function as an object "final control
>element" unless I have had the forsite
>as a programmer to create the object
>"final control element" first and
>defined all of that structure to
>include the type "valve", "motor" and
>"hydraulic ram" etc.

Wow. That equaled MY run-on sentences. But I'm afraid it precisely says the opposite of what you want. Having to have the foresight to include everything is what OOP avoids. Having to remember which AOIs and which UDTs go together is what OOP avoids. Basically OOP was invented to avoid the limitations of EXACTLY what you just said. It's a completely different paradigm for creating software.

DF:
>Without having that forsite unless I am
>missing something (again entirely
>possible), in any language to have in
>some place created that class
>structure, will the software whether
>"object oriented" of not to "morph"
>into something I did not program.

Yes. It morphs. Without the foresight. That's the point. You write a program with a type Weapon that uses BowAndArrow, without ever having conceived of a ShoulderLaunchedMissle. If I write a ShoulderLaunchedMissle class that extends Weapon and send it to your program your program will work just fine, without ever changing a line or even recompiling.

DF: "...we could never all agree on what kind of
donuts to buy if we all have to agree on one definition of what a donut is..."

True. But you would all agree quickly that a chair was not a donut.

DF: "I say that conceptually there are PLC/PACS out there that adhere to the jist of OOP, you say there are NONE."

Yep. And for sure RSLogix 5000 isn't. If we count DeltaV as a PAC, I'll have to defer.

-James Ingraham
Sage Automation, Inc.

The main question is:
Which way can OOP simplify control algorithms programming?

Yes. It can. Theoretically. When we need to process complex data structures, but it is not a case for a vast majority of the algorithms. Complexity of language vs. usability of additional linguistic means. Advantages of OOP must be under question (for PLC programming).

Really, PLC programming just needs no OOP means.
--
Best regards,
zyubin

Belligerent... wow, what color is the pot...

You need to spend some more time with internal/external variables and in/out parameters in AOIs and Global Objects and again you say potato and I say patata, doesn't make you right, it makes you right in your mind. I have made logic function to your interpretation of OOP (100% no but close enough at 99.5% conceptually to my interpretation) and again re-read the words YOUR INTERPRETATION. I can make the UDT part of the AOI and when I import in XML (or other) they are created automatically as if part of the AOI. I can persist by attaching as internal/external variables. Remember that all of the code exists somewhere.

Again, so that I can be sure you get my point... WE CAN AGREE TO DISAGREE.

This will be my last post on the topic, so as always you can get the last word in (please disregard your interpretation of belligerent here). Or maybe you already have (but I doubt it).

So with your reply, you WIN... the loudest minority usually does.

Dave

Can you share your experience and let us know if Sattline implements what I am talking about?

I have a lot of experience with Sattline. It is indeed object oriented, an example of what you can do with it is create a Unit (e.g. a fermenter) complete with its graphics and equipment and control modules, and then make multiple instances of the unit.

Sattline was I believe used as the basic core of ABB Ax800.

Francis
www.controldraw.co.uk

Take a look at http://www.3s-software.com/se_data/_filebank/3S/News/Pressemeldung/SD_ Schuenemann_atp_i_02_07.pdf

Classes, inheritance, interfaces - gimme!

Beckhoff use CoDeSys in TwinCAT - I believe (hope) a new version of TwinCAT with these features will be available later this year...

Roger

You can also take a look at http://www.sigmatek.at
They really have Object Oriented software. I've worked with it for quite some time and it is really a pleasure to work with it.

Koen

Object Oriented Programming for PLC is definitely an interesting topic. I have recently moved from the PC programming world to the PLC world and I have a few opinions on the subject.

Abstraction is a very powerful tool - you can make wonderful things happen by just typing "SomeObject.DoSomething". But abstraction comes at a cost, it divorces you from the low level code that is actually implemented - which as a PLC programmer is what you are interested in most of the time.

Highly abstracted code hides complexity, but when you are debugging abtracted code you often have to trace through the layers of abstraction to find where/what the code that is actually implemented. That is why people recommend a maximum of 3 levels of abstraction if you can help it.

As PLC programmers we work close to the physical I/O and there is no point abstracting ourselves from the hardware if we don't need to. Device drivers are normally written in low level languages such as C or Assembly language for the same reason. The programmer needs control of what is happening at the hardware level.

I personally like to write code that deals with real outputs in ladder - it is a no non-sense WYSIWYG low level visual language. I like to use FBD for sections of code that have lots of timers and/or other function blocks. I think drawing a couple of power rails on either side of a cluster of function blocks and calling that ladder is wrong - I am talking about you RSLogix! And nothing beats the power of structured text when it comes to data manipulation.

Saturday, September 06, 2008, 7:49:16 AM, twu026 wrote:

TA> As PLC programmers we work close to the physical I/O and there is no point abstracting ourselves from the hardware if we don't need to.

It will be correctly to say: As IEC61131-3 programmer we work...

The languages have no (or too low) means for structurization of control algorithms. BTW, OOP has the same problems as well. There is no way to inherit "Create.Vacuum" from "Open.Valve" and "Start.Pump" in OOP.

Logical parallelism (e.g., divergence/convergence of control flow), synchronism (e.g., timeouts, latencies), event-driven polymorphism (e.g., changes in the algorithm because of a fault)... OOP can not meet the requirements in a clear and weakless style, etc.

To be short, control algorithms need process oriented programming/languages.

--
Best regards,
Vladimir E. Zyubin

>[In] OOP... There is no way to
>inherit "Create.Vacuum" from
>"Open.Valve" and "Start.Pump" in OOP.

I have to disagree. First, you've got that backwards. It would be "Valve.Open" and "Pump.Start." Second, this is exactly what interfaces are for, and what you want is very commonly used. It's common enough to be described by the Gang of Four as the Command Pattern. You can make an interface that defines the method "Actuate." Both Pump and Valve implement the interface. When you write your Pump class, the .Actuate method calls "Start" internally.

>Logical parallelism (e.g.,
>divergence/convergence of control
>flow), synchronism (e.g., timeouts,
>latencies), event-driven polymorphism
>(e.g., changes in the algorithm because
>of a fault)... OOP can not meet the
>requirements in a clear and weakless
>style, etc.

I'm not sure I completely understand what you're saying there, but I think I disagree here as well. In OOP I can most certainly accomplish logical paralleism and event-driven polymorphism, quite easily. In fact, by thinking about communication between objects as message passing those two features fall in place rather naturally. Synchronism I'm not sure about, but I think that concept can be implemented in OOP or structured programming without fundamentl alterations to the languages.

>To be short, control algorithms need
>process oriented programming/languages.

This I quite agree with. While I hate to inflict another language on the world I would like to see a truly modern language for implementing controls. LabView is reasonable example, but I think it has weaknesses that prevent it from being a true replacement for ladder logic and the other 61131 languages. Function block diagrams look a lot like LabView, but not as elegant. Sequential function charts and flow charts are a BAD idea; they try to allow structured programming but don't actually enforce the rules. It's like going back to "goto" statements all over the place.

-James Ingraham
Sage Automation, Inc.

>>[In] OOP... There is no way to
>>inherit "Create.Vacuum" from
>>"Open.Valve" and "Start.Pump" in OOP.
>
> I have to disagree. First, you've got that backwards. It would
> be "Valve.Open" and "Pump.Start." Second, this is exactly what
> interfaces are for, and what you want is very commonly used. It's
> common enough to be described by the Gang of Four as the Command
> Pattern. You can make an interface that defines the method
> "Actuate." Both Pump and Valve implement the interface. When you
> write your Pump class, the .Actuate method calls "Start" internally. <

Well,
1. Valve.Open <-> Open.Valve. Really, it is the question of philosophy (systematization). Operation and process are the key aspect for technologist, not objects, and, especially, actuators kinda valves, pumps, motors, etc. So, the order just reflect this circumstance. But if you insist to use the OOP-style order, I have no objections.

2. With my heartfelt respect to the Gang of Four, method "Actuate" is just an attempt to put a brave face on a sorry business (to hide the OOP problems in the case). Actuate/deactuate, construct/deconstruct is just a generalization, kinda "do something". Technologists think in terms of verbs: open, close, turn on, turn off, start, stop, move, jog, clamp, clench, etc. Control algorithms written by the only method "actuate" have the problem with readability. So, such programs will have problems with maintainability and verification. So it will be a bad program.

>>Logical parallelism (e.g.,
>>divergence/convergence of control
>>flow), synchronism (e.g., timeouts,
>>latencies), event-driven polymorphism
>>(e.g., changes in the algorithm because
>>of a fault)... OOP can not meet the
>>requirements in a clear and weakless
>>style, etc.
>
> I'm not sure I completely understand what you're saying there, but
> I think I disagree here as well. In OOP I can most certainly
> accomplish logical paralleism and event-driven polymorphism, quite
> easily. In fact, by thinking about communication between objects
> as message passing those two features fall in place rather
> naturally. Synchronism I'm not sure about, but I think that concept
> can be implemented in OOP or structured programming without
> fundamentl alterations to the languages. <

1. Yes, logical parallelism and event-driven polymorphism could be implemented by OOP-languages... as well as in Assembler (obviously), or in any other programming language, even esoteric one. The problem is the concepts are outside of OO-programming. So, the concepts will be implemented by different ways by different programmers at least. It is just a hell (problems with readability, etc.) So, even LD with all its problems will be more preferable than C with thousand of pluses.

..."quite easily", if only! I think, if it will be true, then nobody will be in need of the IEC 1131-3 languages.

2. When I wrote "synchronism" I meant the necessity to synchronize control algorithm with physical processes on the controlled object (necessity to use a time maintenance system, necessity of active manipulations with time entities such as time interval, time delay, and timeout). And again, such things is out of scope OOP. They are implemented with alien means (of OS).

>>To be short, control algorithms need
>>process oriented programming/languages.
>
> This I quite agree with. While I hate to inflict another language
> on the world I would like to see a truly modern language for
> implementing controls. LabView is reasonable example, but I think
> it has weaknesses that prevent it from being a true replacement
> for ladder logic and the other 61131 languages. Function block
> diagrams look a lot like LabView, but not as elegant. Sequential
> function charts and flow charts are a BAD idea; they try to allow
> structured programming but don't actually enforce the rules. It's
> like going back to "goto" statements all over the place. <

FBD and G (LabVIEW) are data-flow languages. A brain-crushing technique in case of control algorithms. Yes, I like LabVIEW because of means to create user interface, but use it for the control part in very few cases of simplest (SCADA-style) algorithms. Yes, SFC is a BAD idea, as well as any things based on the Petri-net model. I think, the truly modern language you would like to see ought to look like finite state machine (thoroughly cleaned from the historical layers (fuzzy terminology, concepts) and enhanced a bit to reflect the basic specific of the field and encourage program implementation).

--
Best regards,

Vladimir E Zyubin
Institute of automation and electrometry

"...if you insist to use the OOP-style order, I have no objections."

Well, it's not so much that I'm insisting. It's just that if we're talking about OOP, odds are it'll be written OOP-style order. It would be very difficult to do it the other way. You could, of course, use functions/methods to keep that order, e.g. Actuate (valve3), but we both get the point.

"2. With my heartfelt respect to the Gang of Four, method "Actuate" is just an attempt to put a brave face on a sorry business (to hide the OOP problems in the case)."

That's got to be the best sentence on Design Patterns I've ever read. No disagreement here.

"Control algorithms written by the only method "actuate" have the problem with readability."

Good point. Of course, won't that be a problem in ANY language? In ladder you have on/off or else you get a special function name for each thing, like timer, counter, etc.

"...logical parallelism and event-driven polymorphism... concepts are outside of OO-programming."

I'm not sure that that's a deal breaker. I mean, just about EVERYTHING is outside the scope of OOP, or any other programming paradigm. There's no such thing as a "Chair" in OOP, but OOP models chairs quite well.

"So, the concepts will be implemented by different ways by different programmers..."

True enough. My "Chair" class will probably look slightly different from yours. But they should both be fairly understandable to either of us.

"even LD with all its problems will be more preferable than C with thousand of pluses."

The market agrees with you on that point. Although personally I just don't THINK in ladder logic. C (C++, Java, C#, etc.) just flows better for me. I'd like to think that the C programs I did in the first 7 or so years of my career are fairly easy to follow. Of course, I also like to think that my ladder logic programs of the last 7 or so years are easy to follow. (There's overlap in those two sets of years.)

Naturally, I've seen badly written programs in just about every language, including C and ladder.

"...'quite easily', if only! I think, if it will be true, then nobody will be in need of the IEC 1131-3 languages."

Not sure I agree. Okay, it's a lot easier to get started by popping open Step 7 or RSLogix or whatever than to open Notepad write C++ code and compile it on the command line. But there's LOTS of stuff out there controlled by C, Ada, C++, etc. There's no IEC 61131-3 application out there that COULDN'T be done in some OOP flavor or another. Still, however good or popular C or Java or language XYZ ever becomes, I think relay ladder logic will still carve out a niche.

"When I wrote "synchronism" I meant the necessity to synchronize control algorithm with physical processes on the controlled object... [This] is out of scope OOP."

Sort of. I model some object. I can then link an instance to a physical device. True, that link method isn't specified. But that's a write-once-use-many problem. For example, if I were to make a class IO_Block, I could implement Modbus/TCP as the method to synchronize to the block. (This is a real world example; I've done this.) From there on out as an application developer you don't care HOW it's synchronizing, it just does. And if I add EtherNet/IP or Profinet communications to the class my code looks the same, bar perhaps a different initialization.

"I think, the truly modern language you would like to see ought to look like finite state machine (thoroughly cleaned from the historical layers (fuzzy terminology, concepts) and enhanced a bit to reflect the basic specific of the field and encourage program implementation)."

Sounds reasonable. To quote Megadeth: "If there's a new way I'll be the first in line. But it better work this time." :-)

-James Ingraham
Sage Automation, Inc.

> "Control algorithms written by the only method "actuate" have the
> problem with readability."
>
> Good point. Of course, won't that be a problem in ANY language?
> In ladder you have on/off or else you get a special function name
> for each thing, like timer, counter, etc. <

It's rather native problem of OOP-approach. The languages (OOP) allow to use arbitrary identifier for a method. We have problem with the "actuate" because of the wrong structure of program we try to use. ;-) (AFAIK, we have the ON/OFF restriction in the LD language when we deal with the concept of relay only. We can use function with various identifiers as well as in others languages. Just a remark.)

> "...logical parallelism and event-driven polymorphism... concepts
> are outside of OO-programming."
>
> I'm not sure that that's a deal breaker. I mean, just about
> EVERYTHING is outside the scope of OOP, or any other programming
> paradigm. There's no such thing as a "Chair" in OOP, but OOP models
> chairs quite well. <

Sounds like you mean "OOP rules". Unfortunately, can not agree. OOP covers many things and do it well enough, but there are areas where OOP sucks. Not only logical parallelism, physical parallelism as well. Keywords: klasters, mpi, multicore, vhdl, mdmi.

And yes, we can tune an OOP-language for a specific task (patterns, etc.), but there is a dilemma we want to tune, or we need to work (program control algorithms). Necessity to work is the answer for the question, why 4GL-es exist.

> "So, the concepts will be implemented by different ways by different programmers..."
>
> True enough. My "Chair" class will probably look slightly
> different from yours. But they should both be fairly understandable to either of us. <

Sorry, many of us don't want to knock up the chair, and know about nails, planes, fish-glue, upholstery. Many of us (and I as well) just want to sit with comfort.

> "even LD with all its problems will be more preferable than C with thousand of pluses."
>
> The market agrees with you on that point. Although personally I
> just don't THINK in ladder logic. C (C++, Java, C#, etc.) just
> flows better for me. I'd like to think that the C programs I did
> in the first 7 or so years of my career are fairly easy to follow.
> Of course, I also like to think that my ladder logic programs of
> the last 7 or so years are easy to follow. (There's overlap
> in those two sets of years.) <

I don't insist that the language must looks like LD. And let's just remember that many years ago C++ was called "C with classes". If you like C, "C with processes" will be a good choice.

> Naturally, I've seen badly written programs in just about every
> language, including C and ladder.
>
> "...'quite easily', if only! I think, if it will be true, then
> nobody will be in need of the IEC 1131-3 languages."
>
> Not sure I agree. Okay, it's a lot easier to get started by
> popping open Step 7 or RSLogix or whatever than to open Notepad
> write C++ code and compile it on the command line. But there's LOTS
> of stuff out there controlled by C, Ada, C++, etc. There's no IEC
> 61131-3 application out there that COULDN'T be done in some OOP
> flavor or another. Still, however good or popular C or Java or
> language XYZ ever becomes, I think relay ladder logic will still
> carve out a niche. <

Yes, any IEC application could be done in C, C++, Java, Assembler and even in machine codes. The difference is in time expenses of various approaches (at least).

And yes, LD have unique features (the metaphoric nature). It provides easy learning. For simple tasks LD is good enough.

> "When I wrote "synchronism" I meant the necessity to synchronize
> control algorithm with physical processes on the controlled
> object... [This] is out of scope OOP."
>
> Sort of. I model some object. I can then link an instance to a
> physical device. True, that link method isn't specified. But
> that's a write-once-use-many problem. For example, if I were to
> make a class IO_Block, I could implement Modbus/TCP as the method
> to synchronize to the block. (This is a real world example; I've
> done this.) From there on out as an application developer you
> don't care HOW it's synchronizing, it just does. And if I add
> EtherNet/IP or Profinet communications to the class my code looks
> the same, bar perhaps a different initialization. <

I rather meant transfer functions (PID), latencies for functioning, actuation times we need to control, the things we need to think about when we program control algorithms. Protocols (very important part of the systems) are just an auxiliary layer and the programmers have no needs to be aware which way it works. So, I agreed when you point out an application developer. There is an application developer and there must be somebody else, an system programmer. The programmer who perfectly knows of PID, OSI/ISO, target technology, C++, patterns, etc. is too expensive to employ. Just an economic reason.

> "I think, the truly modern language you would like to see ought
> to look like finite state machine (thoroughly cleaned from the
> historical layers (fuzzy terminology, concepts) and enhanced a bit
> to reflect the basic specific of the field and encourage program
> implementation)."
>
> Sounds reasonable. <

Thanks.

--
Best regards,
Vladimir

In reply to Vladimir Zyubin: On the one hand you say SFC and Petri nets are bad, while on the other hand you would like to base a language on finite
state machines. How would you do a finite state machine that doesn't look anything like an SFC or Petri net and which doesn't have any of the problems that you perceive with the latter two?