Enumerate camera interface names with an index loop

The SDK sees the first two grabbers and stops. The third board sits in its slot with the link LEDs lit, and the interface-name call still returns img0 and img1 and nothing after. That pattern almost always means the calling code, not the SDK: this API family returns exactly one interface name per call, and the list ends at the first error return. This how-to is for anyone bringing up a multi-camera PC. It shows the loop that enumerates every camera interface name, explains why a multi-port frame grabber still counts once, walks through the port-count query that runs on port 0, and ends with the arithmetic that proves every board and every port was found.

Why does the interface list stop after the second frame grabber?

The loop is doing what the SDK documents: the name query returns exactly one interface per call, so a third board only appears when you keep incrementing the index, and the list ends at the first call that returns an error.

The query is not a bulk list call. A classic frame grabber SDK documents its name query as imgInterfaceQueryNames(index, name): give it an index, receive the interface name identified by that index. There is no count output and no array to fill, so code that calls it once receives one name, and code that stops once it has enough names leaves every later board invisible to the application even though the runtime sees it.

The symptom has a signature. Interfaces appear in order, the list ends cleanly, and no error surfaces anywhere, because the code never asked for the index past the last board it expected. One question settles it before any driver reinstall: how many times does the loop call the query? If the answer is once, or once per board the call was expected to return, the loop is the defect, and the fix is three lines long.

How do you enumerate every camera interface name in one loop?

Start the index at 0, store the returned name, add one to the index and call again, and stop only when the call returns an error, because that error is the documented end-of-list signal rather than a failure.

1. Set the index to 0. The documented first call uses index zero, so declare the counter as the unsigned type the signature expects — uInt32 in the classic form.
2. Call the name query once per pass. The documented form, imgInterfaceQueryNames(uInt32 index, char* name), fills name with the interface string for that index.
3. Store the returned string, then add one to the index. Each successive call increments the index by one.
4. Stop at the first error return. The usage notes define that error as the end of the list rather than a fault, so continue only while the call reports success.
5. Log the final index. It equals the number of interfaces the runtime exposed.

/* One name per indexed call: enumerate until the list ends.
   imgInterfaceQueryNames(uInt32 index, char* name) is the documented
   signature; buffer size, success convention and printout are illustrative. */
unsigned int index = 0;   /* first call is documented at index 0 */
unsigned int found = 0;
char         name[64];    /* size to the name length your SDK documents */

for (;;) {
    int status = imgInterfaceQueryNames(index, name);
    if (status != 0) {       /* any error return ends the list */
        break;
    }
    printf("%u  %s\n", index, name);
    index = index + 1;       /* each successive call increments by one */
    found = found + 1;
}

Run it on a three-grabber PC and the test passes when the output reads 0 img0, 1 img1, 2 img2, found equals 3, and the call at index 3 returns the end-of-list error. If found stops at 2 on that bench, the loop logic is proven and the third board is a stack problem rather than a code problem, so move to the missing-interface checks below.

Why does a multi-port frame grabber still show up as one interface?

Enumeration lists interfaces, not ports, so a grabber with several camera connectors registers one name at one index no matter how many ports it carries, and a four-port board costs exactly one entry, same as a single-port board.

The mechanism sits at the interface level: one board, one driver instance, one name, one index. Ports are a second axis underneath it. The usage notes say it directly: an interface that supports multiple ports is still enumerated under its single name, so a two-port board named img0 lists as img0, once, at one index.

That single fact explains a family of integration surprises. A four-camera cell on a four-port board needs four sessions but owns one interface name, and the session-open call takes that name plus a port number, with port 0 as the documented entry point for the rest. It also breaks the assumption that interface count equals camera count; on a bench with multi-port boards it never does, so keep the two counts separate in start-up logging and follow the guide on assigning cameras to ports reliably in a multi-camera system rather than trusting open order. To map a name back to the physical board, use the part-number route in the guide on identifying a frame grabber model from its part numbers.

How do you count the ports hiding behind an interface name?

Open the interface at port 0 and read the documented port-count attribute, IMG_ATTR_NUM_PORTS, which returns the number of camera ports that interface supports; SDKs built on other APIs expose the same count under their own attribute names.

1. Open the interface at port 0. Port 0 exists on every interface, single-port boards included, so the same call works across the whole bench.
2. Read the port-count attribute. The SDK that documents this pattern names it IMG_ATTR_NUM_PORTS, and it returns the number of camera ports the interface supports.
3. Repeat for every interface in the list and keep the results in a name-to-count table.
4. Size the camera-open loops from that table rather than from a constant in the code.

