Force Glowforge to use SVG path order from file?

I know that the Glowforge cloud servers take SVG designs and re-computes the order of paths in the file to help optimize it for cutting/scoring; however, I have a design I have created with many many score lines (a maze design) and have worked to order the paths in the file to be (what I consider) a very optimized route for the laser to take while scoring.

After uploading and allowing the software to calculate the paths, the strokes have been re-ordered in such a way as to add a lot of extra travels by the laser head and results in a long print time.

Is there a way to force the Glowforge to use the path order from the svg file itself instead of recomputing its own order?

1 Like

Nope.

And it’s been indicated that Glowforge finds that optimizing for the traveling salesman problem doesn’t save much time.

You can force stage order by use of colors.

For more on that:

4 Likes

Aside from assigning each one a color and ordering it manually?
(And even then it won’t travel the direction you may want.)
Some parts safety so it isn’t working in an area too long another part voodoo that we don’t understand.

Edit:

And also that. It apparently doesn’t save as much time as we’d think it should.

2 Likes

Hah, I even tried that with some groups of the maze (lines going the same direction), and it still re-ordered them in a strange way!

1 Like

Somewhere a programmer is snickering.

4 Likes

I think someone at one point figured out how to force it via winding(?) directions manually but it took way longer in design setup than it saved in cutting.

3 Likes

I’m generating these designs programmatically, so if I can program in the winding directions it would be totally fine :smiley:

I’d at least love to see the time difference since I spent so much effort on the routing… eek.

1 Like

Here’s a start to your rabbit hole.

Search function. :mag_right: there are other threads. This one was added to the user maintained spreadsheet(the matrix) as good to know.

6 Likes

Thanks! I’ll keep searching around. I already have the vector path directions all setup to flow from one to the next… will keep trying!

For kicks I grouped all the individual “rings” of a circular maze and made each one a different color to force the stroke ordering… this meant the laser head just travels in 16 concentric circles, firing when it needed to for the lines, and it saved 27 seconds on a 70 second print (38.5% !). I could try to similarly batch the radial lines, but this is already bordering on impractical (so many objects in the GFUI and having to choose the settings for each one). At least it’s nice to know that my paths were indeed faster, but I may have to stop my investigation here b/c the GFUI becomes the bottleneck after uploading the design (oh, what I wouldn’t give for an upload/configure API).

1 Like

I feel your pain.

My biggest sellers have a score lines to make a brick work pattern. You would think left to right, right to left would be simple and fast. But that is not what the GF does.

It will do a bunch of L-R, move to start, L-R, move to start, L-R. Move somewhere else entirely, do some other stuff, come back do so more L-R, L-R.

I have said often on these forums, that there is a simple tweak to their line algorithm.

After all the grouping and stuff:

  1. Sort all the lines in a group by starting co-ordinates
  2. After printing one line - check the list and find the nearest start or end of line
  3. Print that line (in reverse if required).
  4. Goto 2

However!!! If the material is acrylic, Do exactly the opposite - find a line which is as far away as possible. This reduces the heat/melt affect on acrylic. (actually there are other ways of doing this, like divide the cut into quadrants and other things).

The first part does optimise for speed - and in my experiments I’ve got about a 20% increase in cut time.

The second part optimises for avoid acrylic melt.

GF have said often they don’t think there is a benefit in speed optimisation - except we are now paying for fast servers - that suggests that there people do think there is a benefit. They’ve also put some efforts into increasing speed on engraves.

Personally, saving 10% on average of my jobs would be a worthwhile improvement. In fact, that is about the overall speed benefit between Basic and Pro.

2 Likes

Preprocessing the job vs executing the job are separate issues The servers only speed up job preprocessing, not job execution.

I’m not saying that a TSP solution is a bad thing to pursue, but Dan has said it doesn’t improve things and I take him at his word. My gut vs his data, I’ll take data every time.

That being said — to your point — maybe GF ought to re-evaluate the math in light of their new budget.

I know that servers vs cut are different. The point I’m making is that as users and at GF the consider that saving to be worthwhile.

Even though it is just a few seconds on cuts that often take minutes or even hours.

What it demonstrates is that both users and GF think the performance benefit is worthwhile.

There appears to be some dependence on the order in which the paths are listed in the file.

I have been cutting multiple copies of a design that consists of multiple, separate paths (all one color), and generally observed that it always cuts the same parts of the object first, but completes the entire object before moving onto the next copy.

On the other hand, I have printed large regular patterns (a grid of circles, like pegboard) that were generated “logically”, and it prints them erratically.

Also, you can print the exact same design and it will often follow a different path.

:man_shrugging:

1 Like

There must be some residual direction issues as if you copy paste a design in the GFUI it will still travel from the outside to the inside but in the opposite direction. clockwise vs counterclockwise

Except that GF has done testing and from the data they obtained, they’ve determined the performance benefit is not worthwhile. We may think it is and want it, but they’ve already voted.

Intuitively, I suspect that the benefit scales with number of segments. So when GF says it’s not “worth it”, they mean “for the bulk of users”. Optimizing path order in jobs with hundreds or thousands of individual paths will see greater and greater reduction in job length as the number of individual segments increases. Likewise, the ratio of “gap length to laser path lengths” will play a part. The more of your total travel that is part of the laser job, the less optimizing order can assist you. This will only improve on the travel between the laser tasks, when the beam is off.

