You have swapped the cable, tried another port and reinstalled the driver, and the camera still does not appear in the viewer. When the model is newer than the software you point at it, stop there: the fault is usually the SDK build, not the hardware. An SDK can only enumerate the models its release knew about, so a camera introduced after your build has no entry in the device table and stays invisible however many times you replug it. This guide gives you the one-minute version comparison that proves the fault, the likely causes ranked in test order, the upgrade sequence that gets the camera enumerating, and the precautions that keep a validated station intact while you do it. It covers USB3 depth and area scan cameras, board-level modules, and the GenTL equivalent on GigE and CoaXPress.
The symptom that clears the hardware
A version fault has a consistent signature. The camera powers up, and the operating system may even list it on the bus. The viewer's device list stays empty, or shows only the older cameras. An older model from the same family enumerates on the same port with the same cable. The shipped cable and any adapter have already been tried, with no change. And the problem appeared when a brand-new model met an existing install, or right after a viewer update.
A cable fault, a weak port or a power problem does not care which generation of camera is plugged in. An out-of-date device table does. That asymmetry — one model fine, its newer sibling absent, same port — is the most useful clue you will get. If your SDK is current and the camera still fails to appear on the bus, hand the case to the physical-link checks in Camera has power but not detected: USB link checks after a cable swap.
Why a healthy camera can be invisible: the device table
Every SDK release carries a table of the models it supports, keyed by the vendor and product ID each camera reports when it is plugged in. Enumeration is a lookup: the camera announces its IDs, the SDK searches its table, and the device appears or does not.
Two consequences follow. First, a model introduced after your build is missing from the table, so the lookup fails without an error message. Second, detection can run ahead of full support: a new model may appear in a viewer built on a release that predates its official support, then refuse to stream. Showing up and being supported are two different checks, against two different releases.
Machine-vision stacks have the same structure one level down: the GenTL producer your runtime loads holds its own enumeration list, which is why Frame grabber SDK support: why one viewer works and another fails tells the same story under different names. When the table is the problem, no cable is ever the fix.
Likely causes, in order of probability
Work down the list; each item carries the test that decides it and the fix that follows.
- The SDK build predates the camera model. Compare your installed version with the vendor's supported-models page or release notes and find the first release that lists your model. If yours is lower, upgrade the SDK. This is the first cause to test and the cheapest to clear.
- Camera firmware outside the release's range. This applies once the SDK supports the model: a listed camera with firmware older or newer than the release expects can be enumerated and then fail to open. Compare the camera's firmware version with the release notes; the camera firmware version mismatch fix covers this failure from the firmware side, and the DFU firmware update procedure brings the camera back into range.
- A GenTL producer older than the camera (GigE, 10GigE, CoaXPress, Camera Link). Read the producer library and version your runtime actually loads, not the SDK installer's version, and update that component from the camera vendor's package.
- Physical link or power. Test on another PC, another port and the shipped cable, with a current SDK. Intermittent dropouts that survive the version check belong to USB camera keeps disconnecting: isolate cable and hardware faults, and a GigE camera that never appears may be a PoE budget question, as Does my camera support PoE: check the port before you buy explains.
- Driver or permission conflict. The OS lists the camera but the SDK cannot claim it. Remove the competing driver binding or correct the access rules for the device, then re-enumerate.
One line of triage, before any screwdriver comes out:
| What you observe | Most likely cause | The test that decides |
|---|---|---|
| New model absent, older sibling fine on the same port and cable | SDK predates the model | Installed version against the supported-models list |
| Absent on every PC, port and cable | Link, power or a dead unit | Bench PC, current SDK, shipped cable |
| OS lists it, the SDK cannot open it | Firmware outside range, or a driver conflict | Firmware version against the release notes |
| Visible in one viewer, invisible in another | Different GenTL producers or versions | Producer file and version each viewer reports |
Worked example: a new depth camera against an SDK 2.40.0 viewer
The case that shaped this guide: a compact stereo depth camera was invisible to a viewer built on SDK 2.40.0, while an older sibling model from the same family enumerated on the same port. The inputs, with their sources:
- Installed software: a viewer on SDK 2.40.0, version read from the viewer's own version panel.
- Camera: a compact stereo depth camera, new to its maker's line that month.
- Support data from the maker's release notes: the model first enumerates on SDK 2.50.0, and official support lands in 2.51.1.
- Already excluded by test: the camera's shipped cable and a USB 3 adapter, neither of which changed anything.
The rule, in words: a release enumerates a model only if that model's product ID sits in that release's device table, so compare the installed version with the first release that lists the model, segment by segment.
The arithmetic. 2.40.0 against 2.50.0: same major version, 40 < 50, so the installed build is ten minor releases older than the first build that detects the camera at all. 2.40.0 against 2.51.1: 40 < 51, so it predates official support by eleven minor releases.
Result. The 2.40.0 device table has no entry for the camera's product ID, so the lookup fails silently. No cable, adapter, port or driver change can make a build enumerate an ID it does not contain — exactly the behaviour observed: sibling model fine, new model absent, hardware blameless.
Decision, with its threshold. If installed version < the first release that lists your model, the SDK upgrade is the fix, and it comes before any hardware work. Only when installed >= that release and the camera is still absent do cable, power and drivers move to the top of the list.
Upgrade order that protects a working station
- Record the working pair before you change anything: SDK version and camera firmware for each station, in the station's own record.
- Read the release notes for the first release that lists your model and note the firmware versions it supports. The SDK and firmware land as a pair; the header and SDK alignment fix shows the same pairing from the build side.
- Install the new SDK on a bench PC, not the station, and confirm the camera enumerates and streams the acquisition you actually run.
- Move the camera's firmware into the new release's range after the SDK upgrade, never before. If an update hangs halfway, the USB ID recovery for a firmware update mode is the way back.
- Deploy with a rollback path: keep the previous SDK installer, validate one full production cycle, then release the station and write the new versions into its record.
GigE and CoaXPress: the same check on a different component
On GigE, 10GigE and CoaXPress cameras the enumerating component is not the SDK installer but the GenTL producer your runtime loads — the transport library that lists devices for the viewer. Two viewers on one PC can disagree because they load different producers, or different versions of the same producer. Read the producer file and version your runtime reports, and update that component from the camera vendor's package before you question the camera. If the first open after the update still fails, the network and adapter causes that mimic a missing device are laid out in First GenTL read always fails: fix the initial camera I/O error.
When the right fix is a camera your stack already knows
If the station cannot take an SDK upgrade this quarter — a frozen OS image, a validation cycle you cannot afford to repeat — stop fighting the table and buy into it. Choose models your installed release already lists, and bench-test the exact model before it is scheduled onto the machine. The three classes this fault bites hardest, worth pairing deliberately with a release you control:
- Type
- Stereo / structured light
Depth cameras of this class stream through their vendor SDK like every other camera, so the version check above applies unchanged. On the 2D side:
- Sensor format
- 1/1.8"
- Interface
- USB3
- Sensor format
- 1"
- Lens mount
- C-mount
A 6 MP bare-board module and a 20 MP C-mount USB3 camera cover the embedded and classic inspection builds. USB3 runs the product-ID check on every plug-in, which is why the version comparison belongs in the purchase decision rather than at commissioning. Browse the 3D sensors, area scan cameras and board-level cameras ranges with the interface filter, then run the check from this guide before you order.
Prevention: pin the pair, test the new model on the bench
A five-line habit prevents a repeat:
- Write the SDK version and camera firmware into the station record at commissioning.
- Before ordering any camera, find the model in the supported-models list of the release you actually run, not the newest release.
- Bench-test a new model against the target software before it is scheduled onto the machine.
- Upgrade the pair together: SDK first, firmware second, both recorded.
- Keep the previous SDK installer on hand for rollback.
More pairing, enumeration and firmware faults, each with its fix, sit on the systems topic page.
The decision, case by case
- New model, old SDK: upgrade to the first release that lists the model, align firmware afterwards, and skip the cable hunting entirely.
- New SDK, camera that used to work: check the firmware range and the GenTL producer version against the release notes before blaming the camera.
- Locked station, new camera needed: buy a model the installed release already lists and bench-test it; plan the upgrade on a pilot PC separately.
- Version current, camera still absent: now it is hardware — work the link, power and driver checks with a current SDK.
If you are specifying hardware for a station that must pair cleanly with your software, start at the camera finder or the camera step of the configurator, and send your SDK version with the enquiry — free expert support with every order means the pairing gets checked before anything ships. Questions that outgrow the guides go to the contact page.
Questions
Where do I read the SDK version my software is running?
The version appears in three places that always agree: the viewer's about panel, the first lines of its startup log, and the package entry if you installed the SDK as a library. Copy the whole string, third digit included. Release notes are published per version, so the notes for 2.51.1 list exactly the models that 2.51.1 enumerates — compare against those, not against a general support page.
Why does an older camera from the same family enumerate fine on the old build?
Enumeration is per model, not per family. The older model's product ID entered the device table in a release that predates your build, so its lookup succeeds; the new model's ID was added later and is absent from yours. Same port, same cable, different table entries — that asymmetry is the signature of a version fault rather than a hardware one.
Can a firmware update make an old SDK recognize a new camera?
No. Model support lives in the SDK's device table, which nothing on the camera can change; a new model stays invisible on a build that predates it, whatever firmware it runs. Firmware alignment matters one step later: once a release supports the model, the camera's firmware must sit inside the range that release states, or the SDK lists the device and then fails to open it.
Does the same check apply to GigE and CoaXPress cameras?
Yes, with a different component to read. These cameras are enumerated by the GenTL producer your runtime loads rather than by a USB product-ID table, so compare the producer's version — and the exact file your runtime loads — against the camera's release notes. Two viewers on one PC can disagree for precisely this reason, each holding its own producer.
The station PC cannot take an SDK upgrade — what is the path then?
Freeze the software and fit the camera to it. Find candidate models in the supported-models list of your installed release, bench-test the exact model against that build before ordering, and keep new units off the machine until they enumerate there. If the next camera generation is unavoidable, image a second PC as a pilot for the upgrade and move the station after validation.