The Next Big Thing for open source 3D printing, IMHO: finite elements and stress simulation embedded directly into the slicer software to reduce the amount of material needed to print an object. So many objects I download could be slimmed down (and loo...
-
Jan Wildeboer ๐ท:krulorange:wrote last edited by [email protected]
The Next Big Thing for open source 3D printing, IMHO: finite elements and stress simulation embedded directly into the slicer software to reduce the amount of material needed to print an object. So many objects I download could be slimmed down (and look better) while still doing what they are supposed to do
-
Jan Wildeboer ๐ท:krulorange:replied to Jan Wildeboer ๐ท:krulorange: last edited by [email protected]
A somewhat simpler goal: material independent slicing. Meaning that you have some pseudo g-code coming out of the slicer and the printer itself creates the final g-code on the fly, depending on what filament is loaded. So the same pseudo/intermediate g-code can be used to print an object with PLA and after that with PETG without the need to send new g-code to the printer. Or at the least the printer can refuse to print a file that was sliced for a different filament.
-
Jkoanreplied to Jan Wildeboer ๐ท:krulorange: last edited by
@jwildeboer why have gcode as an input to the 3d printer at all? Wouldn't it be better to have support for obj at the printer itself?
-
Jan Wildeboer ๐ท:krulorange:replied to Jkoan last edited by [email protected]
@jkoan Not sure. Tuning the slicing process (support comes to mind) is better not left to the printer, IMHO. But having to upload three different files because Iโm printing the same object with PLA, PETG and TPU is annoying. Also โ I need to be careful with naming the files to avoid printing with the wrong settings. That could easily be avoided if the printer knows what material the g-code is for and what material it has loaded so it can warn me if it doesnโt match.
-
Dan Winemanreplied to Jan Wildeboer ๐ท:krulorange: last edited by
@jwildeboer Wrong-filament (and nozzle size, and printer model) warnings are already implemented on Prusa printers, and likely others. It prompts you to specify the filament type when you load it, and thereโs metadata in the gcode file header. If they donโt match, the printer complains.
Filament-independent slicing is much trickier, since everything including temperature, speed, cooling, pressure advance, wall order, even support and infill generation can vary.
-
Jan Wildeboer ๐ท:krulorange:replied to Dan Wineman last edited by [email protected]
@dwineman Yes, I know (from some 13 years of experience And I wonder why this problem hasnโt been handled in better ways. Ideally the printer knows how it can print and the slicer knows how to best describe the expected result. Seeing how Bambu Lab, Klipper etc. are moving more of the decisions like dynamic flow/pressure control closer to the nozzle and further away from the slicer (figuratively speaking), Iโm hoping that this will lead to a better layering of what decisions are made where
-
Jan Wildeboer ๐ท:krulorange:replied to Jan Wildeboer ๐ท:krulorange: last edited by
@dwineman The road ahead would be IMHO (In My Humble Opinion) to first have an open standard on metadata in g-code, as a second step a decoupling/abstraction of intermediate g-code that allows for more decision making and optimisation "at the nozzle" which in turn could lead to the decision that g-code might not be the perfect vehicle for that so we could work on "something" that fits better as intermediate standard. The goal being that your printer knows better how to get the perfect result.
-
Dan Winemanreplied to Jan Wildeboer ๐ท:krulorange: last edited by
@jwildeboer The main reason we arenโt there yet, I think, is that printer hardware has just been too computationally underpowered to do analysis like that. Itโs better now, but youโd still be stuck previewing the output on a tiny screen with minimal controls. Unless youโre willing to put a GPU in the printer, or forego gcode preview entirely โ and I wouldnโt trust anything but very simple prints that much โ itโs hard to see how to solve that part.
-
Jan Wildeboer ๐ท:krulorange:replied to Dan Wineman last edited by
@dwineman Oh, don't get me wrong. I don't want to move the slicer to the printer. That would lead to proprietary, lock-in solutions. But the little optimisations like corner speed, dynamic flow control, vibration compensation etc can be done by printers that have the power to do so (and this is already done). So making it easier for the printer to do the right thing by "relaxing" the interpretation of g-code is a valid approach, IMHO. The printer should still just deal with what I throw at it.