The Machine That Worked on Screen and Failed on the Floor
We built a four-station assembly cell. The mechanical design was reviewed, the PLC program was written, and the cycle simulation looked perfect — every station cycled in 6 seconds, the robot picked and placed without collision, and the throughput target was met. On the floor, the robot waited 2 seconds every cycle because the PLC’s handshaking between stations had a delay nobody had simulated. The robot didn’t know when the station was ready; it waited for a sensor that triggered 2 seconds late. The throughput dropped from 600 parts/hour to 450. We spent two days on the floor fixing the interlock logic that a simple simulation would have caught.
Digital twin for custom machine design sounds like marketing jargon. But at its practical level, it’s simple: simulate the machine before you build it. Not the geometry — the motion, the logic, the handshaking. The gaps between the PLC program, the mechanical motion, and the sensor interlocks are where floor time gets wasted. This article is how I use mechatronic simulation to catch those gaps before the steel is cut.
What a Digital Twin Actually Does (and Doesn’t Do)
A digital twin isn’t a 3D CAD model. A 3D model shows what the machine looks like. A digital twin shows what the machine does — how the PLC logic, motion sequences, sensors, and actuators interact over time.
What It Catches
- Logic errors: A step sequence that waits for a sensor that never triggers. A handshaking delay between stations. These are invisible in a static 3D model but obvious in a simulation.
- Cycle time issues: A station that takes longer than the target. A bottleneck that nobody expected. The simulation runs the cycle and tells you the actual time.
- Collision detection during motion: A static assembly shows no collision. An animated motion shows the gripper opening while the feeder is still moving into position.
- Sensor placement: A sensor that sees the wrong surface. A proximity switch that triggers too early or too late. The simulation shows what the sensor sees.
What It Doesn’t Catch
- Weld distortion and machining tolerances: The physical build still has real tolerances. The digital twin assumes perfect geometry.
- Electrical noise and signal integrity: A shielded cable grounded wrong still causes interference on the floor. The simulation assumes clean signals.
- Operator behavior: The operator loads the part wrong. The simulation assumes perfect loading.
The digital twin doesn’t replace the floor debug. It reduces the floor debug from two weeks to two days.
Three Levels of Simulation: Pick What You Need
Not every machine needs a full digital twin. Three levels match the project complexity.
Level 1: Motion Simulation (3D Animation)
The simplest. Animate the 3D assembly through its cycle. Use the CAD software’s motion study (SolidWorks Motion, Inventor Studio) or a dedicated robot simulation (RobotStudio, ROBOGUIDE). Watch the mechanism move. Check for collisions.
What it catches: collisions between moving parts, stations that interfere, robot reach issues. It doesn’t simulate the PLC logic or the sensor timing.
For: any machine with moving mechanisms, especially robots. This is the minimum I do on every project.
Level 2: PLC-in-the-Loop (HIL)
The actual PLC program runs in simulation. The virtual machine (3D model with sensors and actuators) responds to the PLC outputs. The PLC reads simulated sensor inputs. The program runs as if it were connected to the real machine — but the machine is virtual.
What it catches: logic errors, handshaking delays, sensor timing issues, cycle time bottlenecks. The PLC program is debugged on the virtual machine before the real machine exists.
For: multi-station cells, complex PLC programs, high-value machines where floor time is expensive.
Level 3: Full Digital Twin (Physics + Logic + Data)
The most advanced. The virtual machine includes physics (gravity, friction, dynamics), the PLC logic, and process models (the part’s behavior under the process). The twin runs in parallel with the real machine, comparing expected vs. actual behavior.
What it catches: everything in levels 1 and 2, plus predictive maintenance (when a component is about to fail), process optimization (what parameters give the best result), and continuous improvement.
For: high-volume production machines, process-critical equipment, and machines where downtime is very expensive.
| Level | What It Simulates | Effort | Best For |
|---|---|---|---|
| 1. Motion animation | Geometry and motion, no PLC | Low (days) | Collision check, robot reach |
| 2. PLC-in-the-loop | PLC logic + virtual sensors/actuators | Medium (weeks) | Multi-station cells, logic debug |
| 3. Full digital twin | Physics + logic + process + real data | High (months) | High-volume, process-critical machines |
Level 1: Motion Simulation in CAD (Do This on Every Project)
The minimum I do on every custom machine is a motion study in the CAD software. It’s low effort and catches collisions that a static assembly doesn’t show.
How to Do It
- Build the top-level assembly with all moving parts (cylinders extended/retracted, robot at multiple positions, grippers open/closed).
- Add mates that define the motion limits (cylinder at 0 mm and at full stroke, robot at home and at pick position).
- Use the motion study to animate between these positions. Watch for collisions.
- For robots: use the robot’s offline programming software (RobotStudio, ROBOGUIDE) to import the cell and simulate the paths. Check reach, collisions, and cycle time.
This doesn’t require special software. SolidWorks Motion, Inventor, or the robot vendor’s simulation package does it. The time investment is a day. The payoff is catching a collision that would have been discovered on the floor — where fixing it costs a week of rework.
The collision test: Animate every station through its full cycle, including the robot moving between stations. If the gripper opens while the feeder is still in the way, the animation shows it. A static assembly doesn’t. Do this before you release drawings.
Level 2: PLC-in-the-Loop (HIL) — Where the Real Value Is
This is the simulation that catches the handshaking delay that caused the throughput problem. The actual PLC program runs against a virtual machine.
How It Works
The PLC program runs on a real PLC (or a soft PLC on a PC). The virtual machine is a 3D model that responds to PLC outputs (valves extend cylinders, motors move axes) and sends back simulated sensor inputs (prox switches trigger when the part arrives). The PLC thinks it’s connected to a real machine. It’s actually connected to a computer screen.
What It Catches
- A step that waits for a sensor that never triggers: The virtual machine shows the cylinder moving but the sensor not switching. The PLC hangs in that step. You find out on screen, not on the floor.
- Handshaking delays: The robot waits for a “station ready” signal that the PLC sends 2 seconds late. The simulation shows the robot sitting idle. You adjust the logic before the machine exists.
- Cycle time bottlenecks: The simulation runs 100 cycles and tells you the average cycle time. If it’s 8 seconds instead of the target 6, you find out before the steel is cut.
- Sensor placement: The virtual sensor triggers at the wrong position. You move the sensor in the virtual model before you drill the mounting hole.
What It Takes to Set Up
HIL simulation requires:
- The PLC program (written before the machine is built — which means the controls engineer starts early, not after the mechanical design is done).
- A virtual machine model (the 3D assembly, simplified for simulation speed).
- A communication link between the PLC and the virtual machine (EtherNet/IP, OPC UA, or a direct driver).
- Time: 1–2 weeks to build the virtual model and map the I/O. This is extra upfront time, but it saves weeks on the floor.
The ROI: What You Save
The question isn’t “can we afford to simulate?” It’s “can we afford not to?”
What Simulation Prevents
| Floor Problem | Cost Without Simulation | Caught By |
|---|---|---|
| Collision between robot and station | 1–2 weeks rework + damaged parts | Level 1 motion |
| Logic hangs in a step | 1–3 days debugging on floor | Level 2 HIL |
| Cycle time 20% over target | Customer rejects, redesign | Level 2 HIL |
| Sensor sees wrong surface | 1–2 days adjusting sensor | Level 2 HIL |
| Handshaking delay between stations | 2–3 days logic fixes | Level 2 HIL |
A typical custom machine spends 1–2 weeks on the floor debugging logic and motion. HIL simulation cuts that to 2–3 days. The upfront time (1–2 weeks to build the virtual model) pays back in the first machine. On repeat machines, the virtual model is reused — the payoff compounds.
Getting Started: You Don’t Need a Full Digital Twin
If you’ve never used simulation, start small. You don’t need a multi-month digital twin project.
Start with Level 1
On your next project, animate the 3D assembly through its cycle. Watch for collisions. This is a day of work. It catches the obvious collisions. It’s the lowest-hanging fruit.
Then Add Level 2 for Complex Cells
For multi-station cells (4+ stations, robot integration, complex interlocks), invest in HIL. The controls engineer writes the PLC program while the mechanical design is still in progress. The program is debugged on the virtual machine. When the real machine is assembled, the program mostly works — it just needs sensor wiring verification and minor adjustments.
Don’t Try to Simulate Everything
Simulate the critical path — the stations that determine cycle time, the handshakes between stations, the robot paths. Don’t simulate the guard light, the warning beacon, or the manual mode. Those work without simulation. Focus on what breaks on the floor.
A Simulation Checklist
- Have you animated the 3D assembly through its full cycle? (Level 1.)
- Have you checked for collisions during motion (not just at rest)?
- For robots: have you run the paths in the robot’s offline simulation?
- Is the PLC program written before the machine is built?
- For complex cells: have you set up PLC-in-the-loop simulation?
- Does the virtual machine model the sensors and actuators realistically?
- Have you measured the simulated cycle time? Does it meet the target?
- Have you tested fault recovery (sensor timeout, part missing) in simulation?
- Will the virtual model be reused for the next machine?
- What floor debug time does the simulation replace? (Quantify it.)
The Bottom Line
Machine simulation before build isn’t science fiction or a consultant’s pitch. It’s the difference between a machine that spends two weeks on the floor debugging logic and one that spends two days verifying it. Start with motion animation (a day in your CAD software), add PLC-in-the-loop for complex cells, and focus simulation on the critical path. The throughput problem that was caught in simulation — the handshaking delay that cost two days on the floor — is the one that makes the next project worth simulating. The machine that works on the first floor run isn’t lucky. It was debugged on screen first.
