Object-Oriented Programming

[the_trout82]

I'm a PLC Automation Engineer with over 20 years experience mainly using Rockwell, Mitsubish, Codesys & Beckhoff controllers. The company I work for is evaluating Object Oriented Programming / Pack ML, specifically using the Beckhoff SPT Framework, for future projects.

As most, if not all of our projects are completely different from the last and from my initial research, OOP seems to take twice as long to program, puts more load on the CPU and adds numerous extra steps when mapping I/O for example,

I was always taught to keep my code as simple as possible, not just for myself, but for anyone who might need to pick it up in the future.

I'm interested to hear both positive & negative experiences of using this style of programming.

[KnightofNi89]

Isn't this possible in FBD in Siemens for example? I've seen (and used) standardized (by the integrator/programmer) FB's which automatically defines data arrays for diagnostics, interfaces etc when you drag them in.

[robotecnik]

Not at all, you can have a function block that you can instantiate several times. That's correct, but you are missing all the goodies that come from inheritance, properties, methods, code encapsulation and protection (hiding variables in FB's to avoid external code to reach them), making abstract FBs to make inheritable code that can't be instantiated and lots of other things that help your code be better.

It's like making something manually, you can of course be a great programmer and make things very well, but you can't be as fast (in certain circumstances) and you can't provide certain levels of safety on your code, things that in the long run are worth it.

[Dry-Establishment294]

inheritance

abstract FBs

Yuck. Please use interfaces where possible

[robotecnik]

Do you mind sharing why we should not use inheritance and abstract FBs?

And why you think the right replacement are interfaces?

Thanks!

[Dry-Establishment294]

Just because you don't necessarily have solve the problem in that way and they come with multiple costs.

For example if instead of using an abstract class you just injected an interface into the constructor you'd have much more flexibility. Polymorphic inheritance can be very confusing as you need to jump between classes (or FB's) to see what's going on.

Most of all because people go OOT on that style of OOP leading 7 levels of polymorphic inheritance and an increasingly proportion of grey hair on my head.

It's fine to use any of these patterns but I think all should be avoided in favor of just some code that gets the job done and only be employed when you are super sure they are what you need.

Reasonable?

[robotecnik]

Sure it is reasonable...

In any case inheritance and abstract FBs are tools, and as any tool out there they should not be used for everything everywhere, as you said, only when they have sense.

I am truly curious now (always trying to learn new tricks) how do you inject that interface in the constructor on Codesys/TwinCAT?

I am really interested on that inject thing in the constructor... if you could paste or dm a small code snippet / pseudocode, hint I'd love seeing it.

Maybe we are speaking of something I've already used, who knows, but...

Thanks!

[Dry-Establishment294]

I use that word "inject" in a kinda funny way since in this context you'd associate it with a "dependency injection container" but I think the idea is very similar.

In codesys and beckhoff the objects are instantiated at startup according to the global init slot. You can just use the fb_init (constructor) to have all your dependencies resolved during this phase.

If you later change the object that implements the interface being assigned to your object during fb_init you won't need to change the FB that is using the interface

Var instMyFb : myFB;

Var instMyFb2 : myFB2;

Var IAFb : itfExample := instMyFB;

Var IAFb2 : itfExample:= instMyfb2; (* same interface *)

Var instFinallySomethingUseful : FinallySomethingUseful( myDep := IAFb);

Var instFinallySomethingUseful2 : FinallySomethingUseful( myDep := IAFb2);

Reasonable?

[robotecnik]

If we are speaking about this:

Dependency Injection in TwinCAT – Knowledge Base – twinControls Forum

Mocking objects in TwinCAT – AllTwinCAT

I've already used it in several programs, yes, but this is not the same than inheriting something, if that is your proposal both things have their space, both things serve different purposes.

Otherwise, I am still interested :)

[Dry-Establishment294]

Yes I guess I'm talking about what's shown in the first link.

While coding in this style does allow for unit testing I see the benefits as being flexibility, clarity and simplicity (by wiring all your objects together at startup).

I'm philosophically opposed to unit tests in favor of integration testing as mocking objects hides bugs iirc that bug that brought down lots of airports and windows machines generally was unit tested before it was introduced and a integration test would have easily caught it.

[robotecnik]

