Multiple vision software instances: one camera per process

Running several copies of your vision software keeps inspections logically separate: one recipe for the code read, one for presence, one for measurement, each with its own tolerances and fail states. That pattern works on a frame grabber because every input is its own device. On GigE and USB cameras it has one hard limit: a camera opened by one process cannot be opened by another. This explainer gives you the rule, the per-instance configuration and startup order that make multiple instances reliable, a worked bandwidth check for a three-camera cell, and the alternatives when two inspections need the same view. Follow it before splitting a single-camera program into instances and you avoid the two classic failures: instance two grabbing instance one's camera, and a link that saturates at full frame rate.

The rule: one camera, one process

A GigE Vision camera is a small server: one control channel that sets exposure and trigger, and one UDP image stream that goes to a single client. Toolkits that implement the standard open both exclusively. Once your first instance has opened the camera, a second instance's open call fails at the driver layer, before your inspection code ever runs — usually reported as a device-busy error or a start-acquisition timeout. USB3 Vision behaves the same way: the host driver allows exactly one owning process per device. There is no sharing mode, and that is by design rather than a licensing restriction.

So plan one camera per instance. If you need N logically separate inspections, you need N distinct devices, or one process that owns a camera and feeds the others (covered below). What GigE Vision compatibility between cameras and software guarantees is interoperability, not multi-client access to a single camera.

One exception exists on paper: cameras that expose several stream channels. A toolkit can only use them when the driver lists each channel as its own device — then channel two behaves like a second camera with its own port. Most drivers do not list them that way, so treat extra streams as a bonus when they appear in the device list, never as the plan.

Name each camera, never "the first one found"

Give every instance its own driver configuration file, and inside each file name the camera by a unique identifier: MAC address, serial number, IP address or a user-set device ID. Never bind an instance to "camera 0" or "the first device found", because enumeration order is whatever discovery returned this boot — it changes with power-up order, cabling and switch topology. The failure is ugly: after a power cycle at 3 a.m., instance two binds to instance one's camera and both inspections run on the wrong view. Device order haunting a multi-camera setup is the same class of problem as swapped channels when frame grabbers enumerate differently, and on Linux, USB cameras add their own device path conflicts.

On the network side, give each GigE camera a static IP and put each network interface on its own subnet — one camera at 192.168.1.10 on the first interface, the second at 192.168.2.10 on the second. Static addressing keeps discovery deterministic and keeps each camera's traffic on its own link.

The port-0 trap and startup order

Even with correct files, one trap remains. Several GenICam-style drivers open the first device in the enumeration — port 0 — even when the configuration file names a different port, then switch to the configured port after that first open succeeds. The detour is invisible while port 0 is free. Once another instance owns port 0, the momentary open fails and your instance refuses to start while its own camera sits idle.

Two fixes, and you should apply both:

1. Enable the driver option that opens the configured port directly — commonly an autoswitch or direct-open flag — so no port-0 detour happens at all.
2. Set the start-up order anyway: launch the instances on higher ports first, the instance that owns port 0 last. It costs nothing and covers drivers that lack the flag.

The order also matters after a crash, so put the sequence in the start-up script rather than launching instances by hand.

Worked example: three instances, three cameras, one host

A filling line runs three inspections at one operator station: a code read on the carton top, a presence check under the cap seat, and a measurement taken during an indexed pause. The code read uses the LS-CMR-0053, a 12 MP GigE camera; the presence check uses a second unit of the same model. The measurement step uses a 20 MP USB3 camera, the MV-CS200-10UM.

Both GigE cameras run at 7.5 frames per second and the USB3 camera at 5. Eight-bit mono keeps a pixel at one byte:

• Camera 1: 12,000,000 pixels × 1 byte × 7.5 fps = 90 MB/s.
• Camera 2: 90 MB/s by the same arithmetic.
• One 1 Gb/s interface: 1,000,000,000 bits ÷ 8 = 125 MB/s theoretical; budget 100 MB/s after UDP, IP and stream-packet overhead.
• Combined on one interface: 90 + 90 = 180 MB/s, which is 80 percent past the budget.

