GigE camera red X error in your vision software: a fix plan

A GigE camera that streams perfectly in the maker's own viewer, then appears in your acquisition software with a red X — or throws “unable to get attribute”, error 0xBFF69011 in one widespread driver — is the most common integration call we get. The camera is rarely broken. The red X means your software enumerated the camera but could not open its control channel, and four things cause that: another program holding the camera, NIC settings that do not match, a firewall rule, or one invalid register value inside the camera. This guide works through them in probability order, with the numbers that decide each — the subnet plan, the packet size, the firewall port, and the user-set save that keeps the fix after power-off.

Why does the camera work in the maker's viewer but show a red X in your software?

Because another program still holds it: GigE Vision allows exactly one controller on the camera's GVCP control channel, and a viewer that only looks closed — a system-tray process or a background service — keeps that channel and blocks your software's open call. Your software listed the camera, so discovery worked and the cable, power and IP address are at least partly sane. What failed was control.

Close every vision program on the PC, check the system tray and the Processes tab of Task Manager for anything from the camera's maker, then power-cycle the camera so the channel is guaranteed free. Open your software first, before anything else touches the camera.

The exclusivity rule crosses platforms: a robot controller or an HMI that polled the camera on the same network counts as the other controller too. If your second controller is a robot rather than a PC, configuring a GigE Vision camera on a robot controller runs through the same checks from the robot side.

What NIC settings does a GigE camera need?

A static IPv4 address in the camera's subnet — NIC at 192.168.10.1 with mask 255.255.255.0 for a camera holding 192.168.10.254 — with DHCP off, jumbo frames on, and adapter power saving disabled. Check the camera's current address first: most ship in link-local mode, where the camera self-assigns an address in 169.254.x.x, and your NIC must sit in that same range to reach it. The cleaner long-term fix is a persistent IP plan — one NIC per subnet, each camera at a fixed address, written on the machine's network drawing. If you are still choosing hardware rather than debugging it, GigE Vision camera selection: bandwidth, cables and software covers the whole plan.

In the Advanced tab of the adapter, set the jumbo frame to the largest value offered, raise receive buffers and receive descriptors from their defaults, switch interrupt moderation off, and switch “Energy-Efficient Ethernet” and “Green Ethernet” off — both save power by dropping packets. In the Power Management tab, clear “Allow the computer to turn off this device”. Leave speed and duplex on auto-negotiation; a forced mismatch creates exactly the intermittent red X you are chasing.

What packet size should you set, and why do frames tear without it?

Set the camera's packet size to 9000 bytes and the NIC's jumbo-frame setting to at least that value — 9014 bytes on most adapters — and the packet rate on the link drops about six-fold at any given frame rate. The arithmetic for one thermal camera:

The LS-IRC-0044 outputs 640 × 512 pixels at 50 Hz over GigE. Assume 2 bytes per pixel of radiometric data, the usual 16-bit format. One frame is 640 × 512 × 2 = 655,360 bytes, about 0.66 MB. At 50 frames per second that is 0.66 MB × 50 = 32.8 MB/s, near 262 Mbit/s — roughly a quarter of one GigE link, which tops out near 115 MB/s usable after protocol overhead.

Packets tell the story. At the default 1500-byte packet size, 32,800,000 bytes per second ÷ 1500 ≈ 21,900 packets per second cross the NIC. At 9000 bytes the same video is 32,800,000 ÷ 9000 ≈ 3,600 packets per second. Fewer interrupts, fewer dropped frames, lower CPU load — that is the whole case for jumbo frames in machine vision.

Two failure signatures point straight at packet size: an image torn along a diagonal line, or a grey band across the bottom of a frame, both from packets the link dropped. If they appear, set the packet size before starting acquisition, and remember that every switch between camera and PC must carry the same jumbo size, or it silently trims packets back to 1500.

Is the firewall blocking the camera?

Very possibly: Windows Firewall drops GigE Vision control packets on UDP port 3950 by default, so your software can ping the camera yet fail discovery or attribute reads — a camera-specific exception for that port and your application fixes it. Test it in one minute: switch the firewall off for the camera adapter's profile only, and re-open the camera. If the red X clears, switch it back on and add two exceptions — inbound and outbound UDP 3950, plus an allow rule for your vision application's executable, because the image stream (GVSP) uses dynamically assigned high ports you cannot pin to one number. Check which profile Windows gave the adapter, too: an adapter labelled “Public” gets the strictest rules, and dedicated camera NICs are often classified Public.

