Re: [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

On 08/09/22 01:50, Computer Nerd Kev wrote:
> In comp.os.linux.misc Soviet_Mario <[email protected]> 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".

OMG ... you are right. I had completely forgotten this 
topic, but now that you've refreshed my memory, yes, I had 
just read of that :\ Alas the purchase has just been made.
The model dates back to 2017, so it is 5 years old. Dunno. I 
recall some dedicated device was invented to reset the coil 
chip state.
#mainagioia (a storming saying here in italy, to express 
dissatisfaction) :D

> 
>> 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.

I am afraid is still actual, since my printer dates back to 
2017 even if it was not even taken out of the box :\

TNX for the reply, a serious problem to be addressed :\


> 
>> 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.
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)