Random lines FIGURED OUT! (but not a fix)

I’ve had random lines appear in two engraves since last night. I’ve seen at least five other other people report the same issue today.

I engraved an SVG once and got the random lines. I opened the filed, searched and fiddled with it looking for open paths (didn’t find any) and tried again. More random lines. The file did have the same repeated pattern that had been copied and pasted several times. I just spent a few hours pinpointing the problem and ran about 20 tests. When I would delete the element that appeared to cause a line, the line would move to another another element in the file. (The nodes causing the issue were hidden behind other nodes and it was a slow search! You don’t want to see all the screen shots documenting it :stuck_out_tongue: )

The problem was not OPEN paths, what was causing the lines were OVERLAPPING nodes that were on top of each other. What was interesting was not every OLN would create it’s own line. However, when I deleted OLN in one place, the line would move to another one.

Here are the final test results. The three engraves on the left of the 1st pic had numerous OLNs in several places, the ones on the right side were fixed. In the bottom test picture I was able to recreate the problem by adding back the OLN and voilà, the lines appeared!

Here’s what’s a bit strange too. When I recreated the issue in the last pic, I added OLNs in different places than before, but the line seems to have reappeared in the same place.

Hey GF, hopefully there a fix for this?


Nice detective work!

1 Like

Sort of confused here.
I would expect an overlap to just burn the same area twice, not make an arbitrary line (somewhere).
Or am I misreading what you said?

I wonder if this is another odd/even anomaly trigger? If it is, there was a thread on a fix for that last week. Had to do with reversing subpaths (if remembering it right) .
Ayup. Here it is

I think I know what happened, and it has nothing to do with even-odd, but it’s kind of hard to explain.

Were you scoring those lines @kittski? Not engraving, right?

Maybe those segments were somehow joined into one long line?

Example below:

Looks like one octagon, but it’s actually a duplicate path lying on top of the one below it:

Delete one node on the top shape, and a line appears between the two new endpoints:

Delete another node and the line shifts again to meet the two new endpoints.

If both of the shapes had the same color stroke, it would be hard to see, and if you’ve got a really complex shape, (which that plaid pattern definitely is), it would take a loooong time to hit them all one at a time.

No, they were engraves. There were no duplicate shapes on top of each other and no open paths. (I literally inspected each and every node.) However the corner of several of the shapes had two, sometimes three nodes stacked on top of each other or so close they were touching. For whatever reason, the nodes being on top of each other caused the error. It looks like the GF incorrectly interpreted them as an open path. The weird thing is not all the stacked nodes in the file caused random lines: there was only ever two error lines and there was 15+ corners with stacked nodes. When I would fix one set of stacked nodes, the GF would just add the line to another set.

Even stranger, the very same elements with stacked nodes was used in this engraving. (I had just cut the file down and enlarged it for the other engraving.) The stacked nodes caused no processing errors in this one at all.


No, you’re not misreading what I said, the GF should have just engraved the same spot twice and that’s what it did with most of the stacked nodes. Why it did it on some stacked nodes and not other is unknown. I also find it very odd that at least five people reported the exact issue yesterday and that seems more than coincidental to me. (It obviously could be though.)

1 Like

Here are more of the processing test I ran. You can see the lines either jumped around as I removed stacked nodes or got shorter or longer.

Yeah, the folks at glowforge are not too transparent and it is possible some coding droog changed something, and then said oopsie. But if still repeatable, then no oopsie just yet.

I guess we (first owners) are the beta testers, and this is sort of understandable, since nothing is etched in stone yet and still in turmoil. But more background knowledge would be nice.

Maybe this quote isn’t true, but it sure seems like ‘The Plan’.

Expose some new code.
If no one complains then the new code worked.
If people squeal, then fix the code on the hush hush.
Return to close the complaint files a few days later.
Lasering occurs…

Then again, maybe a coincidence, who knows.

Interesting to see where this goes, since it directly affects the finished product from this machine.


Thanks for letting us know about this. I’m sorry I’m late to respond.

We’re seeing this, too, and we’re looking into it. I’m sorry for the inconvenience. If you rasterize the parts of your design you want to engrave, that will also consistently prevent the extra lines from appearing.

1 Like