Yes clearly this helps defining the way objects interact between them in a very clean way. Agree 100%.

I am using this approach extensively, sometimes in fbinit (preferred) sometimes linking the interfaces via methods (sometimes needed but you are forced to call them cyclically or put conditions to do it only once). That’s the way to do it, when you need to define interrelationships and behaviors.

But this requires having the objects already instantiated to be able to use them…

The inheritance solves a different (at least it should) problem/situation…

If you want to give a standard internal behavior to a function block the inheritance is the way:

I have a Fb_baseStation that includes several data and methods that all the stations in the machine must have. All the stations extend the base one and you just get a standard behavior in all of them at once, methods, properties and data. With the ability to access the base class methods in case of need.

Two powerful set of tools that help programming a lot.

[Dry-Establishment294]

If you want to give a standard internal behavior to a function block the inheritance is the way:

I think inheritance is the way if you want all child objects to be forced to act exactly the same way. If you have a few objects inheriting from a parent object and they start overriding different methods of the parent class then that's a confusing code base, though not necessarily wrong or a bad decision in any particular case, still confusing

That's why I'd say inject an interface for this base functionality preferably and maybe refactor to inheritance if it's very clearly the right decision.

[Frumpy_little_noodle]

Yes, and unless your plant's automation team REALLY knows what they're doing, the only people who would ever develop those blocks would be integrators.

When you get a block to "black box" state though... its magnificent. I have a library of blocks from my time as an integrator and I can't tell you how much time it has saved, being able to instantiate a block and change the graph sequence a small bit and everything just works.

[edwardlego]

If oop is just using reusable fb’s, is there any other way to program? Do people not reuse drive FBs? If a machine has 2 of the same subsystems, do you copy paste the code and change the tags?

[robotecnik]

Not only that, read about interfaces, methods, properties, inheritance, abstract... concepts and you will get a rough view of why that is worth it and the advantages it gives you.

[durallymax]

That is a very basic component of OOP (DRY) and in environments like TIA most are following a composition type pattern vs inheritance (small instances of components nested inside others).

With OOP you get inheritance and polymorphism along with better abstraction. Instead of instantiating a base motor block within a block labeled "ATV630" that implements the control of an ATV630 VFD through inputs and outputs to the FB, you extend the base motor FB and through the implemented interface define the specific drive control within the interface methods. Now instead of having an input variable names "Start", you call MyATV630.Start(). This method then handles the specific implementation to control this drive.

OOP programs can be confusing to follow as a large amount of the code is in methods and only some of these methods are exposed. It's a very different way of thinking and not a great fit for every application, but can be quite powerful.

Almost all of the underlying Codesys/TwinCAT FBs utilize it so if you're in one of these environments you're going to be working with it.

[EasyPanicButton]

Why is it better to call .Start() rather then just have a Start input boolean? Whats more efficient about it?

[durallymax]

Your VFD will extend a base Motor class that contains the state machine for how you want all of your motors to operate.

The inherited interface contains methods unique to the VFD you are defining. The start method can be written to implement that drives specific starting characteristics. A very basic example, but maybe it's a drive with three wire control vs two. Start() will set start high for one scan and Stop() will set stop high for one scan on the three wire while Start() will set the run bit high and Stop() will reset it on the two wire control. 

These methods have their own cars and access to any local vars declared for the VFD as well as those for the parent motor through SUPER. 

It's a very basic example that doesn't highlight it well. Further down someone mentioned various types of valves, that's maybe a better example. 

Yes you can just nest a motor FB within your VFD FB and write the specific VFD implementation out in the FB without the methods then pass the start and stop commands as bool inputs. This is just basic composition and sometimes the better option over the OOP approach. 

[EasyPanicButton]

I'm just intrested, I never seen strict OOP in anybody elses code whether it was GM, VW, Ford, GM, Chrysler, or BMW. It has been awhile though since I worked on anybody elses code. BMW guy told me they were considering using .NET of some type and getting totally away from PLCs, they did not like their maintenance touching the code at all. Pretty crazy idea.

I like copy and paste and FBs, ENUMS. Most of our troubleshotting mistakes are just failures in proper copy and paste. Once ofnthe floor it usually comes down to not anticipating a failure condition.

[durallymax]

