GigE camera not detected in MAX on a cRIO RT target

The camera is powered, both link LEDs are lit, and the driver modules show as installed on the controller — yet the device list in MAX stays empty. This page is for that exact fault: a GigE Vision camera wired to the secondary Ethernet port of a compact real-time target such as a cRIO-9082, where the camera never appears under the target's devices. The fix is almost never another installer. Camera discovery is a network event, and on an isolated port it fails silently. Work down the four causes below in order — subnet, filtered discovery, driver match, port hardware — test each with the check given, and the fault usually shows itself in minutes. The last sections budget the port and set the packet size so the camera keeps streaming once it appears.

Look under the target's own device list first

MAX keeps one device list per system, and the camera in this set-up is on a private network your PC is not part of. It hangs off the target's secondary NIC, so it can never appear under your local machine's devices, and no host-side reinstall will change that. In the configuration tree, expand the remote real-time target and open its own devices-and-interfaces branch: that is the list the target's driver fills. If the target itself is missing from the tree, fix that first — it is a separate fault on the office network, and the walkthrough on adding a remote cRIO target in MAX across different subnets covers the addressing it needs.

Why discovery fails quietly on an isolated port

The driver finds cameras by sending a discovery broadcast — GigE Vision control packets on UDP port 3956 — out of each of its own network interfaces, and every camera on that subnet answers. A camera with no persistent IP and no DHCP server available falls back to a link-local address in the 169.254.x.x range. Put the two facts together and the classic failure appears: the secondary NIC holds a static 192.168.x.x address while the camera sits at 169.254.x.x, so the broadcast goes out on a subnet where no camera lives and the question is simply never asked. Ping will not catch this, because ping is a directed unicast test between two known addresses; GenICam discovery uses subnet broadcast: why ping is not enough shows what the driver actually sends and why the answer can be missed.

The four causes, in the order to test them

Test in this order; each check takes a minute and rules out a whole branch.

1. Subnet mismatch. Match the NIC to the camera's addressing. A factory-fresh camera on link-local wants a 169.254.x.x address with a 255.255.0.0 mask on the secondary NIC; a planned station wants a static pair such as NIC 192.168.10.1 and camera 192.168.10.5 with a 255.255.255.0 mask and an empty gateway field. Refresh the device list under the target after the change.
2. Filtered discovery. Ping now works but the list stays empty, so something drops the broadcast or its reply. On a bench PC that is the OS firewall: allow UDP 3956 in and out on the camera adapter, or leave the dedicated camera NIC unfiltered. On the target path, audit switch ACLs and VLAN boundaries between camera and port. GigE Vision camera firewall: ping works, discovery fails works through that exact split, and GigE Vision firewall troubleshooting for missing images extends it to the stream side.
3. Driver mismatch between target and host. An incompletely installed driver leaves the device list empty, so note the module versions on both machines and reinstall target and host from the same release line — a target can show IMAQdx 4.3.5.3.0 with Vision RT 13.1.0.3.2 while the PC runs a different generation. If the installer offers no separate IMAQ server component, leave it alone: enumeration happens at the network layer before any server component loads, and a successful ping from the target to the camera proves the remaining work sits at the discovery or driver layer, not the cable. The compatibility path is laid out in GigE Vision camera on an RT controller: driver support check.
4. Port, cable or power. Check link LEDs at both ends, swap the cable, then move the camera to a PC adapter set to the camera's subnet. It enumerates on the PC and not on the target: target-side fault, go back to causes one to three. It fails in both places: camera fault or service. A PoE-powered camera on a port without PoE stays dark at both LEDs — Does my camera support PoE: check the port before you buy shows the port check to run before wiring.

Bandwidth budget: one 2.5 MP, 8-bit, 30 fps camera on one GigE port

Inputs and where they come from: the 2.5 MP, 8-bit mono camera is the up-to-3-MP GigE class in the area scan camera catalog; 30 fps is the frame rate assumed for this example; 1 Gbit/s is what a GigE port provides; about 950 Mbit/s is the usable payload of a 1 Gbit/s link after Ethernet and IP overhead; the 10% allowance covers UDP/IP headers, GigE Vision packet headers and resends at the 1500-byte default MTU.

