Re: Inheritance (object-oriented) in PLC programming?


Thread Starter

Jeremy Pollard

"I think if PLCs moved towards a language that is similar to a higher level it would open the doors not only for specially trained technicians or engineers, but for common computer scientists and programmers. Such programming would then follow the design cycle similar to that of desktop programs."

Are you out of your mind???? Sorry - used my outside voice... a process IS NOT a desktop application, and you are not designing a 'program', you are designing a control system, which HAS a program.

Please don't confuse the two. Just took some valium - I'm OK now. :)

Cheers from: Jeremy Pollard, CET The Caring Canuckian!

Control Design www[.]
Manufacturing Automation www[.]

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

Vladimir E. Zyubin

The idea is quite understandable: we need an effective tool for control program design as well as a lot of tools that are used in the PC world. And we have to agree that the IEC61131-3 world (in comparison with the PC world) looks like Stone Age.

The saddest thing (I see and have heard) -- It is impossible to enhance the IEC 61131-3. It seems any valuable attempt to move the standard forward is blocked by the committee members.

The good news -- it seems some developers are ready to enhance the standard (concretely, the ST language) independently from the IEC 61131-3 committee, albeit it is not obligatory the direction will be object oriented (I, personally, think it ought to be process oriented).

Best regards,
Vladimir E. Zyubin
Very funny. :p

I am sure you know a thousand times more than me about control and automation, but hey that's what learning is all about. I like questioning things, especially when to me it seems that PLC programming is somewhere between the equivalent PC level of assembly language and C programming (not that there is anything wrong with assembly when it is used at the appropriate level).

I started using PLCs at a point where PCs were miles ahead in terms of software design models. That's why I see PLC programming as a pain in the rear. Many of my university friends who have had exposure to this have had similar complaints. Like I said, I understand why PLCs have not gone much further; the main reason being "it just works".

I understand what the differences are very well. I know that a desktop program is nothing like a PLC program. Every aspect from hardware to the core of the operating system and architecture is different. As I said in my comments, a PLC is still the best thing to manage processes in plants and such.

I'm simply saying rather than spending $3000 for 2 days of training to learn about boolean variables, someone with programming experience would work with a more familiar software model to program PLCs. I'm not saying that this can be done easily nor quickly given the past history of change in PLCs...

I'm not saying desktop programmers should suddenly program PLCs, rather generic programmers could move into the PLC industry more easily. I'm sure professional programmers could bring along many benefits including documentation, testing and source control practices.

Anyway my interest is more in larger "systems" with a moderate amount of user interaction, not systems that are mainly time-critical.

For example:

Home Automation
Weather Stations
Power Monitoring
Pumping Stations
Lighting (e.g. Sports Ground)

What most these systems have in common is they are useless without some user interaction. Most of them rely on the fact that a human will control them or read data that they store. They may be internet enabled and have remote control features.

So yeah PLCs
-> Good for plants and process control

Something between a PLC and PC
-> For developing systems

Curt Wuollet

I think Bill has hit it on the head. PLCs are great at what they are great at. There comes a point in complexity where it would simply be much easier to use something else. I probably set that point lower than most people because I've seen PLC programs that simply _couldn't_ be made to work well doing things that would be straightforward with a different platform or language. Stretching the PLC too far defeats its purpose as a solid, easy to use, fairly transparent and reliable tool for implementing control logic and the other things it does well. Really big PLC programs become extremely difficult to understand, troubleshoot and modify even if you wrote it.



William Sturm

This is why PAC systems are becoming popular.  They are meant for higher level control than a typical PLC, with more PC like features.  A PAC system sounds just like what you are looking for.

Think of a PLC as an object in a higher level object oriented system. :)
As for what might be in between a PLC and a PC, I've been working on writing an example of that for a while now. This is the web site for it on Sourceforge

and this is the download page

If we look at your criteria:

1) "some user interaction" - I do that through a Web-based HMI. I've released a demo version of that, and will be integrating it into the main system soon.

2) "internet enabled and have remote control features" - I think a Web-based HMI meets that criteria. It also has various protocols that can be used to control it automatically from another program.

3) "larger systems" - It's based on a communications platform that allows for multiple protocols, server, and clients to operate simultaneously.

For logic execution, I've got the majority of a PLC logic engine similar to the Koyo DL205 written. However, Koyo has recently come out with their new "Click" PLC. That software architecture is a very interesting design which seems even better suited to a soft logic system than traditional PLCs. I have about 95% of a logic engine for that done, and that will be what gets integrated into the main system (the new version is much better than the previous one).

