Optimized laser head travel

One issue I’ve found with other lasers is that they are often inefficient cutting different parts of a multi-piece design. For example, it will cut a part in the upper left of the material, then move the head all the way to the lower right to work there, then go to another non-adjacent cut, and so on. Since most places charge by the minute, there’s usually a line-up to use the machine, and you have to monitor the whole process, I looked for information on why the software chose the cutting order it did so I could tweak it. No info I could find, so the best workaround seems to be using color mapping of different parts of the drawing.
Does the Glowforge have more optimized cutting order?

1 Like

I wouldn’t worry but this may not be in day one. (Seemed pretty optimised from some videos I saw) due to it being cloud software I would expect them to revisit this if they haven’t got it down by shipment.

@dan on the list?

They already want to do a packing algorithm (automatically fit pieces with smallest waste). And if the GF programmers are anything like me, when you get us going on an algorithm like this you can’t really stop us. I expect they would want to optimise everything!

1 Like

Thread-nomancy

Could also be a built in sneaky way to get a second or two of cool down time while moving from one corner to another?

1 Like

Interesting thought, but on the lasers I’ve used it seems to be totally random, which is very frustrating.

The material’s thermal properties might require that stagger in cutting to prevent dumping too much heat into a small area.
Learned this the hard way (story of my life) when plasma cutting 16 guage steel. The heat caused the sheet to expand and warp up, where the torch snagged a raised edge and displaced the work trashing the attempt.

I’ve experienced this on my KnK Zing plotter using Make The Cut software -
Not entirely convinced material integrity is driving those algorithms. It is frustrating, but mostly because the head moves at the same speed when transversing to a new point as it does while cutting - so even just moving the head at “max speed” when not cutting would be a most welcome improvement over my existing cutting experience

I have seen some software do it by layer (top to bottom), others do it by location and others do it by line type.
So many factors to work out. And poly lines kill your time.
Example would be:
Lets say you had 3 circles in a row #1 , #2 and #3. #1 and #3 are set to 100% power and #2 is set to 50% power.
The software might be written to cut all “same like” power first. so it might cut #1 and #3 before #2.
Just an example. Not saying it’s right, but I have seen it done that way before on devices that have issues with “quick change” settings. It’s just a way to get around a “cool down” time at each location.

A good example of this is a plasma cutter or water jet where the spin-up/change time is slow. But on these units, you normally set your paths anyway.

@PDWarne, Agree 100% with you on that.
A lot of the plotter companies tend to still be using “old code” and for some reason do not think this is a big deal for us users.

I have a KNK Maxx. I am pretty sure the algorithm for moving the cutting head around involves dice.

I think that there are actually accuracy considerations when moving the cutting head quickly. I know that when calibrating the machine for print-and-cut, they say you should set the non-cutting speed to a value much lower than the machine is capable of.

That is funny! And feels so true.
Seems a lot of these companies tend to make the software as a afterthought.

The laser doesn’t know what material is being cut, so it’s thermal properties will have no bearing on head travel.
I read somewhere that when using an Epilog Zing with a file created in Inkscape, objects are cut in the order they were created. Did some quick tests which did not work that way, so cut order is still a mystery to me.
The dice theory is most easily supportable by evidence to date :wink:

3 Likes