I've been meaning to write something about this topic for a long time. Especially now where there's a lot of talk out there on programming languages, what AI can do for your logic in the future 🤖, how high-level programming languages like C++ and others could fit into the mix etc...
There's definitely been some entertaining content 💬out there from both the old-school PLC folks and the new up-and-coming 😀.
Although I enjoy reading most of those posts (I'm always ready to learn new things 🧑🎓), I think they often overlook one important point.
You see, a real-life application 🏭 e.g. a production line, a processing plant or a stand-alone machine - isn't just inputs, outputs, global and local data, and a bunch of logic 🧩 to connect them all together (in other words: the programming LANGUAGE).
If you zoom out 🔍 and look at the bigger picture 🖼️, a real-life system is really a collection of modules - smaller, logical, self-contained units 📦 (you got it - the program STRUCTURE).
And if you did your homework right, those modules should be:
✅ Scalable
✅ Easy to troubleshoot
✅ Simple to maintain
✅ Straightforward to update
In my opinion, this is what separates the 1% of PLC programmers from the rest - the ability to create modular PLC software - not just being great at ladder, structured text or any other language out there.
I feel there is way too much focus on programming languages and nowhere near enough on how to structure an application properly. You could write flawless code in the “perfect” language, but if your structure sucks, no-one will have a nice time troubleshooting your PLC application🔧 (speaking of which - I'm in the middle of one such mess right now 😅).
So what should you actually do before diving into any programming language?
👉 Break your application into smaller, manageable parts
👉 Define the key sections of your application (general, equipment, safety, motion, library, global data, etc.)
👉 Create clean, independent data structures for each module
👉 Build reusable functions or function blocks for repeatable logic (or at least define them - the logic comes later)
And the best part? 💡These structuring principles apply regardless of the programming language you use. Your program structure is like LEGO bricks 🧱 - it’s the framework you define to build your application. The programming language? That’s what goes inside those bricks.
So next time you start a new PLC project, remember:
1️⃣ structure first
2️⃣ language second
I appreciate you making it to the end of this little rant of mine 😁
Do you agree with me, or have some other opinions?
⬇️ Let me know in the comments below ⬇️
PLCskilltree
🔷 PROGRAM STRUCTURE > Programming Language 🔷
I've been meaning to write something about this topic for a long time. Especially now where there's a lot of talk out there on programming languages, what AI can do for your logic in the future 🤖, how high-level programming languages like C++ and others could fit into the mix etc...
There's definitely been some entertaining content 💬out there from both the old-school PLC folks and the new up-and-coming 😀.
Although I enjoy reading most of those posts (I'm always ready to learn new things 🧑🎓), I think they often overlook one important point.
You see, a real-life application 🏭 e.g. a production line, a processing plant or a stand-alone machine - isn't just inputs, outputs, global and local data, and a bunch of logic 🧩 to connect them all together (in other words: the programming LANGUAGE).
If you zoom out 🔍 and look at the bigger picture 🖼️, a real-life system is really a collection of modules - smaller, logical, self-contained units 📦 (you got it - the program STRUCTURE).
And if you did your homework right, those modules should be:
✅ Scalable
✅ Easy to troubleshoot
✅ Simple to maintain
✅ Straightforward to update
In my opinion, this is what separates the 1% of PLC programmers from the rest - the ability to create modular PLC software - not just being great at ladder, structured text or any other language out there.
I feel there is way too much focus on programming languages and nowhere near enough on how to structure an application properly. You could write flawless code in the “perfect” language, but if your structure sucks, no-one will have a nice time troubleshooting your PLC application🔧 (speaking of which - I'm in the middle of one such mess right now 😅).
So what should you actually do before diving into any programming language?
👉 Break your application into smaller, manageable parts
👉 Define the key sections of your application (general, equipment, safety, motion, library, global data, etc.)
👉 Create clean, independent data structures for each module
👉 Build reusable functions or function blocks for repeatable logic (or at least define them - the logic comes later)
And the best part? 💡These structuring principles apply regardless of the programming language you use. Your program structure is like LEGO bricks 🧱 - it’s the framework you define to build your application. The programming language? That’s what goes inside those bricks.
So next time you start a new PLC project, remember:
1️⃣ structure first
2️⃣ language second
I appreciate you making it to the end of this little rant of mine 😁
Do you agree with me, or have some other opinions?
⬇️ Let me know in the comments below ⬇️
Stay structured!
-Hans
PS. If you want get structured in TIA Portal, then grab my free guide right here 👉www.plcskilltree.com/free-guide-optin
You’ll learn 5 simple steps to drastically improve the structure of your PLC applications in TIA Portal 💪
2 months ago (edited) | [YT] | 9