Understanding Networks & Network Topology

Network Topologies

Network topology describes how devices like cameras, switches, and PCs are connected and how data flows between them. In machine vision setups, choosing the right topology helps balance reliability, performance, and scalability.

Here are some of the Network Topologies that are useful in machine vision systems:

Star Topology
In a star topology, each camera connects directly to a central switch or PC network interface. This layout is simple, easy to troubleshoot, and provides dedicated bandwidth to each camera. If one camera or cable fails, the rest of the network continues to operate normally.
Typical use: Most GigE Vision camera setups use a star topology, connecting all cameras to a managed or unmanaged Ethernet switch.

Bus Topology
In a bus topology, multiple devices share a single communication line. All data travels along this shared cable, and each device listens for data addressed to it. If the communication line breaks at any point, devices beyond the break will lose connectivity.
Typical use: Compact or experimental setups where cameras are connected along a single shared Ethernet run.

Ring Topology
A ring topology connects devices in a closed loop. Data travels around the ring from one device to the next until it reaches its destination. In a standard ring, if a cable or device fails, communication can be interrupted.
Typical use: Experimental or compact machine vision setups where devices are connected in a loop, though this topology is less common than a star.

Understanding Networks

In a typical GigE Vision or Ethernet-based camera setup, each device on the network—whether it’s a camera, a PC, or a switch—requires a unique IP address to communicate. These addresses allow devices to find each other, exchange control commands, and transmit image data efficiently.

Machine vision cameras often operate on dedicated network interfaces, separate from general corporate or internet traffic. This ensures predictable bandwidth, low latency, and minimal packet loss.

Understanding IP Addresses

An IP address (Internet Protocol address) is a unique numerical label assigned to each device on a network. Most machine vision systems use IPv4, which consists of four octets (e.g., 192.168.1.12).

Each octet can range from 0–255, and the address is divided into two logical parts:

• Network ID – identifies the network segment (e.g., 192.168.1)
• Host ID – identifies a device on that segment (e.g., .12)

To communicate successfully:

• All devices must be on the same network (share the same Network ID)
• Each device must have a unique Host ID

If two devices share the same IP, communication conflicts occur. If they are on different networks, they will not be able to see each other unless routing is configured. Below are an example of a host and a camera running on the same subnet with their own addresses: 192.168.1.10 for the host and 192.168.1.12 for the camera.

Connecting to a Camera on a Different Subnet

In standard GigE Vision environments, discovery and connection typically occur within the same subnet. Device discovery relies on Layer-2 broadcast packets that do not pass through routers, which is why cameras on a different network segment cannot be automatically found by eBUS Player or similar applications. However, it is possible to connect and stream from a camera located on a different subnet if a few conditions are met.

First, the network administrator must allow routed communication between the two subnets. This is usually achieved by adding a static route or firewall rule to permit UDP/TCP traffic.

Second, the camera should not use a persistent IP that binds it to a specific subnet.

Finally, the connection must be established manually by specifying the camera’s IP address rather than relying on broadcast discovery.

Case Summary: Connecting To Different Subnet

In this case, the camera is located on a different subnet from the host PC. While the camera responded to pings, it could not be discovered or connected via eBUS Player because broadcast-based discovery does not cross subnet boundaries.

After reviewing the setup, we confirmed that network routing between subnets was open and that the camera did not use a persistent IP address. To verify communication, we used a custom Python script which utilises the Pleora eBUS Python API to manually connect to the camera by IP address.

The script establishes the connection using this line in the code:

This direct IP-based method bypasses automatic discovery and enables streaming through routed Layer-3 communication. Once connected, the script successfully configured the camera’s resolution, frame rate, and stream parameters.