Integrate a thermal camera into a DAQ application via its SDK

Here is the whole decision in one line: if the camera ships a documented DLL or C API, your DAQ program needs four to six library calls — initialize, start streaming, copy each frame, stop — and a buffer budget of 640 × 512 pixels × 2 bytes × 50 frames/s ≈ 33 MB/s per camera, about a quarter of a GigE link. Load the SDK at runtime, pull radiometric 16-bit counts instead of palette pictures, convert each count to °C with the scale and offset the SDK reports, and size the host PC, link and storage from that 33 MB/s figure. You have a process or a test rig that already logs pressures, currents and speeds, and now it needs temperature as an image: one thermal camera, one DAQ program, and a maker SDK your DAQ software has never heard of. This guide gives the order of operations, so you can redo the arithmetic with your own camera's pixel count and frame rate before you commit.

What do you need before you integrate a thermal camera into a DAQ application?

Three things decide the project before you write any code: a camera whose maker ships a documented DLL or C API, a PC with one free GigE or USB3 port, and the camera's calibration range in °C — the DAQ package you run matters far less than those three.

Gather four items first:

• the SDK package, taken from the camera maker's own download area or your distributor: the DLL, the header file with every function signature, and the manual;
• your DAQ environment's mechanism for calling an external library;
• the connection settings — for a TCP/IP camera, its IP address and port on your subnet;
• the temperature range the camera is calibrated for, which tells you what the raw counts will span.

For the host, a fanless vision controller is the usual choice, because it puts several LAN ports, industrial power and I/O in one box. The MV-VC3301H-128G66 covers a single-camera bench: 5+ LAN ports, an Intel Core i3, 8 GB of RAM and a 128 GB SSD, with PCIe expansion if you later add interface cards.

How do you call the camera's SDK from a DAQ program with no native driver?

You load the vendor DLL at runtime and call its functions in a fixed order — initialize, start streaming, copy each frame into your own memory, stop and release — usually four to six calls, whatever DAQ package sits on top.

The sequence is the same for every thermal SDK:

1. Install the SDK from the maker's package. You get the DLL, the header and the manual. The DLL name and each function's exact signature come from the header; declare them exactly, because a wrong argument list is the classic cause of an access violation on the first call.
2. Declare the functions in your DAQ environment. Many packages have a single library-call mechanism for this — extern() in one well-known DAQ package — where you declare the return type and argument types once, then call each function by name.
3. Load the DLL and resolve the function addresses. On Windows the calls are LoadLibraryA and GetProcAddress:

/* Illustrative flow: <angle brackets> stand in for names
   in your SDK's header file and manual. */
HMODULE lib  = LoadLibraryA("<dll name from the SDK manual>");
FARPROC init = GetProcAddress(lib, "<initialize function from the header>");
FARPROC grab = GetProcAddress(lib, "<frame function from the header>");

4. Open the connection with the manual's settings. A TCP/IP camera takes an IP address and port on the same subnet as the DAQ PC; a USB module takes a device enumeration call.
5. Start the stream and copy each frame into your own buffer inside the callback, before you log, plot or convert anything.
6. Shut down in reverse order: stop the stream, close the camera, free the library.

The callback pattern — grab, copy, hand off to a worker — matches the one used with standard industrial cameras: calling a camera SDK DLL with callbacks, buffers and a snap walks through it call by call. If the first call fails with a missing-module error, matching the DLL to the target OS is the fix plan. When the DAQ PC later moves to production, running your application without the SDK installed lists which runtime files to ship with it.

Which camera and PC keep up with your frame rate?

Do the buffer math first: 640 × 512 pixels × 2 bytes per count × 50 frames/s ≈ 33 MB/s, about a quarter of a GigE link, so one camera per port is comfortable and the DAQ PC needs buffered LAN plus a disk that sustains 33 MB/s of writes.

The LS-IRC-0044 is exactly that stream: a 640 × 512 LWIR camera delivering 50 Hz over GigE, sensing 8-14 μm, with an 88.5° × 73.2° field of view, a C-mount lens mount and a 9-24 V DC supply.

When the camera hangs on a short bench cable instead of the plant network, the LS-IRC-0016 is a 640 × 512 LWIR module that streams over USB3.

Scale is linear. Four cameras of that class write 4 × 32.8 ≈ 131 MB/s, so put each camera on its own LAN port and log to a fast SSD. The MV-VC5525-256G70-NN carries that load: 5+ LAN ports, a 12th-generation Intel Core i5, 32 GB of RAM, a 256 GB SSD, PoE camera ports and 8 built-in light channels.

