Area Inkscape Gcode extension & artifacts
Добавлено: 02 апр 2011, 06:58
This extension is great - I am just learning but I think I will really enjoy it - thanks for making it.
I have a question about the Area extension...I will include example files inline...
When I use the area function to mill out a shape I get some missed areas. For example, in Inkscape I make a rectangle, 25 mm wide x 15 mm high at 5 mm X, 5 mm Y position. I subtract from it a circle, 5 mm in diameter a bit offset to one side. So now I have a box with a hole I want to mill this out so that I have a rectangular recess with a round post in it. I set tool diameter to 2 mm, and run the Area extension with "Area width" set to 50. I get a bunch of paths, plus a dynamic offset box on the outside (multiple copies), which I have to delete (I am curious about this but it is not my main problem) I then select the actual paths, and run Path to Gcode, it gives me the nice colours etc and exports the gcode So far, so good. But, when I run the paths through a visualizer (in my case cncSimulator), I notice that the paths leave some chunks of material untouched that should be milled out - especially in corners where the linear outlines inset from the outer border meet the curved lines inset from the circular interior hole Code is used as it comes out of the extension, but I add "T5" as the first line to specify a 2 mm diameter cutter from my library. Visual examination of the last block of Gcode (which makes the outermost cut) shows it is correct to within rounding error for a 2 mm cutter. If I set width to 2 mm under Stroke Style in Inkscape, I see the same gaps, so this is not an artefact of the cncSimulator but a problem with the actual gcoded paths.
It looks to me like what is happening is that there are places where the logic cannot mill out the material without part of the cutter intruding into an area that has already been milled, and so it does not do this. Possibly this is a result of re-using the code that decides where the first boundary is to select subsequent milling paths? (e.g. the initial boundary path must not cut outside the desired area, but subsequent paths can exceed their target area and overlap with previous cuts, as long as they don't go outside the original boundary). Is there a way around this behaviour?
Thanks and I really appreciate you making this available, I will have a lot of fun with it once I figure out how to use it.
Mark
I have a question about the Area extension...I will include example files inline...
When I use the area function to mill out a shape I get some missed areas. For example, in Inkscape I make a rectangle, 25 mm wide x 15 mm high at 5 mm X, 5 mm Y position. I subtract from it a circle, 5 mm in diameter a bit offset to one side. So now I have a box with a hole I want to mill this out so that I have a rectangular recess with a round post in it. I set tool diameter to 2 mm, and run the Area extension with "Area width" set to 50. I get a bunch of paths, plus a dynamic offset box on the outside (multiple copies), which I have to delete (I am curious about this but it is not my main problem) I then select the actual paths, and run Path to Gcode, it gives me the nice colours etc and exports the gcode So far, so good. But, when I run the paths through a visualizer (in my case cncSimulator), I notice that the paths leave some chunks of material untouched that should be milled out - especially in corners where the linear outlines inset from the outer border meet the curved lines inset from the circular interior hole Code is used as it comes out of the extension, but I add "T5" as the first line to specify a 2 mm diameter cutter from my library. Visual examination of the last block of Gcode (which makes the outermost cut) shows it is correct to within rounding error for a 2 mm cutter. If I set width to 2 mm under Stroke Style in Inkscape, I see the same gaps, so this is not an artefact of the cncSimulator but a problem with the actual gcoded paths.
It looks to me like what is happening is that there are places where the logic cannot mill out the material without part of the cutter intruding into an area that has already been milled, and so it does not do this. Possibly this is a result of re-using the code that decides where the first boundary is to select subsequent milling paths? (e.g. the initial boundary path must not cut outside the desired area, but subsequent paths can exceed their target area and overlap with previous cuts, as long as they don't go outside the original boundary). Is there a way around this behaviour?
Thanks and I really appreciate you making this available, I will have a lot of fun with it once I figure out how to use it.
Mark