Glowforge making two passes over some single lines when only one pass specified

Beyond the Manual
#1

Hi All–

We’re making progress learning to use our GF Pro. We’ve purchased a business, and what we mostly bought are the plans that the former owner made over 20 year for laser-cut wood kits of structures for model railroads. So the parts are pretty tiny.

We’ve been having a problem with pinholing and scorching (especially on thin stock–like, 1/64" plywood thin stock O_o ), and the forums have been incredibly helpful as we’ve figured things out. Slowing speed and lowering power have nearly solved our pinhole problem.

The remaining issue has something to do with our legacy plans, which have traveled a tortured path:

  • Originally drawn in Designer over the last 20 years (Designer was discontinued ages ago and won’t run on anything newer than Windows XP)
  • Exported from Designer into .drw format, which at least Corel Draw can read
  • Opened in Draw and exported as .svg files, which Glowforge can use

Something about that process seems to have caused some weirdness that I can’t figure out. The .svg files from Corel Draw open and run just fine in GF… but then GF makes two or three passes over some (not all) of the line segments.

To make sure my eyes weren’t tricking me, I burned a small test drawing from the original plans, then drew a similar figure by hand, exported it as an .svg, and burned it alongside the original using the same power and speed settings on the same piece of material. Then I watched the burn process carefully, and sure enough: the GF passed over some segments in the original plan twice and all segments in my new plan just once. The result of the unwanted multiple passes is some nasty scorching. See the side-by-side results (original plan sample on the right; my hand-drawn test on the left):

IMG_5839
IMG_5839.JPG4032×3024 2.57 MB

I’ve attached both plans here. The original is called “test_sheet.svg” and my hand-drawn example is called “test_sheet-mine.svg.” I’d be most grateful for any help y’all can offer figuring out what’s amiss with the .svg generated from the original plans (“test_sheet.svg”)! Note that the weight of the lines in both files is .001, so yes: it’s hard to see and you’ll want to bump up the weight to .25 or something if you want to take a look.

testsheets.zip (5.2 KB)

2 Likes
#2

Hi Seth. Your files got mangled as uploads — a frequent occurrence with svg files here. Archive them as .zip files, then re-upload — they’ll survive the transit that way.

Without looking at them, it sounds like you have multiple lines in the places where the GF is making more than one pass. The translations from format to format probably caused this. The cure is to go through the files and delete the redundant lines.

3 Likes
#3

Thanks, @petej. I’ve edited the original post and replaced the .svg file attachments with a single .zip including both. Much appreciated!

#4

Update: for the heck of it, I opened the original file and deleted and replaced individual line segments with identical segments. GF now makes only one pass on the ones I replaced, and the difference in cut quality is pretty stark. Check it out…

IMG_1955%202
IMG_1955 2.JPG4032×3024 2.26 MB

(Note that “150/20” refers to the cut speed and power I used on the three columns of small pieces at the top of the test card, while the “300/10” refers to the score speed and power I used on the lower segment, which is only meant to be scribed in.)

So… this “solves” the problem… but I’m looking at a legacy plan set of 90 different kits, each kit comprising 8-10 sheets, and each sheet comprising hundreds of very small, very precisely-measured and -placed segments. I could do exactly what I’ve done here… but it’d take me years. Literally. So I’m really hoping somebody can help me detect what’s up here and find a systematic / programmatic way of fixing the problem.

For interest’s sake, I’ve attached the half-fixed plan below…

test_sheet_reborn.svg.zip (4.2 KB)

#5

I have to say, just spot checking the file, I don’t see any lines duplicated (overlaying one another). Tried to go by your image above with the more scorches lines (for example, the vertical line just to the right of the 8).

#6

I know, right? It’s baffling, especially given the results of my half-fix-it-manually test just now (posted just above your reply, but probably while you were writing it). There aren’t hidden second lines… but some property of the lines in the original files makes GF think it needs to do them in two passes.

If it’s helpful at all, the action when burning is that GF passes over these once in one direction and then reverses course and cuts going the other way over the same line.

#7

Try moving a node and seeing if there’s a node under it. You might have a single path that has two passes in it

2 Likes
#8

Sometimes when I have question about a path direction, I open up the Stroke palette and just add arrowheads to see where the path originates/ends.

When I do this on your original file, the arrowheads end up on top of one another, pointing the same direction, like the path is being doubled back on itself somehow.

Looking at the document info, it shows all of the paths are closed, which they shouldn’t be, since these should just be line segments - not closed shape paths.

When selecting one of the little horizontal lines from the top set of boxes, it shows it is only 2 points, but is a closed path. The length of the line in the transform panel shows an object length of .1105" - but looking at it in document info, it shows .2214".

Somehow those paths are doubling back on one another.

7 Likes
#9

AAAH. That’s helpful. OK. You’ve given me something to go on here. Thanks much! I’ve got some tinkering to do now.

1 Like
#10

I can’t see the file since I’m on my pad, but based on what jb said, could be the paths were outlined. I believe that would make it do what you describe. If the thickness of the lines is tiny like you said, it would be hard to see unless zoomed way in, or in outline mode (or both)

#11

Looking at the SVG code:

Here’s an example of one of the paths:
d=“M58.8,14.1V6.2V14.1z”

D defines a path to be drawn
M is moveTo
V is LineTo
Z is close path

Break it down to:
d=
“M58.8,14.1
V6.2
V14.1
z”

So this path is saying something like, move to 58.8, then 14.1, Line to 6.2, then Line (back) to 14.1 and close, which is effectively a path doubling back on itself, I believe?

I just can’t tell ya how to fix it :slight_smile:

1 Like
#12

Wow; this is super helpful stuff. Thanks, everybody. I think I may have caused my own problem by doing something dumb to the files while trying to solve a different problem (and doing it wrong) a couple of months ago. I’ll go back and find a version of the files that predates my clumsy “fix” effort and go from there…

#13

@seth.r.johnson, what programs are you using to create the files? Illustrator? Inkscape? (Yeah, there is a doubling back on itself problem in a lot of the lines, but not all of them. It might be fixable in Illustrator using a centerline trace.)

1 Like
#14

If I were fixing it I’d do the following:
EDIT: (in inkscape)

Select all

Set stroke to something wide, 1/8” or something

Set opacity to 50%

Any doubled paths will stand out like a sore thumb now

Depending on how many problem paths you have would set the next step… if you have a lot it might be simpler to redraw the shapes but if it is just a few:

Select a doubled path. Select all the nodes

Break apart all nodes. Now you’ll have a ton of individual line segments

Click on one doubled path. Delete. You should be left with one path now.

Continue, deleting the doubled paths.

Select all your single path line segments. Select all nodes that you want to be a single path and join them.

Should take care of you.

EDIT EDIT:
Previously - https://community.glowforge.com/search?context=topic&context_id=31999&q=%40evansd2%20opacity%20&skip_context=true

6 Likes
#15

I’ve got access to both Illustrator and Inkscape. I’m finding I like both of these better than Corel Draw, which makes me want to cuss pretty regularly.

#16

Okay, we’ve got a Centerline Trace tutorial for Illustrator here:

I think that will work if you have a lot of files to process. Since those are hairline, you probably won’t have to make adjustments to the line width.

If it was just one or two files, I would suggest just dragging and deleting the doubled lines individually, but they’re impossible to determine until you burn them and wind up overburning.

Try the Centerline Trace on one and see if it works. :slightly_smiling_face:

3 Likes
#17

In Illustrator, you could run through use the direct select tool clicking on each path and deleting (or shift-click and delete multiple at once), but I can only imagine how tedious that would be for lots of files. But, I can’t think of any way to do programmatically (but that’s not my strong point either). You could open the file source and find the various instances of V (or H which is also used) and delete the second occurrences where the path doubles back.

I’d be concerned about it mimicking the paths exactly - trace is good but I don’t know that I would trust it for exactness.

#18

Yeah, I was just thinking about that…it might be necessary to Expand/Combine and then Centerline trace.

Dammit, I’m really busy this morning, but I can probably run one quick test to see if it’s feasible…stand by… :smile:

#19

Thanks so much!

#20

I bet it would be pretty easy to do for 2-node closed paths using php or perl. (Or awk or sed) (or of you are desperate anything that has regex support like a text editor such as notepad++ or even JavaScript (ew))

d=“M58.8,14.1V6.2V14.1z”

Could be expressed as

Any path with an M, followed by 2 V’s and ending with a z

Then you just remove the Z from those instances.

Now I don’t know if all 2 node closed paths look like this or not, I’m just saying it shouldn’t be hard to do.

You could probably work out more complicated examples.

2 Likes