Skip to content
PreciSim
Features

Features

Organised around the trouble you run into — not around what we happened to build.

01 / 06

Virtual device engine

A virtual camera (exposure, gain, noise, distortion, defocus), virtual axes (accel/decel profiles, backlash, positioning error, limits), virtual IO and lighting. Every error parameter is configurable, so you can exaggerate one until a trainee sees what it does.

  • Camera: resolution, pixel size, lens distortion, depth of field, noise model
  • Axes: trapezoidal/S-curve motion, backlash, pitch error, repeatability
  • IO: cylinder position signals, light curtain, e-stop, with configurable delays
  • Galvo: field distortion, jump delay, mark delay
02 / 06

Calibration chains with ground-truth scoring

All six chains implement one interface: prepare, acquire, solve, verify, persist. The virtual device knows the true values, so every chain ends with the gap between what you measured and what is actually there.

  • Any step can be re-run on its own — no starting over
  • Results are versioned, so you can compare and roll back
  • When a criterion fails it names which one and by how much
  • The same procedure runs on real hardware; you just lose the truth reference
03 / 06

An HMI shaped like a real one

Not a screen full of buttons. Role-based login, alarm popups with history, structured logs, recipe management, a device debug page, manual/auto mode switching — the things a production line actually asks for.

  • Roles: operator / engineer / administrator
  • Alarms: popup, history, exportable
  • Recipes: parameter sets with change tracking
  • Debug page: single-axis jog, IO forcing, live camera parameters
04 / 06

Workflow (Station + DAG)

A station describes its steps as a dependency graph, not a chain of if-statements. Adding a station or changing a sequence does not mean touching framework code.

  • Step dependencies are declared, not implied
  • Single-step execution and breakpoints
  • One consistent retry / skip / abort policy for faults
  • Execution traces export for post-mortem
05 / 06

Integration interfaces

Two public interfaces: vmc.dll (C API) and Modbus TCP. Drive the virtual machine from Python, C#, or from the PLC side — for automated tests or for teaching.

  • vmc.dll: C-style exports, P/Invoke from any language
  • Modbus TCP: a documented register map, connect a PLC directly
  • Quick-start samples for Python and C#
  • Interfaces are versioned; breaking changes only on a major release
06 / 06

Offline and intranet friendly

School labs and factory networks usually have no internet. Offline activation codes, an offline grace period and local docs are all in the box.

  • Offline activation: machine code in, activation code out, no network
  • A 7–30 day grace period when online checks fail
  • Docs ship with the installer for offline reading
  • No personally identifiable information is collected