The camera finder filters the infrared cameras by interface, resolution and shutter, so you can shortlist models that match the arithmetic above.

How do you get true temperatures instead of the palette picture?

Ask the SDK for the radiometric stream, not the rendered image: each pixel then arrives as a 16-bit count proportional to the infrared the sensor received, and you log °C instead of decoding the 8-bit palette colors the viewer draws.

Radiometric output is a capability of the camera class, not code you add on. Two habits make it pay off. If the SDK offers a structured payload that already carries calibrated values per pixel or per ROI, parse that and skip the conversion step — reading a camera's temperature data with structured types shows the parsing pattern. Keep the 16-bit grayscale for analysis and render color only for the operator's screen: exporting high-bitdepth grayscale from thermal cameras covers the file formats that preserve every bit, and a pseudocolor map from 16-bit counts to a palette makes the live view readable without touching what you store.

How do you convert raw thermal counts to °C?

Use the scale and offset the SDK reports with every frame: °C = count × scale + offset, so a frame reporting scale 0.01 and offset −50.00 turns a count of 8,000 into 30.00 °C — and read the pair per frame, because it follows the camera's calibration range.

The pair 0.01 and −50.00 is illustrative; your SDK reports the real values, and some report a range instead. If the calibration spans −20 to +150 °C over 65,536 counts, derive the pair yourself: scale = (150 − (−20)) / 65,536 = 0.00259 °C per count, with offset = −20 °C at count 0. The multiplication never changes, so either form of report lands in the same line of code.

Converting raw thermal counts to temperature covers the calibration side of that formula — what the factory calibration fixes and what you set on site.

How do you stop frames from tearing or dropping mid-run?

Copy the frame buffer your callback receives before anything else touches it: the SDK reuses that memory the moment the callback returns, and two to four buffers in flight ride out the disk and display hiccups of a long DAQ run.

At the example rate the timing is tight: one frame period is 1/50 s = 20 ms, so the callback must finish inside 20 ms and exposure must stay below 20 ms as well. Keep the callback to a single copy, log from a separate consumer thread draining a ring buffer of two to four frames, and let the display path wrap the original buffer without a second copy — wrapping an SDK frame buffer in an OpenCV Mat without copying shows that split line by line. When frames still tear, the cause is almost always buffer lifetime, and copying the buffer before you queue it is the diagnosis path. If the SDK lacks an exposure setter, setting exposure through sensor registers is the register-level fallback.

How do you verify the temperatures you logged are right?

Check the chain once against a reference of known temperature — a stirred water bath near ambient or a calibration source — at the same distance and focus as production, and expect agreement within about ±2 °C or ±2% of reading, the accuracy class industrial thermal cameras print.

Set emissivity to the real surface before the run, because it dominates the error: matte painted and non-metal surfaces sit near 0.95, while polished metals fall to 0.1-0.2 and reflect the background rather than their own heat. If the check lands outside that band, work down the list: emissivity first, then the background the surface reflects, then any window or extended optics in front of the lens.

When should you skip the SDK and pick a GigE Vision camera instead?

If the camera choice is still open, pick a thermal model that speaks GigE Vision: any GenICam-aware library opens it like a standard industrial camera, and you skip the vendor DLL, its callbacks and its runtime housekeeping entirely.

A GigE Vision camera is discovered, opened and streamed through the GenICam standard that many DAQ environments already support, which removes the DLL declarations and the callback plumbing from the project. The infrared camera range includes GigE models alongside USB3 and Camera Link, so this route is usually available rather than exceptional. The SDK route stays right when the camera's value is its proprietary radiometric payload, when you want a compact USB module, or when the model is a special-purpose imager such as a gas-leak camera, where the maker's library is part of the instrument.

The decision, one line per case: the camera ships a documented DLL and your DAQ package can call a library — integrate through the SDK, four to six calls, and plan roughly 33 MB/s per 640 × 512 camera at 50 Hz. You still get to choose the camera and a GigE model covers your spectrum — skip the SDK and open it like any GenICam camera. Either way, you log calibrated °C at the full frame rate.

Next step: shortlist the host in the vision controllers category — the filters there sort by LAN port count, memory and PoE — or contact us for help matching a specific camera's SDK to your DAQ package. The cameras topic page collects the camera-side guides.