Inheritance (object-oriented) in PLC programming?

  • Thread starter Zen Master Soso
  • Start date
Z

Thread Starter

Zen Master Soso

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!
 
D

DAVE FERGUSON

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
 
Z

Zen Master Soso

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?
 
M

Michael Griffin

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

Dave Ferguson

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
 
D

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
 
C

Curt Wuollet

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
 
R
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
 
J

Jeremy Pollard

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
 
J

James Ingraham

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

Michael Griffin

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

Curt Wuollet

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
 
D

DAVE FERGUSON

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
 
J

James Ingraham

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

DAVE FERGUSON

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
 
D

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
 
Top