Inefficient slicing with too many distant non-print moves



  • Can we have a discussion regarding the decisions the slicer makes, especially when generating infill?
    It seems like it does things inefficiently, filling in an area, leaving gaps then having to move all the way back to finish.

    (These examples are printing bottom solid layer 2)
    Wish I could insert gifs, but, for example, why does the infill start here and work its way left?
    0_1563994827292_inf1.PNG

    I can see what the thinking is here
    0_1563994867588_inf2.PNG
    and maybe that's the most efficient, but if I turn off "Avoid Crossing Perimeters" it takes the same path, which I don't think it should.

    Those previous paths were created with the "Infill Overlap" set to 75%. The identical slice with that value set to 50% produces remarkably different results:
    0_1563995052170_inf3.PNG
    And there is no way that's the most efficient. What you can't tell here is that it's still printing towards the right...
    0_1563995215854_inf4.PNG
    before moving back left and filling in those gaps.

    Many times you can see a scenario where a small area is unfilled at one end, the entire layer gets printed, then we have to do a long move all the way back to the start just to finish off the layer.

    So yeah, just wondering 🙂



  • Here's one, for instance:
    0_1564004701696_inf5.PNG

    Printed the whole layer left to right, then has to travel all the way back:
    0_1564004741040_inf6.PNG



  • Well there are 2 things
    1.) Part of it might be on purpose - as you do not want to keep the hot end in the same area too long to give the plastic some time to cool down hence a little here a little there

    2.) If you consider the places where it goes as stops on a trip and you want to find the shortest distance - there are some algorithms for that around but they are all far from perfect. Now should you find the perfect one and write a proof for it - then you have solved the "salesman problem" which is one of the million dollar math challenges - IOW you will most likely win a million bucks if the math world agrees with you that the math is correct

    3.) Yeah there might be some unintentional travel going on and that would not surprise me either



  • Mattercontrol is horrible. That's really all there is to it. Sadly I'm forced to use it with the Pulse DXE. It's inefficient, buggy, produces a horrible surface layer, and printing dual extrusion hasn't exactly been a very good experience for me overall.



  • I got a PULSE too. I use SLIC3R to slice and then only run the Gcode file through MC to apply the bed leveling. So what you would do is level the bed in mc then Slice in SLIC3R hit export Gcode and save the gcode file to a folder then go into MC and instead of loading the STL you load the GCODE file and then hit print it will add/subtract the Z-offsets for bed leveling but that way you can also use Volumetric E which improves print Quality - if you are interested I made a video on it

    https://www.youtube.com/watch?v=kugqYO-Jang&t=90s



  • @mpirringer

    The issue with that for is that there's no profile for the DXE yet. I know nothing about Gcode and so I'm not really wanting to attempt writing my own. Without the right profile for Cura or some other slicer it wouldn't be able to do the necessary tool changes.


Log in to reply
 

Looks like your connection to MatterHackers Community was lost, please wait while we try to reconnect.