The pattern “ping works, discovery fails” gets a full walk-through in GigE Vision camera firewall: ping works, discovery fails.

What is error 0xBFF69011, “unable to get attribute”?

It means the camera answered but one register holds a value your driver cannot parse: certain thermal camera batches left the factory with an invalid value in a single register, and every generic GenICam read of that feature fails while the maker's own viewer, which never reads that feature, streams normally. The transport standard guarantees the camera will answer; it does not guarantee every feature value parses. For what generic software may rightly expect, see what GigE Vision guarantees for camera compatibility.

The cure needs any generic GigE Vision player — every camera and frame-grabber maker ships one, and all speak the same GVCP protocol:

1. Open the camera in the player. A red X on the device or its control tree marks the fault.
2. Walk the feature tree to the node flagged invalid, or to the one the error names.
3. Correct the value — copy it from an identical camera that works, or use the valid range the node itself prints.
4. Write it, confirm the red X clears, then save it as described next, because a bare register write dies at power-off.

How do you make the fix survive a power cycle?

Save the corrected values into a user set and make that set the power-on default: set UserSetSelector to UserSet1, run UserSetSave, then set UserSetDefault to UserSet1 so the camera loads your values at every boot instead of the faulty factory ones. Register writes are volatile, which is why this fault “comes back” after the weekend: the camera reloaded its stored set and the invalid value returned with it. After saving, pull power for ten seconds, let the camera reboot, and confirm the attribute reads back correctly in your software before the camera goes somewhere hard to reach. The habit generalises — checking saved settings and readback at startup applies to exposure and trigger settings exactly as it does to register fixes.

How do you run two cameras on one computer?

Give each camera its own NIC and subnet — camera 1 at 192.168.10.254 on a NIC at 192.168.10.1, camera 2 at 192.168.20.254 on a NIC at 192.168.20.1 — and reserve a shared single-NIC set-up for camera pairs whose combined stream stays under about 100 MB/s. The budget decides it. Two thermal cameras at 0.66 MB per frame and 50 Hz each total about 66 MB/s; they share one NIC without strain. Resolution changes the answer fast. The LS-CMR-0053 is a 12 MP GigE area scan camera running at 9 fps. At one byte per mono pixel, 12 MP is about 12 MB per frame, and 12 MB × 9 fps ≈ 108 MB/s — essentially one whole GigE link, so a camera of this class gets a NIC to itself.

Two NICs also keep the control channels tidy: discovery broadcasts stay on their own adapters, and one camera rebooting cannot stall the other's stream. To keep the mapping stable across reboots, assign cameras to ports reliably in a multi-camera system; if both cameras answer the first discovery burst at power-up, that start-up contention is covered in multi-camera discovery contention.

What proves the camera itself is faulty?

Only failing everywhere: the camera must refuse in the maker's own viewer, on a second PC, with a different cable and a measured supply — four variables changed and still no image — before you treat the red X as a hardware fault. Work the list in order, cheapest first:

• Power. Measure at the connector under load. A camera that enumerates and then drops is usually seeing low voltage, and long thin power leads cause it.
• Cable. Swap in a known-good industrial cable with locking screws; office patch cords and vibration do not mix, and copper GigE is only rated to 100 m. The LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks.
• Second port, second PC. A different NIC rules out the adapter's settings; a different PC rules out its software stack. If the fault follows the camera across both, it is the camera — camera fault isolation for repeatable unit-specific failures lays out the method.
• Software pair. One maker viewer and your acquisition package, nothing else running, firewall excepted per the test above. This is the clean-room condition every support engineer asks for first.

If the camera passes all four and your software still shows the red X, the residue is a software-stack issue: GigE Vision camera software compatibility checks lists what to compare, and the systems topic page collects more integration notes. Replacement cameras, cables and NICs are one finder away — infrared cameras, area scan cameras, camera cables and the full camera finder — and we will gladly look at the set-up with you. When a new camera enters the picture, the system configurator starts at the camera step.