Someone must have done the math on the benefits of TSP optimization for large data sets, you know for a fact that UPS/Fedex certainly has. Let’s do some googling.

Huh well, that’s a heck of a rabbit hole:

Want to try your hand at it?

https://www-m9.ma.tum.de/games/tsp-game/index_en.html

Here’s my quick effort with 50 nodes:

Then the computer solved for it:

Algorithm beat me by about 15%.

I tried it again with only ten nodes, computer only beat me by 5%. Pretty unscientific methodology here, but it seems to confirm my diminishing returns theory. I’m guessing GF looked at the average job and how many different paths it has and said “not worth the development time to help the weirdoes like @evansd2 that make polyhedrons with literally thousands of paths per job.” I get it… I’d like it to be optimized, but I know I’m an outlier.

The unfortunate thing here is that probably nobody from Glowforge is going to read this, they don’t monitor this category.

Oh this is interesting too, it’s a simulator:

https://www.fourmilab.ch/documents/travelling/anneal/

Check it, seemingly random mess:

And now TSPed…

Unfortunately they don’t parse the data and tell you how much the relative solutions save, but just looking at the amount of blue you know full well it’s a major savings.

Oh this is fun and really deep, an animated simulation of solving for it:

Anyway, someone should tell GF staff to revisit this issue.

3 Likes

Those are good points. There’s also probably a cost benefit analysis in 1) programmer time, 2) computational time.

I have a separate program I talked Trotec into giving me (not sure what regular price is, but not cheap) that is used for a few things (kerf compensation, redundant points, very limited path editing, etc.), but it’s primary function (for me) is path sorting. I can set a few different parameters - traveling salesman, nearest neighbor, vertical or horizontal weighting, inside geometries first etc.

My typical travel reduction on a puzzle file straight from Illustrator is around 25% — a typical file is about 2200-2300” of travel, and it will reduce that to around 1600”. That alone doesn’t save me much time (because of head speed - it really only saves me like 20 seconds in run time at best), but that would probably be amplified a bit by the slower GF head speed.

But, I’ve started playing around a bit and found that horizontal weighting will save me a fair amount of time. I haven’t done any actual A B C comparisons, but do know that just by observing times that the horizontal nearest neighbor has worked the best for me so far (traveling salesman really bogs down and takes a while to compute with that much path length, so I don’t use it). Makes sense because horizontal (X) movement is much faster than vertical/Y.

It will show me the moves if I ask it — I should see how it looks different between balanced, horizontal and vertical.

4 Likes

Just for kicks…

I cut a bunch of freakin’ 8x10" puzzles from a generator, just to get an idea. I don’t think generated puzzles are the best testing solution though.

But, those results anyways, at my normal cut speeds with “throughput on”.

Default file:
Inches: 534.62
Cut time: 1:45 mins

Symmetric Weighting/Nearest Neighbor:
Inches: 493.36 (7% savings)
Cut time: 1:44 mins

Horizontal Weighting/Nearest Neighbor:
Inches: 511.54 (4% savings)
Cut time: 1:44mins

Vertical Weighting/Nearest Neighbor
Inches: 509.77 (4% savings)
Cut time: 1:44 mins

Traveling Salesman/Symetric
Inches: 525.42 in (1% saving)
Cut time: 1:45

Traveling Salesman/Horizontal
Inches: 526.75 (1%)
Cut time: 1:45

Traveling Salesman/Vertical
Inches: 528.51 (1%)
Cut time: 1:45

I could see some of the different cutting patterns, but it just didn’t make a difference hardly at all in time. The “inches” are total head movement for the job, and the head moves so quick (up to 180 inches per second), that a few inches saved doesn’t matter much on this machine.

I switched gears and scoured the internet for a free file to use that might have a lot of different elements, and came up with this Dymaxion Map (Laser Cut Dymaxion Map Wall Art SVG File Free Download - 3axis.co). For this, I removed the engraves and changed all of the different lines to one color, so everything was a score. I didn’t want to cut out a bunch of dang stuff. I did change this back to “standard” for cutting speed… I dunno why, thought maybe it would show more of a difference or something - I don’t think it messed up any comparisons though since it was a different file. I’m running it in throughput mode right now, just because…

Default file
Inches: 785.44
Cut time: 2:39 mins (throughput mode: 2:02 mins)

Nearest Neighbor/Symmetric
Inches: 558.75
Cut time: 2:25 mins (throughput mode: 1:55)

Traveling Salesman/Symmetric
Inches: 805.69 (actually longer than the default file and whatever order it came in as)
Cut time: 2:35 mins (throughput mode: 2:00 mins)

You may or may not be able to decipher anything from this, but here are some screenshots showing the movement paths:

Default:

Nearest Neighbor, Symmetric:

Traveling Salesman, Symmetric:

I don’t know what the basis of traveling salesman is for the software, but it just doesn’t seem to be anywhere near as good as nearest neighbor cutting (and it takes a lot longer to calculate!).

2 Likes