GenICam-based stacks do not carry that attribute name; the equivalent count lives in the interface's feature list, and the guide on querying camera capabilities with GenICam shows how to read typed values from a node map. Treat the returned number as the authority on the board: a unit ordered as four-port that reports two ports is a firmware or model question, and it changes the session arithmetic in the verification section.

What else keeps an interface off the list?

An interface missing from a correct loop is almost never a detection bug in your code; the usual causes sit one layer down — a board the bus never saw, a driver that failed to bind, or a runtime and firmware mismatch that stops the SDK stack before enumeration starts.

Work down the stack in this order, which is also the order of how often each check turns out to be the cause.

A runtime and firmware mismatch is the most common software-side cause, and it usually fails during initialization before the loop runs at all; the guide on fixing frame grabber initialization failures walks the update order. When the interface opens but the first frame never lands, move to a stage-by-stage probe of the pipeline instead of re-testing enumeration. Treat NICs as first-class interfaces too: every Ethernet adaptor appears even with zero cameras attached, and cameras sharing one adaptor also share its bandwidth, so budget per port.

How do you verify the loop found every board and every port?

Compare two counts before you trust the list: interfaces found must equal boards installed plus network adaptors visible to the SDK, and camera ports must sum across interfaces, so three grabbers with 1, 1 and 4 ports mean 6 sessions must open.

Work a concrete bench: three frame grabbers, two of them single-port and one four-port, and no NIC in the SDK list.

• Interfaces expected: 3.
• Loop trace: the call at index 0 returns img0, at index 1 img1, at index 2 img2; the call at index 3 returns the end-of-list error, so interfaces found = 3 and the list is complete.
• Port counts: img0 reports 1, img1 reports 1, img2 reports 4.
• Camera ports behind the three names: 1 + 1 + 4 = 6.

Six ports means six sessions at acquisition time, not three. If the start-up log shows three sessions on this bench, the missing three live on the four-port board and the name-to-count table was never consulted. That is the whole verification: compare interfaces found against boards installed, sum the port counts, then compare sessions opened against the sum.

When is loop-until-error the wrong enumeration pattern?

Skip the index loop when the SDK is GenICam or GenTL based, because those environments expose an interface list you walk once, each entry carrying an identifier and a type, rather than one name per indexed call that fails past the end.

The index loop belongs to older grabber SDKs. GenICam and GenTL environments enumerate differently: the transport layer exposes a list of interfaces, and the application walks that list once instead of driving a call until it fails. Some SDKs document a single call that returns every interface visible to the runtime, adaptor cards and frame grabber cards alike. When the vendor stack wraps GenTL, a missing interface is usually a producer-side problem — version mismatches between producer and runtime are the recurring suspect — and rewriting the loop will not fix it. The port question changes shape too: instead of opening port 0 for a count, read what the interface entry and its node map report, following the GenTL node map guide. The habits still transfer: log what was found, compare it against what was installed, and open by name. More start-up and enumeration fixes sit on the systems topic page.

Which multi-port frame grabber adds camera ports without adding interfaces?

A multi-port board is the move when PCIe slots run out: an octo-port CXP-6 frame grabber turns one slot into eight camera ports behind a single interface entry, and a quad-port 10GbE NIC does the same for GigE-camera benches.

The decision follows the camera interface, because ports per interface are fixed by the board chosen.

CXP cameras: where the cameras speak CXP-6, the MV-GX1008 is an octo CXP-6 frame grabber, so a single PCIe slot feeds the camera rack while the interface list grows by a single entry.

XoFLink benches: the MV-GS1104F-DF carries 4 ports over XoFLink with an SFP+ slot and 40G total bandwidth supported, and its DataForwarding function keeps downstream sessions fed behind that one interface name.

GigE-class benches: for a bench of GigE-class cameras, the MV-GT2104 is a quad-port copper 10GbE NIC; the SDK lists it once and every camera session opens through that single interface.

Board count multiplies interface entries, driver instances and failure points; port count on one board keeps the enumeration flat. That is the tie-breaker when slots run short. If boards and cameras are being matched at the same time, the frame grabbers category collects the interface options in one place.

Match the board to cameras, host and lenses in one pass with the configurator below, or filter by interface and port count in the frame grabber finder first. Session counts, interface names and the area scan cameras behind them should agree before the first order goes out.

In-stock items ship within one business day. When the interface list still reads short after these checks, send the loop output and the port table through the contact page.