Three things get an ABB PLC order flagged in my queue, and none of them is price. The software version tied to the hardware revision. The VFD specification sheet checked against the real duty cycle instead of the catalog headline. And the safety question nobody wants to answer at quote stage: is this unit OEM or private label, and who owns the liability when it trips?
Get those three right and you avoid most of what fails at goods-in inspection — in my experience, roughly three out of four rejections trace back to one of them.
I'm a quality and brand compliance manager at an industrial automation distributor. I review every submission before it reaches a customer — roughly 200 items a year, counting datasheets, sample units, private-label packaging drafts, and OEM proposals. In 2024 I sent back about 22% of first submissions. Almost none of those were bad parts. The paperwork didn't match the promise, and that's a different problem with a different fix.
Where this checklist came from
When I first started doing supplier reviews, I assumed a brand-name part number did the work for me. If the box said the right name, the specs were the specs. That assumption cost us a $9,400 rework in 2022 on a panel build where the drive frame we approved was rated for normal duty and the application was anything but.
In my first year, I made the classic specification error: I signed off on a batch of drives against the headline kW number without reading the current rating at the ambient temperature our customer actually had. Forty-one degrees in a compressor room. Everything looked fine on paper. It wasn't fine in the room.
We built a formal verification protocol after that. Every submission now carries an order code, a firmware revision, a software version, and an application duty class. It's not glamorous. It's the reason our rejections happen at the desk instead of on site.
ABB PLC software is a hardware question in disguise
People treat "ABB PLC software" as a procurement line item. It's actually a compatibility constraint that starts with the CPU.
For AC500-class controllers and the Automation Builder environment, the things I ask for — every time, no exceptions — are the exact CPU order code, the current firmware revision on the shipped unit, and the software version the customer's project was originally built in. Those three numbers decide whether a project archive opens cleanly or opens with warnings the engineer will discover at 11 p.m. before a Monday startup.
The failure mode I see most often isn't a missing license. It's a project saved in a newer software revision than the one on the commissioning laptop, or a library dependency that the original integrator never documented. Nobody notices until someone tries to modify a running line. Then it's an outage, not a ticket.
And then there's the language problem:
I said "ABB compatible." They heard "ABB equivalent." Those aren't the same sentence, and the gap between them showed up when a drop-in module didn't speak the same protocol handshake as the original.
If you're sourcing a private-label or third-party module into an ABB PLC system, "compatible" needs to be defined in writing — protocols, function blocks, diagnostic behavior, and what happens on a firmware update. I'd rather see a documented limitation than an unqualified claim. If you ask me, an honest "it does these six things, not the seventh" beats a spec sheet with no asterisks every single time.
VFD specifications: read past the kW number
VFD specs are usually the most abused sheet in the folder, because the headline rating is the least useful number on it. Two drives with the same kW figure can carry meaningfully different continuous current, and current is what your motor actually responds to.
Here's what I check, in order:
- Duty rating. Normal duty and heavy duty are different ratings of the same frame. Overload figures differ — typically something like 110% for 60 seconds versus 150% for 60 seconds. If your application starts under load, you want the heavy-duty column, not the one at the top of the page.
- Ambient derating. A rating quoted at 40 °C is rarely the rating at 50 °C. Panels get hot. Ask for the derating curve, not the ambient claim.
- EMC class. Under IEC 61800-3, category C2 and C3 aren't interchangeable, and whether the EMC filter is built in or supplied as a separate enclosure changes both your panel space and your cable length limits.
- Motor cable length. This is the line buyers skip most often, and it's the one that decides whether you need an output filter. On a long conveyor or a rooftop fan, that filter can cost more than the difference between two drive options.
- Harmonics. Above 16 A per phase, IEC 61000-3-12 becomes relevant, and a DC choke or active front end may stop being optional.
- STO claim level. Don't accept "has STO." Ask which SIL or PL the Safe Torque Off input is certified to, in which configuration, per the safety manual. The answer is almost never the same as the marketing line.
VFD private label: the question isn't quality
The "private label means cheap junk" thinking comes from the 1990s, when a private-label drive was usually a leftover with no documentation and no firmware path. That's changed. Some private-label VFDs today run on the same hardware platform as the branded version and differ in parameter defaults, labeling, and the support chain.
Which means the question isn't "is it good?" It's "what did you give up?" Four things, specifically:
- Who holds the firmware update path, and how long will it stay open?
- Who owns the warranty — the brand on the box, or the manufacturer behind it?
- Is the full parameter list documented in your language, or is it a partial list with "refer to OEM" in the middle?
- Is there a written spare-parts availability statement, or just a verbal one?
Private label is a legitimate choice. If your volume justifies it and you've locked down those four items in a contract, you've made a commercial decision, not a compromise. What I push back on is private label as a surprise — discovered after the order, not before it.
Safety PLC: OEM vs private label is a liability question
This is the one that keeps me up at night, because it gets framed as a sourcing debate when it's actually a documentation debate.
Under IEC 61508 and ISO 13849-1, a SIL or PL claim belongs to the complete safety function — sensor, logic, actuator, and architecture — not to a box. So the same certified hardware can legitimately be sold under two different names and the certificate still holds. What changes is the paper trail behind it.
With a safety PLC OEM arrangement, the brand on the unit is normally the certificate holder, and the support path is direct. With private label, the brand on the unit might be your distributor's — and the safety certificate still has to point back to a named, real, contactable entity that owns the safety manual, the proof-test interval, and the diagnostic coverage figures.
So when a private-label safety PLC crosses my desk, I want the original certificate reference, the declaration of conformity, the safety manual, and a written statement that the safety manual applies unchanged to this branded version. I also want a name and a support obligation attached to the firmware. If the vendor can't produce that in writing, I don't argue about it. I stop there. Not because the electronics are suspect, but because a safety function without a traceable owner is a liability with a part number.
Where this checklist doesn't apply
Being honest about the boundaries is the whole point of a checklist, so here's where I'd tell you to ignore mine.
If your plant is standardized on a single control platform, adding an ABB PLC to one machine because it was 8% cheaper on the quote is rarely worth it. You'll pay it back in training, spares, and the engineer who has to remember a second toolchain at 2 a.m. In my opinion, that's a decision that looks excellent in a spreadsheet and poor in a control room.
If the application is a standalone pump, fan, or small conveyor, a full safety PLC is over-spec. A safety relay at the right performance level is cheaper, simpler to validate, and easier to prove out at commissioning. Buying more safety architecture than your risk assessment calls for is a real cost with no matching benefit — and personally, I'd rather see a well-documented relay than a poorly documented PLC.
And if the support network for a given platform is thin in your region, no specification sheet fixes that. Service response time is a specification. Treat it like one.
None of this is really about which logo sits on the front of the panel. It's about whether the paperwork you file today can still answer a question in 2031 — from a maintenance tech, an auditor, or an insurance investigator. Build the file like someone else will have to read it. Odds are, they will.