Python depth camera not detected: troubleshoot host setup

A Python application that imports its depth-camera wrapper without error and then reports zero devices has a host, runtime or environment fault; the message names the layer that noticed, not the cause. This guide runs a four-test sequence that isolates the failing boundary without reinstalling packages or touching firmware: the operating system's device list, the vendor acquisition utility, the interpreter that actually runs your code, and a minimal capture script. Each test names its fix, and the USB and GigE Vision numbers here let you judge cables, ports and subnets on the spot — which is where the physical faults live.

Read the symptom before changing anything

Three different results get reported as "not detected", and each has its own fix. Separate them before touching software:

Save the whole traceback. The bottom exception carries the transport error, and a handler that collapses every failure into "no device" destroys that evidence before anyone reads it.

Test 1: the host device list — power, cable, port

Open the OS device list before connecting the camera, connect it, and compare. Three outcomes, three branches:

• Nothing appears. The fault sits below the driver. Windows code 0xA00F4244 ("no cameras attached") means the OS itself sees no imaging device, so fix power, cable and port before opening Python again. A charge-only USB cable carries the two USB 2.0 data pairs at 480 Mbit/s and silently downgrades a camera built for USB 3.2 Gen 1 at 5 Gbit/s; use a full data cable into a rear-panel port. Check the power budget as well: a USB 2.0 port delivers 500 mA at 5 V (2.5 W), a Gen 1 port 900 mA at 5 V (4.5 W). A projector-based camera rated beyond bus power browns out on the bench, and a brown-out presents as this exact symptom.

• An entry appears with a warning marker. Driver branch: install the vendor's driver package from the manufacturer or its distributors, then rescan.

• Expected entries appear. Move to Test 2.

When the host lists the camera but the runtime does not, work through USB camera not enumerating: diagnose the host path; on Linux, USB camera in lsusb but not detected by the vision SDK on Linux covers the device-permission rules behind it.

Network cameras: one subnet, one open port

GigE Vision discovery is a UDP broadcast to port 3956, the GigE Vision Control Protocol port, and the handshake that follows needs plain IP reachability. Put camera and interface card on one subnet — host 192.168.1.10, camera 192.168.1.50, mask 255.255.255.0 — and allow UDP 3956 through the host firewall. A camera that answers ping but will not discover is a blocked port; a camera that does neither is an addressing fault.

Test 2: the vendor utility sets the baseline

Close your application and every viewer first. Depth sensors grant exclusive ownership to one client, and a viewer left open is the cheapest fault on this list. Open the utility that shipped with the runtime and ask two questions: does it list the camera, and does it stream it?

If it cannot list the camera, Python cannot either — return to the Test 1 branch. If it lists and streams, record four facts: camera identity, firmware release, the exact profile (resolution, frame rate, pixel format) and the utility version. Your minimal script replays exactly that profile; inventing a different one adds a variable to a fault you have not found yet.

Update firmware only when the vendor's release notes name your symptom. A camera the utility streams has working firmware, and a flash changes nothing on the Python side. When the notes do call for a firmware and runtime alignment, follow 3D camera header version mismatch: fix firmware and SDK alignment and write down both releases before and after.

Test 3: prove which interpreter is running

An editor, a terminal, a notebook kernel and a scheduled service each launch their own interpreter, and only the one that prints the failure matters. Run this from the failing context — the notebook cell or the service's shell, not a fresh terminal:

import platform, struct, sys
print(sys.executable)
print(sys.version)
print(platform.machine())
print(struct.calcsize("P") * 8)

The last line prints 64 on a 64-bit interpreter, and 64-bit Python needs the 64-bit native runtime; the mismatch fails at import with a DLL load error, covered in Python wrapper ImportError DLL load failed: fix camera SDK bitness. List packages through that same interpreter with python -m pip list and confirm the wrapper sits in that environment's site-packages — a copy in the project folder shadows the installed one.

If the wrapper is a GenTL consumer, it finds camera producers through the GENICAM_GENTL64_PATH variable, which names the directory holding the producer library. Services do not inherit your shell, so set it system-wide:

GENICAM_GENTL64_PATH=/opt/runtime/gentl

Failures one step further along that chain are covered in troubleshoot a GenTL XML file path during camera setup, and the notebook case in camera not detected in notebook: compare Python environments.

Test 4: minimal enumeration and capture

