Skip to content

CRITICAL: Unreal Engine / Disguise Network Broadcast Traffic Can Interfere with Robot Control

Summary

SAFETY WARNING: Unreal Engine, Disguise XR, and similar real-time rendering engines send large volumes of broadcast/multicast UDP traffic on the local network. This traffic can overwhelm the InTime real-time network on the Flair PC, causing EtherCAT dropouts, axis trips, or loss of robot control. The robot and the rendering PC must be on separate network segments (different subnets or VLANs), with camera tracking data (FreeD/OSC) crossing between them only through a controlled, single-unicast connection. Never put the Unreal PC and the robot on the same flat network. This is one of the most dangerous configuration errors in virtual production setups.

Symptoms

  • Robot trips or disengages unpredictably during LED volume shoots.
  • EtherCAT errors appear when the Unreal/Disguise PC is on the network.
  • InTime reports timing violations or missed packets during production.
  • Axis trips that cannot be reproduced when the rendering PC is powered off.
  • Network appears correctly configured but robot behavior is intermittent.
  • Problem appears only when all systems are online simultaneously.

Community Guidance

[RESOLVED] Separate Robot Network from Rendering Network

Community consensus — multiple operators

The InTime real-time network is extremely sensitive to broadcast traffic because InTime polls the EtherCAT bus on a strict timing schedule. Large volumes of UDP broadcast from Unreal Engine (used for LiveLink, nDisplay, NDI, etc.) or Disguise XR (used for LED wall synchronisation) can cause InTime to miss timing windows — resulting in axis faults, e-stop triggers, or in extreme cases, uncontrolled robot motion.

Required network architecture for VP setups:

[Robot EtherCAT Network] ← separate switch ← InTime network
         ↑
    [Flair PC]
         ↓ (single unicast UDP only)
    [Tracking data bridge / secondary NIC]
         ↓
    [Rendering Network]
         ↓
[Unreal PC] [Disguise server] [LED wall processor]

Key rules: 1. The Flair PC needs two NICs: one connected to the InTime/EtherCAT network, one connected to the rendering network. 2. Unreal Engine and Disguise must never be on the InTime side of the Flair PC. 3. FreeD/OSC tracking data crosses from the Flair PC to the rendering network as a single unicast UDP stream (point-to-point, not broadcast). 4. The rendering PC must not send broadcast traffic to the InTime network. 5. Configure Windows Firewall on the Flair PC to block broadcast forwarding between NICs.

Community guidance: "Unreal broadcast traffic is one of the most common causes of unexplained robot trips on VP shoots. Always design the network with this in mind."

confidence_score: 0.97

[RESOLVED] LED Volume Network — Unreal PC on Different Subnet

Community — see also VP-led-volume-different-subnet.md

For LED volume setups, the Unreal PC typically needs to be on a different subnet from the robot. Assigning the Unreal PC a secondary IP address on the Flair tracking data subnet (via Windows → Network Adapters → advanced TCP/IP settings → additional addresses) allows it to receive tracking data while remaining on the correct LED wall subnet.

confidence_score: 0.93

[INFORMATIONAL] Dragonframe Also Requires a Secondary NIC

Community — see NET-dragonframe-secondary-nic.md

The same principle applies to Dragonframe — it must communicate through a secondary NIC rather than through the InTime network. Multiple external software systems each need their own network isolation from the robot control network.

confidence_score: 0.90

Official Documentation

MRMC Forum — Virtual Production