False Rejects at 2 a.m.: When a Cognex Vision System Is the Victim, Not the Problem

At 11:47 on a Tuesday night, I got the call that ended my sleep. A packaging plant had a Cognex vision system that was throwing false rejects. The shift lead had already cleaned the lens, restored the saved job, and swapped in a camera from another line. The result was the same. A truck was due to load at 6 a.m., and the line had been down for more than two hours.

I do emergency automation service for a living. I have been on maybe 200 of those calls, maybe 180 if I count only the ones where getting on-site actually changed the answer, and the pattern is too consistent to ignore: the part that gets named in the phone call is rarely the first part that failed.

The Surface Problem: The Vision System Is Down

It is easy to understand why people start with the component name. The operator sees a false reject. The screen says vision fail. The maintenance supervisor asks whether the camera is dirty, the lighting is wrong, or the job file is corrupted. In some cases, that is the real failure. But in my experience, a bigger portion of emergency machine vision trouble is caused by something upstream of the camera.

The Cognex system was not rejecting good parts because it forgot how to inspect them. The Cognex system was making decisions based on images that were never clean in the first place. Put another way: it was doing exactly what it was designed to do with the information it received.

The part you replace is rarely the first part that failed. It is usually just the part you can name fastest.

A Vision System Is Only as Trustworthy as Its Trigger Signal

On high-speed lines, Cognex vision systems often do not free-run. They wait for a trigger. That trigger frequently comes from an encoder. The encoder tells the camera when the product is in front of the lens. If the encoder sends clean pulses, the camera fires at the right moment and the image looks sharp. If the encoder signal has noise, missing edges, or jitter, the camera can fire too early, too late, or at a product that is not fully in view.

I remember one line where the false reject rate jumped from almost nothing to around 4 percent. Images looked fine when the line was stopped. The sensor was detecting product. The lighting was stable. The lens was clean. The trigger signal told a different story.

When I put a scope on the encoder A channel, the square wave looked rough. The signal was not a clean digital pulse. It had timing jitter that made the camera capture inconsistent frames. The original problem was mechanical, not optical: the encoder coupling had loosened slightly, so the encoder shaft wobbled as it turned.

The team had already replaced the encoder once before I arrived. That was the logical thing to do because the fault log showed lost counts. The replacement encoder still had the same problem because the coupling still wobbled. My gut said to stop replacing electronic parts and check the mechanics, and that is what finally led to the real fix.

The Flow Sensor SI5000 Was Telling the Truth

The same thing happens in areas that have nothing directly to do with vision. At a food plant, a cleaning circuit kept stopping because of a low flow alarm. The model on the tag was a flow sensor SI5000, if I remember correctly. The maintenance team ordered a replacement SI5000 with overnight shipping and paid extra for the speed.

The new sensor arrived, got installed, and produced the same low flow alarm. That was the clue nobody wanted to hear. The original sensor was not lying. The flow really was low. A manual isolation valve in the line had been left nearly closed, and the pump could not push enough liquid through the circuit.

That story is not really about a sensor. It is about the difference between replacing a part and proving a hypothesis. The overnight freight cost was small compared to the lost production time, but it was wasted because the diagnosis started with the name on the component tag instead of the process behind it.

Sometimes the Hidden Problem Is Electrical, Not Optical

There is another failure mode that causes all kinds of sensor madness: insulation breakdown on motors fed by variable frequency drives. A motor can develop a small leakage path to ground that does not trip a breaker and does not show up on a normal multimeter check. The leakage current hunts for a return path, and it often finds one through cable shields, sensor grounds, or communication lines.

I worked on a line where a Cognex vision system would lose Ethernet communication every time the conveyor ramped up to high speed. The network switch did not look bad. The cables tested fine. The camera was responsive when the motor was stopped. But every time the VFD increased speed, the fault came back.

The motor insulation was breaking down. It was not a hard short. It was a leak that only became significant when high voltage and high speed stressed the winding. A regular digital multimeter could not catch it because the insulation still measured fine at low voltage. The insulation resistance test caught it.

How to Use a Megger Insulation Tester in These Situations

If you have never been shown how to use a megger insulation tester, it is simpler than the name sounds, but it is not something to learn while you are in a hurry. The short version of the procedure goes like this:

• Disconnect the motor leads from the drive and lock out / tag out the circuit.
• Wait for the drive DC bus to discharge, then verify that it is safe with a voltmeter.
• Set the megger insulation tester to a suitable DC test voltage. For a typical 460 V motor, that is usually 500 V or 1,000 V, depending on the manufacturer guidance.
• Connect the test leads from the motor winding group to motor ground.
• Apply the test voltage for about 60 seconds and watch the reading.

One caution: do not use a high-voltage megger on a VFD output unless the drive manufacturer explicitly allows it. The test can damage the drive. Isolate the motor and cable first, and test them separately.

The exact number matters less than the trend. A motor that used to read 100 megohms and now reads 0.8 megohms is telling you something important, even if it has not tripped a breaker yet. That kind of leakage is enough to inject noise into nearby sensor circuits.

Deadlines Make Certainty More Important Than Speed

I have mixed feelings about rush fees. On one hand, paying extra for freight feels wasteful when the diagnosis is wrong. On the other hand, when a line is down and the truck is waiting, the goal is not to save money on shipping. The goal is to remove uncertainty.

This is why I now ask a different question when I triage an emergency. I do not ask which part can arrive fastest. I ask what we can verify before the deadline. A part that arrives at 5 a.m. but does not fix the problem is not fast; it is just another delay.

A wrong diagnosis with expedited freight is more expensive than taking twenty extra minutes to check the signal path first. The expensive version of on time is the one that still fails after the part is installed.

The Last Twenty Percent: A Better Emergency Workflow

When a machine vision system looks like the problem, I now go through the same rough sequence before changing anything expensive:

1. Look at the actual image while the machine is running. Is it sharp? Is the product in the same position every time?
2. Check the trigger source. If the line uses an encoder, inspect the signal path and the mechanical condition of the encoder mount.
3. Check what else changed. Flow, pressure, temperature, motor current, and process setpoints usually tell the real story.
4. Check for electrical interference and insulation problems, especially when the fault is intermittent and tied to motor speed.
5. Only then search for replacement parts and software updates.

When I do need to verify software or firmware, I go straight to the Cognex official website. It is tempting to trust the first search result on a phone at 2 a.m., but the wrong version can make a healthy camera look broken. I also keep a Cognex app for quick code checks on my phone. It does not replace a fixed industrial reader, but it helps answer the basic question of whether a label is physically readable before you start blaming the reader.

The packaging plant call ended in an anticlimax. The final fix was not a new camera or a new vision algorithm. It was an encoder coupling and a few minutes of careful alignment. The line was running again by 4:50 a.m.

I charged more for that hour than the part cost. I do not apologize for that. The customer was not paying for the coupling. They were paying for a verified answer before a hard deadline. That is what certainty costs, and in emergency industrial automation, certainty is the only thing that matters.