The rule: payload rate equals pixels per frame, times bytes per pixel, times frames per second, times eight bits per byte; add the protocol allowance; keep the planned load under 80% of the usable rate so heartbeats, resends and a second burst have room.

Worked through: 2,500,000 pixels at one byte each and 30 fps give 75 MB/s; times eight bits gives 600 Mbit/s of payload; the 10% allowance brings the plan to 660 Mbit/s. The threshold is 80% of the usable rate: 950 × 0.8 = 760 Mbit/s. The camera fits with 100 Mbit/s of margin and runs at about 69% of the usable line.

Decision: one camera of this class belongs on the secondary port alone. Two on one port plan 1,320 Mbit/s against 950 usable and do not fit, so a dual-port target such as the 9082 takes one camera per port — the port split described in Two GigE cameras on one host: NIC ports and bandwidth budget. Past the 760 Mbit/s threshold on any port, split cameras across NICs, cut frame rate or region of interest, or step up to a faster interface.

Once it appears: the stream port and packet size

Discovery and control share UDP 3956; the image stream does not. The camera announces its stream port during negotiation and the driver cannot know it in advance, so a filter that admits only listed ports drops image data while enumeration works fine — leave the camera NIC unfiltered, or permit the ephemeral range on a dedicated vision VLAN.

The same story continues at the packet level. The standard 1500-byte MTU works everywhere; jumbo frames raise it to a typical 9000 bytes, which cuts per-packet header cost from about 5% to under 1% and drops the packet count, and receive interrupts with it, by roughly six times. Set the camera's packet size and every NIC and switch MTU along the path to the same value — a mismatch corrupts frames rather than hiding the device, and it looks like partial images or timeouts. GigE Vision high performance NIC driver: how much you gain measures what host-side tuning adds, and troubleshooting IMAQdx buffer overflow errors covers the failure mode when the target cannot keep up with a stream it has accepted.

If the target keeps fighting you

Two honest ways out. First, isolate: the camera on a PC adapter with the PC set to the camera's subnet either enumerates — target-side fault, keep working the list above — or it fails there too, and the fault ships with the camera.

Second, remove the constraint instead of fighting it. A controller built for vision carries more network ports than a general-purpose target: the MV-VC3301H-128G66 vision controller lists 5+ LAN ports and 4 built-in light channels, so each camera takes its own port, its own subnet and its own slice of the bandwidth budget. Other models in the vision controller catalog add PoE camera ports.

At the camera end, any GigE Vision-compliant camera behaves identically at the discovery layer, so the network work on this page applies unchanged; a 2.5 MP global-shutter camera with C-mount like the MV-CU020-90GC is the class of camera these targets usually drive.

The port plan that prevents the next no-detect

Run these checks once, write the answers on the station sheet, and the next camera lands in minutes instead of days.

Addressing

• One subnet per camera port, written down — 192.168.10.0/24 for the first, 192.168.20.0/24 for the second. Discovery broadcasts stay inside their subnet, so a documented plan removes the silent mismatch.
• Static addresses on both ends of an isolated port, gateway empty. Nothing depends on a lease, and nothing renumbers itself at boot.

Filtering and software

• UDP 3956 permitted end to end, or the camera NIC unfiltered. Discovery, control and heartbeats all travel there.
• Target and host driver modules from the same release, versions recorded. An out-of-step install empties the device list without an error message.

Bandwidth

• Planned load per GigE port kept under the 760 Mbit/s threshold from the worked example. Headroom is what absorbs resends and bursts.
• Packet size moved from 1500 to 9000 bytes on camera, NICs and switches together, and only after first light. One variable at a time keeps the working state reproducible.

The systems topic page gathers the neighbouring troubleshooting guides.

When the target is not the problem

If the camera fails the PC bench test as well, stop working the controller: the device is faulty or it is not a GigE Vision camera at all, and no network change makes a non-compliant device enumerate — the identification steps are in GigE camera not detected: subnet and compliance checks first.

If the fault was never a fault but a capacity wall — more cameras than ports, or planned load past the 760 Mbit/s threshold — the answer is hardware, not debugging: filter GigE models in the camera finder, or compare LAN port counts across the vision controller catalog to pick a target with a port per camera. And when the list above clears the camera on the bench but the target still hides it, send us the target's installed module versions and the subnet table through the contact page — free expert support with every order covers exactly this kind of diagnosis.