GigE camera works in the vendor viewer but not in MAX

You install the acquisition software, open MAX, expand Devices and Interfaces, and the GigE camera that streamed all morning in its own viewer is simply not there. Refresh does nothing. This guide is for that exact combination: the camera enumerates and streams in the maker's viewer, so the camera, cable, NIC and physical link are all proven good. What failed is the discovery path the second tool uses. You will rank the five likely faults, split them with one capture filtered on gvcp, apply the matching fix, and finish with the camera listed, grabbing frames and ready for a production packet-size check.

What the viewer already proves

When the vendor viewer shows live pixels, five things are proven at once: the camera powers up, the link negotiates, the cable carries gigabit traffic, the PC NIC and its driver pass UDP traffic, and the camera's IP setting is reachable. Swapping the camera or recrimping the cable cannot fix a tool that misses a camera the same PC already sees.

So test only what the new tool adds on top: its own GigE Vision acquisition driver, the adapter it decides to enumerate, the subnet match between camera and NIC, and a firewall rule for its discovery traffic. The general adapter-layer case, any camera and any API, is covered in Camera detected but not in acquisition tool: fix the adapter layer; here we stay on the GigE discovery chain and its packet-level proof.

How MAX builds its camera list

Listing a GigE camera is a four-step broadcast exchange, not a port scan:

1. The tool loads its acquisition transport, IMAQdx for MAX, which speaks the GigE Vision control protocol (GVCP).
2. On each network adapter it watches, the tool broadcasts a DISCOVERY_CMD packet to UDP port 3956.
3. Every camera on that subnet answers with a unicast DISCOVERY_ACK carrying its model, serial, MAC, IP settings and whether another application already holds it.
4. The tool lists the cameras whose acknowledgements arrived on adapters it trusts.

These packet names come from the GigE Vision control protocol, and a packet analyzer's gvcp display filter shows every discovery exchange on the wire. Discovery rides on subnet broadcast, which is why a successful ping proves so little; the same reasoning is set out in GenICam discovery uses subnet broadcast: why ping is not enough.

Rank the causes, then split them with one capture

For this exact symptom, camera good in its own viewer and absent in the acquisition tool, the causes line up in this order:

1. Acquisition driver missing or not loaded. A fresh PC, a partial uninstall or an update that dropped the driver binding. The tool never sends a discovery packet at all.
2. Subnet mismatch. Someone followed a setup note, set the NIC to a private range that does not contain the camera's address, and the broadcast dies at the IP layer.
3. Firewall rule missing. Windows classifies the NIC as a public network and drops the inbound acknowledgement while the outgoing broadcast leaves fine.
4. Wrong adapter. Multi-NIC PC: the tool enumerates adapter 1 while the camera hangs off adapter 2.
5. Camera reserved. The vendor viewer is still open and holds GVCP control.

One capture splits all five. Start a packet capture on the NIC the camera uses, set the display filter to gvcp, press refresh or enumerate in MAX for about ten seconds, then stop and read:

The full chain from driver to packet is walked step by step in GigE Vision camera not detected in software: fix the enumeration chain.

Fix A: install the acquisition driver stack

MAX lists GigE cameras only through its GigE Vision driver, IMAQdx. That driver arrives with the vision acquisition software package, not with Windows and not with the camera viewer's own installer, so a machine that runs the vendor viewer happily can still have no IMAQdx at all. Check the software list in MAX: if the driver is absent, install the package, reboot, and let its services start before you open Devices and Interfaces again. The camera should then appear under Network Devices.

