A camera that enumerates in your driver's device list, opens without complaint and still delivers nothing is usually not a broken camera. The grab call is waiting on a session another application already holds, and it gives up at the timeout with the image still blank. This page is for engineers bringing up a camera under a machine-vision SDK or reviving a live-view station that went dark between shifts. You will identify the holder, free the session, prove the stream with a standalone grab, and set the host up so it stays free.
The single-session rule: why a detected camera can still be silent
Detection and acquisition are different layers. Enumerating a camera only proves the link, power and driver are alive; it says nothing about who owns the stream. GigE Vision, USB3 Vision and GenICam-based drivers hand each camera to one acquiring session at a time, and most desktop stacks enforce the same rule for USB Video Class (UVC) webcams.
When a second application opens the device, the open often succeeds anyway, and the fetch then waits for frames the driver never routes to it. Every grab burns the full timeout and returns nothing, so the image stays blank and the failure surfaces as a timeout rather than an access error. That signature — opens fine, times out forever — is why the lock hides: your code looks innocent.
Check this first because it costs ten seconds. The most common ending for a detected-but-blank case is a camera that was fine all along, with the driver's test panel quietly holding it.
Likely causes, in order of probability
Work down this table and stop at the first row whose signature matches your station. The first row clears in seconds and accounts for most blank-feed cases; the middle rows live in your own settings; the last two are hardware and driver-layer faults.
| What you see | Likely cause | Test | Fix |
|---|---|---|---|
| Device opens, every fetch times out | Another app holds the session | Close test panels, viewers and video-call tabs; grab from one clean tool | Quit the holder; keep one owner per camera |
| Snap works in the test tool, your app times out | Wrong acquisition settings in your code | Compare pixel format, exposure and gain against the tool's values | Match the format; set exposure and gain |
| Frames arrive at the configured rate, image black | Cap on, exposure far too short, light off | Histogram: a capped lens reads a flat line at zero | Remove the cap; raise exposure; check the light |
| Camera listed in one app, missing in another | Driver-layer conflict, media framework vs GenTL | Enumerate in both stacks and compare lists | Load the matching driver layer |
| Camera absent everywhere, even after swaps | Power or link fault | Swap cable and host port | Follow the USB link checks |
The branch links for the last two rows are at the end of this page, with the other faults a blank feed can imitate.
Run the grab test outside your own code first
Your own application cannot tell you whose fault it is while it is the only app running. Isolate with a grab test that shares no code with it.
- Close every application that can open a camera: the driver's test panel, any viewer, browser tabs running video calls, recording tools, and yesterday's copy of your own executable. Minimized counts as open.
- Start one clean grab tool — the test utility that ships with the camera driver, or the operating system's camera app for a USB webcam.
- Take a single-frame snap. An image appears: the device, driver and settings path are fine, and the fault lives in your session or configuration — go to step 5.
- The snap times out here too: a holder survived step 1, or the fault sits below the session layer. Restart the host to clear every held session and snap again. Still nothing after a clean restart? Work through the capture pipeline startup failure checklist before blaming hardware.
- With the snap working, run your own application, everything else still closed. It streams now: the holder was the cause, and step 1's list tells you which one.
- It still times out with nothing else open: compare your pixel format and exposure settings against the tool's, and make your grab loop stop on the first error so you read the failure at frame one instead of at shutdown.
Worked example: timing the fault on a 30 fps USB3 camera with a 1000 ms timeout
The LS-CMR-0166 streams 4000 × 3000 at 30 fps over USB3, which makes it a convenient reference for this test.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
Any 30 fps machine-vision camera behaves the same way, so the numbers below transfer directly.
Inputs
Frame rate: 30 fps, the camera's documented full-frame rate. Fetch timeout: 1000 ms, an illustrative input you set in your own grab call — the arithmetic scales with any value you choose. The question: how fast should the live view refresh when healthy, and what cadence gives the lock away?
Rule
A live view cannot refresh faster than frames arrive. Divide 1000 ms by the frame rate for the frame period. When no frames arrive, every grab consumes the whole timeout, so the refresh cadence equals one update per timeout period.
Result and decision
A healthy station refreshes about 30 times a second. A station whose camera is held by another application refreshes once per second — a 30× slowdown with a metronome-steady rhythm, because every grab dies at exactly the timeout. No exposure or bandwidth fault produces that cadence: short exposure gives fast, dark frames; short bandwidth gives partial or dropped ones.
Decide from the cadence. Near one refresh per timeout period means no frames are arriving, so go find the holder. Full-rate refresh with black pixels means the session is fine — switch to the exposure branch. Use a tenth of the configured rate as the line: under about 3 refreshes/s at 30 fps, treat the stream as dead.
Free the camera and confirm the stream
Close holders in the order that usually catches them: test panels first, then viewers and video-call tabs, then anything in the process list that belongs to a camera tool. Most desktop operating systems show a camera-in-use indicator while any app holds the device — use it to confirm the release before you retry.
Two holders catch teams out. Your own previous run can keep the session if it crashed mid-acquire; end the process, not just the window. And a background preview from an HMI or recording service holds the stream indefinitely.
If the camera stays locked after every application is closed, restart the host. A reboot clears every software holder, which is why it is the isolation step, not the fix.
Confirm the fix with a counter, not an eyeball: with the 30 fps example, watch the frame counter climb 30 in one second. A counter that climbs at the configured rate proves the session is yours and delivering.
Stop it recurring on a production host
Three habits keep the lock from coming back. First, one owner per camera: the station's acquisition process is the only thing that opens the device, and test panels stay closed while production code runs. Second, fail fast: wire the grab error into the loop's stop condition so the first timeout ends the run with its message visible, instead of queuing silent failures until shutdown. Third, watch the rate: log frames per second and alert below half the configured rate for 5 s — an example policy, tuned per station.
Multi-camera hosts make one-owner-per-camera natural by giving each camera its own network port, which also isolates bandwidth and lets you restart one camera without the rest. Browse the vision controllers category for hosts built around multiple camera ports. The MV-VC3301H-128G66 provides 5+ LAN ports, 8 GB of memory and an Intel Core i3 processor.
- LAN ports
- 5+ LAN ports
- USB 3 ports
- 3-4 USB 3 ports
- Light outputs
- 4 built-in channels
- Memory
- 8 GB
One port per camera also means a hung device never stalls its neighbors, and a single acquisition process can be restarted without touching the rest of the cell.
When the lock is not the cause
A held session explains one signature only: the device opens and no frames arrive. Map everything else to its own branch.
- Camera missing from every application: power, cable or host port first — the USB link checks after a cable swap.
- Frames at the configured rate but black pixels: cap, exposure or lighting — the stage-by-stage blank-image probe.
- Listed in one application, absent from another: driver layer — camera listed in one app but not another: DirectShow vs GenTL.
- A timeout that follows one camera and not its identical twin: link hardware — the FFC cable swap test.
The rest of the systems guides work through those lower layers in the same order: prove the layer above before you blame the one below.
Two-minute isolation checklist
- Quit every camera-capable application, minimized test panels included — a minimized holder behaves like a closed one.
- Snap once from a clean grab tool — one image separates device faults from your code.
- Read the refresh cadence — one refresh per timeout means no frames; full-rate black frames mean the exposure branch.
- End processes, not windows — a crashed acquisition keeps its session until the process dies.
- Take the station out of automatic before any host restart — PLC handshakes do not survive a surprise.
- Log frames per second against the configured rate — a stream that quietly degrades, or gets re-held, shows up in the log before an operator notices.
If the camera passes every test and your code still gets timeouts, bring the grab tool's settings and the timeout signature to the contact page and we will work the session and driver layers with you. If the camera itself is the problem, size a replacement in the area scan cameras category with the camera finder — free expert support comes with every order.
Questions
Can two applications share one machine-vision camera at the same time?
No. GigE Vision and USB3 Vision drivers give the acquisition to a single session, so the second opener either errors or receives no frames, which shows up as fetch timeouts in whichever application opened last. If two processes genuinely need the same images, one acquires and the other subscribes to its output, or each process gets its own camera.
Why does the timeout error only appear when I press Stop?
Your grab loop keeps calling fetch, and each call fails after the timeout, but the loop keeps running unless the code reacts to errors. The failures stay queued until the loop unwinds at shutdown, so you read them all at once, minutes later. Wire the grab error into the loop's stop condition and the first failed fetch ends the run with its message visible.
What fetch timeout should I use while diagnosing a blank feed?
Start from three to five frame periods. At 30 fps one frame lasts 33.3 ms, so 150 ms proves a healthy camera fast; use 1000 ms on first bring-up so slow exposure changes or network hiccups do not cause false failures. A working stream returns frames well inside any of these; if every grab consumes the whole timeout, frames are not arriving at all.
Frames are arriving but the image is black — is that still a session lock?
No. A lock stops frames entirely, so you see timeouts, not black frames. If your frame counter climbs at the configured rate, the session is yours and the fault sits downstream: lens cap still on, exposure far too short for the lighting, gain at minimum, or a pixel-format mismatch. Check the cap and exposure first — a capped lens reads a flat histogram line at zero.
Does a minimized viewer still hold the camera?
Yes. Test panels, viewers and video-call tabs hold the acquisition while the process exists, not while the window is visible. Minimizing releases nothing, and closing the image view inside some tools releases nothing either — the process has to exit. Quit the application outright, or end its process, before your own code opens the device.