I Rejected 31% of First Deliveries in 2024. Almost None Failed Because of the PLC.

I rejected 31% of the panel packages and product datasheets that crossed my desk in 2024. Almost none of them failed because of the PLC.

That's not a popular thing to say at a trade show. Everyone's reading Omron PLC news about new NJ SKUs and EtherCAT cycle times, and honestly, I get it — the hardware is genuinely good. But I've been doing quality and brand compliance review for four years now, roughly 200 deliverables a year, and the controller is the most reliable part of almost every system I look at. The failures happen in the layer around it.

I should flag that I'm not 100% sure our 31% generalizes to other companies — we hold a fairly tight spec, and a shop with looser standards would probably report a lower number and mean something different by it. But the pattern holds. Here's what I actually find in the rejections.

The controller is the part that already works

Take the Omron NJ Series PLC. It's an IEC 61131-3 machine automation controller running EtherCAT, and Omron publishes sub-millisecond motion cycle times for the NJ501 line — check the current datasheet before you quote me on that, they've revised SKUs more than once since 2022. My point isn't the spec itself. My point is that a published spec is verifiable. You can write a test against it. You can fail it. Nobody argues about what "500 µs" means.

The things that actually get rejected don't have that property. A wall control panel is specified as NEMA 12 on the drawing, the shop builds it off a cut sheet that's two revisions stale, and nobody catches it — because "enclosure" isn't a line item on the incoming inspection script. It's on page 41 of a PDF that three people have open and none of them have read in full.

Same story with ancillary equipment. Everyone in this industry can explain what a PLC does. Ask the same room "what is a fuel pump supposed to do on this skid?" and you get hand-waving — it's a lift pump pulling from the tank, or a high-pressure pump on the engine side, and which one you're actually specifying changes the whole control philosophy. I sat in a review where an engineer had written "fuel pump: standard" on a Lister diesel generator package. That's not a specification. That's a placeholder that got quoted.

We dodged a bullet there, honestly. It surfaced in our internal FAT script about a week before the customer's. Had it gone out, the generator wouldn't have picked up load cleanly on transfer test, and we'd have been booking a site visit plus a rework in the $22,000 range — that's my estimate off the last one, not a quoted invoice.

"Paper is safer" was true, once

The instinct I keep running into is that a printed checklist is more trustworthy because you can hold it, initial it, and file it. That was true 15 years ago, when digital QA tools were thin and mostly meant a scanned PDF of the same paper form. Today the gap has largely closed, and in a few places it's inverted — a paper form can't flag that the tolerance on line 12 contradicts the tolerance on line 30. A structured form can, and it tells you before the enclosure gets cut.

I went back and forth on this for about a month in 2022, while I was rebuilding our verification protocol. Paper had one real advantage: inspectors trust what they can see, and a binder doesn't have a login screen. Digital had the obvious advantages — searchable, versioned, and I could hand an auditor a complete trail in ten minutes instead of a day. I went digital, mostly because the audit trail was what had actually cost us money, not the inspection step itself.

To be clear, I'm not saying the old way was stupid. Anyone who tells you paper-based QA was just laziness hasn't done a site walk with a clipboard in a panel room at 40°C.

The one place I'll still defend the paper habit is safety validation. When you're working against ISO 13849-1 and need to establish a performance level, a printed, signed validation record that a customer's engineer physically stamped is worth more than a checkbox in a web app. We keep both. That's not elegant, but it's what the customer asked for.

Here's the part people get backwards

People assume thorough documentation slows a project down. In my experience the causation runs the other way — teams that document well ship faster, because they stop re-deciding things. When the spec is unambiguous, the shop floor doesn't call you on Friday afternoon to ask which terminal block they should use across a full run of panels.

We moved first-article review from a nine-day average to roughly three after the digital protocol went live. Same people, same products, and no more effort per item — just fewer round trips and less rework. Errors that used to slip through, like a wall control panel rated for the wrong environment, now get caught before the enclosure is even ordered.

That's the whole efficiency argument, and it's boring and it's correct: fewer manual handoffs means fewer places for something to quietly go wrong. It isn't about going fast for its own sake. The teams that treat speed as the goal and skip the spec work end up slower, because they're doing the job twice.

Where the traditional approach still wins

I'll push back on my own argument here, because there are cases where a standardized digital checklist actively hurts you. One-off, heavily customized panels — say a single skid for a plant that has to match an existing 1990s control scheme — don't fit a template. Half the value in that job is a senior engineer standing in front of the panel saying "that's not right," and you cannot script that instinct.

Same for incoming inspection on a new distributor. Our first three orders from any new supplier get eyeballed by a person, not a form. We had a batch of enclosure hardware show up with plating that didn't match the sample we approved, and no checklist in the world would have caught it — it looked fine in the photos.

What I'd actually tell you to check

If you're specifying a control package right now, my advice is short and unglamorous. Write down the things the datasheet doesn't cover — the environment rating on the wall control panel, the pump control philosophy on your backup generator, the firmware revision you're actually going to ship — and then put those items into the inspection script. Not the appendix. The script.

And on the documentation side, this is where brand compliance and quality stop being two separate jobs: every claim needs to be verifiable. Per FTC guidance (ftc.gov), advertising claims have to be substantiated with evidence, and "industry standard" is not evidence. I've kicked back more copy for that phrase than for anything else I can think of.

If you can't point at the document that proves it, it's a marketing claim, not a specification.

So no — the Omron PLC news cycle isn't what's going to make or break your next project. The controller will do what the datasheet says it does. Your job, and mine, is everything around it.