Frame grabber camera file missing: configure an unlisted camera

Your frame grabber software asks you to choose a camera from a list, and yours is not on it. That list is not a capability test. It is a library of pre-written descriptions, and a camera missing from it — discontinued, niche, or running custom firmware — can still be acquired once someone writes the description. Here is the path: decide whether your camera needs a camera file at all, collect the five groups of values its manual must give you, check them against the grabber's port capacity with one multiplication, build the file with the vendor's camera file generator, and read the test image well enough to correct a wrong value in one pass.

What a camera file actually does

A camera file is a small configuration record the grabber software loads before it will acquire. It states how many parallel output taps the camera drives and in what order, how many bits each tap carries, what pixel clock to expect, how active pixels and blanking sit inside each line and frame, and how to talk to the camera's serial control port — baud rate, data bits, stop bits, parity — so your code can set exposure and gain. The camera manufacturer defines these image and control parameters; the file just copies them into a form the board can execute.

Two consequences matter. The file programs the grabber, never the camera, so a wrong file costs debugging time rather than hardware. Files also do not travel between grabber vendors, because each writes its own format. And a file that produces a picture is not automatically a correct file: several fields can be wrong while the image still looks almost usable, which is why the acceptance grabs near the end matter.

Why the list has no entry, in order of probability

Work down these causes; the first two settle most cases.

1. The camera needs no file. GigE Vision, USB3 Vision and CoaXPress cameras never appear in camera file lists — they describe themselves to the driver through GenICam. Test: read the interface line of the camera's data sheet. If it is one of these, close the list and troubleshoot discovery instead, starting with the blank-image pipeline probe.
2. The camera was never submitted. Grabber vendors publish files for the cameras they tested, and a niche scientific or infrared sensor camera can sell for years without an entry. Test: search the library by sensor name and by resolution, not only by model — files are often filed under the sensor part number.
3. A sibling model's file exists. Camera families reuse timing across resolutions. Test: search under the series name, then plan to edit only resolution and clock.
4. The driver or SDK is half-installed and the library loads empty. Test: reinstall from the vendor package (driver fix); if one viewer sees the board and another does not, compare SDK versions (SDK support).
5. Custom camera firmware changed the timing. A stock file then describes hardware that no longer matches. Test: ask the camera maker what the firmware revision changes.

First check: does this camera need a file at all?

Packet interfaces — no file, by design. A GigE Vision, USB3 Vision or CoaXPress camera hands the driver a feature list at start-up; the network card or frame grabber only moves packets and has no timing to configure. If your camera is one of these, the missing-file path ends here and the real problem is discovery, driver or IP set-up. Any GigE port will do; a dual-port PoE GigE NIC feeds data and power to a small GigE camera over the same cable.

Parallel video — a file is mandatory. Camera Link and analog cameras stream pixels over parallel pairs with separate sync lines, and the receiver cannot ask the camera anything. Without a file the grabber does not know where lines start or how the taps interleave, so it refuses to configure or grabs noise. Everything below follows that path. The frame grabbers page lists the boards that take camera files; a Camera Link model like the one below is what a file-driven camera lands on:

The five value groups to take from the camera manual

Collect these before you open the generator. All five live in the camera manual — usually the specifications table plus the video output or Camera Link configuration section — and four of the five are also measurable on a scope if the manual disappoints.

1. Active resolution: pixels per line and lines per frame.
2. Tap configuration, also called tap geometry: how many parallel outputs, how many bits each carries, and the read-out order — 1 × 8-bit, 2 × 10-bit and so on. This is the field most often entered wrong and the hardest to guess from a picture.
3. Pixel clock and bit depth: the clock in MHz, and bits per pixel, so the board unpacks data correctly.
4. Line and frame timing: blanking widths and the behaviour of the frame-valid, line-valid and pixel-valid handshake lines.
5. Serial control settings: baud rate, data bits, stop bits and parity, plus the command set the camera answers with.

For an analog camera the equivalent set is the video standard — RS-170, CCIR or PAL — with its horizontal and vertical timing, and the board choice narrows accordingly: this analog frame grabber selection walkthrough covers the decode-style boards that class of camera needs. Do not expect an adapter to land an analog camera on a digital grabber — see why analog-to-digital adapters fail.

Worked example: 640 × 480 camera, 2 × 8-bit taps, 40 MHz pixel clock

Inputs. Active resolution 640 × 480 pixels, tap configuration 2 taps × 8 bits, pixel clock 40 MHz — the values a typical manual prints. Blanking is not printed, so assume 25 % and correct it against a live grab. The documented limits come from the Camera Link standard: a Base port carries 24 data bits per pixel clock — three 8-bit taps — at up to the 85 MHz Base clock ceiling; a Medium board doubles that to 48 bits, and 80-bit Full mode carries up to ten 8-bit taps.

