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

[Soviet_Mario]

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.

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.

Which one would you best recommend ?
(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).


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

Last question : can the slicers guess the "filled" volume ?
This in order to esteem in advance how much plastic one will
consume.
If not, do you know some 3D manipulation SW that can import
any of the output formats from OpenSCAD and calculate
volumes of 'filled' space of a (COMPLEX !) shape


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 ?


sorry another question, LOL
are there DRIVERS for the Da Vinci XYZ 3D printer for debian
? The CD had only windows drivers ...



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

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

["Followup-To:" header set to alt.os.linux.]

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.

ABS is somewhat challenging to use -- it likes to warp as it cools and
shrinks. You'd do best to start learning with the PLA. I've used both,
without realizing the initial troubles I was having were BECAUSE of the
ABS itself.

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

A slicer is what turns the model (usually saved as a *stl file) into the
gcode that the printer understands.

>
> Which one would you best recommend ?
> (formats : .deb, .flatpak, .appimage

Doesn't really matter; kind of depends how the devs package it for you.
I use Cura, and that comes as appimage.

>
> Another question : those slicers, also suggest the correct
> orientation ? I mean, the best orientation for stability of
> the intermediate states ?

No, the slicer just takes whatever orientation you give it. It can
automatically add support material if needed, but it will not re-orient
the model in the event rotating it will make for a "better" or "easier"
print.

> Last question : can the slicers guess the "filled" volume ?
> This in order to esteem in advance how much plastic one will
> consume.

yes, most will give you an indication of how much plastic you need (Cura
will give a rough length -- e.g. 1 or 2 meters, etc).

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

no. You have to accommodate for that (e.g. splice old / mostly used
spools into one)

> sorry another question, LOL
> are there DRIVERS for the Da Vinci XYZ 3D printer for debian
> ? The CD had only windows drivers ...

I've not come across ever needing "a driver" for the printer -- usually
just a USB -> UART converter chip on the printer.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmMYmkAACgkQbWVw5Uzn
KGCA6Q//SfahMmLrgxvKTYLnly1vCYy9WDC7oEvvAfkTEGsIMWzCpI/Jrl+FDymp
QrFL4LS/v+FfFAER8C4W4J7YmPoI9Fua07q+TMhj3DDSTYikE4AO921cTvgrsp7d
fj2c25SsAnKPgAHcLSjlOS018jZGuk+MjxtQU9M8aBwoEEA4k0n+0HcecvLDKda2
j6h1rkFsKaWD95W2SbPvsoufSawT6m8ZGzurMEMmDy9qsCh4VI6Zqjq7PFFurOLL
KKjt/oL6DK7D2mKLZD95k1Yodts78KG2aL2yPOegZd8Km2qR5AkPO3G8cNMGFHBp
otSFFSO5klyzDm4UFfRcijj2syeXXF26Aof/wF6bvLNsTUlXucOeFlyA25DMtnGo
g1kuDLtAQK+20Vv72LWKP3U+TLkoV/8TnMYc70/L4zOyoRilIsWmAyOuiYq8XCWZ
F8Lyi/Tp98PpKYw2+c0ZnoVW0knH81uG4qz3msSvBA8FHwNwCHcV+bz3bHmlIpsg
l9GomS8ysDRb2lsyVdHLRa47otO/U9KEwPXot3Hye8+74fodOk4b7zpYStIt6XJl
B01KG0gFb1cNBDbdCeKS3+3pdlzeTshJSDGibAfIArUhNj5Aw9nAnwxsgfTFUnXf
dniMa8UpA3Y+5ztCb76+B3B+XSnWB0cae+8qINQa0aAL+oTs10U=
=ZF7B
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

[J.O. Aho]

On 07/09/2022 14.13, Soviet_Mario wrote:

> (formats : .deb, .flatpak, .appimage

As long as you don't have to manually download the packages and install
it, then it don't matter at all.

I do prefer packages for a distro over flatpak/appimage/snaps, as they
have a lot more than just the application itself, which leads to longer
download time as the files are larger.

My distro do have support for flatpak, so those can be simply installed
in the same manner as other applications, which makes updates a bit
simpler, just the download time that bah... sometimes like if you were
installing CUDA SDK.

> are there DRIVERS for the Da Vinci XYZ 3D printer for debian ? The CD
> had only windows drivers ...

No specific driver software needed, that comes with the kernel, but
different manufacturers uses different protocol to talk to the printer
over the usb, which makes not all 3d printers works with Linux, as far
as I know xzyprinting don't really support Linux, they had some version
of their tool back in the days.

What a fast duckduckgo gave me was these two applications that should
work with some models from xzyprinting:

https://www.simplify3d.com/support/hardware-setup-guides/xyzprinting-da-vinci-1-0/
https://github.com/reality-boy/miniMover

[Robert Heller]

There is a CLI program: slic3r and a GUI program: cura. Both should be
available in your distro's repository. On my Ubuntu 18.04 system:

sauron% dpkg-query -l slic3r cura
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii cura 3.1.0-1 all GUI G-code generator for 3D print
ii slic3r 1.2.9+dfsg-9 amd64 G-code generator for 3D printers

Once you have your CAD software export a .stl file, either of these programs
can generate a gcode file. Then it is a matter of transporting that gcode
file to the printer.

Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
hel...@deepsoft.com -- Webhosting Services

[Computer Nerd Kev]

In comp.os.linux.misc Soviet_Mario <Sovie...@cccp.mir> 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.

--
__ __
#_ < |\| |< _#

[Soviet_Mario]

On 07/09/22 17:23, Robert Heller wrote:
> There is a CLI program: slic3r and a GUI program: cura. Both should be
> available in your distro's repository. On my Ubuntu 18.04 system:
>
> sauron% dpkg-query -l slic3r cura
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==============-============-============-=================================
> ii cura 3.1.0-1 all GUI G-code generator for 3D print
> ii slic3r 1.2.9+dfsg-9 amd64 G-code generator for 3D printers
>
> Once you have your CAD software export a .stl file, either of these programs
> can generate a gcode file. Then it is a matter of transporting that gcode
> file to the printer.
>

TNX, I'll look for this packages.

[Soviet_Mario]

On 07/09/22 16:51, J.O. Aho wrote:
> On 07/09/2022 14.13, Soviet_Mario wrote:
>
>> (formats : .deb, .flatpak, .appimage
>
> As long as you don't have to manually download the packages
> and install it, then it don't matter at all.
>
> I do prefer packages for a distro over
> flatpak/appimage/snaps, as they have a lot more than just
> the application itself, which leads to longer download time
> as the files are larger.
>
> My distro do have support for flatpak, so those can be
> simply installed in the same manner as other applications,
> which makes updates a bit simpler, just the download time
> that bah... sometimes  like if you were installing CUDA SDK.

CUDA not CURA as said Dan Purgert ... ok, note taken. Tnx

>
>
>> are there DRIVERS for the Da Vinci XYZ 3D printer for
>> debian ? The CD had only windows drivers ...
>
> No specific driver software needed, that comes with the
> kernel, but different manufacturers uses different protocol
> to talk to the printer over the usb, which makes not all 3d
> printers works with Linux, as far as I know xzyprinting
> don't really support Linux, they had some version of their
> tool back in the days.

But I'll possibly not even connect the printer with the PC.
Just to save the final project file in the correct format
and to transfer it into the USB port.
I had a misconcept about this process

>
> What a fast duckduckgo gave me was these two applications
> that should work with some models from xzyprinting:
>
> https://www.simplify3d.com/support/hardware-setup-guides/xyzprinting-da-vinci-1-0/
>
> https://github.com/reality-boy/miniMover
>

I'll have a look, tnx

[J.O. Aho]

On 08/09/2022 00.42, Soviet_Mario wrote:
> On 07/09/22 16:51, J.O. Aho wrote:
>> On 07/09/2022 14.13, Soviet_Mario wrote:
>>
>>> (formats : .deb, .flatpak, .appimage
>>
>> As long as you don't have to manually download the packages and
>> install it, then it don't matter at all.
>>
>> I do prefer packages for a distro over flatpak/appimage/snaps, as they
>> have a lot more than just the application itself, which leads to
>> longer download time as the files are larger.
>>
>> My distro do have support for flatpak, so those can be simply
>> installed in the same manner as other applications, which makes
>> updates a bit simpler, just the download time that bah... sometimes
>> like if you were installing CUDA SDK.
>
> CUDA not CURA as said Dan Purgert ... ok, note taken. Tnx

CUDA is for nVidia graphics cards, was just using it as an example of a
big package that generally takes long time to download as it's in size a
few gigs.

>>
>>
>>> are there DRIVERS for the Da Vinci XYZ 3D printer for debian ? The CD
>>> had only windows drivers ...
>>
>> No specific driver software needed, that comes with the kernel, but
>> different manufacturers uses different protocol to talk to the printer
>> over the usb, which makes not all 3d printers works with Linux, as far
>> as I know xzyprinting don't really support Linux, they had some
>> version of their tool back in the days.
>
> But I'll possibly not even connect the printer with the PC. Just to save
> the final project file in the correct format and to transfer it into the
> USB port.
> I had a misconcept about this process

Yes, that a possibility as long as the printer do support it.

--

//Aho

[Soviet_Mario]

On 08/09/22 01:50, Computer Nerd Kev wrote:
> In comp.os.linux.misc Soviet_Mario <Sovie...@cccp.mir> 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 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.
>


--

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

["Followup-To:" header set to alt.os.linux.]
Soviet_Mario wrote:

> On 07/09/22 16:51, J.O. Aho wrote:
>> On 07/09/2022 14.13, Soviet_Mario wrote:
>>
>>> (formats : .deb, .flatpak, .appimage
>>
>> As long as you don't have to manually download the packages
>> and install it, then it don't matter at all.
>>
>> I do prefer packages for a distro over
>> flatpak/appimage/snaps, as they have a lot more than just
>> the application itself, which leads to longer download time
>> as the files are larger.
>>
>> My distro do have support for flatpak, so those can be
>> simply installed in the same manner as other applications,
>> which makes updates a bit simpler, just the download time
>> that bah... sometimes  like if you were installing CUDA SDK.
>
> CUDA not CURA as said Dan Purgert ... ok, note taken. Tnx

CUDA is nVidia's GPU tech. Used a lot in heavy math / supercomputing
applications as I recall (and, of course, gaming).

CURA is a slicer for 3d Printers.



-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmMbJOQACgkQbWVw5Uzn
KGCs5A/+ODSww+N4e2FKojNOsjmJuORdPPVTInv6uZvcerFmt48KDBHcra1m+EFU
SaOc0Cailx2CFmICaZbRYigdVaKQXwJ28gpY6NlBmmvyHQlzSq+FtE+4/+5Qtzt6
JTgY2B3bKHTkTgx6p6qEUVp7/iWr2ZwsejWbiW3U7cyTYGZLzEufmlfNoRR2uwpp
LrggYU+PtXIlOr47SowUTTM0q0yopssLhKuhxRdT4gbJmeWjF5e/HDsmsVqXGrt1
jzaFEc5cB6KuJMCxG1S0aBVwAIlyQZyOwsc7hNpIRzvDVtHQrRBU8/aTwUmaoB2M
6OGfvVZR/v79M3Scql8TWm/BnaBCGTr+vFOzc/UrSAn+MNMr0SWToeHNzx+qU1k3
u+/AbICOgtzT+tqPTLgtzHdhqATFsyXy/CGJHnA6m5nrNz0t2eNkegatEFDt9aWo
sUNMNXGOpGqfHZ28AYzEMGMB1tsUwGfNo+RdhNzbFlauA75hyBYjAb64PV9509rm
cJ7fYFYSCZGaeeUu8KMzp6XuZNP2aLXApbgC/+HQDg0CH3iMfu4YHvkdpASeNhTW
xah3IHHOmW2nfID72kVMDfLM0u+Fa7e6IqCVb+MpeinR114CrcMjYciFg2atX4c5
impA7/gd0EuokGgWCDn0MgZzk+tYxkXe1iBFVTIePfUc10ssGFU=
=T0Hk

[J.O. Aho]

On 12/09/2022 12.28, Dan Purgert wrote:
> Aragorn wrote:
>> On 09.09.2022 at 11:34, Dan Purgert scribbled:

>
>>> CUDA is nVidia's GPU tech. Used a lot in heavy math / supercomputing
>>> applications as I recall (and, of course, gaming).
>

>> Nowadays, it's SPECIFICALLY being used for cryptocurrency mining. And
>> Nvidia has now even begun developing GPUs which specialize in that.
>
> Yeah, but GPUs for crypto are so 2010. Thought it all moved over to
> ASICs for that?

Depends on the crypto you are mining, there are some which has
intentionally made it difficult to use ASICs. Changes in the cyrpto
chain could cause that the ASIC you have to be outdated and needs to be
replaces with new hardware.

--

//Aho