CODESYS and PLC Philosophy…

Hi all! I’m continuing to make good progress on my new CODESYS book — Claude has definitely helped keep things moving.

Along the way, though, I’ve been wrestling with something, and I want to put it to the group.

The OOP Problem

CODESYS gives you real object-oriented programming: methods, protected variables, encapsulated code. On paper, that’s a great thing. It makes total sense when you’re building OEM equipment that’s never meant to be opened up and modified by the end user’s maintenance team — lock the logic down, expose a clean interface, and move on.

But that’s not the world most of my clients live in. Take the plant I was at last week. If I’d handed their maintenance guys a nicely encapsulated OOP program, they wouldn’t have known where to start. And that’s not a knock on them — it’s just not how they were trained, and it’s not how the plant operates day to day.

There’s a school of thought that says maintenance shouldn’t be modifying machines in the first place — that changes should go back through the OEM or a system integrator. In theory, sure. In practice, that’s often not realistic. Plenty of smaller plants simply can’t afford to bring in the OEM every time something needs to change. Plenty of OEMs, meanwhile, don’t have the in-house capability for higher-tech modifications — machine vision, robotics — and may not have a trusted integrator they can lean on either.

The larger plants I work with are a different story. Many of them do have real internal capability to make material handling or machine modifications on Allen-Bradley and Siemens platforms — the “Big Boys” of this industry. And that’s actually a big part of what I do: my training and consulting work is aimed at building up exactly that kind of in-house capability, drawing on a long career of programming and building machines.

Still, the field is changing fast. Structured Text and OOP — real computer-science-style software development — is clearly where the technology is heading, whether the plant floor is ready for it or not.

I’d Like Your Take

This is where I want to open it up. I work primarily in the US, but I know program design philosophy — and expectations around who touches the code after commissioning — can look pretty different elsewhere. If you’re a PLC programmer or system integrator, I’d genuinely like to hear how this plays out where you are:

How do you approach program design when you know plant personnel, not just the OEM or an integrator, will be the ones making changes and upgrades down the road? Do you scale back the OOP and encapsulation on purpose, or do you build it in anyway and train around it? And for anyone working outside the US — particularly in Europe — how does the balance between structured, encapsulated code and maintainer-friendly, transparent code tend to shake out compared to what I’m describing here?

I’d love to hear your experience in the comments, or feel free to reach out directly. This is exactly the kind of real-world tension I want to make sure my book addresses honestly, rather than just repeating the textbook answer.

— Frank Lamb