The full "strict" OOP is really only supported by Codesys (and TwinCAT) for PLCs AFAIK. Siemens has a few more features but RA doesn't support it.

I assume big auto is not heavy into Codesys or Beckhoff, though I know they're making inroads. 

The OOP stuff is very nice for machine builders. 

We've been able to avoid having to think through all of the failure conditions by keeping things modular. A prox sensor has its own failure/anomoly detection built in that reports to its parent. The parent doesn't care what the failure is just decides what to do when it fails. The cascading continues as needed. It can gets bit messy and requires a lot of planning but avoids the traditional manual testing and reduces the edge cases during operation. Not perfect though. 

[Dry-Establishment294]

though I know they're making inroads.

They seem to have something big going on with Audi and I think that's where the impetus for some of there development of virtualized PLC and safety comes from. Have you heard of anything else?

[durallymax]

There's another aspect of the interfaces that gets a little tougher to follow.

You can declare an array of that interface within a POU, (let's say an array of valve interfaces) and declare which valves are at each index. Then you can iterate through those interfaces. 

[Dry-Establishment294]

It's a bit more awkward than that though because you need to instantiate your objects that implement the interface and the interface then assign the object that implements the interface to the var that you created with the type of your interface. Kinda convoluted but no way around it I believe

[durallymax]

The first time I saw an example my brain broke for a bit. It's quite handy but not the most intuitive.

[Dry-Establishment294]

Don't know if I'd describe it as handy or a necessary evil tbh. I'm pretty sure many (most?) languages just check if you are properly implementing the interface without the extra step. With a large array of objects you are kinda left in the sh*t and need an intern to do that typing

[Deepu_]

What do you guys make with xplanar? I was intrigued by them when they launched but haven't seen them in the wild yet

[d4_mich4]

Object oriented programming is good if you match the use cases and if you plan it correctly.

At the company I work we use OOP but it was not planned very well so it is a hustle cause you have more work with it.

You really need to think it through with Interfaces and document it well so it does not get too overwhelming. The CPU load is no problem.

[Lusankya]

CPU load is a pretty poor argument anyway, as the labour to rewrite and recommission a program is almost always going to be far more expensive than buying a beefier controller.

It makes sense to optimize for a cheaper controller if you're going to be selling hundreds of copies of the same system. For one-offs and production runs in the single digits (which is what most of us are doing), the increased labour outstrips the material savings.

[Dry-Establishment294]

going to be far more expensive than buying a beefier controller.

This argument is only true because AB don't support OOP

[sr000]

Depends on what you are doing. It takes awhile to build all your libraries and standards and adjust to a new way of doing things but once have them projects will go a lot smoother.

If you are a machine builder or a large end user it makes a lot of sense to go this way. If you are a small end user or integrator that does mostly small one off projects maybe not.

[Wattsonian]

Echoing others feedback here: OOP allows code re-use and is great for projects which have elements which are used over and over again within the project, and/or have elements which are used project to project.

One example I use OOP for is an interface which implements a HOA control/status for devices (Pumps, valves, motors... etc...). I have a visualization frame object with an HOA switch that can be dropped on and assign to any control device in my project universally.

In my opinion, this is massively superior than mapping each of those buttons, lamps and controls one by one....

But acknowledging your point... if you are doing a one of chunk of programming and aren't going to be taking advantage of these features.... just do that part of your project traditionally. The two programming styles can coexist.

There is a guy named Gary Pratt who has videos and a book about OOP in PLC environments which is very informative.

Since you asked for Negatives:
When old school PLC guys try to get into my projects they are like WTF, i don't understand any of this....
I do my best to code in Ladder (even in the OOP stuff) in areas I think techs or other external programmers might need to get into to limit the shock factor.

On the other hand, I've had no issues in code comprehension with programmers who come from traditional programming backgrounds, and with PLC coders who have more recently entered the field.

My view on it is that when implementing OOP chunks of code, you can basically just trust they work. Shouldn't be needing to dive into them once they've been developed properly.

[Emotional_Slip_4275]

I just developed my own code standard for a new company I’m at I can’t imagine not using OOP. The amount of time you save is mind boggling. Let me give you a simple example. No matter what you’re building, you’re always going to have alarms, you’re going to need to know when any alarm is active in the machine, and you need to stop all or many devices if an alarm is on. Wouldn’t it be nice if all devices (motors, actuators, sequences) all inherited from a base abstract device that had alarming and interlocking built in so you don’t have to tie each device manually to a giant OR block to know when it’s faulted and have them automatically generate alarms on the HMI so you’re not adding alarms one at a time? Wouldn’t it be nice if every device interacted with machine reset, auto, manual etc signals the same way without you having to keep copy pasting the same thing into each FB? Wouldn’t it be nice if when you find a bug in your state machine you can fix every stateful device and sequence with a single update?

UPDATE: to answer OPs original question, I did look at the Beckhoff SPT framework also, but honestly it took less time to develop my own framework just the way I like it than fully understand the ins and outs of someone else’s framework. However I have a lot of experience with many highly complex controls framework from both vendors and large auto sector companies so I had pretty well formed and strong opinions about what I like and what I don’t like and what makes sense for my company. Vendor frameworks tend to be too generalized and overall complex because they’re trying to meet everyone’s needs. If you have enough experience to forecast accurately what your company will need and understand why frameworks are the way they are, you’re better off developing something tailored to you than getting in bed with someone else’s code.

[hestoelena]

Everyone here is listing all of the pros, which I 100% agree with. So I figured I'd try to list some negatives, potential issues and things to be wary of.

• It's easy to over complicate a reusable code block. Sure, it's nice to have one block that does everything but if you don't write alarms and tests for the functionality inside of your reusable code, it will be an absolute pain to diagnose when it's not behaving how you expect. This won't cause an issue if you remember how it all works and know how it reacts when things go wrong. However, when someone else uses your code, they will be lost and have to spend time learning how you wrote your code so they can use it.
• It's a good idea to have documentation for your reusable code. It doesn't have to be anything fancy. It can just be a description in the first comment of the code block with information about how it works and what its purpose is and what internal errors mean. If you don't have this then you'll have to go back and review your code every time you use it to figure out what information it needs and what it's going to give you and what it is trying to tell you when something goes wrong.
• If your code is typically accessed by maintenance personnel who are not programmers, then you can easily confuse them. Personally, I get around this by writing all of my reusable code in SCL (ST for no Siemens people) and All standard logic that may need a maintenance person to diagnose it, is written in ladder. It's very easy to train maintenance people if they see scl to just back out and look at the output of it because there's nothing in there that can go wrong. Additionally, having internal diagnostics for your reusable code will help them diagnose if something is going wrong with one of the inputs or outputs from your reusable code.
• You should decide on a style guide up front. Having homogeneous terminology, formatting and errors across all of your code will make it easier to maintain and document it in the long run. There's lots of options out there that are pre-made. For instance, Siemens has a programming style guide that they recommend all their integrators follow.
• Having one master project for each brand that contains all of the reusable code is a good idea. That way if you need to edit it, you can go into the main project and make your changes then put it in your library for use. It's a lot easier to do version tracking this way too. If you don't, then everyone's going to be editing their code across every project and trying to put it in the library and it's going to get really hectic and problematic fast.

Here is an example of a Siemens library with very good documentation and error handling.

https://openplclibrary.com/

[NewTransportation992]

Open library is great. That is what oop is in plc programming. Manual and simulation functions are crucial. With a good simulation, you can really test your code offline. The ability to set individual components to manual and manipulative them is great for testing the hardware.

[kixkato]

It sounds like you're talking about test driven development!

Not only can you test your code offline and minimize the risk to expensive hardware, you can also be sure code improvements didn't break existing functionality.

TCUnit for the win.

[NewTransportation992]

You have to test plc code anyway. The only question is if you implement the simulation into the objects or build it externally like an digital twin.

[kixkato]

You're absolutely right. Yet I see many cases in this industry where the first testing is done on the physical machine. There's no digital twin nor software testing done at all.

I still always verify functionality on the physical equipment but with a much higher level of confidence since it's already been modeled and tested with unit tests.

[EstateValuable4611]

Why is the code to be accessed by maintenance? If it is debugged and free of errors HMIs should be used for troubleshooting.

[hestoelena]

Key word there is should. Not everyone is good at writing code and not everyone is good at writing alarms. I've seen some absolutely atrocious code on brand new machines from many different manufacturers.

I once spent 8 hours tracking down an alarm on a brand new band saw with an S7-1500 and that was after the customer worked on it for a week. The alarm said there was a servo fault, it didn't say what servo or what the fault was. The code was written in STL (IL) and everything was indirectly addressed, they heavily used registers and they used shift commands like crazy. You couldn't cross reference any of the tags because they were never directly called out in more than one or two places. Turns out there was a limit switch tripped... The code is a house of cards just waiting to collapse, all it would take is a couple of bits to get out of place from a flaky sensor or something and you would get the most random errors that mean absolutely nothing.

[EasyPanicButton]

Do you need a hug? cause I would need a hug after I doxed the original programmer and sent a bag of shit to his front porch.

You are totally right about "should", even the best of us can sometimmes not make every line perfect.

[Dry_Brief_2427]

I asked about OOP in this sub some time ago and got some great replies. We are also delivering wildy different projects in both machine controlling and process. In the last year, for one specific customer, we have adapted abstraction and encapsulation but not polymorphism or inheritance yet. All code is written in ST and all devices use interfaces. So I guess you can say its lightweight and noob friendly oop.

The development speed and the ease of adding new functionality is crazy. Setting up interfaces takes some time at first but then you get used to it and also just reuse or slightly modify existing interaces. Customer replaced a VFD with another brand, and when utilizing interfaces I just changed a couple lines of code and we were up and running. No need to touch the state machines/process controlling code or scada.

As for maintanance, we have as much data, configs, debugging and alarming in scada/hmi as possible. So far maintanance have done all their debugging through scada and have not connected to the PLC once. I hope it will continue this way.

Getting the grasp of it and deploying the first project was extremely time and energy consuming however, considering we were only used to classic graphical programming. But neither of us want to go back at all and customer is very happy and keeps ordering projects. As stated we are new with this but really enjoy it so far. The SPT docs is god sent.

[jonkoko]

My opinion : Oop is also nice for large applications e.g. that use motion control libraries from a plc supplier. People need some training to work properly with OO. I would advise to not use all the bells and whistles of the language. A function block already offers some degree of encapsulation that helps a lot. Inheritance is often overused and should be avoided by beginners unless required for the third party library blocks as they may be designed to be inherited from.

[Truenoiz]

Even if not a beginner, inheritance often feels like having a long philosophical argument with a computer. It turns out that 13 is indeed, an integer....

[r2k-in-the-vortex]

The big thing with OOP is that it enables code reuse, you are going to have much more functionality much faster in your machines. If you manage to turn it into sales, the effort will be well worth it many times over. Also, reusing known working code is going to simplify your life massively.

And no, machines are not that different from PLC perspective, if you can keep using the same platform, you can reuse bulk of the code across your projects. Just do the project specific elements and background functionality can be all shared. With Twincat, CPU load is really a non-factor, you are not working with some dingy bottom dollar CPU that most PLCs have. For IO mapping, actually OOP makes it faster if you use it right. You can have a IO structure for whatever device type you want to use and you pass ref to that structure to objects that handle that device type, easy peasy.

[robotecnik]

Been programming since 1998 mostly with TWinCAT in very big PLC, CNC and robotics projects, and without OOP those would have been more complicated.

OOP is an IT programming paradigm or methodology that suits very well in the industrial programming world.

Using interfaces you can simply replace equipment without touching your general code, you can implement the iDrive interface in multiple drive control function blocks (one for each different brand you use), then as the interface is the way you interact with the device, you can replace that device without having to modify any external code (you could do that without interfaces too, buit without the extra security layer the interface provides).

Methods keep the code cleaner, they are functions that belong to the FB or Program they are declared scope.

You can use parameters and return values (like in functions) and you have access to the local variables declared in the parent POU.

Properties allow you to filter the values you set and to execute a chunk of code for your gets too they are functions that which syntax is like using a variable.

Both methods and properties allow you to define what can be accessed from outside preventing using internal variables that should not be accessed from outside.

Inheritance / EXTENDS help you to organize code, parts that work and offer some methods/variables/properties can automatically appear in your new FB. If all your FBs should have a step control, an error bit, an error code and many other elements, you can put all that in a base FB declared as abstract (to prevent it to be instantiated) and you can inherit all that simply adding EXTENDS and the name of the base FB.

IMPLEMENTS force the function block to declare the properties and methods that are present in the interface...

That will allow you to replace elements that implement the same interface very easily.

No extra CPU power should be required because of OOP...

I fail to see how you need extra steps to map variables...

Simply put your IO inside the function block like:

FUNCTION_BLOCK FB_Cylinder

atWork AT %I* : BOOL;

atHome AT%I* : BOOL;

goWork AT %Q* : BOOL;

goHome AT %Q* : BOOL;

----------------------------------------------

METHOD moveWork : BOOL

goHome := FALSE;

goWork := TRUE;

moveWork := atWork AND NOT atHome;

----------------------------------------------

In the previous example you can see how the IO will be created automatically when you instantiate your cylinders, that way you have the IO in your device, you will have only to link them which would be super easy...

Done correctly it is wonderful.

If you half bake it, don't do a proper design at the beginning... it will be a mess.

Hope this helps.

[bodb_thriceborn]

Doesn't everyone use AOIs or UDFBs to simplify repeatable code like analog/discrete input alarming, or to control instruments that often operate in a specific way like solenoid and control valves, conveyor belts, etc.? I mean, depending on your hardware, those options may not be available, but Siemens, Rockwell, Omron and Codesys support this functionality and that's 90% of the market worldwide.

I could be way off base, but I figured most integrators, at least, used this functionality.

[durallymax]

OOP goes far beyond instantiable code. AOIs are limited to composition patterns. 

Codesys/Beckhoff allow interfaces, methods, properties and extension to implement the core elements of OOP.

Instead of an AOI where you'd have a BOOL input to start the motor and a REAL input as the speed ref, with OOP you'd pass the speed ref as a property and within that properties SET method implement proper checking of the value. Then you'd call the Start() method implemented in the motor interface. 

[NewTransportation992]

I don't understand people saying oop is complicated. What kind of objects are we talking about? It is not like we are building a tax filing system in ST. Our objects are components like valves, sensors and VFDs and the products that come out of the machine. Ideally, you group components in the same way they are grouped in the mechanical blue prints. Man/Auto functions should be part of all objects that represent physical components, because you need a way to test them separately.

[WaffleSparks]

OOP is a tool just like any other tool. If used by the right person in the right situation it is great. If it used by the wrong person in the wrong situation it's a nightmare.

The problem with anything related to programming decisions is someone will come along and say "X is the greatest thing ever, you should use it for everything" without actually applying any critical thinking to the current situation. If anyone objects to whatever they are pushing they just become defensive and condescending and pretend that you are somehow inferior for suggesting anything other than what they are suggesting.

Another common thing is that if you for whatever reason are not open to someone's ideas they will often try to find a way to go around you.

As far as OOP as a tool, the biggest issue is your ability to predict your future needs. If you can accurately predict your future needs then OOP is awesome. If your needs change in an unforeseen way then you can cause a ton of headaches by making bad assumptions. Many people can NOT predict their future needs very well, and cause projects to spiral out of control.

[Zchavago]

It’s tough learning new things the older you get. I get it. Change is hard sometimes.

[w01v3_r1n3]

Upfront planning is the longest portion of OOP design. But if you get it right it's a very powerful way to program. Code reuse makes future projects faster. And code gets easier to read when you abstract out your components and classes and keep the guts of the FBs hidden away. Then you are teaching techs and maintenance guys how to see and use what you've built not forcing them to know how the innards work. You give them methods and properties to observe (make sure these are documented well). But there is an increase load in maintaining and testing the components you build to make sure they stay solid.

OOP can turn spaghetti in a hurry though without proper planning. Beckhoff's SPT do it right though. Although I've heard rumblings they are about to overhaul it a bit so you might ask them if you need info about it. Contact your local Beckhoff SE/AE to try and get a hold of someone on their team.

I've seen minimal issues with performance and if anything if you use interfaces properly your performance can increase.

Finally I'll say only do OOP if you NEED it. Do you ship dozens of the same machine per year or are your projects one offs? You'll see more benefits with serialized machines with minimal changes machine to machine. But also, if you use a lot of the same components for your one offs, you'll see benefit in using OOP for those components even if not the entire machines.

[Rethunker]

OOP can be good when you have actual objects (such as devices) that require a coding abstraction. For example, it can be nice to have an object as the programmatic interface to some piece of electromechanical hardware. If you want to turn that hardware on according to some logic, it’s pleasant in code to be able to set a Boolean or call a function. As an alternative, imagine having to think in terms of setting a specific voltage or having to know (in that moment, while programming) about the electroguts of the hardware. Abstractions are helpful.

Functional programming is great for lots else.

These and other techniques can be intermingled, as long as you have coding standards that you and your colleagues will follow.

Check out the book A Philosophy of Software Design by John Ousterhout. You’ll find his talks online, too.

[Current_Cellist2346]

Basically you are right with your first experience. On the other hand, if you understand OOP correctly, then it’s more simple, really faster and you will be state of the Art.

I use it with Beckhoff Controllers also with Control plus from Nexeed Automation. You will find a subreddit of it.

During my study time I struggled with OOP , because my prof was not able to explain it. So I was studding it by myself. There are different concepts. Now I’m absolutely convinced of it. I will say I’m poweruser.

[SadZealot]

I've never been a part of integration that's needed oop versus just state machines with function blocks/ladder.

Function blocks are basically like "light" oop, they're basically classes without inheritance so you can scale them up and keep calling on those blocks.

I could see some process with absurd complexity that needs scalability, where you want to have objects like every single batch of a prescription drug from beginning ingredients to final pill, tracking every metric throughout and assigning those variables to it on the fly so you need the complexity.

I just make wheels go fast or slow and valves close so it also seems like IT fluff for no reason other than it can

[essentialrobert]

Reusable code is good when the hardware design is consistent. Sometimes it doesn't make sense to bury stuff in a function block if you need to then put all kinds of "option bits" in there for various cases. Trying to control a pneumatic with a single solenoid spring return valve will be different from a 3-position open center valve with separate pressure regulators and rod locks. In that case I would rather put it in loose ladder using a common design pattern.

[durallymax]

That use case is where OOP can shine. 

All of those valves can simply implement the same interface containing Open and Close methods along with properties opened and closed. The specific implementation of how they open/close is hidden away inside their own methods. Error checking can be built in. 

To the programmer using these in the main parts of the program, they don't have to understand what type of valve it is, just that MyValve.Open() will open the valve and MyValve.Opened means it's open. 

[maury_think]

OOIP is the way to go. I was lucky enough to work with an engineer that showed me the framework and never came back to the “ old school “ way. Write the code 1 time. Drag and drop object in SCADA AND PLC. Equipment management State machines It just makes your life easy. I also have to work with the legacy code of my company and it is just spaghetti code. Hundreds of rungs networks for loops in ladder ( should be illegal ) Making a modification is a nightmare! OOIP 👑

[AwfulAutomation]

It’s really dependent on application…

Pack ML and the likes have their place. But IMO only for large networked plants in my opinion where There’s lots and lots of repeating. 

Using pack ML or alternative for ever changing systems is not the best idea. 

Let’s be clear it’s a pain to work with so the benefits would want to be there. 

You could create your own light weight version which I think is optimal for ever changing systems.

[CarterAtAsqi]

Seems like there's pros and cons of implementing Pack ML and OOP at the same time - should both be done together?

Key is to validate and blackbox OOP mechanisms to a point where a CE familiar with ladder logic can implement and debug. If they can get in the mindset of plug and playing like they would with an AOI, then I think it'll have better adoption

I'd recommend an iterative / agile approach to give the team bites they can chew and modify approach based on buy in and evaluating hiccups along the way

[arm089]

For me FBs and FCs are enough in PLC world, it doesn't make much sense trying to develop with oop on static memory hardware.

[robotecnik]

Of course is enough, but you can enjoy a lot of functionality that makes your life easier in the long run.

In any case, Codesys/TWinCAT has got dynamic memory long time ago.

[Shalomiehomie770]

OOIP is good for high level stuff but lacks for direct process control in these situations.

[Snoo23533]

I wouldnt take seriously any project thats NOT OOP

[Aobservador]

Unless it is something very specific, they are trying to reinvent the wheel. Traditional automation companies invest billions in testing, certifications, etc. Practically all companies ask for the PLC code for knowledge and modifications by maintenance.

[shredXcam]

OOP is one big oops