My opinion, up front: in industrial controls, the twenty minutes you spend verifying the boring stuff before a panel ships will save you more money this year than any diagnostic tool you buy.
I am the quality and compliance manager at a systems integration shop. I review every panel build and every program handover before it reaches a customer — roughly 70 projects last year, everything from a two-door conveyor retrofit to a full Omron Sysmac cell running nine servo axes. About one in three first submissions gets rejected at my desk. Almost none of those rejections are for bad engineering. They are for checks that nobody thought was their job.
That ratio used to embarrass me. Now I treat it as the most useful number in the building.
The Filter Mat That Cost Us $2,400
In March 2023 we commissioned a packaging line in a plant with a corrugated roof and no real ventilation. Ambient hit 40°C by mid-July. The line tripped on drive over-temperature twice a day for three weeks. Everyone blamed the program, because the program is the thing you can see. We sent a programmer out twice, rewrote a ramp, stretched a fault delay, and burned somewhere around $2,400 in travel and lost production. Maybe $2,200, but don't quote me on the exact figure.
The cause was the enclosure fan filter. The mat had not been changed since installation — eighteen months of cardboard dust. That was the whole fault. Nobody had cleaned an air filter because nobody's name was on that line of the maintenance log.
That month changed how I think about verification. I stopped asking whether the equipment works and started asking who is supposed to confirm each individual thing, and when. If the answer is a shrug, that item is a future service call with your name on it.
Most Rejections Are Documentation Failures, Not Logic Failures
Here is the pattern I see over and over. The programmer writes something perfectly serviceable, then drops it into a context the original author never intended, and nobody opens the manual to check the operands.
A good example is SPED(885), the set-pulse-output instruction on the Omron CS/CJ platform. It is genuinely simple: you give it a port, a mode, a target frequency. What catches people is the mode operand. If you copy a snippet from an older project where the pulse output was configured for independent mode and drop it into a project wired for continuous mode, the instruction compiles. It runs. The axis just moves at the wrong rate, and if your feed tolerance is loose enough, nobody notices for weeks.
If you have ever pulled up the Omron PLC SPED(885) entry in the instruction manual, you know it spells out the operand combinations in a table nobody reads past the first row. We had exactly that failure on a feed conveyor. Three weeks of a slightly wrong index, and it only surfaced because a downstream photo-eye started double-counting. The manual was on the shared drive the entire time. Somebody had it open. Nobody had compared the operands against the actual wiring schedule.
The instruction manual is not a reference document. It is a checklist you read with a pen in your hand.
That is the change I made. Every handover now includes a written, line-by-line justification for any motion or pulse instruction, with the relevant manual section pasted next to it. It adds maybe fifteen minutes per axis. It has caught four scaling errors in two years, and two of those would have shipped.
Why the Smarter the Software, the Sloppier the Handover
This one is counterintuitive, and I argued against it for a while.
When we moved a chunk of our work onto the Omron Sysmac PLC platform — NX and NJ controllers, Sysmac Studio, the whole integrated environment — programming got dramatically easier. Configuration that used to be three pages of parameter settings became a dialog box with a dropdown. I assumed that would drag our rejection rate down. It did not move for about a year, and then it got slightly worse.
The reason is that friction used to be a filter. When you had to look up a parameter, you read the paragraph around it. When a dropdown does it for you, you click and move on. Ease does not eliminate the gap between the machine and the documentation. It just makes the gap quieter.
The specific thing that catches us now is version discipline — the firmware revision on the controller versus the revision of the project file, and whether the backup sitting on the customer's server is genuinely the one that matches what is running. I want to say we rejected eleven handovers in 2024 for that alone, out of roughly sixty-eight, but I would have to pull the log to be sure. The point holds either way, and nothing in that category is a programming-skill problem.
The Equipment Nobody Owns
Then there is the gear that sits at the edge of the controls scope. It never appears in a commissioning plan because no engineer considers it theirs, and it fails on a schedule you would not believe.
Take the Rain Bird sprinkler control panel in the landscaped strip behind our own building. It shares an electrical room with a small pump starter. When a power blip wipes the schedule, the controller comes back up on its default program and waters at 2 p.m. in August. Nobody notices until the turf is scorched, and then the electrician gets the call because the box is in the electrical room. The actual fix takes twenty minutes at seasonal start-up: verify the zone wiring, confirm the rain sensor is not bypassed, and re-check the schedule after every outage.
Same story with a 10 circuit manual transfer switch. It is a mechanical device with contactors and lugs that sit perfectly still for 364 days. The failure mode is not dramatic — it is a lug that was never torqued, or a mechanism that will not throw because it has not moved since the last test. An annual transfer under load takes under an hour and it is the only way to actually know. NFPA 70B treats a documented maintenance program for electrical equipment as the baseline expectation rather than an optional extra, and a transfer test sits squarely inside that scope.
And then, back to the filter. If you want the short answer to how to clean an air filter on a control cabinet: pull the mat, vacuum it from the clean side so you are not pushing dust into the media, replace it if it is loaded or torn, and write the date on the inside of the frame in marker. Twenty seconds. That single habit would have paid for itself in July 2023.
The version of the check I actually run is short:
- Filter mat condition, plus a date written on the frame
- Firmware revision on every controller versus the project file
- Printed as-built drawings in the panel pocket, plus one digital copy
- Annual transfer test result logged for any backup power
- One named person for every seasonal or annual item
Five lines. It has paid for itself several times over, and I keep adding to it whenever something new bites us.
Yes, I Know It Slows You Down
The pushback I get is always some version of three arguments.
We do not have time for another checklist. A service truck roll on our contracts runs $600 to $900 before you count downtime at the customer's site, which on a packaging line is usually four figures an hour. Against those numbers the checklist is a no-brainer. Honestly, if a check takes longer than twenty minutes I cut it or automate it, because a check people skip is worth nothing.
The vendor is responsible for that. This is where communication failures live. I said as-built drawings. They heard the drawings we used to build the panel. Result: a maintenance technician spent two days tracing a conductor that had been rerouted during commissioning and never redrawn. Both parties were acting in good faith. Nobody's contract contained the words verify that the document matches reality, so nobody did.
This is overkill for small jobs. It is the opposite, and I will say that plainly. On a small job the check is ten minutes and the failure still costs somebody a full day. The math gets better, not worse. The only jobs where I have regretted a check are the ones where I decided the job was too small to bother with.
Five minutes of verification beats five days of correction. I have never once watched that trade go the other way, and I have been on the wrong side of it often enough to stop pretending otherwise. If a red flag shows up during a handover review, it is almost never a red flag about the engineering. It is a red flag about ownership.
So here is where I land, and I will keep landing here until something proves me wrong: treat every unanswered question about your equipment as an invoice you have not received yet. Somebody is going to pay it. The only thing you get to choose is whether it is paid in twenty minutes at your desk or across three weeks of somebody's summer.
Function codes, firmware behavior, and configuration defaults vary between platform generations — confirm current details against Omron's published instruction references at omron.com before writing them into a procedure. Maintenance intervals for electrical equipment should follow NFPA 70B and your local authority having jurisdiction. Cost figures above are from our own project records and are not a quotation.
