Search Results (Searched for: )
- tuxcnc
- tuxcnc
Today 08:45
- tuxcnc
- tuxcnc
Today 06:34
- tommylight
Yesterday 02:49
Replied by tommylight on topic Mesa Ethernet / QtPlasmaC retrofit experience — lessons from a marginal mini PC
Mesa Ethernet / QtPlasmaC retrofit experience — lessons from a marginal mini PC
Category: Computers and Hardware
You are welcomed, always.
P.S.
Wait till you figure out what you can do in HAL !
That is the main thing why i liked it so much back then, for me it just clicks "connect this pin to this pin" and it works!
P.S.
Wait till you figure out what you can do in HAL !
That is the main thing why i liked it so much back then, for me it just clicks "connect this pin to this pin" and it works!
- trackwhack
- trackwhack
Yesterday 02:17
Replied by trackwhack on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
- FabLabRacing
- FabLabRacing
Yesterday 01:35 - Yesterday 01:36
Replied by FabLabRacing on topic Mesa Ethernet / QtPlasmaC retrofit experience — lessons from a marginal mini PC
Mesa Ethernet / QtPlasmaC retrofit experience — lessons from a marginal mini PC
Category: Computers and Hardware
**A Few Months With LinuxCNC / QtPlasmaC — Follow-Up and Thank You**
Back in July, I posted about the PC and realtime issues I encountered while converting my home-built plasma table from MASSO to LinuxCNC / QtPlasmaC. Now that I have been using it for a few months, I wanted to follow up and, more importantly, thank the LinuxCNC community.
The short version is that I am very happy I made the conversion.
At this point I have cut roughly a dozen actual parts and spent a large number of hours setting up the machine, troubleshooting it, experimenting with it, and generally just playing with it. None of those hours were wasted.
The Dell OptiPlex 7060 with Intel Ethernet has proven to be the “boring” control PC I was looking for. After some additional tuning, including CPU isolation and changes to how my camera project delivers frames, I have been able to run QtPlasmaC and FabScan together for hours without realtime, Mesa, watchdog, or Smart Serial faults.
I still stand behind the main point of my original post: with Mesa Ethernet, the details of the PC matter more than raw horsepower. The NIC, driver, BIOS and power-management behavior, and long-term realtime stability are more important than whether the computer looks powerful on paper. A modest business-class PC with Intel Ethernet has worked much better for me than the newer mini PC I originally tried.
What has changed since July is my understanding of LinuxCNC itself.
LinuxCNC / QtPlasmaC can definitely be challenging to set up and dial in. There are a lot of layers, and there are plenty of opportunities to configure something incorrectly. At first, that can make it seem unpredictable.
After working with it for a while, I have found the opposite to be true. LinuxCNC is actually very predictable. When something does not work, there is normally a logical reason for it. It may be a signal polarity, a HAL connection, a configuration path, a file permission, a post-processor issue, or a setting I did not completely understand, but there is usually an identifiable cause.
More importantly, LinuxCNC gives me the tools to find that cause. I can look at the HAL signals, see the machine state, follow what the controller is doing, and change the logic when necessary. Once I began to understand how the pieces fit together, troubleshooting became much less intimidating.
I also think LinuxCNC is easier to get into now than it was a few years ago. One of my previous problems with Linux-based projects was that a traditional Google search would often return information that was several versions out of date. AI-assisted searches have helped me sort through that, especially when I include the specific LinuxCNC and QtPlasmaC versions in the question.
The documentation also seems better than I remember, although it is possible I am just getting older, slowing down, and actually reading it this time.
The QtPlasmaC feature set has lived up to my original expectations. The material handling, probing, THC operation and visibility, Arc OK handling, cut recovery, scribing, hole processing, and operator feedback all feel like they were designed specifically for plasma cutting rather than added to a general-purpose CNC interface afterward.
Cut recovery is probably one of my favorite examples. If a cut stops, I can use Reverse to back up along the actual cut path, stop wherever I want, and press Cycle Start. QtPlasmaC then performs the normal plasma-start sequence, including waiting for Arc OK before continuing. When cutting larger parts, that is a very useful production feature rather than just a convenience.
The openness has also allowed me to do things that would be difficult or impossible with a closed controller. I was able to connect and configure my existing MASSO MPG pendant through the Mesa card, integrate the THCAD-2, customize the QtPlasmaC interface, and continue developing FabScan alongside the machine control.
FabScan was one of the main reasons I started looking at LinuxCNC in the first place. It uses a USB camera mounted to the machine and LinuxCNC motion to trace existing parts and templates, with the eventual goal of exporting usable geometry. It is still very much an ongoing experiment, but LinuxCNC gives me access to the machine state and motion control needed to build it. I am not limited to whatever features the controller manufacturer decided to include.
For perspective, I have used GRBL, ChiliPeppr/TinyG, Mach3, Mach4, MASSO, Langmuir Systems’ MR-1 Cut Control, and now LinuxCNC. If I build another CNC machine, I am almost positive it will be a LinuxCNC machine.
That is not because I now think every other controller is bad. MASSO, for example, remains a very solid and reliable controller. For someone who wants an appliance-like system, does not need much customization, and stays within the intended configuration, it is extremely easy to recommend.
The difference, in my opinion, can be summed up this way:
MASSO is easier until you need something it does not support.
LinuxCNC is harder until you understand it—then very little is off-limits.
Finally, I want to thank the LinuxCNC community.
A project like this only exists because people contribute their time to writing the software, developing QtPlasmaC, maintaining the documentation, designing hardware such as the Mesa cards, and answering questions from people like me who are still learning how all the pieces fit together.
The help I received made a real difference. Even when the answer turned out to be a single setting, an inverted input, or changing a 1 to a 0 after several hours of troubleshooting, someone was willing to help explain what that setting actually did and why it mattered.
When I wrote the original post in July, I hoped my experience might help the next person avoid a few days of chasing intermittent PC and realtime gremlins. After a few months of real use, my conclusion is that the “boring PC” advice still stands—but LinuxCNC / QtPlasmaC has absolutely been worth the effort.
Thank you to everyone who helped me get this far.
Back in July, I posted about the PC and realtime issues I encountered while converting my home-built plasma table from MASSO to LinuxCNC / QtPlasmaC. Now that I have been using it for a few months, I wanted to follow up and, more importantly, thank the LinuxCNC community.
The short version is that I am very happy I made the conversion.
At this point I have cut roughly a dozen actual parts and spent a large number of hours setting up the machine, troubleshooting it, experimenting with it, and generally just playing with it. None of those hours were wasted.
The Dell OptiPlex 7060 with Intel Ethernet has proven to be the “boring” control PC I was looking for. After some additional tuning, including CPU isolation and changes to how my camera project delivers frames, I have been able to run QtPlasmaC and FabScan together for hours without realtime, Mesa, watchdog, or Smart Serial faults.
I still stand behind the main point of my original post: with Mesa Ethernet, the details of the PC matter more than raw horsepower. The NIC, driver, BIOS and power-management behavior, and long-term realtime stability are more important than whether the computer looks powerful on paper. A modest business-class PC with Intel Ethernet has worked much better for me than the newer mini PC I originally tried.
What has changed since July is my understanding of LinuxCNC itself.
LinuxCNC / QtPlasmaC can definitely be challenging to set up and dial in. There are a lot of layers, and there are plenty of opportunities to configure something incorrectly. At first, that can make it seem unpredictable.
After working with it for a while, I have found the opposite to be true. LinuxCNC is actually very predictable. When something does not work, there is normally a logical reason for it. It may be a signal polarity, a HAL connection, a configuration path, a file permission, a post-processor issue, or a setting I did not completely understand, but there is usually an identifiable cause.
More importantly, LinuxCNC gives me the tools to find that cause. I can look at the HAL signals, see the machine state, follow what the controller is doing, and change the logic when necessary. Once I began to understand how the pieces fit together, troubleshooting became much less intimidating.
I also think LinuxCNC is easier to get into now than it was a few years ago. One of my previous problems with Linux-based projects was that a traditional Google search would often return information that was several versions out of date. AI-assisted searches have helped me sort through that, especially when I include the specific LinuxCNC and QtPlasmaC versions in the question.
The documentation also seems better than I remember, although it is possible I am just getting older, slowing down, and actually reading it this time.
The QtPlasmaC feature set has lived up to my original expectations. The material handling, probing, THC operation and visibility, Arc OK handling, cut recovery, scribing, hole processing, and operator feedback all feel like they were designed specifically for plasma cutting rather than added to a general-purpose CNC interface afterward.
Cut recovery is probably one of my favorite examples. If a cut stops, I can use Reverse to back up along the actual cut path, stop wherever I want, and press Cycle Start. QtPlasmaC then performs the normal plasma-start sequence, including waiting for Arc OK before continuing. When cutting larger parts, that is a very useful production feature rather than just a convenience.
The openness has also allowed me to do things that would be difficult or impossible with a closed controller. I was able to connect and configure my existing MASSO MPG pendant through the Mesa card, integrate the THCAD-2, customize the QtPlasmaC interface, and continue developing FabScan alongside the machine control.
FabScan was one of the main reasons I started looking at LinuxCNC in the first place. It uses a USB camera mounted to the machine and LinuxCNC motion to trace existing parts and templates, with the eventual goal of exporting usable geometry. It is still very much an ongoing experiment, but LinuxCNC gives me access to the machine state and motion control needed to build it. I am not limited to whatever features the controller manufacturer decided to include.
For perspective, I have used GRBL, ChiliPeppr/TinyG, Mach3, Mach4, MASSO, Langmuir Systems’ MR-1 Cut Control, and now LinuxCNC. If I build another CNC machine, I am almost positive it will be a LinuxCNC machine.
That is not because I now think every other controller is bad. MASSO, for example, remains a very solid and reliable controller. For someone who wants an appliance-like system, does not need much customization, and stays within the intended configuration, it is extremely easy to recommend.
The difference, in my opinion, can be summed up this way:
MASSO is easier until you need something it does not support.
LinuxCNC is harder until you understand it—then very little is off-limits.
Finally, I want to thank the LinuxCNC community.
A project like this only exists because people contribute their time to writing the software, developing QtPlasmaC, maintaining the documentation, designing hardware such as the Mesa cards, and answering questions from people like me who are still learning how all the pieces fit together.
The help I received made a real difference. Even when the answer turned out to be a single setting, an inverted input, or changing a 1 to a 0 after several hours of troubleshooting, someone was willing to help explain what that setting actually did and why it mattered.
When I wrote the original post in July, I hoped my experience might help the next person avoid a few days of chasing intermittent PC and realtime gremlins. After a few months of real use, my conclusion is that the “boring PC” advice still stands—but LinuxCNC / QtPlasmaC has absolutely been worth the effort.
Thank you to everyone who helped me get this far.
- rodw
Yesterday 01:24
Replied by rodw on topic Help with Modbus needed
Help with Modbus needed
Category: Advanced Configuration
- tommylight
Yesterday 21:27
Replied by tommylight on topic Help with Modbus needed
Help with Modbus needed
Category: Advanced Configuration
- viesturs.lacis
- viesturs.lacis
Yesterday 20:25
Help with Modbus needed was created by viesturs.lacis
Help with Modbus needed
Category: Advanced Configuration
- dbtayl
- dbtayl
Yesterday 20:08
- tuxcnc
- tuxcnc
Yesterday 19:54
- Odessit
- Odessit
Yesterday 18:51 - Yesterday 19:21
Replied by Odessit on topic Turn G-code: conversational lathe cycle generator for LinuxCNC (12 cycles)
Turn G-code: conversational lathe cycle generator for LinuxCNC (12 cycles)
Category: Show Your Stuff
Update: Archimedean spiral - real cut on video
Here is the face spiral cycle cut on my lathe, start to finish (real cut, not an air run). Two frames are attached; a short video of the whole cut (49 s, sped up 2-4x, with music) is on the cycle page:
turngcode.com/en/features/archimedean-spiral/
I painted the face black before cutting so the spiral is easy to see on camera; the paint went on a bit unevenly, so some lands look thinner than they are. The video colour is slightly corrected for contrast, nothing else is edited.
Parameters: diameter 10 -> 110 mm, 3 starts, 2 mm insert (groove) + 2 mm land = 4 mm per turn, spiral lead 12 mm, 1 mm deep in 3 passes + 1 finishing pass, 50 RPM, right-hand.
How it works: the spiral is a G33 move along X, synchronized with the spindle encoder - the same way threads are cut, only across the face instead of along Z. The program works out the lead from the insert width, the land between turns and the number of starts.
Handy detail: the hand of the spiral is set simply by the order of the diameters. Start at the small diameter and finish at the large one - you get a right-hand spiral. Swap the start and end diameters (cut from the outside in) - and the same cycle gives a left-hand spiral, with the same spindle direction.
More on the geometry, lead and speeds, with a sample program:
turngcode.com/en/blog/archimedean-spiral-face-groove/
Questions and criticism welcome.
And here is the cycle form with exactly these parameters (English UI):
- Geometry: start and end diameter, pitch P (the land between turns), insert width, number of starts, depth, number of passes, finishing allowance and finishing passes, plunge feed.
- Spindle: roughing and finishing RPM.
- Approach / retract: safe X/Z and retract X/Z.
- Options: tool T number in the program, coolant M8, comments, M30 at the end, G7/G8 output.
The program works out the real pitch per turn (insert width + land = 4 mm) and the spiral lead (x 3 starts = 12 mm) by itself. The 2D preview on the right shows the planned G33 path and the current pass, so you can check the spiral before the machine moves. Generate writes the .ngc file, Send to LinuxCNC hands it over to LinuxCNC.
Here is the face spiral cycle cut on my lathe, start to finish (real cut, not an air run). Two frames are attached; a short video of the whole cut (49 s, sped up 2-4x, with music) is on the cycle page:
turngcode.com/en/features/archimedean-spiral/
I painted the face black before cutting so the spiral is easy to see on camera; the paint went on a bit unevenly, so some lands look thinner than they are. The video colour is slightly corrected for contrast, nothing else is edited.
Parameters: diameter 10 -> 110 mm, 3 starts, 2 mm insert (groove) + 2 mm land = 4 mm per turn, spiral lead 12 mm, 1 mm deep in 3 passes + 1 finishing pass, 50 RPM, right-hand.
How it works: the spiral is a G33 move along X, synchronized with the spindle encoder - the same way threads are cut, only across the face instead of along Z. The program works out the lead from the insert width, the land between turns and the number of starts.
Handy detail: the hand of the spiral is set simply by the order of the diameters. Start at the small diameter and finish at the large one - you get a right-hand spiral. Swap the start and end diameters (cut from the outside in) - and the same cycle gives a left-hand spiral, with the same spindle direction.
More on the geometry, lead and speeds, with a sample program:
turngcode.com/en/blog/archimedean-spiral-face-groove/
Questions and criticism welcome.
- Geometry: start and end diameter, pitch P (the land between turns), insert width, number of starts, depth, number of passes, finishing allowance and finishing passes, plunge feed.
- Spindle: roughing and finishing RPM.
- Approach / retract: safe X/Z and retract X/Z.
- Options: tool T number in the program, coolant M8, comments, M30 at the end, G7/G8 output.
The program works out the real pitch per turn (insert width + land = 4 mm) and the spiral lead (x 3 starts = 12 mm) by itself. The 2D preview on the right shows the planned G33 path and the current pass, so you can check the spiral before the machine moves. Generate writes the .ngc file, Send to LinuxCNC hands it over to LinuxCNC.
- scotth
- scotth
Yesterday 17:44
- fmueller
- fmueller
Yesterday 17:20 - Yesterday 17:32
- tuxcnc
- tuxcnc
Yesterday 14:32
- fmueller
- fmueller
Yesterday 12:54 - Yesterday 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
Time to create page: 0.482 seconds