Strip the program to acquisition only — no inference, no display, no file writes, no alignment — and run the vendor's smallest Python example in stages, so each failure names itself:

1. Import the wrapper; on error, report the raw message and stop.
2. Create the discovery context the runtime requires, nothing more.
3. Enumerate devices and print the count and identity fields.
4. Select the intended camera; a stored serial number must match the unit on the bench.
5. Open it with the profile recorded in Test 2.
6. Acquire one frame with a 5 s first-frame timeout, so a slow first frame is not read as a missing device, then check the returned status.
7. Release in reverse order: stop acquisition only if it started, then close the device.

A generic video app covers only the RGB interface — the USB Video Class standard defines the webcam path, while depth streams ride vendor-specific endpoints. An RGB preview with no depth in a generic app is the expected layout; UVC camera not detected by software: choose the right capture path sorts which capture path each interface needs.

Then sample discovery for stability: three enumeration passes spaced 2 s apart, after the runtime's initialization wait. Three of three closes the boundary; one of three points at an intermittent link or a second client holding the device.

A station that fails this way reads as follows: the host lists the camera, the vendor utility streams it, and the application's interpreter returns zero devices on all three passes — 0 of 3, a 0% discovery rate — while the same script in the deployment virtual environment returns 3 of 3, 100%. Same camera, cable and port; the interpreter was the fault. Re-point the service at the working environment and the empty-list report ends.

If enumeration works but the stream fails, the fault has moved up a layer: stereo camera works for RGB but no depth: fix missing mono sensors covers missing sensor entries, and no depth stream? your depth camera is in passive IR mode covers a projector that never fires.

The bandwidth arithmetic behind open-but-no-frames

When frames time out with the camera open, do the arithmetic before replacing hardware:

width and height are the profile's pixel counts, bytes_per_pixel is 2 for 16-bit depth, and fps is the frame rate; the result is megabytes per second, and multiplying by 8 gives megabits per second.

Worked example: 1280 x 720 x 2 x 30 = 55.3 MB/s, or 442 Mbit/s. USB 2.0 high-speed signals at 480 Mbit/s but sustains roughly 35-40 MB/s of bulk traffic after protocol overhead, and 55.3 does not fit inside that. USB 3.2 Gen 1 at 5 Gbit/s carries the stream with headroom. The decision follows directly: frame timeouts on a captive USB 2.0 cable or a front-panel port are a link fix, not a reinstall.

Bring the application back without burying the error

Add stages back one at a time — the second stream, conversion, inference, then display or storage — and capture after each addition. Initialize acquisition before loading the model, so a missing camera fails in seconds instead of after a long model load. Keep four error strings distinct: enumeration, open, configuration, frame timeout; one generic message throws away everything the four tests built.

A process that started before the camera enumerated needs a fresh discovery pass, not a retry against a stale handle. The reconnect patterns in Python USB camera disconnect: fix errno 19 crashes keep a dropped link from killing the application.

Pick hardware the host can drive

Not-detected faults also start at purchase: a camera whose transport, supply or runtime support does not fit the station behaves exactly like a software bug. Compare the sensing method and the integration path separately. The 3D sensors category and the camera finder list both; before committing a unit, get the supported operating systems, the runtime distribution and the wrapper's Python coverage in writing. Plan edge vision inference deployment across camera and host covers sizing the host that receives the streams.

The MV-DPS200P-02 is a projected structured-light 3D camera — the method that recovers full-surface shape on a static part, discovered through its own vendor runtime rather than a generic stack.

The MV-DT01WMU is a ToF sensing camera — the method for per-pixel depth on moving targets at presence-check frame rates.

For either sensing method, standardize the interpreter before rollout and pin the wrapper and runtime pair that passed Test 4.

Close the fault and keep the record

Before the station returns to production, confirm every line:

• Interpreter path, wrapper version, runtime release and camera identity, written into the deployment notes.
• The working profile — resolution, frame rate, pixel format — copied from the vendor utility's successful capture.
• Three-of-three enumeration from a clean process, repeated once after a host reboot.
• Closing the application frees the camera; confirm by opening the utility immediately after exit.
• Error strings still separate for enumeration, open, configuration and timeout.

If one boundary still fails with this evidence in hand, send it to technical support — the interpreter path, the utility result and the three enumeration counts carry more than a screenshot of the final exception. For a new station, start at the camera configuration step and settle the transport before the software.