Questions about Perimeter and Shell Execution Order

59 views
Skip to first unread message

Colin Hudson

unread,
Mar 10, 2018, 9:24:04 PM3/10/18
to IceSL
Hi,
 is there any reason for the execution order for printing the shells and perimeter at separate times?

For example with this simple model.

A long rectangle with 3 holes.


emit(difference{ccube(150, 10, 10), ccylinder(2, 12),
translate(50, 0, 0) * ccylinder(2, 12),
translate(-50, 0, 0) * ccylinder(2, 12)})


IceSL- forge seems to generally.
-------------------------
Print all the inner shellsfor 3 holes and the outer cube. This involves at least three (50mm) long travel moves (with retraction)

Print the perimeter of the model for 3 holes and the outer cube. At least another 3 (50mm) long travel moves (with retraction)

Print the solid layer (or infill)
-------------------------

Is there a reason why ICESL doesn't print the inner shells and the perimeter of each feature in one go?

For the model above printing the features in two passes causes additional long travel moves and retracts. The current implementation slows the printing and has caused me issues with the finish of the perimeter of the print because a travel of more than 10cm was done before starting the perimeter.

Could this printing order be changed to print the inner shells and the perimeter of each feature in one go? Could the path optimiser be improved to eliminate the additional long moves and retracts?

I have tried tuning retraction, temperature and speed with limited success. I don't think that these fixes are as reliable and would not speed up print times as the two suggestions above.

Thanks,
Colin..

 





Maze Mietner

unread,
Mar 15, 2018, 4:06:21 PM3/15/18
to IceSL
I agree, it should print the inner perimeter of the three holes as soon as the shells of the holes are completed. There's no need to wait for the shell of the rectangle to be completed before starting with the perimeter shell of the three holes.
But I'm afraid this would require much more program logic. (Doing shells first and perimeters second is much easier to program - and that's most likely the reason why it's currently implemented like this).

And I also agree: Ideally perimeters would be printed immediately after completing the infill (or shells if no infill) without any travel. Having travel with retraction won't give good results (unless the printer is perfectly tuned).

Maze

sylefeb

unread,
Mar 16, 2018, 3:19:38 AM3/16/18
to IceSL
Hi Colin, Hi Maze,

Actually ordering and traveling is quite a big part of what the engine does. The order is chosen to work best in most cases, based on our experience, but that remains a tradeoff between many considerations (aesthetics, print time, supportability, etc.). The order can be changed in the engine. However, exposing it would mean exposing several other things such that enough control is provided. I'll definitely give it more thoughts.

As a rule of thumb:
- Shells are done first to best deal with cases where the surfaces are in overhang. Being the innermost contours, they usually suffer less from the overhang and provide additional adhesion to the perimeter.
- Infills are done last such that their presence does not perturb the shells and perimeters (otherwise, tiny bumps may become visible along surfaces).

However, the case you are showing here is interesting. If these were not holes but bars, you would get exactly the desired behavior. Try:

emit(union{ccylinder(2, 12),

translate(50, 0, 0) * ccylinder(2, 12),
translate(-50, 0, 0) * ccylinder(2, 12)})

I do think we can improve this case, that is a good point. I'll look into it.

Thanks!
Sylvain

Reply all
Reply to author
Forward
0 new messages