GigE Vision multicast receiver: control and stream setup

A camera stream can feed an inspection application, a recorder and a monitoring station without sending separate image copies across the camera link. Multicast makes that possible, but joining a multicast group does not turn an ordinary UDP listener into an image acquisition application. You still need software that understands the image transport and its configuration.

For engineers planning multiple receivers, the key decision is who controls acquisition and who only observes it. Start by confirming explicit multicast support in the camera and receiving software. Then define stream ownership, image reconstruction, network forwarding and acceptable behavior when a receiver misses packets.

Decide whether you need multicast

Use multicast when independent receivers need the same transmitted image stream and your camera, acquisition software and network support that arrangement. Keep one application responsible for camera configuration and acquisition commands. Let the other applications receive without competing for control.

A second receiver does not inherently need a second camera control session. However, its acquisition library may require a documented monitor or multicast-receiver mode. Some libraries query image metadata through a camera connection, while others accept enough configuration to receive without one.

The distinction matters: protocol capability does not guarantee that every acquisition package exposes the necessary operating mode. Start with the GigE Vision software compatibility checks, then ask specifically about multicast reception and control ownership.

Multicast is distribution, not synchronization between receivers. They can receive the same image identifiers yet finish processing at different times.

What a GigE Vision multicast receiver actually does

A generic UDP multicast listener joins a group and delivers datagrams to an application. A GigE Vision multicast receiver must also interpret the GigE Vision Streaming Protocol, commonly called GVSP, and reconstruct usable image buffers.

For a conventional image payload, that typically involves:

• Recognizing frame or block identifiers and packet identifiers.
• Interpreting leader information describing the transmitted image.
• Placing payload data in the correct locations within an image buffer.
• Detecting the expected frame boundary and completeness.
• Reporting missing, duplicate or out-of-order packets according to the library's capabilities.
• Exposing pixel format, dimensions and relevant payload metadata to downstream processing.

Receiving the expected number of bytes is not enough. Packed pixel formats, padding and optional chunk data can make a simple byte-to-image conversion incorrect. The receiver must support the actual payload type, not merely the UDP transport.

A packet capture showing incoming multicast traffic therefore proves only that traffic reached the capture point. It does not prove that the application joined correctly, reconstructed complete images or interpreted the pixel data correctly.

If your software already acquires images reliably in unicast mode, confirm that its multicast mode retains the same payload-format support. Changing the destination address should not become an accidental pixel-format change.

Separate camera control from passive reception

Camera configuration and image delivery serve different purposes. GigE Vision Control Protocol, or GVCP, handles camera access and configuration. GVSP carries the image stream. Receiving GVSP packets does not itself grant permission to change exposure, start acquisition or modify the destination.

The controlling application normally performs these tasks:

• Obtains the documented control access.
• Sets exposure, triggering and image format.
• Configures the relevant stream channel and destination.
• Starts and stops acquisition.
• Maintains any required control-session heartbeat.

A passive receiver joins the selected multicast group on the correct network interface and processes the transmitted stream. It should not attempt to take camera ownership merely to display images.

“Passive” also needs a precise definition. An application might avoid configuration writes while still issuing metadata reads or packet-resend requests. Another receiver might send no camera-directed traffic at all. Confirm which behavior your software implements and which behavior the camera permits.

Assign one owner for configuration changes. If several applications independently modify exposure or acquisition state, every receiver can experience unexpected changes even though multicast forwarding remains healthy.

Configure the stream and receivers as one system

The following sequence separates network reception from camera ownership without assuming that every software package uses the same menu names.

1. Prove ordinary acquisition first. Use the intended pixel format, image size, exposure and trigger source with one receiver. Record a working configuration before changing distribution.
2. Choose the controller. Identify the application responsible for acquisition commands, reconnection and restoring stream settings after a restart.
3. Reserve the destination. Select an administratively scoped multicast group and UDP destination port under your network policy. For example, an isolated test could use group 239.192.10.20 and destination port 50000, provided they are unused and permitted locally.
4. Configure the camera stream channel. Use the manufacturer's documented controls for multicast destination, destination port, packet size and transmission rate where supported.
5. Configure each receiver. Select its multicast-capable acquisition mode, local network interface, group and destination port. Supply any required stream metadata through the documented method.
6. Start the listeners before acquisition. This gives receivers an opportunity to join the group before image traffic begins. Verify how the software handles joining an already-running stream.
7. Start acquisition from the owner. Confirm that every receiver reports complete images with the expected format and image identifiers.

The receiver's local interface selection is particularly important on hosts with multiple network adapters. A valid group address does not help if the membership request or receiving socket uses the wrong adapter.

When a library opens the camera automatically, check whether that operation requests exclusive control. Read-only access, monitor access and entirely connectionless reception are not interchangeable capabilities.

Calculate the traffic before adding receivers

Multicast reduces duplicate transmission on the camera uplink. It does not eliminate traffic on receiver links or inside the switch. Each subscribed receiver still receives a complete copy.

For an unpacked image without additional payload data, estimate:

Consider a hypothetical stream with 2048 × 1536 pixels, Mono8 data and 20 frames per second. These are planning values, not specifications for any listed product.

The arithmetic is:

