3D camera link local address: configure both ends and wait

You wired a 3D camera straight to a PC — no switch, no DHCP server — and the camera sits with no address while your software lists nothing. That is exactly the case link local addressing exists for: when no server answers, both the camera and the PC interface self-assign an address in 169.254.0.0/16 and the link comes up on its own. Two things trip engineers. The camera only falls back after more than 45 seconds, and the PC side must be set up to self-assign too. This walkthrough sets the camera mode, configures both PC operating systems, and proves the link with one captured frame.

The decision first: which addressing mode the link gets

Choose the addressing from the physical link, not from habit.

For a bench set-up, a laptop, or a camera that moves between machines, commit to link local. Once a switch and several cameras are involved, DHCP for a 3D camera is the mode to run instead.

What must be true before the fallback fires

The camera's documented fallback behavior makes four conditions non-negotiable:

• The camera is in DHCP mode. A camera left in static mode waits forever; falling back is something DHCP mode does when nobody answers.
• No DHCP server answers on that segment. A router port, an internet-sharing feature or a dock network will happily serve the camera an address, and then you are debugging DHCP, not link local.
• The PC interface self-assigns as well: Windows through APIPA, Ubuntu through netplan's link-local option.
• More than 45 seconds have passed since the camera connected or powered up.

Addresses in 169.254.0.0/16 are never routed: no gateway, no crossing between segments. That is both the strength and the limit of the scheme — it works on exactly one physical link.

The bring-up, end to end

1. Plan the physical link. One camera on one PC interface, nothing between them. Gigabit copper covers 100 m per segment, so a bench lead is easy. With no switch in the path there is no PoE either, so plan the camera's own supply or a midspan sized to its power class.

2. Reach the camera once to set its mode. If the camera holds a static address today, give the PC interface a temporary address in that subnet so you can talk to it. Then switch it to automatic (DHCP) mode through any of the three routes an SDK gives you: the camera software's configure dialog, where you select the automatic mode and apply it; the command-line configurator that ships with the SDK, which takes the camera's current address and a DHCP flag; or the API, where you build a network-configuration object with IPv4 mode set to DHCP and apply it.

3. Windows: leave the adapter on DHCP. APIPA is enabled by default and only fires when DHCP gets no answer, so keep the adapter's IPv4 properties on automatic addressing. If that adapter ever picked up a lease, use the adapter's release function so nothing half-configured survives.

4. Ubuntu: enable link-local in netplan. In the netplan configuration for that interface, turn on link-local addressing for IPv4, apply the configuration, and confirm the interface is up.

5. Power the camera and start a 60 second timer. The camera requests DHCP, hears silence, and self-assigns; the PC interface does the same in parallel.

6. Read both addresses. The SDK's camera listing shows the camera's address; the interface status shows the PC's. Both must sit in 169.254.x.x with mask 255.255.0.0.

7. Open the camera by its address. The walkthrough on opening a link local camera by IP from Linux covers this step in detail, and the same logic applies on Windows.

8. Prove data, not just ping. An ICMP reply says the subnet works; it says nothing about the vision control port, a distinction the article on ICMP not being the control port works through. Capture one frame before calling the link done.

The arithmetic that proves the link

Say the camera self-assigns 169.254.37.9 and the PC adapter self-assigns 169.254.118.203 with mask 255.255.0.0. Test the two networks:

Both addresses land in the same /16, so the PC delivers packets straight out that interface with no gateway involved. On the clock: connect at t = 0 s, the camera finishes its fallback just past t = 45 s, and a first open attempt at t = 60 s carries about 15 s of margin.

Now the classic failure in the same arithmetic. The adapter still holds 192.168.1.10 with mask 255.255.255.0, so 192.168.1.10 AND 255.255.255.0 = 192.168.1.0, which is not 169.254.0.0. The PC has no route to the camera and every packet dies. One AND per address, two minutes of diagnosis.

Windows: the one mistake that blocks APIPA

The mistake is a static address left on the camera adapter. APIPA only fires from DHCP mode, so an adapter pinned to 192.168.x.x never self-assigns and the subnet test above fails exactly as shown.

The second blocker is a DHCP server you forgot about: internet connection sharing, a virtual adapter's bridge, or the office network the bench PC also jacks into. Anything that answers turns the exercise into finding a DHCP camera's address after every reboot instead.

Ubuntu: netplan and the stale configuration

Ubuntu leaves unconfigured interfaces bare, so the camera port needs its own netplan file with link-local addressing for IPv4 enabled. Check the existing netplan files before adding one — a leftover static entry on the same interface produces two configs fighting over one port. Apply the configuration, then read the interface state: a 169.254.x.x address next to the interface name is the pass condition.

If the address is right and the camera still stays silent, the 3D camera not pingable on a Linux controller checklist covers the subnet and link-level problems that sit below addressing.

When link local is the wrong answer

• Firmware updates. An updater often wants a fixed address and can refuse a camera in DHCP mode; why a static IP is needed for a 3D camera firmware update explains the mechanism.
• Addresses that must survive. If settings vanish after power cycles, read camera persistent IP not retained after a reboot before blaming the mode.
• Anything routed. 169.254.0.0/16 never crosses a router, so a monitoring PC on another subnet can never see a link local camera. Put shared cameras on the managed segment.
• Fixed production stations. Static wins, because nothing on a permanent line should ever move.

Parts for a direct link

A point-to-point link still needs a cable and power, and both are worth getting right once. Use a shielded GigE camera cable with locking screws: the LS-CBL-0199 is a 3 m high-flex GigE camera cable with screw locks, built for drag-chain use. For power, match the voltage on the camera's label; the LRS-75-48 is a 48 V, 76.8 W industrial power supply for 48 V loads.

Structured-light 3D cameras that live on exactly this kind of dedicated interface:

Browse the 3D sensors category or the camera finder for the full range, the cables category for other lengths, the power supplies category for other voltages, and the system configurator to build the whole station in one pass.

Checklist before first capture

• Camera mode set to automatic (DHCP) and applied
• No DHCP server on the segment: router ports, sharing features, dock networks
• PC adapter on the camera NIC in DHCP (Windows) or netplan link-local (Ubuntu)
• Both addresses in 169.254.x.x, mask 255.255.0.0
• 60 seconds waited from camera power-up
• One frame captured through the SDK, not just a ping reply

Each line is a two-minute check, and together they close the four failure modes that fill a first bring-up afternoon: wrong camera mode, a forgotten server, a PC interface that never self-assigns, and impatience with the 45 second fallback.