Global Variables in PLC Programming: Are We Making This Too Complicated?
MWL Automation Notes | Manufacturing With Light
I’ve read quite a few articles and discussions lately suggesting that PLC programmers should avoid global variables. Some go so far as to imply that using them is simply bad programming practice.
I don’t entirely agree.
I understand the arguments against global variables, and I agree with many of them. But I also think we need to consider what we’re programming, why we’re programming it, and who is going to maintain it.
Not every automation application is a large, complicated production system. In fact, much industrial automation consists of relatively small machines, individual workcells, and process skids.
And sometimes, the simplest approach is also the best one.
Not Every PLC Gives You a Choice
Let’s start with something that occasionally gets overlooked in these discussions.
Not every PLC supports the same programming architecture.
Some smaller PLCs have limited support for local variables, function blocks, structured data, or the kinds of programming techniques available in larger platforms. Some use predominantly global memory or fixed data registers as their basic programming model.
Does that make them bad PLCs?
Of course not.
A small PLC controlling a pump skid, a simple assembly fixture, or a handful of pneumatic cylinders may be exactly the right controller for the job.
It may be inexpensive, reliable, easy to program, and perfectly capable of controlling the equipment for the next twenty years.
Why should we select a more expensive controller, or introduce software complexity the application doesn’t need, simply to follow a particular programming philosophy?
The same reasoning applies to global variables.
Just because a programming technique has limitations doesn’t mean it isn’t the right choice for a particular application.
I Believe in Modular Programming
Before someone gets the wrong idea, I’m not suggesting that we abandon structured or modular programming.
Quite the opposite.
I believe reusable functions and function blocks should generally have clearly defined inputs and outputs. Their internal logic should not depend on a collection of global variables scattered throughout the application.
If I develop a function block to control a pneumatic cylinder, I want to reuse it on another machine without rewriting the code or recreating a particular global-variable structure.
The block should receive the necessary commands and feedback, perform its function, and return the appropriate status.
It shouldn’t need to know where those signals originated.
That is good modular programming, and it makes sense whether the application is large or small.
But I don’t believe that means we should avoid global variables everywhere else in the machine program.
Global Variables Can Be Useful
Consider a small automated workcell.
It might have a few pneumatic cylinders, several sensors, a servo axis, an operator interface, and a relatively simple automatic sequence.
The application needs to share information such as:
- Machine operating mode
- Cycle running and cycle complete
- Part present and clamp status
- Fault and alarm conditions
- Recipe parameters
- Operator commands
There is nothing inherently wrong with organizing that information in a set of well-named global variables.
In fact, it can make the machine easier to program, understand, and troubleshoot.
I like being able to open a variable table and see a machine’s key operating conditions without having to navigate through several layers of function blocks.
And when a maintenance technician is trying to determine why a machine won’t start, that kind of visibility can be valuable.
The important distinction is between sharing machine information through global variables and creating hidden dependencies inside reusable code.
Those are two different things.
There Are Legitimate Concerns
Of course, global variables can cause problems.
If several different sections of a program can write to the same variable, it may become difficult to determine which one is actually controlling it.
If a function block depends on global variables that aren’t obvious from its interface, the block becomes harder to reuse and test.
And when global variables are scattered throughout a large application without any organization, troubleshooting can become a nightmare.
I don’t dispute any of that.
But those are arguments for using global variables carefully, not necessarily for eliminating them.
For example, I generally want one clearly defined section of the program responsible for controlling a physical output. Other programs can request an action, but they shouldn’t all write to that output independently.
That’s a good design practice whether the variables are global or local.
Sometimes We Create Complexity Trying to Avoid Complexity
This is probably my biggest concern with some modern programming recommendations.
We can become so focused on following software design principles that we lose sight of the equipment we’re trying to control.
I’ve seen discussions advocating multiple layers of abstraction, elaborate function-block hierarchies, and extensive object-oriented programming techniques for applications that really don’t require them.
Those techniques have their place.
If you’re developing a standardized machine platform, creating a reusable software library, or working with a team of programmers on a large production system, the advantages can be substantial.
But what about a small machine with one PLC, a few dozen I/O points, and a straightforward operating sequence?
Will all that additional structure make the machine easier to maintain?
Maybe.
But maybe not.
A well-written, straightforward program with meaningful variable names, organized globals, and a few reusable function blocks may be far easier for the next engineer to understand.
And that matters.
Choose the Programming Approach to Fit the Machine
I don’t think we should establish programming rules without considering the application.
A large multi-station assembly system developed by a team of engineers has very different requirements from a standalone test fixture or a small process skid.
The larger system may benefit from extensive encapsulation, carefully controlled interfaces, standardized software libraries, and a more formal architecture.
The smaller system may need little more than organized machine logic, a few reusable functions, and clearly named global variables.
Neither approach is inherently better.
What matters is whether the result is reliable, understandable, and maintainable.
And let’s not forget that the choice of PLC itself should follow the same principle.
A relatively inexpensive controller with a simple programming environment isn’t necessarily an inferior solution. If it meets the application’s functional, performance, safety, and support requirements, it may be the best choice.
We shouldn’t make the hardware or the software more complicated than it needs to be.
The Real Goal Is Maintainable Software
I think most experienced controls engineers would agree that poorly organized software is a problem regardless of how it is written.
You can create a terrible PLC program using global variables.
You can also create a terrible PLC program using function blocks, local variables, and object-oriented techniques.
Following a particular programming philosophy doesn’t automatically produce good software.
Good software should be understandable to someone who didn’t write it.
A technician should be able to find out why the machine stopped. Another controls engineer should be able to make a reasonable modification without reverse-engineering the entire application.
Reusable functions should be reusable, machine states should be understandable, and the software should reflect how the equipment actually operates.
Those are the things I care about.
A Tool, Not a Programming Sin
My view is pretty simple.
I believe in modular programming, particularly for functions and function blocks that may be reused.
I also believe global variables are a perfectly legitimate tool for organizing and exchanging information within a machine application.
For many small machines, workcells, and skids, they can be an efficient and practical choice.
And if a small PLC relies primarily on global memory, that doesn’t automatically make it a poor controller. It may still be exactly the right tool for the job.
We should evaluate programming practices by how well they serve the application, not by whether they conform to someone’s preferred software architecture.
After all, we’re building machines, not demonstrating programming techniques.
Manufacturing With Light (MWL) — Automation Notes
Practical perspectives on motion control, machine automation, and software engineering.