Decision: one network interface per GigE camera. Each link carries 90 MB/s against a 100 MB/s budget and passes. A shared link fails at full rate — often not during commissioning, when the line runs slowly, but on the first full-speed shift. The USB3 camera needs 20,000,000 × 1 × 5 = 100 MB/s; the USB3 line rate of 5 Gb/s is 500 MB/s after encoding, roughly 350 MB/s usable in practice, so it fits on the host's USB controller with margin — the same arithmetic that governs several camera modules sharing one host bus.

Timing closes as well: 7.5 frames per second leaves 133 ms per frame, so a 5 ms exposure on moving cartons leaves more than 125 ms for readout and transfer. Assign ports by MAC address, put the code-read camera on port 0, and start the presence and measurement instances first, the code-read instance last.

Thresholds to carry forward: above roughly 100 MB/s of combined camera traffic, one 1 Gb/s link is out; above roughly 1,000 MB/s, move to 10GigE. When one camera alone exceeds that, CoaXPress is the interface; the MV-CH250-90YC-M58S-NN is a 25 MP CXP-12 example. Turn jumbo frames on at camera and NIC before trusting any of these numbers, because standard-size packets raise per-packet overhead enough to pull a link below its budget.

The host follows the same discipline: one settings folder and one network buffer set per instance, CPU cores reserved the same way the link budget above is. Outside vision the pattern repeats — running multiple Ignition instances side-by-side on the SCADA side and running multiple WinCC Flexible runtime instances on the HMI side both come down to one configuration per instance and separated resources.

When two inspections need the same view

Sometimes two logically separate inspections look at the same face of the part — a code read and a print check on the same label. Three routes, in order of preference:

One instance acquires and distributes. One instance owns the camera and writes each frame to shared memory or a local stream; the second inspection subscribes. A 6 MB frame copied at 10 GB/s of memory bandwidth takes 0.6 ms, so the subscriber runs effectively live. Many toolkits ship this as an image server or frame-replication feature; if yours has one, that is the supported multi-consumer path — and note it is still one camera per process, with the relay as the owner.

Two cameras, side by side. Simple to add, harder to align: the views differ by parallax, so checks that must share a pixel grid — one measuring what the other reads — cannot be split this way. Feature-independent checks can.

One instance, two jobs. If the "two inspections" differ only in thresholds, one recipe with two tool chains beats every option above.

When the inspections are truly unrelated, the cleanest split is not software: a smart camera per inspection, each with its own sensor, lens and light, reporting pass/fail over Ethernet. The LS-SMC-0063 packs a 1.6 MP sensor and a 16 mm lens — acquisition, decision and communication in one housing. You give up the shared image, which for unrelated checks you never wanted. If instead one camera must cover several stations, the trade-offs of serving multiple stations with one camera are about resolution and coordination, not device access.

Choosing the route

Checks before you commission the cell

• Every instance's configuration file names its camera by MAC address, serial number or user-set ID, never by enumeration position.
• Direct-open enabled where the driver offers it, and the port-0 instance starts last in the start-up script.
• Each GigE camera on a static IP, each interface on its own subnet, jumbo frames on at both ends.
• Every instance soaked at full production frame rate for half an hour, dropped-frame and resend counters flat.
• Kill test: stop the port-0 instance, restart it while the others run, confirm it rebinds to its own camera and the others never miss a frame.
• Power-cycle test: cut camera power, restore it, confirm every instance rebinds to the right camera.
• If no camera appears at all, a ping that succeeds while discovery finds nothing points at the transport layer, not at your files.

Once the camera count is fixed, the camera finder filters area scan cameras by interface and resolution, and the system configurator walks camera, lens, light and controller in one pass. For a multi-camera cell, send the camera list and target frame rates through the contact page and we will check the link budget with you.