Connect multiple 3D cameras to one PC: sequence and IP rules

Three 3D cameras on one PC work when you fix two things up front. Give each camera a unique static IP on its port's subnet — for example camera 1 at 192.168.1.11 and camera 2 at 192.168.1.12, both with a 255.255.255.0 mask — and enumerate and connect every camera sequentially from a single thread.

Both failures that most integrators hit on day one, a second camera that refuses to open or a discovery pass that crashes mid-list, trace back to those two rules that 3D camera SDKs enforce everywhere. Two threads that list together race for the same hardware, and two cameras sharing one address answer the same call.

Get the plan right and one worker thread per camera captures in parallel afterwards. This guide gives the bring-up order, the IP plan with real addresses, the bandwidth arithmetic that decides how many cameras one network card carries, and the checks to run before the cell goes live.

Why do multiple 3D cameras collide on one PC?

Collisions come from two shared resources: the enumeration step and the address space. Listing cameras is not read-only — the SDK briefly opens every unit to read its serial number and firmware version, so two threads that list together race for the same hardware, and two cameras sharing one IP answer the same call.

A 3D camera accepts exactly one connection at a time, which is why the list call opens each unit: that is how it reads the details it shows you. Two enumerations at once therefore end in an access error, a half-opened unit, or a device list that repeats one camera twice. The same one-connection rule produces the other classic symptom: units straight out of the box often carry the same factory IP, so the second camera on the bench answers on an address the first one already owns.

When a camera disappears after another connects, you are seeing one of these collisions, not broken hardware. The network camera discovery troubleshooting guide walks the same diagnosis for GigE cameras, and duplicate PoE camera discovery covers the address clash itself.

What order to connect, address and start several 3D cameras in

Address the cameras first, connect each one from a single thread, and only then start per-camera workers — the rule the whole design hangs on is sequential connect, parallel capture. The connect phase costs seconds even for four cameras, so there is nothing to gain by parallelizing it, and every SDK race lives exactly there.

1. Wire one camera to the PC or switch and power it alone. Set its static IP inside its port's subnet, and write the serial number next to the address in a table.
2. Repeat per camera, one powered at a time, so no two factory-default addresses fight on the wire.
3. In one thread, enumerate once, then open every camera by serial number. Selecting each depth camera by serial number is the reliable handle precisely because addresses can change.
4. When the last camera reports connected, spawn one worker thread or process per camera and start capture. From this point the workers run fully in parallel.
5. Treat firmware updates as exclusive, sequential operations — one unit at a time, never during discovery.

Repeat the single-threaded connect at every application start, not only on commissioning day: enumeration is a start-up phase, not a one-time setup. An architecture drawn this way needs no locks around connection, no retry loops around discovery, and no surprises when a worker restarts.

Which IP addresses do multiple 3D cameras need?

Every camera needs an address unique on its own port's subnet, and two network cards on one PC must sit on different subnets. Plan 192.168.1.x for NIC 1 and 192.168.2.x for NIC 2, all static — never DHCP on a production cell.

The two-subnet rule comes from routing, not preference: the operating system picks the outgoing interface by subnet, and two cards sharing one subnet leave the return path ambiguous, so packets leave by the wrong port or never arrive. Gateway fields stay empty on camera ports — nothing on a camera VLAN should route toward the office network.

Jumbo frames belong in the same commissioning pass. Set a 9,000-byte MTU on every camera, NIC and switch port in the path; a size mismatch stays invisible until the cell runs flat out, where it surfaces as fragmentation and receive errors.

How much network bandwidth does a multi-camera 3D PC need?

One gigabit port carries about 115 MB/s of usable payload — the 125 MB/s line rate less roughly 8% of headers and packet gaps. Budget each camera as bytes per frame times frame rate, keep the sum under that figure, and split ports before you buy anything faster.

Worked example, with an illustrative frame size to swap for your camera's resolution: a 2,048 × 1,536 depth map at 16 bits holds 2,048 × 1,536 = 3,145,728 pixels, so 3,145,728 × 2 bytes = 6,291,456 bytes, about 6.29 MB per frame. At 10 fps the camera streams 62.9 MB/s. Structured-light cameras usually return a matched intensity image with the depth, which doubles the figure to 125.8 MB/s — past the 115 MB/s the port actually carries. Two such cameras on one card lose frames from the moment the second starts; the fix is one camera per port, not a bigger switch.

What moves the number: frame rate and pixel depth scale the stream linearly, jumbo frames lift the usable share by a few percent, and retransmissions on a noisy plant network pull it down. USB 3D cameras live under the same arithmetic with a different ceiling — a 5 Gbit/s line rate becomes 4 Gbit/s after 8b/10b encoding and roughly 400 MB/s after protocol overhead, shared across the controller's ports — and the USB camera bandwidth and power budget guide works that side in full.

Frame-based structured-light 3D cameras size exactly this way, because depth and intensity arrive as whole frames. The MV-DPS200P-02 projected structured-light 3D camera is a representative unit: budget its port from the frame rate and pixel depth you actually run.

