If a program works only when I am standing next to it watching the monitor, I have not finished the job. I learned that on a battery charger job that cost $3,200 and one very uncomfortable customer call.
I’m a controls engineer, and I’ve handled Siemens PLC service and programming orders for nine years. I’ve personally made and documented 23 significant mistakes. Together, those mistakes wasted roughly $187,000 in budget and credibility. I keep that number in a note on my desk. It is not there for sympathy. It is there because I need to remember that quality is not an option.
The request arrived in our inbox as “how to connect battery charger.” I understood it as a wiring task. The controller was a Siemens S7-1200 G2 PLC. The battery charger had a remote start input, we had a relay output on the PLC, and I made the assumption that the rest of the charger’s brain was not my problem.
I was wrong.
In simulation, the output energized at the right step. On the customer’s floor, the charger ignored it. The charger had its own internal state machine. It performed a self-test after power-up and only accepted a start command after that self-test was complete. My PLC sent an edge-triggered command too early. The charger rejected that edge, and then it would not accept another one until it received a reset command. My logic didn’t send one.
The frustrating part was the silence. No fault. No alarm. The HMI sat on a comfortable screen that looked as if everything was normal. The operator pressed start. Nothing happened. I pressed start. Nothing happened. We cycled power, the same sequence repeated, and the machine looked broken even though every individual component was fine.
The fix required reading the charger manual and adding the correct reset/ready sequence to the PLC program. The cost was not in the code. It was in the client’s perception. After that visit, the client didn’t say, “your program had a timing issue.” They said, “your system is unreliable.” Code quality became brand quality in one sentence.
From the outside, the charger looked fine, the control panel looked fine, and the PLC output was toggling. People assume a missing fault means nothing is wrong. The reality is that many expensive PLC problems are silent. They happen because the program did not account for the state of the process around it, not because the syntax was wrong.
Most buyers ask, “Does it run?” They should also ask, “What happens when it stops unexpectedly?” That second question is where a controls brand is made or broken.
People search for “PLC programming language” when they are trying to decide between Ladder, FBD, SCL, or something similar. I get it. But a programming language did not cause my battery charger mistake. The problem was that I focused on the code and not on the physical device’s behavior.
IEC 61131-3 organizes PLC languages, and Siemens gives us capable tools in TIA Portal for the S7-1200 G2 and larger controllers. Yet a well-structured language can still produce a machine that fails in confusing ways. I have written Ladder that looked clean on the screen and behaved badly on the machine. I have also written SCL that was easier to review because it forced me to express the sequence order more clearly. The language matters less than the logic, and the logic matters less than the assumptions underneath it.
I often see people searching for “Siemens PLC programing” because they want to learn TIA Portal shortcuts or how to set up a new CPU. Those skills are useful. But the hard part of Siemens PLC programming is not the programming language. It is the failure-mode review: checking what happens before the alarm, after the alarm, and especially when there is no alarm at all.
An appliance repair friend once explained his approach to a blank Jenn Air control panel. His first instinct was to replace the panel. After several callbacks, he learned to check the voltage, the harness, and the component behind the panel before ordering the expensive part. In many cases, the panel wasn’t the problem. It was only the part that looked bad.
PLC programs have the same trap. If I patch a confusing sequence by adding a delay, the machine may start working again. But if I don’t find out why the sequence reached a confusing state, I have only made the control panel look normal. The underlying condition is still there, waiting for the next operator to trip over it.
This is why I now treat a “working” program as the beginning of the review, not the end. Code that handles normal operation is the baseline. Code that handles abnormal operation is where the quality shows up.
After the charger incident, I changed our team’s release procedure. We still test the happy path. But we also test the path that happens when reality does not follow the sequence. The checklist has three core questions:
We have caught 31 issues with this checklist in the past 18 months. Not all were expensive, but all of them would have been embarrassing.
A checklist like this sounds expensive only until you compare it with the cost of a callback. A callback is not just hours on-site. It is also the moment the client starts doubting your next proposal.
Quality in PLC programming is not how little code you write. It is how easy the system is to trust when something goes wrong.
Some engineers say, “The client won’t care about the code as long as the machine runs.” That is only true until the machine stops. Then the client cares about callbacks, downtime, repair costs, and the confidence of their own maintenance team. All of those things are shaped by code quality.
I don’t expect every customer to open a program file and admire our tags. But customers do open an HMI. They do read alarms. They do watch how long it takes for a service call to show up. And they remember whether the fix lasted or whether the same strange fault came back two weeks later.
The program you ship is the quiet part of your brand. It does not need to be beautiful for the buyer. It needs to be honest enough for the next person who has to touch it.
I still like the Siemens S7-1200 G2. I still use TIA Portal every week, and I still debate PLC programming languages with engineers who ask. But today, I judge a job by a sharper test: if the process stops at midnight, will the program make the next step obvious and safe? If not, I have more work to do before the project is really done.