What will happen on site — visible before you get there
The simulator behaves like the line: friction, mass, inertia, acceleration and braking. The PLC program sees it through the same inputs as on site.
The simulator is a line where bodies behave as on site
An animation replays a drawn path: a pack reaches the sensor exactly when it was drawn there. On site it never happens like that — the pack slips, stops at back-pressure, arrives later than the cycle.
The simulator calculates bodies: the product rides the rollers by friction, the conveyor accelerates with mass and inertia, the sensor fires when the product really blocks the beam. The PLC program sees this simulator through the same inputs as on the line.
The simulator is built from the same twin that prints the configuration of the real controller. There is one line model, not two — for simulation and for control.
Bodies, not drawn trajectories
Friction
The product slips, stops at the backstop, falls — as on rollers.
Beam sensors
Triggered when the product really blocks the beam.
Mass and inertia
Acceleration and braking of equipment and load — as on site.
Your parameters
Belt speed, masses and friction — from the model and datasheets; you can edit them.
What gets caught at the desk
| On site | In the simulator | Status |
|---|---|---|
| A pack slips, stops at back-pressure, falls | The product rides the rollers by friction — a jam and a fallen pack are visible before the trip to site | subject of the implementation |
| The sensor is silent or fires at the wrong time | The sensor fires on a blocked beam; the program is checked on the same signals | subject of the implementation |
| The conveyor cannot accelerate in time, the pack reaches the sensor later than the cycle | Mass and inertia of rollers, carriages, robot links and load — from the model and datasheets | subject of the implementation |
| A robot with a load brakes longer than the programmer calculated | A heavy load lags behind; acceleration and braking are visible on the timeline | subject of the implementation |
| There is no test bench for checking, or it is busy | The unit test run starts in the browser | works |
From the twin to a program run
- Unit in the twinThe mechanism is data: links, joints, limits and sensor points. Axes, the working tool and drive profiles.
- Body parametersConveyor speed, masses, friction and inertia — from your model and equipment datasheets.
- Program against the simulatorThe real unit program in IEC 61131-3 controls the simulator exactly as it would control the line.
- Sensors through the same inputThe blocked-beam signal reaches the program through the same input as on site.
- Findings — on screenA jam, a late arrival at a sensor, a transition that did not fire are visible in the browser before the trip to site.
What remains on site is to bind the real sensors and axes. The same commands go to the equipment and the simulator in parallel; responses are compared and differences are visible at once — line shadow.
The unit simulator — right in the browser
What it contains
Product, conveyor, reset and unit sensors. The run starts with a button on the unit page — no test bench, no software installation.
Why it matters before an implementation
See how the unit behaves with the product even before the simulator next to the controller is built: the customer and the integrator look at the same scene.
What it is not
The browser shows and starts, but does not decide: checking the program on the same signals as on site happens in the simulator next to the controller — that is a subject of the implementation.
The parameters are yours, and each one is marked
From the model and datasheets
Masses, friction, speeds and inertia come from your unit model and equipment datasheets. They can be adjusted to your hardware.
Typical — not measured
A number inherited from a unit sample carries a “typ.” badge — a typical template number, not a measurement of your hardware. While the mark is there, it is a starting point for discussion.
Unknown — a dash
No rated torque in the datasheet — the per-mille scale does not exist, the value shows a dash, and a torque condition does not fire.
Next to the controller; the screen is a window
- The simulator runs on your siteNext to the controller; data stays inside the perimeter.
- Sensors come through the same inputBy its signals, the PLC program cannot tell the model from the site.
- The browser shows and runs the testThe unit test run is started with a button on the unit page.
- The browser “decides” nothingThe truth about the line is computed next to the controller; the screen shows it.
What works and what is being worked out
| Unit test run in the browser: product, conveyor, reset, sensors | works |
| Simulator next to the controller, sensors through the same input | subject of the implementation |
| Line shadow on real servos: axis facts, correction by sensors | subject of the implementation |
| Virtual units started by a neighbour's sensor | subject of the implementation |
The load on the axis is confirmed on a real drive: torque on a virtual axis is a model, the measurement is on hardware.
What the model proves, and what only the drive proves
| Quantity | In the simulator | On the drive |
|---|---|---|
| Step and transition logic | Checked in full | The same program, without rewriting |
| Axis torque | A model: derived from the difference between “commanded” and “actual” | Measured by the drive, per mille of rating |
| Axis lag behind the command | Not checked — it is the model working, not a fact | Default fault threshold — 0.05 revolution for longer than 0.2 s |
| End-stop search, tightening | The logic is debugged | Force is confirmed by a sensor or by drive torque |
The simulator removes logic and sequence errors. The load properties of an axis are proven by a run on a real drive — that is the next stage, not a replacement.
Units where physics decides the outcome
Discuss an implementation
Describe a unit where time is lost on site: slipping, jams, sensors. Target figures are fixed in the implementation specification.
Request accessDiscuss an implementation
Describe the unit or line — we will tell you what we will verify and in what time. Target indicators are fixed in the implementation specification.
Request access