Your Allen-Bradley PLC Isn't the Problem. Your Training Is.
At 3:07 PM on a Thursday last March, I got an emergency call from a maintenance supervisor at a regional airport. Their aviation battery charger—a system built around an Allen-Bradley Micro870 PLC—had stopped mid-cycle. An A320 needed a certified battery by 5 AM the next morning. The supervisor had already checked the battery with a multimeter: 12.6 volts, stable, within spec. He'd verified input power. Fuses were good. The PLC had a solid RUN light and no fault indication. But the charger was delivering zero amps.
"The PLC is running fine," he said. "I think the SCR module blew."
He was wrong. And I understand why he thought that, because the "PLC is running" assumption is the most dangerous phrase in industrial troubleshooting. A PLC can execute its program perfectly while the program tells the system to do the exact wrong thing. That's precisely what was happening here.
The Surface Problem: A Charger That Won't Charge
The surface problem was simple: the charger stopped charging. Every step the supervisor took was by the book. Power. Fuses. Battery state. And when the PLC appears to be running, you assume it's doing its job. That assumption is what lets the real problem hide for weeks.
Here's the distinction that matters: "the PLC is running" and "the PLC is running the correct application" are two completely different statements. Most maintenance teams never pause to consider the second one. They check everything that can be checked with a multimeter—and then they stop. But the next layer of the system, the logic layer, is invisible to meters.
My first question to the supervisor wasn't about the SCR module or voltage readings. It was: "Who modified the PLC program last week?" The silence on the other end of the line told me everything I needed to know.
The Deep Cause: A Training Gap Disguised as Hardware Failure
When I dialed into the system remotely and opened the application in Studio 5000, the root cause was visible within a few minutes. A week before the failure, the facility's electrician had made "a small improvement" to the charging sequence. He'd just completed a two-day Allen-Bradley PLC training course and wanted to add a stage-duration readout to the HMI. He wasn't careless. He was undertrained. And in his edits, three critical things went wrong.
First, a timer preset that was 60 times too short. The absorption stage of the charge profile is supposed to hold a constant voltage for 45 minutes. The timer had been changed to 45 seconds. The charger was stepping through its entire algorithm in under five minutes, then dropping to float mode while the battery sat at roughly half charge. The voltage looked normal on the HMI. The amp-hour deficit was invisible—until the first cold start attempt.
Second, a one-shot that never fired again. The transition logic from bulk charge to absorption used an ONS—a one-shot instruction that triggers only on the rising edge of a condition. The electrician placed it on a rung with a parallel branch, so the ONS bit fired exactly once at download and then never again. The state machine never advanced past its intermediate step. No fault. No alarm. Just a system sitting in limbo, waiting for a condition that would never be true.
Third, non-retentive tags for critical state data. The charge stage numbers were stored in non-retentive memory tags. Any brief power dip—like when heavy ground support equipment kicked in on the same bus—reset the PLC to stage 0, as if a new battery had just been connected. The charger would restart from the beginning. The battery never received a complete cycle. And because the PLC always restarted cleanly and the display always came back up, nobody realized anything was wrong.
Every one of those is a programming issue, not a hardware issue. The PLC was executing the code exactly as written. That's the whole point: the code was written by someone who knew how to create rungs but didn't yet understand system design. He could navigate Studio 5000, enter instructions, download a program. But he hadn't internalized scan cycles, retentive memory, or state transition pitfalls—the things that actually determine whether industrial code survives contact with reality.
Per IEC 61131-3, the international standard for PLC programming languages, control logic should be structured to prevent unintended behavior on power restoration. Most of the field failures I encounter are direct violations of that principle—which makes sense, because violating a standard is easy when nobody teaches you the standard exists.
I've seen this pattern in dozens of emergency calls. Let me be honest—I'd need to check the dispatch log for an exact count, but it's somewhere north of 60 cases in the past two years. A fleet operator's battery charger for dump trailers kept terminating the charge at 70% instead of 100%. They'd already replaced three charger units—three—before somebody thought to open the ladder logic inside the Micro820 controlling the profile. The code used latched bits instead of a proper state machine, so any voltage disturbance on the trailer's 12V supply reset the cycle early. (Which, honestly, should have been caught during commissioning. But the company didn't have a commissioning checklist that covered PLC logic.)
The Cost of Ignoring the Real Problem
Let me put some numbers around this, because "training gap" sounds abstract until you see the price tag.
The aviation call cost the facility a $4,000 emergency service fee. That's the visible cost. The invisible cost was the week of degraded operation before anyone called—planes flying with batteries that had never completed a full charge cycle. In aviation, that's not a line-item expense. That's risk exposure that could end a company's reputation overnight.
The dump trailer fleet was spending about $1,200 per month on premature battery replacements. That's $14,400 per year at one location. They'd been living with the problem for five months before the real cause was found—roughly $72,000 in unnecessary costs, plus hours of mechanics chasing a "charging problem" that was really a logic problem.
I used to believe that a certification course was enough to get someone productive on a PLC. I stopped believing that after the dump trailer case. The technician who wrote that code had passed his two-day training with good marks. The certificate proved he could follow instructions. It didn't prove he understood how the system could break.
And here's the pattern that keeps me busy: when a PLC-controlled system fails, the customer blames the brand, not the code. The charger manufacturer was ready to replace the dump trailer unit under warranty before the program was even examined. The aviation supervisor was already researching alternative controllers when I showed him the program modification history. The equipment was fine. The training budget was the failure point. A two-day course that cost around $2,000 ended up causing tens of thousands in direct costs, plus damaged confidence and a near-miss safety event.
The quality of your code becomes the quality of your brand. When your product runs well, people say your equipment is solid. When it fails, they don't say "the programmer made an error." They say "this brand isn't reliable." Protecting your brand means investing in the people who write the logic that runs your products.
What Actually Fixes It
The fix isn't a better PLC. The hardware is rarely the issue. The fix is changing how you approach Allen-Bradley PLC training and program management.
If you're learning how to program Allen-Bradley PLCs—or if you're responsible for someone who is—structure the learning around system behavior, not just instruction syntax. Training should cover scan cycles. It should cover retentive vs. non-retentive memory. It should cover state machine design, power-loss behavior, and failure mode analysis. Knowing how to drop an ONS instruction onto a rung is not the same as knowing when—and when not—to use one.
If you manage a maintenance team, implement code review for every modification to a running system. A 15-minute review by an experienced programmer can catch a 45-second timer preset before it becomes a 3 PM emergency call. It feels like overhead right up until it saves you from a $4,000 service fee and a missed flight.
Build a staged commissioning checklist. Every program change should be exercised through its full operating envelope—power dips, timer expirations, fault conditions—before production trusts it.
One caveat: my advice comes from my context—mid-market industrial and commercial facilities without huge in-house engineering teams. If you're in a fully regulated utility with dedicated control engineers and formal change management, your world is different. The principle still holds; you probably already have the review gates I'm describing. (If you do, you're ahead of most facilities I visit.)
And even after we pushed the corrected program to that Micro870, I kept second-guessing. What if there was an intermittent scaling issue I'd missed? What if the HMI was writing to the same tags? I didn't fully relax until the charger held the full 45-minute absorption phase, the current locked at 90 amps the entire time, and the battery was certified at 4 AM.
The supervisor asked what they should do differently going forward. I told him: don't let a $2,000 training decision put a $4,000 emergency fee back on your desk next quarter. And don't let a well-meaning electrician edit production code without a second set of eyes.
He didn't argue. The next week, his electrician was enrolled in an advanced Allen-Bradley PLC course—not the two-day version. The kind that actually goes deep enough to prevent the next 3 PM call.
