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 
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. 
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:
- Sort all the lines in a group by starting co-ordinates
- After printing one line - check the list and find the nearest start or end of line
- Print that line (in reverse if required).
- 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.
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:
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
Huh? Seriously though…huh? And, honestly serious…as my husband would say “they’re not talking to you”…and this would apply here. 
4 Likes
I guess this topic veered off course slightly 
I’m not trying to solve or optimize the Traveling Salesman Problem in general. I am merely trying to optimize the paths for a very domain specific type of design. It seems, though, that it can’t be forced through the SVG or GFUI (w/o making each path it’s own color, which would be completely impractical to configure). So, I might try a couple new approaches to improve the time, but at least I do have the answer to my original question 
Thanks, all!
That never happens around here!
5 Likes