Inheritance (object-oriented) in PLC programming?

  • Thread starter Zen Master Soso
  • Start date
J

James Ingraham

"Step 7 allows the UDT to be declared within the Function Block."

That's an advantage.

"RSLogix doesn't allow a UDT to be passed into the block."

Yes, it does, by reference. UDTs can't be DECLARED inside the AOI, but they can certainly be used by the AOI.

"Here is an example of OOP using SCL in Step 7..."

I appreciate you posting such a concrete example. It was a little difficult for me to follow, since I usually program in LD. In particular, I can't figure out how the distinction is made between static and temporary variables. Still, the static variables are an advantage over Logix.

Importantly, this is NOT an example of OOP. You can't create a reference to an instance of this FB and pass it to another FB. Several "functions" have been amalgamated into the FB, but there's no way to distinguish except the state variable. So the internal implementation is critical to the external access, which is exactly what OOP is supposed to prevent.

-James Ingraham
Sage Automation, Inc.
 
J

James Ingraham

"Inheritance in PLC programming happens if you do a real instantiation of a composite function block."

That sounds suspiciously like composition rather than inheritance. And inheritance has to happen BEFORE instantiation. Perhaps I don't fully understand what you are trying to say.

I didn't actually mention inheritance in my last post (although I've mentioned it earlier in the thread.) My specific complaints were (a) an instance of the function block cannot be manipulated, and (b) the interface is not decoupled from the implementation.


"Most IEC61131-3, IEC61499 tools and DACHSview-SDL can do this"

Create composite function blocks? Okay. That doesn't make them objects.

-James Ingraham
Sage Automation, Inc.
 
> "Inheritance in PLC programming happens if you do a real instantiation of a composite function block."
>
> That sounds suspiciously like composition rather than inheritance. And inheritance has to happen BEFORE instantiation. Perhaps I don't fully understand what you are trying to say.
>

Atomic function blocks can be considered as class definitions. If you build a composite function block out of atomic function blocks the composited function block is derived from the class definitions of the atomic function blocks and represents a definition of a new class. The inheritance works only if real instantiation of composite function blocks are supported.

> I didn't actually mention inheritance in my last post (although I've mentioned it earlier in the thread.) My specific complaints were (a) an instance of the function block cannot be manipulated, and (b) the interface is not decoupled from the implementation.
>
>
> "Most IEC61131-3, IEC61499 tools and DACHSview-SDL can do this"
>
> Create composite function blocks? Okay. That doesn't make them objects.
>

IMHO, an object is an instance of a class. A composite function block is not a bunch of code ... it must be a class definition which can be instantiated.

Best Regards

Armin Steinhoff
 
This article has some interesting points. I was the only one to post an example that can be dissected and can also run in the background scan of a PLC (Simatic S7). Let me me remind you that the original question was based on conformance with:

* encapsulation
* modularity
* polymorphism
* inheritance

Encapsulation: my example demonstrates encapsulation by using PLCopen blocks within the block I authored. It uses data (unique Params structure) and functions (PLCopen motion) in a single unit.

Modularity: my example demonstrates that this block can be instantiated by axis of many different types of Params structures to account for different mechanics.

Polymorphism: my example uses a State Output variable to represent what the axis is doing. This block indicates movement, idle, or faulted.

Inheritance: Okay, this is where the OOP gets a bit grey. I'll attest that my example demonstrates inheritance in that in Simatic S7 you can use the Blk_Move command to directly address the instance of this block to be used elsewhere in the program. Also, my example can be used as a starting point for a much more complex State Model motion block. I'd be glad to show you my Gearing and Camming block based on the same example.

I believe my response and my example clearly show how ST programming or SCL programming with a State Model approach is as close to OOP we can get in a PLC!
 
M
Hi,

the best implementation I know of is TeachTalk or KeMotion from Keba.
Fully OOP for PLCs. Very nice!

br. Marc Ricke
 
K

Ken Emmons Jr.

This is a nice looking controller, but I've never heard of them before. It looks like Sanyo Denki relabels them or has a partnership with them.

Can you program your entire machine (not just the motion tasks) with
their teachtalk "Robot" language? In other words, is the robot language limited in function, and can you have simultaneous robot tasks running?

Thanks,
KEJR
 
Top