The upgrade finished cleanly, the application opened, and every camera delivers frames — on the wrong channel. Camera 1 now shows what camera 4 used to, the strobe meant for the left lane fires on the right, and every recipe that addresses a channel number aims at a different camera. Nothing was unplugged and no board moved. With multiple frame grabbers this is the standard aftermath of any upgrade that touches drivers, and it has a standard cure: pin the board order back with a one-board-at-a-time reinstall, then bind channels by serial so order stops mattering. This guide gives the cause, the diagnosis, the reinstall procedure with timings, and a channel test with real numbers.
Why the channels moved
An application running several identical boards computes each camera's address:
Nothing in that formula is physical. The board index comes from enumeration: at every boot the Windows PnP manager has the PCI bus driver scan the bus and report the boards in scan order. A board keeps its bus, device and function address as long as it stays in its slot, but which board counts as first is decided by scan order and driver state — not by the order you installed the boards, and not by your cabling.
A vision software upgrade typically ships or reinstalls its frame grabber drivers. That reinstall clears the stored device-to-driver associations, the next boot repeats first-detection behavior, and two identical quad-port boards can come back interchanged. Every channel on both boards then shifts by the port count. If your boards stopped working entirely instead of reordering, that is a version mismatch rather than an enumeration swap — start with frame grabber driver mismatch after a vision software upgrade.
Confirm the cause before you open the case
Four checks, in order of likelihood. Each takes minutes and points at a different fix.
| Cause | Signature | Test | Fix |
|---|---|---|---|
| Driver reinstall during the upgrade | Wrong order in the vendor tool and in the application; driver dates match upgrade day | Device Manager, board Properties, Details, Location information; compare PCI bus/device/function against your slot map | One-board-at-a-time reinstall below |
| Ghost or duplicate devices | Grayed-out grabber entries; one board counted twice | Device Manager, View, Show hidden devices | Uninstall the gray entries and rescan |
| Application config cached by index | Order correct in the vendor tool, wrong only in the application | Count the boards in the vendor viewer first | Rebind channels by camera serial in the application |
| Discovery race at startup | Mapping differs between cold boot and application restart | Restart only the application and compare | Stagger power-up and bind by serial — see camera discovery startup contention |
Ghost entries and stale driver packages that hold interrupt and memory ranges are a failure family of their own; the resource-level method is in resolving frame grabber resource conflicts.
The fix: install one board at a time
- Record the target map first: for every camera, its serial, its connector, and the application channel it must answer to. Label both ends of every cable, and settle any two boards with near-identical markings using identify a frame grabber model from its part numbers.
- Export or screenshot the application's full camera configuration, channel by channel.
- In Device Manager, uninstall every frame grabber — each board plus any gray duplicates — and accept the offer to remove the driver software. Shut down.
- Leave only the board that must be board 0 in its slot. Boot, let Windows detect it, install the vendor driver, and confirm its cameras stream.
- Shut down, seat the next board in its own slot, boot, bind its driver, confirm. Repeat for every remaining board.
- Verify the final order in Device Manager — view by connection and read each board's bus, device and function — then rebuild the application mapping and run the channel test below.
Budget 15 minutes per board: 2 down, 3 to boot, 5 for the driver bind, 5 to verify. A three-board cell is back in service in under an hour plus the final test. When Windows refuses to bind a driver to a freshly detected board, walk through manual driver installation via Device Manager instead of letting the upgrade package retry blindly.
Prove the mapping: the ten-minute channel test
Work the numbers on a concrete cell: two quad-port GigE boards, eight area scan cameras at 2448 × 2048 mono 8-bit, running at 20 fps.
- Interface
- GigE
- Ports
- 4 ports
The line rate per camera:
A GigE port carries 125 MB/s on the wire and delivers about 115 MB/s of image payload with jumbo frames, so one camera per port at 100 MB/s fits with margin — while two cameras parked on one port at 200 MB/s drop frames. That is why you never merge channels temporarily while remapping: dropped frames look exactly like a mapping fault and send you chasing the wrong cause.
The identification pass:
- All eight cameras streaming, strobes off.
- One camera at a time, drop its exposure to 20 µs at normal room lighting. Exactly one channel goes black. Record that channel against the camera's serial — every GigE Vision camera exposes its serial over the interface.
- Restore the exposure, move to the next camera. About a minute per camera.
- Compare the recorded pairs with the target map and correct mismatches in the application's serial binding — never by swapping cables to chase the software.
The reorder reaches the I/O as well: trigger and encoder lines are numbered per board, so TTL input 0 after the swap is a different physical pin. Re-map the I/O one line at a time, and take the chance to move from bare pins to a color-documented break-out cable:
- Type
- Frame grabber I/O cables
- Length
- 6-8 m
Bind by identity so the next upgrade cannot do this
The reinstall pins today's order; identity binding makes order irrelevant. Compare the keys:
| Binding key | Survives a driver reinstall | Survives a slot move | Survives a board swap | Verdict |
|---|---|---|---|---|
| Enumeration index | No | No | No | Never in a multi-board cell |
| Slot address (bus/device/function) | Yes | No | No | Secondary check only |
| Board serial plus connector number | Yes | Yes | Rebind once | The key for Camera Link and CoaXPress |
| Camera serial or DeviceUserID | Yes | Yes | Rebind once | The key for GigE and USB cameras |
For GigE and USB cameras, set a DeviceUserID string per camera in the GenICam feature tree — lane1-left, lane2-right — and open cameras by that string; a static IP per camera works as well. The port side of the same problem is covered in assigning cameras to ports reliably. For Camera Link and CoaXPress the channel is a physical connector on a named board: open interfaces by the board's device ID plus connector index, never by discovery order — the mechanics are in frame grabber image acquisition for Camera Link and CoaXPress.
Cut the board count, cut the risk
A single board cannot swap order with itself — port-to-channel mapping on one board is fixed by the connector. Every additional identical board multiplies the ways an upgrade can reshuffle you, so when a cell grows past its board count, consolidate instead of adding a third board. CoaXPress concentrates the most channels per board: CXP-6 moves 6.25 Gb/s per coax, about 625 MB/s of payload before protocol overhead — call it 600 MB/s usable — so an octo-port CXP-6 board carries a complete camera set on one enumeration unit. The MV-GX1008 is that kind of board. A quad-port 10GbE board such as the MV-GT2104 does the same for high-resolution GigE-family sensors.
Compare the consolidation options directly:
| Specification | MV-GE1104 | MV-GT2104 | MV-GX1008 |
|---|---|---|---|
| On-board memory | 512MB DDR3-RAM | – | 4 GB DDR4-RAM |
| Interconnect | PCI-E gen2 ×4 | PCI-E gen3 x 8 | PCI-E gen3 × 8 |
| Delivery bandwidth | 860 MB/s (peak bandwidth), 800 MB/s (sustained bandwidth) | 7800 MB/s (max. transmission bandwidth); 6700 MB/s (sustained transmission bandwidth) | 7800 MB/s (max. transmission bandwidth); 6700 MB/s (sustained transmission bandwidth) |
| Bus status indicators | 3 | – | 1 |
| Standard | GigE Vision | IEEE802.3 | CoaXPress 1.0/1.1 |
| Interface | 4 × RJ45 | RJ45 × 4 | DIN 1.0/2.3 × 8 |
| Camera type supported | GigE industrial camera | 10 GigE industrial camera | CXP-6 connector industrial camera |
| Camera quantity supported | 4 at most | 4 at most | 8 at most |
| Camera connection speed | 1 Gbps | 1000/2500/5000/10000 Mbps | 1.25/2.5/3.125/5/6.25 Gbps (CXP-1/2/3/5/6) |
| Stream | 4 | 4 | 8 |
| Stream status indicators | 4 pairs | – | 8 |
| Jumbo frame | 2/4/8 KB | 9 KB | – |
| Price | $699.00 | $1,429.00 | $1,949.00 |
All 3 share: Humidity 10% RH to 95% RH (no condensation). Values as printed in each product's data sheet; open a part for its drawing and full specifications.
Before you restart production
- Channel map proven: every application channel paired with a camera serial by the dark-frame test, one line per channel on the cell drawing.
- Cold-boot check passed: full power-off and power-on, then the board order confirmed again. A warm reboot often keeps assignments; a cold boot re-runs the scan that bites you on Monday.
- Driver version recorded for every board, so the next upgrade's driver swap is visible before it surprises you.
- I/O re-mapped and tested with a real part, not a software toggle.
- Serial binding live in the application, with the board serials on the cell drawing.
- Cable labels at both ends match the drawing.
Make this pass a standing item after every upgrade — the full sequence is in the machine vision software upgrade validation checklist. If the cell is growing or boards are being replaced anyway, start at the frame grabber configurator step, browse the frame grabbers or the accessories finder, and bring mapping questions on your exact boards to the contact page.
Questions
Why did the camera channels swap when no hardware was touched?
Because the order was never a property of the hardware. The application addressed cameras by enumeration index, and that index is recomputed from the PCI bus scan plus installed driver state at every boot. The upgrade replaced or rebound the frame grabber drivers, which cleared the stored device associations, so the boards came back in a new order. Cabling, boards and cameras are all healthy; only the numbering moved.
Can the order be fixed without physically removing the boards?
Usually, yes. Disable the extra boards in Device Manager instead of pulling them: uninstall every grabber's driver entry, disable all but the board that must be first, boot and bind that board, then enable the next and repeat. Physical removal is the fallback when a board will not hold its place between boots.
Does moving a frame grabber to a different PCIe slot change its channel numbers?
It can. Enumeration follows the bus scan, so a board in a different slot reports a different bus, device and function address and can change position in the discovery order. If the application binds by board serial and connector number, the channels stay correct wherever the board sits. If it binds by discovery index, treat a slot move exactly like a driver upgrade: rerun the channel test before releasing the cell.
How do I identify which camera is on which channel without tracing cables?
Run every camera live and drop one camera's exposure to its minimum — 20 µs at normal room lighting with the strobe off. That channel goes black while the others keep imaging; record the channel against the camera's serial, restore the exposure, and move to the next camera. Budget about a minute per camera. A lens cap works too, but the exposure method needs nobody at the cell.
Is one octo-port frame grabber better than two quad-port boards?
For channel stability, yes. Port-to-channel mapping on a single board is fixed by the connector, and a board cannot swap order with itself, so one enumeration unit removes the failure class. Two or more identical boards are precisely the configuration that reorders after a driver change. The trade is port bandwidth and a single point of failure, so check each camera's line rate against the port standard before consolidating.