Where’s that old Dan thread where he talked about this? Basically he says that optimizing cut order yields a surprisingly small improvement. Let’s see….
Here’s one but not the one I was looking for:
Interesting, the inter-operation movement speed is fast enough that optimizing order doesn’t yield great returns. Never thought of it that way.
Still not the one I was thinking of.
@Dan, Aug ‘19:
Almost none, but when we manually path optimized a random set of prints, we found only small speed improvements (much less than 10%). As a result, we haven’t prioritized it in the hopper to date.
Aha, this is the one I meant, from 2018:
So if we do the math, Dan claims low single digit percents, and this only applies to cut/score jobs… the longest cut jobs I do have many tiny parts and clock in at about 1:20, or 80 minutes. Let’s assume 5% as a sort of worst case, that’s a potential savings of only 4 minutes. If we assume 2%, that’s about a minute and thirty seconds.
The difference is even less on more typical cut job lengths like 2-5 minutes. A 5% time saving on a 5 minute job would clock in at just fifteen seconds.
So I tend to agree that this isn’t worth a great deal of effort to “fix” even at the extreme end of the use case.