Case Study: Hybrid Virtual Commissioning of a Robotic Manipulator with Machine Vision

A peer-reviewed, open-access paper ("Hybrid Virtual Commissioning of a Robotic Manipulator with Machine Vision Using a Single Controller," MDPI Sensors, 2022) is a rare fully-documented, real-hardware-in-the-loop MCD case study that goes into specific technical failure modes and their fixes. Full text is freely available via PubMed Central.

Source: https://pmc.ncbi.nlm.nih.gov/articles/PMC8874962/ (also published at https://www.mdpi.com/1424-8220/22/4/1621)

Setup

• Digital twin / simulation environment: NX MCD (Mechatronic Concept Designer).
• Controller: Siemens S7-1500TF, programmed in TIA Portal v15.1.
• Vision: SIMATIC MV540 smart camera for object recognition, communicating over Profinet.
• Coupling: OPC UA between the PLC and NX MCD.
• Commissioning style: "hybrid" — the same controller runs both the simulated (digital twin) and the eventual real hardware, rather than a fully separate simulated PLC.

Concrete pitfalls and how they were resolved

1. OPC UA sampling rate too coarse for fast motion. The initial PLC-side OPC UA server had a 100 ms minimum sampling interval. This produced visible "looping" artifacts in the simulated tool trajectory — i.e., the digital twin path did not match the intended/real path, showing discontinuities. The team's diagnosis: "communication speed was not sufficient." Fix: switch to an OPC UA .NET server running a 20 ms cycle, after which simulated and real traces matched. This is a specific, quantified data point (100ms → 20ms) rather than generic "increase your polling rate" advice.

2. Model validation via trajectory tracing caught step-function artifacts. The team used animation-based verification and validation (V&V) — specifically tracing the tool's motion path — to compare TIA Portal's intended trajectory against NX MCD's simulated trajectory. This surfaced step-function signal changes producing unrealistic "loops" that needed investigation before the team trusted the model enough to proceed toward real-device testing. The practical takeaway: don't just eyeball the simulation animation — trace and diff the actual motion path against the expected/control-side path before treating the model as validated.

3. Real-time simulation could not keep up with full robot speed. The paper states plainly that real-time simulation for systems with fast dynamics is, "due to limited computational power, not feasible for a full speed of motion attainable by the device." This is an important expectation-setting data point for anyone assuming a modern workstation can always simulate a fast robot arm in true real time alongside PLC co-simulation and vision processing.

4. Early error detection prevented physical damage. On the positive side, the virtual commissioning process caught errors that "could make the arms overturn and hence collide with the base" — a serious mechanical failure mode — before physical commissioning, which the authors present as the central value proposition of the hybrid approach: catching kinematic/collision errors in simulation is materially cheaper and safer than catching them on real hardware.

Why this case study is a useful reference

Unlike marketing-oriented case studies, this paper documents specific numeric parameters (100ms vs 20ms sampling), a specific verification method (trajectory tracing), and an explicit statement of a real technical limitation (real-time simulation speed ceiling) — all of which are directly transferable checks for anyone building an MCD + TIA Portal + OPC UA virtual commissioning pipeline.