How do laser profilers fit into a multi-camera 3D PC?

Profilers are easy on bandwidth because they stream a line, not a frame: at 1,000 profiles per second with 1,280 points per profile at 4 bytes of height each, one camera carries 5.12 MB/s, and three profilers share a single gigabit port with room to spare.

The profile rate comes from your motion, not the camera: a part travelling at 100 mm/s that needs a profile every 0.1 mm asks for 100 ÷ 0.1 = 1,000 profiles per second. Bytes follow: 1,280 points × 4 bytes = 5,120 bytes per profile, and 1,000 × 5,120 = 5.12 MB/s. Three sensors together take 15.4 MB/s of the port's 115 MB/s, which is why profiler cells rarely need more than one gigabit NIC even with several units running.

At the far end of the scale the picture inverts. The MV-HLVS-16K100-L60 line-scan 2.5D inspection system pairs 16K resolution with a 120 kHz sampling rate across a 600 mm emitting area.

Scale that line up and the stream changes class: 16,384 pixels × 120,000 lines per second × 1 byte per pixel minimum is 1.97 GB/s, an order of magnitude past any Ethernet port. Systems of this kind therefore arrive as matched capture systems with their own pipeline — plan one as a station of its own, and apply the sequential connect and unique-IP rules to the frame and profile cameras you add around it.

For discrete parts on a conveyor, a profile sensor joins the same bring-up as any other camera: assign its address, connect it once from the set-up thread, then let its worker stream profiles for the shift. The MIS-DP3850-01P 3D laser profile sensor is the pattern in a single unit.

Can several threads or processes share one 3D camera?

One camera holds exactly one connection: a second process cannot open it while your capture process owns it, and two threads that enumerate at the same moment collide while each tries to read serial and firmware from the same units.

Sharing done right means division of labour, not a shared handle mid-set-up. After the single-threaded connect phase, one worker thread per camera is the portable pattern: each worker calls capture on its own unit and the workers run in parallel. Recent 3D SDK releases also allow several threads to operate one already-connected camera — useful when one thread fetches while another converts — but older stacks make no such promise, so the threading notes of your SDK decide that variant.

Two processes work cleanly on one PC as long as each owns its own camera and neither enumerates while the other is listing. Start them staggered by a second or two, or let the first process signal once its set-up phase completes.

Firmware is the strictest case, because an update holds the camera's only connection for minutes. Run updates strictly one unit at a time: start one, wait for completion, reconnect, confirm the new version, then move to the next camera. Listing cameras while an update runs is the same collision — the list call meets a unit that is mid-flash.

A mixed fleet changes none of this: a laser galvanometer stereo camera such as the MV-DLS300P-04 just occupies one more row in the same table — address, connect once, one worker, capture.

When is one PC the wrong choice for multiple 3D cameras?

Split the fleet when one of three budgets fails: the summed stream passes the port budget from the worked example, per-camera processing saturates the CPU, or the robot cannot wait behind a shared host. A second port or a second PC costs less than a week of chasing dropped frames.

The bandwidth half is the easy one: a quad-port NIC with subnets 192.168.1.x through 192.168.4.x carries four saturated links without touching a line of code. The half people forget is CPU — every depth frame becomes a point cloud that needs filtering, matching or defect checks, and three cameras at 10 fps can load the converter harder than the network. On latency-critical stations, robot guidance over a moving line, a vision controller per station keeps each capture loop off the shared host entirely.

When several cameras must see one part from different sides, the job does not end at capture: the clouds need registration into a single model before you measure anything. That pipeline has its own guides — start at merging multiple depth frames into one gap-free point cloud and merging point clouds from multiple viewpoints.

What to check before go-live

Five checks catch nearly every multi-camera fault before the cell runs: unique addresses per port subnet, one enumeration pass, one connection per camera, a bandwidth sum under the port budget, and jumbo frames end to end. Run them with the real cables, switch and power budget in place.

• Ping each planned address from a clean command line. Anything that answers before the intended camera is connected is a clash or a stray device on the camera VLAN.
• Enumerate from a fresh process and count. Three cameras ordered means three cameras listed — a repeated serial or a missing unit means the address plan has a hole.
• Open every camera in one thread, start every worker, and capture one frame set with timestamps. If the workers queue behind each other instead of running in parallel, the timestamps show it immediately.
• Enable 9,000-byte jumbo frames on camera, NIC and every switch port, then run a ten-minute soak and watch the NIC receive-error counter. It must stay flat.
• Log the firmware version of every unit at start-up. Identical units on different versions explain most works-on-the-backup-PC mysteries.

The decision in one line: address first, enumerate once, one connection per camera, then parallel workers — and add ports before you add cleverness. Choose the sensors in the 3D sensors category or step through the configurator below; the camera finder filters by resolution and interface, and free expert support comes with every order. More multi-camera capture and integration fixes sit on the 3D topic page.