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