Standalone LinuxCNC machine simulator using the Stepper-Ninja HAL interface
03 Oct 2026 12:54 - 03 Oct 2026 13:27 #350079
by fmueller
Standalone LinuxCNC machine simulator using the Stepper-Ninja HAL interface was created by fmueller
Hi,
I've been working on a standalone CNC machine simulator for LinuxCNC and have now published the first experimental version.
The main idea is that the simulator does NOT interpret G-code itself.
LinuxCNC remains responsible for G-code interpretation, trajectory planning, coordinate systems, offsets and compensation. The simulator sits behind LinuxCNC where real motion hardware would normally be connected.
Currently I use the original Stepper-Ninja HAL driver and its UDP protocol as the interface:
The important part of this approach is that the simulator sees the motion that LinuxCNC actually sends to the virtual hardware instead of trying to reproduce LinuxCNC's trajectory planner.
Communication is bidirectional. The simulator can also send virtual machine inputs back to LinuxCNC. I can already use this for limit switches, homing and a simple configurable probe plane.
The current version also contains a sparse voxel workpiece and persistent material removal. Tool movement is processed as continuous swept volumes rather than just removing material at individual sampled positions.
One interesting problem was performance during curved motion. LinuxCNC can generate many small motion segments. Instead of approximating those segments with a larger chord, I batch the actual swept segments for a short time window and calculate the union of their removal volumes. This keeps the resulting voxel state identical while greatly reducing repeated work.
At the moment the simulation is still quite limited:
- flat-end cutter only
- no geometric stock probing yet
- no toolsetter yet
- no spindle/holder model
- no general collision detection
- no rotary material transform
The next area I would like to work on is geometric contact detection. My idea is to use the same contact system later for workpiece probing, a machine-fixed toolsetter and eventually collision detection.
Stepper-Ninja is currently just the interface between LinuxCNC and the simulator. A physical machine does not need to use Stepper-Ninja hardware. I chose it because an existing LinuxCNC HAL driver and a small bidirectional protocol already existed, so I did not have to invent another LinuxCNC hardware interface.
This is my first public release and I consider it experimental development software, not a machine safety system.
Source and v0.1.0:
github.com/FredericM88/linuxcnc-sim
I would be particularly interested in feedback about the architecture. Does placing the simulator behind LinuxCNC at the hardware interface make sense to you? Are there LinuxCNC behaviours or use cases that would be especially useful to test with this approach?
Frederic
I've been working on a standalone CNC machine simulator for LinuxCNC and have now published the first experimental version.
The main idea is that the simulator does NOT interpret G-code itself.
LinuxCNC remains responsible for G-code interpretation, trajectory planning, coordinate systems, offsets and compensation. The simulator sits behind LinuxCNC where real motion hardware would normally be connected.
Currently I use the original Stepper-Ninja HAL driver and its UDP protocol as the interface:
G-code
|
v
LinuxCNC
|
v
Trajectory planner / compensation
|
v
Original Stepper-Ninja HAL driver
|
| UDP
v
linuxcnc-sim
|
+-- virtual machine motion
+-- virtual digital inputs
+-- limit switches
+-- probe input
+-- OpenGL visualization
+-- voxel workpiece
+-- material removalThe important part of this approach is that the simulator sees the motion that LinuxCNC actually sends to the virtual hardware instead of trying to reproduce LinuxCNC's trajectory planner.
Communication is bidirectional. The simulator can also send virtual machine inputs back to LinuxCNC. I can already use this for limit switches, homing and a simple configurable probe plane.
The current version also contains a sparse voxel workpiece and persistent material removal. Tool movement is processed as continuous swept volumes rather than just removing material at individual sampled positions.
One interesting problem was performance during curved motion. LinuxCNC can generate many small motion segments. Instead of approximating those segments with a larger chord, I batch the actual swept segments for a short time window and calculate the union of their removal volumes. This keeps the resulting voxel state identical while greatly reducing repeated work.
At the moment the simulation is still quite limited:
- flat-end cutter only
- no geometric stock probing yet
- no toolsetter yet
- no spindle/holder model
- no general collision detection
- no rotary material transform
The next area I would like to work on is geometric contact detection. My idea is to use the same contact system later for workpiece probing, a machine-fixed toolsetter and eventually collision detection.
Stepper-Ninja is currently just the interface between LinuxCNC and the simulator. A physical machine does not need to use Stepper-Ninja hardware. I chose it because an existing LinuxCNC HAL driver and a small bidirectional protocol already existed, so I did not have to invent another LinuxCNC hardware interface.
This is my first public release and I consider it experimental development software, not a machine safety system.
Source and v0.1.0:
github.com/FredericM88/linuxcnc-sim
I would be particularly interested in feedback about the architecture. Does placing the simulator behind LinuxCNC at the hardware interface make sense to you? Are there LinuxCNC behaviours or use cases that would be especially useful to test with this approach?
Frederic
Attachments:
Please Log in or Create an account to join the conversation.
Time to create page: 0.334 seconds