In the procurement seat, you learn to count everything. I manage a machine-vision and automation budget of roughly $200,000 a year for a 40-person integrator. I've negotiated with 30+ vendors, tracked every invoice for six years, and audited $180,000 in cumulative spending. So when I say the most expensive part of our last Cognex vision sensor project was not the vision sensor, I mean it in the bookkeeping sense: it was the gap between the quote and the reality.
In Q2 2024, we quoted a Cognex vision sensor for a new inspection lane. The hardware came in $4,200 below another integrator's proposal. I signed it. By the time the lane ran reliably, the project was $31,000 over the original estimate. The sensor was fine. The assumptions around it were not.
The Surface Problem: The Quote Looked Good
Maybe you've watched this scene: a salesperson shares a line-item quote, the price for camera, lens, light, and controller looks reasonable, you compare it to a second quote, choose the lower one, and create a purchase order. That is the way we used to do it. It is also the way we created that overrun.
Here's the thing: a vision sensor is a sensor. It sees what you put in front of it. The expensive part is the putting in front of it. That's where the line between quote and reality starts to blur.
Deeper Cause #1: We Bought a Part, Not a System
The datasheet for a Cognex vision sensor tells you resolution, frame rate, working distance, and communication options. It does not tell you whether your parts will arrive at the trigger point at the same angle, speed, and lighting every cycle. Those variables live outside the sensor, but they decide whether the sensor works.
We had a classic mismatch: our test stand used a fixed encoder on the conveyor. The line speed changed during production, but the encoder pulses per revolution did not. The sensor got a trigger signal, sure. It also got blurry images on faster runs and skipped part checks on slower ones. We spent three weeks trying to tune the sensor before someone asked a very basic question: 'Is the encoder signal actually proportional to part speed right now?' It was not.
We replaced the fixed unit with a programmable encoder. The advantage is not rocket science. You can change output pulses per revolution on the bench instead of buying a different gear ratio or adding a gearbox. For a test stand that has to simulate different line speeds, that flexibility is worth the extra $400. But we discovered this after the fact, and discovering after the fact has a price.
These are the details that don't appear on a purchase order. No line item says 'assumption risk.' But every time we skipped a compatibility check, the cost showed up somewhere else: in a late-night phone call, a rushed flight to a customer site, or a rework order we couldn't bill. The sensor's price was fixed. The system's price was open.
Deeper Cause #2: We Trusted 'Same Specs' From Memory
I assumed the encoder's output type was compatible with the sensor's input because both vendors used the word 'encoder.' I didn't verify it. Turned out one side was push-pull and the other was open-collector. They worked on a multimeter. They did not work at speed.
That sentence, 'they worked on a multimeter,' explains a lot about maintenance carts, too. It's the same reason the question 'megger vs multimeter' keeps coming up. A multimeter measures continuity and resistance at low voltage. A megger measures insulation resistance at high voltage. They look like similar tools, and sometimes both read 'open' or 'closed,' but they answer completely different questions. A multimeter can tell you a cable is connected. It cannot tell you whether that cable's insulation will hold up on a hot, vibrating machine. We learned that the hard way when a pinched cable jacket caused intermittent sensor flicker for two weeks. I knew we should run a megger test before going live. I told myself a continuity check was probably enough. That was the one time it mattered.
Now we keep a Fluke 62 MAX+ infrared thermometer on the commissioning cart, too. A quick thermal scan catches hot terminations, failing bearings, and enclosure heat buildup before it becomes a drift problem. The sensor may be the brain, but the rest of the machine is the nervous system. You cannot diagnose the nervous system with one tool.
People ask why we need a separate insulation tester when a multimeter already measures resistance. Same reason we don't use a pocket knife to torque a flange: different tool, different job. A megger applies a higher voltage and reveals leakage currents that a multimeter cannot see. We found a cable that measured fine on the bench and failed on a machine with a 60-foot run next to a variable-frequency drive. The failure was insulation breakdown, not continuity.
The Cost of Not Solving It
Let's put numbers on it. The $4,200 quote difference looked like a win. The final overrun came from these line items in our cost tracking system:
- Three extra site visits to chase an intermittent trigger: $4,800
- Re-engineering the encoder interface and adding a programmable unit: $11,000
- Replacing a damaged cable and adding protective routing: $3,900
- Engineering time for retesting and documentation: $7,400
- Miscellaneous small items that added up: the rest
The $4,200 savings turned into a $31,000 cost. When I audited the project in our cost tracking system, 61% of the overrun came from interface mismatches, not from sensor quality. The sensor was never the problem. The system around it was.
One more detail: in another project, a vendor offered 'free setup.' That covered one visit only. The second visit, the one that actually fixed the issue, was billed at $150 per hour plus travel. The 'free' setup ended up costing $450 more than a paid setup with the right application engineer the first time. I put that in my spreadsheet, and my spreadsheet remembers.
There's an uncomfortable pattern here. Most of our big budget misses weren't caused by a vendor being dishonest. They were caused by us not asking the right questions before signing. The most expensive question we never asked was: 'What changes when this line speed changes?'
What We Do Now (Short Version)
If you are in procurement or engineering, you don't need another hundred pages of theory. You need a checklist. Here's what changed for us.
1. Quote from the system, not from the part. Before we request a quote, we log into the Cognex portal and pull the exact specifications from the current model line. The portal helps us confirm part numbers, software versions, and accessories. It doesn't make the decision, but it kills the 'I think that model supports it' conversations that caused our interface mismatch.
2. Include the encoder in the first conversation. If there is any possibility of line speed changes, we quote a programmable encoder from the start. It is cheap compared to the engineering time spent later.
3. Test with tools that answer the right question. The commissioning cart now has a Fluke 62 MAX+ infrared thermometer, a megger, and a multimeter. We use all three because they reveal different failure modes. Speed, heat, and insulation breakdown are not interchangeable.
4. Treat '100%' as a red flag, not a promise. No one can guarantee 100% defect detection on an unvalidated line. Per FTC guidelines (ftc.gov), claims need to be truthful, not misleading, and substantiated. When a vendor uses '100%' to close a deal, that's marketing, not engineering.
5. Leave room for the system. Our procurement policy now requires quotes to include a system design review, not just the line items. It adds a little to the up-front number, but our post-install overruns dropped.
This worked for our context: a 40-person integrator with a machine shop and mostly small-batch inspection lines. If you are an OEM building hundreds of identical machines, your calculus is different. You may not need the same flexibility, and your TCO model should reflect that. Your mileage may vary, but please check your assumptions before they become budget lines.
Look, I'm not saying you should never take the lower quote. I'm saying the lower quote is only the first line of the story. The rest of the story is about encoders, cable jackets, and whether someone actually verified the specs before signing. That's where the real money goes.
Leave a technical question