Message-ID: <63192e5f@news.ausics.net> From: not@telling.you.invalid (Computer Nerd Kev) Subject: Re: [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Newsgroups: alt.comp.os.linux,alt.comp.linux,alt.os.linux,comp.os.linux.misc References: User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/2.4.31 (i586)) NNTP-Posting-Host: news.ausics.net Date: 8 Sep 2022 09:50:55 +1000 Organization: Ausics - https://www.ausics.net Lines: 121 X-Complaints: abuse@ausics.net Path: csiph.com!news.mixmin.net!news.ausics.net!not-for-mail Xref: csiph.com alt.comp.os.linux:542 alt.comp.linux:2655 alt.os.linux:76166 comp.os.linux.misc:35610 In comp.os.linux.misc Soviet_Mario wrote: > > I'm completely new to 3D printing, but I do have a XYZ Da > Vinci 3D printer and I've caught sort of an offer for 12 1 > kg coils (6 PLA, 6 ABS), so I am thinking about making sth. Sounds good, but I remember hearing that you needed to buy Da Vinci's own filament "cartridges" for that printer - you're not supposed to refill them using raw coils of filament. That caused lots of outrage years ago and I think there were hacks to allow refilling the cartridges. Maybe they backed down and you can use raw filament with the newer models, but a quick search shows that they're still talking about "cartridges". > I use OpenSCAD for modelling, reasonably well, but that's > all for now. > > So, now ? > I've heard about the keyword "SLICER", but dunno exactly the > function of this kind o sw, though I guess I will need some. You export a mesh in STL format from the 3D modelling software that describes your shape as a lot of triangles in three dimensions, but for printing you need two-dimensional layers that the printer can trace out in sequence. The slicer generates the 2D paths that the print head follows, which at the same time determines the print quality according to things like infill and layer height. > Which one would you best recommend ? None of the newer ones support my old Makerbot Cupcake, so all I've tried is Skeinforge which is a (slow) Python slicer that won't support your printer. It probably won't run on any version of Python that is available for up-to-date Linux distros either. So I can't recommend any, but this does point out that you have to be sure that the slicer supports your 3D Printer. This means that it knows the right commands to tell it what to do. > (formats : .deb, .flatpak, .appimage > I am not very willing to reenable .snaps and I no longer use > windows at all, so let's we exclude it). Prefer .deb if it's available (eg. in your package manager) and works. The flatpak/appimage versions might be newer though, so if there's a feature that isn't in the .deb, then you might look at them. > Another question : those slicers, also suggest the correct > orientation ? I mean, the best orientation for stability of > the intermediate states ? > I am sketching shapes with many hollow spaces (tubes, > fittings, flanges and so). In my world you have to orientate the STL correctly and position it on the build platform before loading it into the slicer. Newer software may have this sort of basic STL manipulation built-in, but it might still be treated as a separate step to the slicing. > Last question : can the slicers guess the "filled" volume ? > This in order to esteem in advance how much plastic one will > consume. The slicer knows the path that the print head follows, all the times when the extruder is turned on/off, and in order to make good prints, the exact amount of plastic that's extruded during the time that the extruder is running. The amount of plastic coming out of the nossle determines the speed that the print head is moved over the path - faster = thinner strings of plastic. So what this means is that the slicer should definately know how much plastic will be consumed, provided all the print settings are correct and it knows the diameter of the filament being used. It doesn't exactly correspond to the volume of the model though, because it depends on the slicer's infill, wall thickness, etc. settings. > Err ... another questions. If one runs out of coil during > printing, the average printer is smart enough to suspend the > work, let the user refill the coil, and resume the work ? Mine sure isn't, but those cartridges that the Da Vinci uses probably know when they've run out. That's actually what people were complaining about when they were introduced because after a cartridge detected that it had run out, it wouldn't accept being refilled - you were supposed to buy another cartridge from the manufacturer instead of just the raw filament. My knowledge is all out of date though, you should check the situation for your model yourself. > sorry another question, LOL > are there DRIVERS for the Da Vinci XYZ 3D printer for debian > ? The CD had only windows drivers ... Maybe this? https://github.com/reality-boy/miniMover That's a controller type program, so you generate GCODE with the slicer and then import in into that program which is able to talk to the printer, so your workflow is: [ 3D modelling program (export STL) ] v [ Slicer (export GCODE) ] v [ 3D printer controller (export printer data format*) ] * Or controls printer directly via serial comms. The slicer still needs to know all the settings for your printer, as well as the specific GCODE commands used by the controller software to do things like turn on/off the extruder. You probably want to find an existing guide for using a printer model like yours with Linux and follow it, because working it all out from scratch could be tricky. -- __ __ #_ < |\| |< _#