RobotStudio is genuinely excellent software. For single-robot programming, path validation, reach studies, and cycle time estimation inside an ABB-only cell, it does what it says. The 3D collision detection is accurate enough to catch real problems before they become expensive hardware incidents. The offline RAPID programming environment is well-designed. For ABB customers doing pure ABB cells, the simulation-to-live workflow is among the best in the industry.
The gap appears when the ABB arm shares a cell with robots or controllers from other vendors, and the orchestration logic needs to account for communication latency, cross-vendor handoff timing, and error propagation paths that RobotStudio has no model for. This post is about where that gap lives, specifically, so you can plan for it.
What RobotStudio Simulates Accurately
To be precise about the gap, first what is accurate. RobotStudio's Virtual Controller (VC) is a genuine simulation of the ABB IRC5 controller running real RAPID code. Cycle times from RobotStudio are typically accurate to within 5 to 10 percent of live operation for single-robot programs, with the deviation coming mainly from acceleration and deceleration profiles on complex trajectories. The signal I/O simulation correctly reflects RAPID's signal handling behavior. If a RAPID program waits for a DI signal before proceeding, the simulation will wait correctly.
EGM (Externally Guided Motion) can be simulated in RobotStudio with a virtual client. This is useful for testing EGM path correction logic before going live. The EGM timing in simulation is somewhat idealized compared to live UDP communication, but the RAPID program logic can be validated.
What the Simulation Does Not Surface: Cross-Vendor Communication Latency
Here is the core gap. When a RobotStudio simulation receives an I/O signal from a virtual PLC or a simulated sensor, that signal arrives with near-zero latency. In a live cell, if the ABB arm is waiting for a digital input from a KUKA robot's output via a PLC relay, the latency chain is: KUKA RSI cycle writing the output (typically 4ms or 12ms depending on RSI cycle time), PLC scan cycle reading that input and writing to an output (typically 2ms to 10ms), physical relay or I/O module switching time (typically 1ms to 5ms), ABB IRC5 digital input sampling period (typically 1ms to 4ms). Total: anywhere from 8ms to 31ms, with jitter on every leg.
In most applications this latency is inconsequential. But for handoff timing that depends on a signal arriving within a tight window, simulating zero-latency signals can produce a RAPID program that works flawlessly in RobotStudio and then exhibits intermittent timing failures in the live cell. We have seen this exact failure pattern on multiple commissioning projects. The RAPID program had a WaitUntil with a timeout that was calibrated on the simulation's near-zero latency; in the live cell, the signal sometimes arrived just after the timeout, causing the program to branch to an error handler that the simulation had never exercised.
EGM in Mixed-Vendor Cells: The Simulation Gap Gets Wider
EGM deserves special attention because it involves real-time external guidance at 250Hz (for 4ms correction cycle) or 83Hz (for 12ms correction cycle). The EGM client sends position or force corrections to the ABB controller over UDP. In a mixed-vendor cell, this EGM client might be running on Sancho's orchestration runtime, or on a Siemens PLC's motion co-processor, or on an external vision system.
RobotStudio's EGM simulation uses a virtual UDP interface that responds synchronously. In a live cell, the UDP packets from an external EGM client experience real network jitter. Even on a well-managed industrial Ethernet switch, packet jitter of 0.5ms to 2ms is typical. For EGM applications that are sensitive to correction timing, this jitter can cause trajectory deviations that the simulation never produced.
The standard advice for EGM commissioning is to run with conservative correction gains in the first live session, then tighten them based on observed trajectory quality. This is good advice precisely because the live jitter cannot be simulated. The simulation is useful for testing the RAPID EGM setup code and the correction algorithm logic, not for final tuning of the EGM gains.
The Orchestration Layer That Simulation Misses Entirely
Beyond communication latency, there is a category of orchestration behavior that RobotStudio cannot simulate at all: the behavior of the entire cell when a non-ABB controller faults. What happens to the RAPID program when the Siemens PLC that is supposed to signal "workpiece clamped" goes into a fault state and stops sending that signal? What happens if the KUKA arm's RSI connection drops mid-cycle?
In a single-vendor ABB cell, RobotStudio can simulate various fault conditions using the VC's fault injection tools. In a mixed-vendor cell, the fault behavior depends on how the integration wired up error propagation between vendors, which is entirely outside the scope of any single-vendor simulation tool. The RAPID error handlers for cross-vendor fault conditions have to be developed and tested on the live system, not in simulation.
When we commission a mixed-vendor cell with an ABB arm, we use RobotStudio extensively for the single-robot programming and reach validation. We consider the RobotStudio work a prerequisite for live commissioning, not a substitute for it. The live commissioning phase is specifically where we spend time on latency characterization (measuring the actual latency from each cross-vendor signal transition), EGM gain tuning with real network conditions, and fault injection testing for the cross-vendor error propagation paths.
What a Live Orchestration Layer Adds
When Sancho sits between the ABB arm and the rest of the cell, the orchestration runtime has direct visibility into the live timing of every signal transition. We instrument the latency from KUKA output write to ABB input receipt, and we can tune handoff timing parameters based on measured data rather than simulation estimates. The cell map defines timing expectations explicitly, and the runtime reports when actual latency exceeds those expectations so they can be recalibrated to match the real hardware.
This does not eliminate the simulation-to-live gap; it instruments it. The RAPID program still needs to be written with realistic latency expectations. But with the orchestration layer logging actual timing, the feedback loop for adjusting those expectations is measured in hours rather than days of trial-and-error commissioning.
Read next: Three Commissioning Mistakes When Mixing KUKA and Universal Robots in One Cell