We can talk about general philosophy, but I'm not sure what you have in mind that isn't already either done, in progress, or planned in my project.

Some sort of advanced sequential control instructions? That's nice as a general concept, but does anyone have any actual concrete ideas? The most practical system that I've seen is what some manufacturers call "stage relays" or "sequence control relays" that let you translate state diagrams or grafcet notation into ladder logic. Implementing that just requires a couple of additional simple instructions, not throwing out all of ladder logic and starting over again.

Some better way of storing and retrieving recipes? I've got something in mind for that which again only requires adding a couple of simple instructions.

Easier alarm and event handling? Again, I think a couple of instructions can be added which have the system do most of the work automatically in the background.

I don't think there is anything fundamentally wrong with ladder logic itself. The problem is that traditional PLCs don't do much else besides execute simple ladder logic (IL actually). They can't be extended by the end user, so everyone is stuck with using whatever the manufacturer's market study says is the lowest common denominator.

Bob Peterson

It's certainly true that some control problems are not dealt with well by typical PLCs. It's also true that large blocks of code (of any type) are difficult to follow.

One of the biggest problems with PLCs I think is just the incredibly poor level of training a lot of people get who are expected to use them.
Object oriented programming is the result of object oriented designing. First you design your system and second you code it.

Certainly, it is possible to design automation systems by thinking in 'object oriented' style, many PLC programmers do this without knowing that they are thinking in 'object oriented' method.

I think that object oriented programming is a set of tools that programming languages present to the programmers for convenience, in theory it is even possible to code in 'brainfuck' as object oriented.

If you are a PLC programmer and you realized that your most of codes are copied and pasted from your previous codes, it is time to meet 'inheritance' of object oriented design.

As I said, object oriented programming is a tool and most modern programming languages support this.

Look at the following example:

Imagine that we are programming in a 'structural' programming language. We have implemented the 'bark' function.

And it is used for 'Dog' s.

Consider the pseudo code below:
Function Bark(Animal As Dog)
' Implement how barking is done here
End Function

Dim Lassie As Dog

We have implemented the function Bark() and can use it for all 'Dog' type variables:
Dim Spike AS Dog

Object Oriented approach changes the way of coding. First you create a class 'Dog' and give a functionality of barking to class 'Dog':
Class Dog
Function Bark()
End Class

Function Bark()
' Implement how barking is done here
End Function

Dim Spike, Lassie As Dog



Only coding style is changed.

Let's consider a design without object oriented thinking:
Dim Lassie, Spike As Dog

' Implement some code to bark Lassie

' Implement similiar codes to bark Spike


If you study on some old PLC automation projects, you can find many samples as an example of non-object oriented design. You can find many smiliar codes for conveyors, lifts and junctions. They are simply copied, pasted and adapted for I/O addresses only.

For this point of view, 'Function Blocks' (FB) are one of the keys of object oriented design in automation.

I think object oriented design in automation systems will be the next subject of my blog. I am planning to describe our one of projects as a case study.

Vladimir Zyubin

> Object oriented programming is the result of object oriented
> designing. First you design your system and second you code it.
> I think that object oriented programming is a set of tools that
> programming languages present to the programmers for convenience,
> in theory it is even possible to code in 'brainfuck' as object
> oriented. <

I have heard the same statement on the net, but the statement is a very disputable one. Structural programming without the function concept (and means) provided and supported by the programming language is a clotted nonsense. As well as object oriented programming without the object/method/class concepts. As well as process oriented programming without the process concept. Why? - because we just lost maintainability of the programs in the case.

Maybe from a math point of view, all languages have the same power, but there is the pragmatics, and pragmatics states, programming in the BF and programming in the C language are different (and it is well harmonized with common sense).

So, the statement about the esoteric language is just a wrong one.

Best regards,
Vladimir E. Zyubin
If your interest is in larger systems with moderate user input, a PC-based control system architecture could well be the answer. We have made a development framework which will help developers like yourself in designing and developing advanced control systems based on standard industry PC hardware. Using e.g. Panel-PCs running Linux, WindowsXP or even RTOS-32, you may execute your user interface and your control algorithms on the same computer. If you're familiar with Qt's way of making GUIs, there is a plugin for our framework. Check it out at:

Best regards,
If you think about it, all the OO languages are just constructs
on top of non OO languages. I think then it is safe to assume
that this can be done at higher levels as well.