Search Results (Searched for: )
- rodw
Today 01:24
Replied by rodw on topic Help with Modbus needed
Help with Modbus needed
Category: Advanced Configuration
- tommylight
Today 21:27
Replied by tommylight on topic Help with Modbus needed
Help with Modbus needed
Category: Advanced Configuration
- viesturs.lacis
- viesturs.lacis
Today 20:25
Help with Modbus needed was created by viesturs.lacis
Help with Modbus needed
Category: Advanced Configuration
- dbtayl
- dbtayl
Today 20:08
- tuxcnc
- tuxcnc
Today 19:54
- Odessit
- Odessit
Today 18:51 - Today 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
Today 17:44
- fmueller
- fmueller
Today 17:20 - Today 17:32
- tuxcnc
- tuxcnc
Today 14:32
- fmueller
- fmueller
Today 12:54 - Today 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
Today 05:25
Replied by trackwhack on topic Perpetual License CAM
Perpetual License CAM
Category: Show Your Stuff
- dbtayl
- dbtayl
Yesterday 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
Yesterday 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
Yesterday 20:32
Replied by NWE on topic What once was no longer works.
What once was no longer works.
Category: Configuration Tools
- spumco
- spumco
Yesterday 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
Time to create page: 7.541 seconds