Inefficient travel

[jerryhalstead]

Version

1.42a7

Operating system type + version

Mac OS 10.14.3

3D printer brand / version + firmware version (if known)

Prus MK3 (3.6)

Behavior

long moves on this circular slice (starting around 9mm) where there's a bunch of small rectangles on the inner circle it jumps from one side and does one, then to other side, instead of doing them sequentially around the axis. Tried with S3d and it does the right thing.
stevenson_shield_v3-shield.stl.zip

[dzieva]

I've seen that, too.
Slic3rPE (Prusa Edition) has an expetacular UI, but in my view this on a not very robust base (Slic3r), I hope the Prusa Edition team will fix it.

[DrLex0]

Yes, travel planning is one of the worst things in Slic3r. I have just added another example to #1409 of uselessly large travel moves that ignore the ‘nearest’ seam position setting, and I have actually found a commented-out if statement that is probably responsible for this and turns all seam position choices into subtle variations on ‘aligned’.

I also often observe pointlessly large travels during infill (see #471) that are caused by a dumb greedy optimisation algorithm that first tries to make the longest possible continuous extrusion, and then makes a bunch of huge travels all across the entire layer, in order to fill in all the little spots it had previously ignored in its quest to maintain a travel-free path. This often causes scars on the top layers that could have been avoided.

The whole path planning should be revised instead of applying patchwork fixes. Replace the greedy algorithm with something that is more globally optimal. I'm willing to wait a bit longer on the slicing process if this will reduce print time and improve quality. If speed really is a concern, the greedy algorithm could still be offered as a ‘quick & dirty’ option.

[wavexx]

I have a new case here: insane_travels.zip

There is a small rectilinear infill area generated on the side of each gear tooth due to the sloping edge. The travel from each of these regions are done along one direction (say, y or x), which is terribly inefficient:

The travels for the complete gear in this case account for most of the printing time. The attached test case is just a slice to demonstrate the effect.

[DrLex0]

@wavexx That looks a lot like #375 which is supposed to be fixed…
Also, curiously I cannot reproduce this in either 2.1.0 or my own build of 2.2.0alpha2. But that could mean that #375 is not truly fixed because it was not consistently reproducible…

[DrLex0]

@wavexx Is your screenshot from 2.1.0 or the latest alpha? I have tested again with the stevenson_shield model from this issue, and 2.2.0alpha2 does a much better job than 2.1.0. Unless you have seen this in 2.2.0, I think this is truly fixed (and this issue was actually a duplicate of #374 indeed).

2.1.0:

2.2.0alpha2:

[wavexx]

The screenshot is from the master branch as of today... (latest alpha).

[bubnikv]

It looks good to me using the 3mf attached

[DrLex0]

I think this is a sporadic bug that only occurs under the right circumstances, as I already found out in #375. When it occurs, it looks as if the parts are being printed in a default order because path planning has not been performed at all. Unfortunately it is unclear what those right circumstances are…

[wavexx]

@DrLex0 I tried your model linked in #375 (PokerChip-inlays.stl) and there the travels look reasonable.

However, just to be sure, I downloaded my own test again and rebuilt from master again, but the travels still look like my screenshot. It is 100% reproducible by just opening insane_travels.3mf for me and hit slice.

As describe, note how the "bad" travels are really due to the rectilinear infill added to the edge of each tooth:

the travels here are from infill-to-infill, the rest of the planning looks good.

You can set infill to 0% and still get degenerate cases on this model:

Note that the travels, in both cases, are not exactly along X or Y, but seem to follow another weird orthogonal angle which is roughly rotated 45'.

[wavexx]

Just thinking out loud, I'm on linux. Could the difference be due to slight difference in rounding/FPU rules?

[bubnikv]

Just thinking out loud, I'm on linux. Could the difference be due to

slight difference in rounding/FPU rules? It could be anything. It may be a memory corruption. Such case may be catched by the ASAN build. It may be numeric rounding issue, in that case it is harder to solve. I will check with my Linux colleges whether they can reproduce it. pá 10. 1. 2020 v 13:05 odesílatel wavexx <[email protected]> napsal:

…

Just thinking out loud, I'm on linux. Could the difference be due to slight difference in rounding/FPU rules? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1934?email_source=notifications&email_token=ABMPSIYIW2F5WSY5YG7HBJTQ5BQAVA5CNFSM4G5GN262YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEITXAXA#issuecomment-573010012>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMPSIY63JTITICLHZWWEZLQ5BQAVANCNFSM4G5GN26Q> .

[vintagepc]

seems similar #2206, which may offer an additional test case

[wavexx]

Good catch, but I don't see gap fill in the gear model.

[wavexx]

It seems that commit 9038dc2 fixed this case

[bubnikv]

@wavexx I see, you are compiling the master. Yes, there was a regression issue.

Could we close this issue then?

[wavexx]

I follow master closely when I can.

I'd say the travels are very reasonable now. Both the gear and the shield work fine.
I didn't check for #2206, but I'd consider this fixed (@DrLex0: any reason gap fill should behave differently for travels?)

I'm not the OP so I cannot close this directly.

[jerryhalstead]

That looks great! Thanks everyone.