(not relevant I think; can repro the problem at LaserWeb)
Problem description
When I generate from an SVG, I expect the laser paths to just etch paths which are in the SVG, but instead I get a whole bunch of extra lines.
Background: I have a 500 mW laser (on Creality Ender 5) and I’m just trying to etch some stuff into wood, not actually cut. but “laser cut” seems like the closest option in generation mode. I don’t know if this is the source of the problem?
This problem has always happened (but I’m new to laserweb and laser etching in general).
Notice how there are a bunch of straight join lines with laser on which don’t correspond to paths in the original SVG. Are these supposed to be there? Is this a bug or some misunderstanding on my part about what LaserWeb is supposed to do in this situation?
I notice those straight lines you’re talking about are a different color… is there a setting to show/not-show the “moves” of the laser head. ie these might just be the movement to reposition the laser head for the next section.
Ah! it’s already in that mode I think. The red lines are definitely “laser on” (I have also verified by printing). greens are laser off, just showing the gcode movements. I’d expect the straight red lines to also be green (ie Laserweb should be saying "OK I’ve finished this path and need to move to somewhere else – I’m gonna turn the laser off for that bit – as it does for the green cases)
Glad you got that resolved, thankyou @tomatsu for the quick suggestion.
One thing you can do with this type of issue is to turn off both the ‘document’ and ‘gcode’ tickboxes so that you are only seeing the laser path. This is handy for debugging, especially in situations where the laser is ‘burning white’ or you have very pale paths that you dont see in the image but the laser sees and tries to cut at a very low power.
I’m going to look at what is going on from a LW perspective. If there is something that can be improved here it can at least be captured in a issue for later.
@dougl yes, you are right. Green are travel (high speed) moves, Red is the ‘default tool active’.
There are other colours for other tools, this is a CNC thing; not all firmwares support the T flag for tool selection, but this is for those that do.
Thankyou for the report @strangefeatures, a quick question; is that image copyrighted? can I attach it to a GitHub issue? I dont want to get anybody in trouble…
I can see what is happening; but fixing it is a job for the future .
If you look carefully at the failed Gcode you can also see that standalone straight lines are being skipped too (eg look in her hair).
This is all related to the fact that the original image is a single path with breaks, and LaserWeb needs to internally break that up into it’s component cut paths; but is obviously confused by the way they are represented.
the whole importer rats-nest needs a re-work and cleanup, this should be part of that
@easytarget ,
I noticed the same thing for basic R12 DXFs polyline paths. I am super careful to leave the polyline paths open, but still the GCode looks like what @strangefeatures is experiencing. It sounds there’s a tendency for the path processing to force-close some of the paths. I fiddled around the mergepaths function (actually created a dontmergepaths to preserve vertex sequence and perform piercing) but I haven’t dug yet where the force-closing is happening. In my case it’s lesser of an issue as I’m aiming for cutting through and the force-close is happening within the part to be removed.
I have to try this again with your fork and DXF2000 to see if there’s any change in behavior.
I’ve done a bit of messing around in Inkscape to remove detail from the image enough a) so that copyright shouldn’t be an issue and you can attach it to Github b) to hone in even more on the problem (although it sounds like you’re across the underlying cause)
Ok I have done some high level testing here. It was a bit of an undertaking because of npm versioning. I have a feeling that the old importer was the one messing the path lines.
Here’s a snapshot of my original document. The paths are not closed.
There was an “optimizer” in the old SVG importer (probably also for DXF) which tried to connect the endpoint of one line with the startpoint of another line if the points where very close together. This is needed to produce continous lines which don’t stutter when cutting. A bad side effect of this optimizer was, that two lines on top of each other (which should not be in clean files) was dropped.
