Search Results (Searched for: )
- tuxcnc
- tuxcnc
03 Oct 2026 14:32
- fmueller
- fmueller
03 Oct 2026 12:54 - 03 Oct 2026 13:27
Standalone LinuxCNC machine simulator using the Stepper-Ninja HAL interface was created by fmueller
Standalone LinuxCNC machine simulator using the Stepper-Ninja HAL interface
Category: General LinuxCNC Questions
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
- trackwhack
- trackwhack
03 Oct 2026 05:25
Replied by trackwhack on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
- dbtayl
- dbtayl
02 Oct 2026 23:07
Replied by dbtayl on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
For context, this is what I'd expect to be able to get out of the Adaptive operation:
That lets me set the speeds/feeds to optimize MRR within my machine's limits, based on the depth of cut I know it's taking. If it starts taking variable depths of cut, I'm running far slower than I need to for the shallow stepdowns. Not to say Z level detection is a bad feature at all! if I weren't so obsessive about trying to optimize toolpaths, it'd be great to have a one-click option. But it's suboptimal if you're trying to optimize cut time.
I'll try not to be a broken record about this, but IMO give me the dumbest, most manual way of specifying an operation first. Once that's bombproof, make it nicer/easier. Doesn't matter how easy it is if I have no way to get the output I want.
And again... I have strong opinions, they may not reflect the general public's. You should design your software to work for your target demographic, not a single squeaky wheel on a forum.
That lets me set the speeds/feeds to optimize MRR within my machine's limits, based on the depth of cut I know it's taking. If it starts taking variable depths of cut, I'm running far slower than I need to for the shallow stepdowns. Not to say Z level detection is a bad feature at all! if I weren't so obsessive about trying to optimize toolpaths, it'd be great to have a one-click option. But it's suboptimal if you're trying to optimize cut time.
I'll try not to be a broken record about this, but IMO give me the dumbest, most manual way of specifying an operation first. Once that's bombproof, make it nicer/easier. Doesn't matter how easy it is if I have no way to get the output I want.
And again... I have strong opinions, they may not reflect the general public's. You should design your software to work for your target demographic, not a single squeaky wheel on a forum.
- dbtayl
- dbtayl
02 Oct 2026 22:43
Replied by dbtayl on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
I've updated my initial comments to reflect where I mis-represented things.
I'll try to move more detailed bug reporting to your actual system, but quick notes below. Also a reminder that I'm just one voice- what I say isn't law, and the way I expect things to work isn't necessarily "right". So long as you can get to the same end result, there's room for interpretation. It's when you literally can't do what you need to that there's a problem.
Adaptive doesn't clear outside stock, regardless of bounding box vs silhouette selection. This is with bbox (silhouette is even more constrained):
(you can also see it cutting a bunch of layers, when I'd really like it to do one depth on the outside and one on the inside- at least the option to control that)
Re AFR: This appears to be a different bug than I presented- it appears cuts you add manually subsequently show up in the AFR list- that caused me to believe it was partially detecting features, when in fact I had only partially selected them.
Re chamfer: The highlighted face is one giving me problems. There's no chamfer modeled on it- I just want to do a slight edge break. The entire contour has tangent end points- tiny radii in the "sharp" corners. If I select the face and try to chamfer, I get an error about the geometry. If I select auto loop, it only touches the outside of the "U" shape. I have yet to get manual selection to work- it's really tedious, and the couple times I've tried it's said it's an open loop and can't connect the edges.
Separate chamfer issue- maybe your fix mentioned above will correct it- but it's not just walls. In this case, trying to deburr (again, add a small 0.1mm edge break to the slot in the bottom) will run into the boss marked in yellow. This is one of the places where being able to adjust the start point would be helpful- normally what I do in these cases is to manually offset the start of the path to skip the area that's problematic.
Re lead-in/-out: This is more about options than operations that I saw that need it. There are lots of places where more control over the lead is required. Different leads for the lead-in and -out may be appropriate. Sometimes you want to lead in with a tangent line, not an arc. Sometimes you want an arc, but only 60 degrees, not 90.
New thing I just found: Pocket operation doesn't seem to respect the entry method for more than the first pass- you can see one helix entry, then a plunge on the outside pass. Doesn't seem to matter if I check the "keep tool down" box or not.
(this also illustrates a second thing I think is a bug- that green face is stuck highlighted, makes it hard to see the toolpaths)
And while I'm being picky... controlling the helix angle is important. Some tools choke at more than 1 degree, others are fine at 5 degrees.
OK, that wasn't that quick... but I'd like to end on a positive note here. Like I said in my initial post, I think the core looks really good here, and you're clearly dedicated to making things better. I really like to see that, and am optimistic you'll get there quickly.
I'll try to move more detailed bug reporting to your actual system, but quick notes below. Also a reminder that I'm just one voice- what I say isn't law, and the way I expect things to work isn't necessarily "right". So long as you can get to the same end result, there's room for interpretation. It's when you literally can't do what you need to that there's a problem.
Adaptive doesn't clear outside stock, regardless of bounding box vs silhouette selection. This is with bbox (silhouette is even more constrained):
(you can also see it cutting a bunch of layers, when I'd really like it to do one depth on the outside and one on the inside- at least the option to control that)
Re AFR: This appears to be a different bug than I presented- it appears cuts you add manually subsequently show up in the AFR list- that caused me to believe it was partially detecting features, when in fact I had only partially selected them.
Re chamfer: The highlighted face is one giving me problems. There's no chamfer modeled on it- I just want to do a slight edge break. The entire contour has tangent end points- tiny radii in the "sharp" corners. If I select the face and try to chamfer, I get an error about the geometry. If I select auto loop, it only touches the outside of the "U" shape. I have yet to get manual selection to work- it's really tedious, and the couple times I've tried it's said it's an open loop and can't connect the edges.
Separate chamfer issue- maybe your fix mentioned above will correct it- but it's not just walls. In this case, trying to deburr (again, add a small 0.1mm edge break to the slot in the bottom) will run into the boss marked in yellow. This is one of the places where being able to adjust the start point would be helpful- normally what I do in these cases is to manually offset the start of the path to skip the area that's problematic.
Re lead-in/-out: This is more about options than operations that I saw that need it. There are lots of places where more control over the lead is required. Different leads for the lead-in and -out may be appropriate. Sometimes you want to lead in with a tangent line, not an arc. Sometimes you want an arc, but only 60 degrees, not 90.
New thing I just found: Pocket operation doesn't seem to respect the entry method for more than the first pass- you can see one helix entry, then a plunge on the outside pass. Doesn't seem to matter if I check the "keep tool down" box or not.
(this also illustrates a second thing I think is a bug- that green face is stuck highlighted, makes it hard to see the toolpaths)
And while I'm being picky... controlling the helix angle is important. Some tools choke at more than 1 degree, others are fine at 5 degrees.
OK, that wasn't that quick... but I'd like to end on a positive note here. Like I said in my initial post, I think the core looks really good here, and you're clearly dedicated to making things better. I really like to see that, and am optimistic you'll get there quickly.
- NWE
02 Oct 2026 20:32
Replied by NWE on topic What once was no longer works.
What once was no longer works.
Category: Configuration Tools
- spumco
- spumco
02 Oct 2026 18:23
Replied by spumco on topic Looking for an older CNC mill to refurbish/retrofit
Looking for an older CNC mill to refurbish/retrofit
Category: General LinuxCNC Questions
- trackwhack
- trackwhack
02 Oct 2026 16:26
Replied by trackwhack on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
- spumco
- spumco
02 Oct 2026 15:31
Replied by spumco on topic New LinuxCNC Multi-Channel System – Looking for Testers & Feedback
New LinuxCNC Multi-Channel System – Looking for Testers & Feedback
Category: Show Your Stuff
- spumco
- spumco
02 Oct 2026 15:25
Replied by spumco on topic New LinuxCNC Multi-Channel System – Looking for Testers & Feedback
New LinuxCNC Multi-Channel System – Looking for Testers & Feedback
Category: Show Your Stuff
- grandixximo
02 Oct 2026 12:13 - 02 Oct 2026 12:16
Replied by grandixximo on topic Would you use a feed rate for rotary axes in mm/min (surface speed)?
Would you use a feed rate for rotary axes in mm/min (surface speed)?
Category: General LinuxCNC Questions
- grandixximo
02 Oct 2026 12:10
Replied by grandixximo on topic Would you use a feed rate for rotary axes in mm/min (surface speed)?
Would you use a feed rate for rotary axes in mm/min (surface speed)?
Category: General LinuxCNC Questions
- djdelorie
- djdelorie
02 Oct 2026 11:57
Replied by djdelorie on topic Would you use a feed rate for rotary axes in mm/min (surface speed)?
Would you use a feed rate for rotary axes in mm/min (surface speed)?
Category: General LinuxCNC Questions
- trackwhack
- trackwhack
02 Oct 2026 09:20
Replied by trackwhack on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
- trackwhack
- trackwhack
02 Oct 2026 09:11
Replied by trackwhack on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
Time to create page: 3.216 seconds