• Image payload: 2048 × 1536 × 1 = 3,145,728 bytes.
• Payload rate: 3,145,728 × 20 = 62,914,560 bytes per second.
• Decimal throughput: approximately 62.9 MB/s, or 503.3 Mb/s.
• Three receivers: 62.9 × 3 = approximately 188.7 MB/s of aggregate receiver payload.

The camera link carries approximately 503.3 Mb/s of image payload, not three times that amount. The switch distributes copies onto the subscribed receiver ports. Its internal forwarding capacity and any shared uplinks must accommodate the actual topology.

These figures exclude Ethernet, IP, UDP and GVSP overhead, additional payload metadata and any retransmissions. Leave operating margin rather than treating nominal link speed as usable image capacity.

Memory requirements also remain local to each receiver. Four image buffers in this example contain 3,145,728 × 4 = 12,582,912 bytes, approximately 12.6 MB, before library overhead and processing copies. Buffering can absorb a short scheduling delay; it cannot correct sustained processing overload.

For shared-link planning beyond this estimate, use the network congestion guide.

Check how the network forwards multicast

On a switched Ethernet network, Internet Group Management Protocol, or IGMP, communicates receiver group membership. IGMP snooping can help a switch forward multicast only toward ports that need it, rather than flooding unrelated ports.

Check the switch documentation for snooping, querier requirements and membership aging. A network can appear to work during a short trial yet lose forwarding later if its membership-management design is incomplete. Behavior depends on the switch configuration and topology.

Keep the first test on a deliberately simple network segment. Multicast across routed boundaries requires additional network support and is not established merely by choosing a multicast address.

Also verify:

• Receiver network adapters accept the selected multicast traffic.
• Host firewall policy permits the intended acquisition application and traffic.
• Packet size is supported across every relevant path.
• Shared uplinks have enough capacity for the replicated streams.
• Unrelated ports are not receiving unnecessary image traffic.

Use narrowly scoped firewall rules rather than disabling host protection. The GigE Vision firewall troubleshooting guide covers reception-policy checks. For separating acquisition traffic from unrelated plant activity, use the vision cell network isolation guide.

Choose hardware without assuming multicast support

An Ethernet interface or a GigE camera listing is not proof of a particular multicast workflow. Ask for documentation covering the camera's stream destination controls and the receiving software's supported access modes before selecting parts.

The area scan cameras category and camera finder help identify interface candidates. The LS-CMR-0053 is a GigE area scan camera. Its listing alone does not establish multicast capability or compatibility with your chosen receiver software.

The physical link still needs the correct cable and connector arrangement. The LS-CBL-0199 is a high-flex GigE camera cable for drag-chain use, with screw locks. Confirm mating connectors, routing requirements and the complete link arrangement for your installation.

Compare other camera cables through the accessories finder. A cable does not provide multicast functionality; it provides the physical data connection on which the configured stream depends.

If you are evaluating vision controllers, ask about acquisition-library support and network-port topology rather than counting connectors alone. Several ports do not automatically imply independent receive paths or compatible multicast acquisition software.

Verify complete images and independent receiver behavior

Commission the system in stages and record observations at each stage. Start below the intended payload rate, then repeat at the required production settings.

1. Run the owner with one receiver. Record image identifiers, complete-frame counts, incomplete-frame counts and received throughput where available.
2. Add another receiver. Check that camera-link traffic remains broadly unchanged while the additional receiver link carries its own copy.
3. Stop a passive receiver. Confirm that the controller and remaining receivers continue normally.
4. Restart that receiver. Verify that it rejoins and starts delivering complete images without reconfiguring the camera.
5. Exercise controller restart behavior. Under safe test conditions, check how ownership, acquisition state and destination settings recover.
6. Run the intended processing workload. Include recording or display tasks if they will operate during production.

Compare image identifiers across receivers when the transport and software expose them. Simultaneous display updates are not a reliable indication that applications are processing the same image.

Packet loss may affect one receiver while others remain healthy. Establish whether the acquisition library discards incomplete images, marks them invalid or offers a documented recovery mechanism. Do not let an incomplete image silently become an inspection decision.

If a receiver gets datagrams but cannot produce complete frames, the stream timeout guide helps separate packet delivery, buffer handling and image completion.

When multicast is the wrong answer

Multicast sends the same stream to every subscribed receiver. It does not give one application a different camera exposure, trigger schedule or transmitted image region. Those changes belong to the shared acquisition configuration unless the camera explicitly provides other supported stream arrangements.

Choose a single acquisition host with downstream redistribution when consumers need different encodings, browser delivery or application-specific image transformations. That architecture adds processing and transport work, but it centralizes camera ownership and can simplify consumer software.

Choose ordinary unicast when only one receiver needs the images. Multicast adds configuration and network-management requirements without reducing camera-link traffic in that case.

Before ordering, confirm:

• Explicit camera support for the intended multicast stream configuration.
• Receiver-library support for the exact payload format and access mode.
• One designated owner for configuration and acquisition commands.
• Network forwarding, firewall policy and payload-rate margin.
• Documented incomplete-image handling and restart behavior.
• Compatible data cabling and connectors.

Start a hardware selection with the camera configurator, or contact applications support with your proposed topology, payload format, image rate and receiver software requirements. Resolve multicast support before committing to a multi-receiver architecture.