Have a question. Maybe I screwed something up, but I don’t think I did? I am cutting the Star Wars AT-ST design recently posted here ( Google Workspace Updates: New community features for Google Chat and an update on Currents ) and ran into an issue where LW4 has created cut gcode into the file where it should not be. I confirmed that these lines are not in the document file (I can post the SVG if needed). It’s almost like they should be travel moves and not cuts. Here is a GIF of what I am talking about in LW4 Placeit | Create Amazing Mockups, Logos, Videos & Designs and a picture of the actual cut https://photos.google.com/share/AF1QipMxPtPSDoOiATDlquppvg_LsgnyB_7XScKy-iVTfw1ywqSoQg9KpOa6rnBTA1QN_A?key=dWJYVmR4S2pSX1lZWU9sSkpTdFl4eHZuUzlOaHJ3 Thanks for any help!!!
The only thing that I can think is unclosed paths. I’ve taken a look at the original source CDR (from the thingiverse link) & I also see no extra lines in the source file. I would consider going through & closing/joining paths if possible, especially since you must have converted to SVG. It’s possible that when reading the paths in it is auto joining them or something.
Actually, if you could post the SVG file that you input into LW4 I (or someone else) can take a look at it & give it a test to see if we can figure out what is causing the issue.
+Peter van der Walt Does exporting the whole workspace allow us to literally load what he has loaded? If so that is a very cool & handy feature. Will be very useful for helping debug issues users are having.
Here’s the workspace export: https://drive.google.com/open?id=0B3A9wmWsyWK1QlhTcG1Ja2RZeGs First time sharing a document, so let me know if that works. On a different note, looking at the file in inkspape, there are lots of paths that are not joined. I did not know they had to be joined. Does this mean the lines have to be connected to another line? There are a few lines that do not have genereated gcode in LW4 after I have generated gcode for them, so maybe they are not connected as well? I appreciate the help!
+Peter van der Walt thanks. You will see I used the color filter for operations. I tried it without using that feature with the same results.
My setup is Arduino Uno w/ GRBL CNC Shield (Protoneer). Laser is 3.5W 445nm w/ PWM driver, firmware is GRBL 1.1e.
The paths in the snapshot are bad. Either there’s something funny about the SVG, or there’s a bug in the SVG parser. Can you post the SVG?
I don’t know if it matters, but I changed the path stroke from .001mm to .1mm so I could see the paths in Inkscape. I tried both in LW4 and had the same results.
LW4 ignores stroke width
It hits a bug in lw-parser plus a heuristic in the CAM misclassifies it. To work around both problems, do this in Inkscape:
- Edit -> Select All
- Path -> Break Apart
https://github.com/lautr3k/lw.svg-parser/issues/7
That did the trick! THANK YOU!
@Todd_Fleming Checking the svg in Illustrator, it seems that the areas that were glitching are “compound paths”. Releasing compound paths (or Break Apart as you say for Inkscape) seemed to remove the issue also on import. Although, I noticed with SVGs saved from Illustrator, the line colours were non existent when parsed in to LW4 & the fill colours were all seeming to be a shade of grey. This didn’t allow me to select based on filter colour.
The color issues happen when Illustrator uses style definitions; LW4 ignores those. Both lw.svg-parser and the CAM are designed to handle compound paths. lw.svg-parser hits a bug for this case which scrambles coordinates. The CAM mishandles this case because they mix closed and open paths in a single compound path. The CAM has a choice between 2 possible interpretations when that happens. The one it chose is good for some files but not this one.
@Todd_Fleming Ah fair enough. I’ll keep that in mind regarding the Illustrator & it’s annoying style definitions & see if I can find a fix for turning that off when exporting the SVG.