Rule in words: bits on the wire per clock equal taps times bits per pixel, and that product must not exceed the port's data capacity.

Arithmetic:

• Bits per clock: 2 × 8 = 16 bits, inside the Base port's 24 with 8 bits spare.
• Wire rate: 40 MHz × 16 bits = 640 Mbit/s = 640,000,000 ÷ 8 = 80 MB/s of image data.
• Clock ceiling: 40 MHz is well under the 85 MHz Base limit.
• Frame-rate ceiling: 40 × 2 = 80 million pixels/s; at 25 % blanking, 80 × 0.75 = 60 million active pixels/s; a frame is 640 × 480 = 307,200 pixels; 60,000,000 ÷ 307,200 = about 195 fps. A camera rated at 60 fps sits far below that, so the manual's numbers hang together.

Decision. Set the file to 2 × 8-bit taps in Base configuration. The threshold to keep: taps × bits above 24 needs a Medium, dual-Base board — 3 × 10-bit = 30 bits and 4 × 10-bit = 40 bits both cross it — and above 48 bits you are into 80-bit Full territory.

Build the file with a camera file generator

Every Camera Link grabber vendor ships a camera file generator, and analog vendors ship the equivalent video-format editor. Take the tool from the grabber vendor or its distributor, not from a forum: a shared file describes someone else's firmware.

1. Open the generator and start from the closest sibling camera in its library, or a blank template. Name the file for your exact camera model.
2. Enter the tap configuration first. It is the field most often wrong and the one a picture cannot always expose.
3. Enter active resolution, bit depth and pixel clock from the manual.
4. Enter line and frame timing — clocks per line, lines per frame, blanking. If the manual prints only active sizes, start with 20-30 % blanking added.
5. Enter the serial settings — baud rate, data bits, stop bits, parity — and save.
6. Load the file in the grabber's configuration tool and run a live grab at the rated frame rate.
7. Verify with two grabs: a uniform target, which shows shading, stripes and tap imbalance at once, then a ruler or resolution chart, which proves geometry. If the tool stops responding while loading files, the fault is on the host side — see fixing an unresponsive configuration host.

What each wrong test image tells you

Two failures sit outside the file. Intermittent grabs that die after minutes, especially with several boards in one host, point at host resource contention rather than timing — this frame grabber resource conflict checklist works through the usual suspects. If several grabbers share the host, also confirm the file loaded onto the intended board, because port order can swap after a reboot (assigning cameras to ports). And on an embedded host, planar pixel formats arriving scrambled on a PCIe grabber under an embedded GPU module have their own documented fix.

When building a file is the wrong move

The multiplication also tells you when to stop.

• Specialty sensor, no modern equivalent: build the file. Infrared and scientific cameras hold their value precisely because nothing replaces them directly, and an afternoon of timing work is a small cost next to the camera.
• Commodity analog camera: replace it. An RS-170 or PAL camera of 1990s vintage costs more to integrate than to swap; a modern USB3 Vision camera drops into a PC with no grabber and no file, which is exactly the migration in replacing an obsolete analog NTSC frame grabber.
• Camera Link camera, growing host: re-platform. Packet interfaces scale through a switch or a 10GigE port instead of one grabber port per camera. Filter the camera finder by interface, resolution and shutter, or use the camera configurator to pair the camera with a lens and light in one pass. A 2.5 MP GigE camera with a global shutter such as the following covers most conveyor and inspection work with no camera file at all:

Rule of thumb: if a supported replacement costs less than about one engineer-day of your time, replace it; if the camera is irreplaceable, build the file.

Checklist before you commit

• Camera manual in hand with all five value groups — the file is only as good as its inputs.
• Tap configuration confirmed by the camera maker in writing, including tap order.
• The multiplication done: taps × bits per clock of 24 or less for Base, 48 or less for Medium, 80 or less for Full.
• Generator and any sample files taken from the grabber vendor or its distributor.
• Cable and sync wiring proven before the file is blamed — a dead grab and a wrong file look identical from the software side.
• Flat-field target and ruler ready for the two acceptance grabs.
• Camera firmware revision recorded in the file name, so a future update cannot silently invalidate the timing.

If you would rather hand the timing work over, describe the camera and grabber on the contact page and we will propose the closest supported pairing. Otherwise start at the frame grabber configurator, filter the frame grabber finder by interface, or read the neighbouring bring-up guides on the systems topic page.