Two siblings of this fault have their own write-ups: a transport layer that never loads (Ping works, zero cameras: GigE transport layer not loaded) and software that misses the driver layer for any camera (Vision software can't find your camera: the missing driver layer).

Fix B: put the NIC and camera on one subnet

The setup note that circulates with these cameras sets the PC NIC to a fixed address and leaves the camera at its link-local default: 169.254.108.19 with subnet mask 255.255.0.0. Copy the network, not the address:

Worked example, with the AND applied octet by octet:

• Camera: 169.254.108.19 AND 255.255.0.0 = 169.254.0.0
• NIC right: 169.254.100.2 AND 255.255.0.0 = 169.254.0.0, same network, so the broadcast arrives
• NIC wrong: 192.168.1.10 AND 255.255.255.0 = 192.168.1.0, a different network, so the broadcast never reaches the camera

Any free 169.254.x.y address with mask 255.255.0.0 works, as long as the NIC does not duplicate the camera's own address. A direct camera-to-NIC link has no router, so gateway and DNS fields stay blank. If you would rather pin the camera itself, use the camera maker's IP configuration utility to give it a persistent address inside the NIC's subnet; when that tool throws an access error, the fix is admin rights, as in GigE configurator tool admin rights: fix the Windows error.

Fix C: let UDP 3956 through the firewall

The signature of a firewall fault is ping succeeding while discovery fails. Windows Defender Firewall treats a NIC it classifies as public far more strictly and can drop the inbound DISCOVERY_ACK while letting the outgoing broadcast through. Allow the acquisition software through the firewall for both private and public networks, or add one inbound rule for UDP port 3956 scoped to the camera's subnet, then refresh with the capture running: the ACK should appear and the list should populate.

The same pattern, with the settings that make discovery pass, is in GigE Vision camera firewall: ping works, discovery fails.

Fix D: point the tool at the right adapter

On a PC with two or more NICs, the tool enumerates only the adapters it is set to watch, and the camera hangs off one of them. Open the tool's network or adapter settings, enable the interface that carries the camera's subnet, and disable unused adapters so their empty subnets cannot confuse the list. Keep one camera subnet per adapter: two NICs both sitting in 169.254.0.0/16 make Windows route broadcasts out one of them only, and multi-adapter hosts are a known place for discovery broadcasts to be mis-routed. Planning two cameras on one host, one NIC each with the bandwidth math, is covered in Two GigE cameras on one host: NIC ports and bandwidth budget.

Fix E: close the viewer that holds the camera

GVCP allows one controlling application at a time, and the DISCOVERY_ACK tells every tool whether the camera is already reserved. Leave the vendor viewer open in live view and the acquisition software can refuse the camera or leave it out of the list rather than fight for control. Close the viewer completely, including any tray process, then refresh the device list in MAX; this costs nothing and explains the cases where the capture shows a healthy ACK for a camera the tool still will not display.

Verify before you close the ticket

The fix is done when all of these pass:

• DISCOVERY_CMD and DISCOVERY_ACK both appear in the gvcp capture while MAX refreshes.
• The camera is listed under Devices and Interfaces → Network Devices with its correct IP and serial.
• A test grab returns a complete frame, not a timeout.
• Frames arrive whole: if images show torn or missing lines, raise the packet size before you start acquisition, as in Set GigE camera packet size before starting acquisition, and check the MTU chain in GigE incomplete frames from a driver and NIC MTU mismatch.
• The camera still lists after a PC reboot, which proves the driver services start on their own.

More enumeration and link-layer fixes sit on the systems topic page.

When it is the cable or camera after all

A viewer-proven camera rules the hardware out for this symptom, with one exception: hardware failing intermittently shows up in every tool, including the viewer, as dropped links and freezes rather than a clean absence. If the link LED flickers, the viewer loses the camera mid-stream, or the camera vanished from both tools at once, swap the cable before anything else.

For the swap test and for the next station, use cable built for the job:

A 3 m high-flex GigE cable with screw locks survives drag chains and repeated swap tests. For longer runs, the LS-CBL-0117 is a 15 m RJ45 camera data cable with a locking stud:

The wider range of camera data and I/O cables covers other lengths and connectors. If the camera answers discovery on no PC at all, with a known-good cable and NIC and a dark link LED, the camera's network port is the genuine hardware suspect; that is the one path from this symptom to a replacement, and the GigE area scan cameras category or the camera finder is where to start comparing. Once the camera lists everywhere, set the packet size for production, and if a trace still reads oddly, send it to us through the contact page and we will read it with you.