You installed the machine-vision SDK, the runtime is in place, and the device list still shows zero thermal cameras. The usual next step — CTI paths, environment variables, firewall rules — is wasted effort when the cause is simpler: the camera does not speak a transport your SDK understands. Many radiometric thermal cameras are process instruments first: they serve video over RTSP and hand process values to a PLC over Modbus TCP or EtherNet/IP, and no GenICam SDK will enumerate them. This guide gives you a ten-minute protocol check, a worked example of the zero-device case, and the three software routes that work, so you can decide between changing the software and changing the camera.
The symptom: a clean install and an empty device list
The failure has a fixed shape. An example script from the SDK throws an exception before any camera work starts, complaining that it could not load a producer and naming an environment variable that must point to a .cti file. You install the full runtime, the exception goes away, the SDK's own viewer opens — and the device list stays empty. The script now runs and prints a device count of zero. Meanwhile the camera answers ping, and anything it serves outside the SDK, such as its own web pages, works normally.
That combination — healthy runtime, healthy network, empty list — is the signature to read. Match what you see against this table before touching a setting:
| What you see | What it points to |
|---|---|
| Producer-load error naming a missing environment variable and a .cti file | Runtime missing or CTI path wrong — a real, fixable host-side fault |
| Viewer opens, list empty, ping works, non-SDK access works | The camera speaks no GenICam transport — protocol mismatch |
| List empty, and the data sheet lists Modbus TCP, EtherNet/IP or RTSP only | Confirmed protocol mismatch — change the software route, not the SDK settings |
| List empty, and the data sheet prints GigE Vision | A genuine enumeration fault — subnet, firewall or CTI match |
The general checklist for every camera-not-detected case lives in the SDK detection guide. What follows is the branch that guide cannot fix with settings: a camera that was never going to appear in the list.
Most likely cause: the camera does not speak a GenICam transport
A GenICam-based SDK never talks to a camera directly. It loads GenTL producers, one per transport layer, and each producer discovers and drives only cameras that speak its transport. For frame-based cameras the two producers that matter are GigE Vision and USB3 Vision; Camera Link and CoaXPress ride their own acquisition paths, as the camera interfaces comparison lays out. Install every producer the maker ships and the SDK still only sees cameras on a transport some producer serves.
Radiometric thermal cameras are usually specified for control rooms, not vision pipelines. Process values travel to the PLC over Modbus TCP or EtherNet/IP, and the video leaves as an RTSP stream that a media player renders. Those protocols carry their own complete stacks, and no GenTL producer speaks any of them. The device count is therefore zero by construction — not a bug, not a license problem, not a path you forgot to set.
The decision follows directly. If the camera's interface list contains neither GigE Vision nor USB3 Vision, further SDK tuning is wasted effort; what remains is a choice between the three software routes below and, where the project allows it, a different camera.
The protocol check that settles it
- Open the camera's data sheet or user manual at the interface section.
- Search for the two phrases that matter: "GigE Vision" and "USB3 Vision". Either one means a GenICam SDK can enumerate the camera once the host side is right.
- Read what is listed instead. Modbus TCP, EtherNet/IP, RTSP and ONVIF are protocol markers for a process instrument, not for a vision pipeline.
- Check which SDK the maker names for this camera family. A dedicated SDK with no GenICam note is the answer in writing, and it tells you the supported route before you install anything.
- Ping the camera once. An answer, an empty SDK list and no Vision transport on the data sheet together close the case.
Worked example: zero devices from a camera with Modbus TCP, EtherNet/IP and RTSP
Take the case as it arrives on the bench: a radiometric thermal camera on Windows 10, a GenICam SDK fully installed, and an example script reporting zero devices.
- Camera interface list: Modbus TCP, EtherNet/IP and RTSP — three protocols, read from the camera's own interface section.
- SDK transport set: GigE Vision and USB3 Vision — the transports the installed GenTL producers serve.
- Host state: 64-bit Windows 10, Python 3.10.11 from python.org, full runtime present and the .cti environment variable set, so the producer loads and both sides are 64 bit.
- Observed device count: 0, in the viewer and in the script.
The rule in words: a GenICam host can only enumerate cameras whose protocol one of its loaded producers serves. The largest device count it can ever report is therefore the size of the overlap between the camera's protocol set and the SDK's transport set.
The result: the empty list is the correct answer for this camera. Nothing on the install side is broken — the producer loads, the architectures match, the network passes — and no setting can raise a count the transport set caps at zero.
The decision, with its threshold: when the overlap is 0, stop tuning the SDK and change the software route or the camera. When the overlap is 1 or more and the count still reads 0, the protocol is not the cause; work the enumeration fixes in the next section instead.
The other two causes: binding mismatch and a genuine enumeration fault
A binding or architecture mismatch
If the producer-load error never clears, suspect the install, and three causes cover most of it. The SDK runtime and the language binding must be the same version and the same architecture — 32-bit Python cannot load a 64-bit producer. A Python installed from the Windows Store has a non-standard layout that breaks producer loading, so install from python.org instead. And the .cti environment variable must exist and point at the .cti file inside the SDK's own install folder. The test that separates this cause from the protocol case: run the SDK's own viewer. If the viewer opens, the native producer loads, so the remaining fault lives in the binding or its paths. The GenTL CTI file path fix and the producer-not-listed check cover the Windows path details.
A genuine enumeration fault
When the interface list does print GigE Vision and the count still reads zero, the familiar causes return. The camera may sit on a 169.254.x.x link-local address while the network interface lives on another subnet; a firewall may be swallowing the UDP discovery packets; or the CTI file in use belongs to a different camera family than the one on the bench. Work them in order: the subnet and compliance checks, then the full enumeration-chain plan; if the producer is present but the list stays empty, the empty-camera-list fix covers matching the CTI to the camera.
Three software routes that work
Once the mismatch is confirmed, three routes cover every legitimate integration.
The maker's SDK. Take the camera's own SDK from the maker or its distributor — that is the supported source, and it is the only route that returns calibrated temperature for every pixel, because it speaks the camera's native protocol. Most ship as a C++ or .NET library with Python access on top; the walk-through of integrating a thermal camera into a DAQ application through its SDK shows the shape. For storage, radiometric file formats keep the numbers intact: saving 16-bit temperature data in radiometric JPEG files, and, for analysis-friendly frames, exporting high-bit-depth grayscale images from thermal cameras.
A protocol client. Modbus TCP needs no SDK at all. The maker's register map lists which holding registers carry temperatures and the scale factor to apply; any Modbus client library reads them, and multiplying the raw 16-bit value by the documented scale gives degrees Celsius for that spot or region. EtherNet/IP serves the same job on PLC-centered lines. An RTSP client gets you live video with nothing more than a media decoder — but read the stream for what it is: the camera's rendered image with its palette applied, not raw radiometry.
A GenICam-capable camera. When the project is young enough to change hardware, the cleanest fix is a thermal camera with a GigE Vision or USB3 Vision interface: it joins the acquisition pipeline, feature tree and logging the rest of the line already uses.
Buy for the protocol your host speaks
For new projects, specify the camera transport to match the host tooling rather than the other way round. If the line already runs GigE Vision cameras through one SDK and one logging pipeline, an infrared camera that speaks GigE Vision slots in without a second software stack. Each of these enumerates in a GenICam SDK directly:
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
- Spectrum
- LWIR
The LS-IRC-0044 is a 640 × 512, 8–14 μm LWIR thermal camera with a GigE interface and a C-mount lens mount.
- Interface
- USB3
The LS-IRC-0016 is a 640 × 512 LWIR camera module with a USB3 interface, for hosts that acquire over a direct USB link.
- Sensor format
- 1/2"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- Up to 3 MP
The MV-CI013-GS-NN is a 1.3 MP SWIR camera with a GigE interface and a C-mount, for short-wave infrared work rather than thermal imaging.
The infrared cameras category lists the LWIR, MWIR and SWIR models with their interfaces and mounts, SWIR area scans also sit in area scan cameras next to the visible-light models, and the camera finder filters by interface so you can pull the GigE and USB3 infrared models directly. To match a camera against the rest of the system, start at the configurator's camera step:
The configurator matches a camera, lens, light, light controller and cables to each other, step by step, and lists only parts that fit what you already picked.
Prevention: read the interface line before you write code
Four checks prevent the whole failure class:
- Before you specify: read the data sheet's interface line, and require GigE Vision or USB3 Vision in writing when GenICam tooling is the plan. That line decides the entire software stack.
- Before you install: match the SDK runtime and the language binding by version and architecture, and install Python from python.org rather than the Windows Store. Between them they cause most producer-load errors that look like camera faults.
- Before you debug an empty list: run the maker's own viewer once. A clean viewer with an empty list moves the suspicion from your install to the camera's protocol.
- On the bench: take firmware and SDK software only from the maker or its distributor. Matched versions keep the documented behaviour intact when you need support.
The decision, one line per case. The camera lists only Modbus TCP, EtherNet/IP or RTSP: keep the camera, use its maker's SDK for radiometry and a protocol client for everything else. The camera lists GigE Vision but the count is zero: run the enumeration fixes, because the host side is genuinely at fault. The camera is not chosen yet: specify a GigE Vision or USB3 Vision thermal model and the problem never exists.
If the interface list leaves you unsure which case you are in, send it through the contact page and we will name the route it forces. More detection and integration fixes sit on the cameras topic page.
Questions
Can a GenICam SDK open an RTSP stream from a thermal camera?
No. A GenICam SDK talks to cameras through GenTL producers, and producers handle transport layers such as GigE Vision and USB3 Vision, not media streaming protocols. RTSP has its own session setup and lives outside the GenICam stack entirely. Pull the RTSP stream with a media client and decode it yourself, and use the maker's SDK when you need calibrated temperature values rather than the rendered video.
What install mistakes produce a producer-load error or zero devices?
Three show up again and again: an SDK runtime and a Python binding of different versions or architectures, where 32-bit Python cannot load a 64-bit producer; Python installed from the Windows Store, whose non-standard paths break producer loading; and a .cti environment variable that was never set after installing the runtime. Fix all three before blaming the camera: match versions and architecture, reinstall Python from python.org, and point the variable at the .cti file shipped inside the SDK's own install folder.
How do I read temperature values from a thermal camera that only speaks Modbus TCP?
Use the register map in the camera's documentation: it lists which holding registers carry temperatures and the scale factor to apply. Read the registers with any Modbus TCP client library, then multiply the raw 16-bit values by the documented scale to get degrees Celsius. That path gives you spot values and regions, not a full radiometric frame; for per-pixel temperature across the whole image, use the maker's SDK or its radiometric file export.
Which thermal cameras will a GenICam SDK enumerate?
Any infrared camera whose interface is GigE Vision or USB3 Vision, because those are the transport layers GenTL producers serve. In the shop's infrared range that means the GigE LWIR models — the LS-IRC-0044, a 640 × 512, 8–14 μm thermal camera — and SWIR area scans such as the LS-IRC-0029, a 0.3 MP GigE camera with a global shutter. Cameras served over RTSP and Modbus TCP are process instruments and will not appear in the SDK's device list.
Does a GenTL producer add support for other protocols?
No. A GenTL producer is a plugin that teaches a GenICam host one transport layer and its device discovery, and each producer is written against a specific standard such as GigE Vision or USB3 Vision. Installing more producers adds more transports of the same kind; it never teaches the host RTSP, Modbus TCP or EtherNet/IP. If the camera speaks none of the supported transports, the software route or the camera has to change — no producer download will help.