Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #76159 > unrolled thread

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

Back to article view | Back to alt.os.linux

Contents

  [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Soviet_Mario <SovietMario@CCCP.MIR> - 2022-09-07 14:13 +0200
    Re: [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Dan Purgert <dan@djph.net> - 2022-09-07 13:18 +0000
      Re: [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Soviet_Mario <SovietMario@CCCP.MIR> - 2022-09-08 00:39 +0200
        Re: [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Dan Purgert <dan@djph.net> - 2022-09-09 12:18 +0000
    Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) "J.O. Aho" <user@example.net> - 2022-09-07 16:51 +0200
      Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Soviet_Mario <SovietMario@CCCP.MIR> - 2022-09-08 00:42 +0200
        Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) "J.O. Aho" <user@example.net> - 2022-09-08 07:56 +0200
        Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Dan Purgert <dan@djph.net> - 2022-09-09 11:34 +0000
          Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Aragorn <telcontar@duck.com> - 2022-09-09 19:08 +0200
            Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Dan Purgert <dan@djph.net> - 2022-09-12 10:28 +0000
              Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) "J.O. Aho" <user@example.net> - 2022-09-12 14:36 +0200
              Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) 5GyYap52yQ1UGMWD <ehj46PkBWfBAng9C@VW28LtWn6wknpUMV.invalid> - 2022-09-12 21:29 +0800
                Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Paul <nospam@needed.invalid> - 2022-09-12 13:58 -0400
                  Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) 5GyYap52yQ1UGMWD <ehj46PkBWfBAng9C@VW28LtWn6wknpUMV.invalid> - 2022-09-13 08:41 +0800
                    Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Paul <nospam@needed.invalid> - 2022-09-13 03:20 -0400
                      Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) 5GyYap52yQ1UGMWD <ehj46PkBWfBAng9C@VW28LtWn6wknpUMV.invalid> - 2022-09-13 16:38 +0800
              Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Aragorn <telcontar@duck.com> - 2022-09-12 20:58 +0200
                Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Dan Purgert <dan@djph.net> - 2022-09-13 10:12 +0000
    Re: [crosspost] recommended slicers for 3D printer and 'filled' volume? estimation (drivers, consumes and so) Robert Heller <heller@deepsoft.com> - 2022-09-07 15:23 +0000
      Re: [crosspost] recommended slicers for 3D printer and 'filled' volume? estimation (drivers, consumes and so) Soviet_Mario <SovietMario@CCCP.MIR> - 2022-09-08 00:43 +0200
    Re: [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) not@telling.you.invalid (Computer Nerd Kev) - 2022-09-08 09:50 +1000
      Re: [crosspost] recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so) Soviet_Mario <SovietMario@CCCP.MIR> - 2022-09-08 03:18 +0200

Page 1 of 2  [1] 2  Next page →

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

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)

[toc] | [next] | [standalone]

#76160

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

[toc] | [prev] | [next] | [standalone]

#76167

On 07/09/22 15:18, Dan Purgert wrote:
> ["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.

I've been warned many times about this :(

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

ok, I'll assess if OpenSCAD is able to export into this 
format then.

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

perfect. CURA then.

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

so how to choose a proper orientation ?
I will have to print a collector : a large howllos pipe with 
flanges at the edges and some ten much smaller "barbed" 
pipes on one side, emergint at 90° to the main axis.

I really dunno how it would be better posed.

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

if it assumes the same diameter of my filament, the length 
would be equivalent to a volume of plastic.

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

is it possible ? With splice you mean "weld" two parts 
together ? The welding is smooth enough not to clog the 
nozzle ? is strong enough not to tear ?

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

the printer has an USB port. I'll format one in VFat, for 
precaution. I've never used any printer, so I dunno if the 
display will be clear enough. Hope so. First experiments 
will start aroung Christmas maybe, I tend to collect info in 
large advance if possible.
TNX

> 
 >

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

[toc] | [prev] | [next] | [standalone]

#76173

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

Soviet_Mario wrote:
> On 07/09/22 15:18, Dan Purgert wrote:
>> ["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.
>
> I've been warned many times about this :(

In all honesty, a couple cardboard boxes made a pretty passable
enclosure for my printer when handling ABS.  I just let it sit and
preheat for 15-20 minutes before starting the print; and then when it's
done, let the "chamber(tm)" come down to room temperature.

>>> [...]
>>> 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.
>
> so how to choose a proper orientation ?

Manually. Really depends on the part in question -- some stuff you can
just intuit (e.g. printing a toy horse will SUCK to try cleaning
supports out from beneath its belly / between its legs); other stuff
sometimes is a bit of trial-and-error

> I will have to print a collector : a large howllos pipe with 
> flanges at the edges and some ten much smaller "barbed" 
> pipes on one side, emergint at 90° to the main axis.

3d printers aren't really geared towards making fluid-tight parts.  I
mean, you can certainly make a quick fix for say your garden irrigation
system that runs at ~10 PSI / ~70 kPA ; but much more than that, you're
probably just gonna break the part.

It probably won't matter for a part like you described, but curved parts
are "difficult" -- you basically never get a smooth curve in the Z
dimension (it'll be a series of steps, based on layer height / nozzle
diameter / etc).

Finally, you also have to consider that the parts are weakest at the
layer lines. For example, if you print a 20x20x200mm part that's laying
on its side (i.e. X or Y is 200mm long), it will be a LOT harder to
break than an identical part where Z was the 200mm dimension.


>>> 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).
>
> if it assumes the same diameter of my filament, the length 
> would be equivalent to a volume of plastic.

You have to tell the slicer the filament's diameter (usually 1.75mm
nominal for a desktop / hobby 3d printer). 

Do bear in mind that there are a number of factors that go into a
print's plastic consumption; so there is not a 1:1 relationship between
"part size" and "filament used". 

>
>> 
>> 
>>> 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)
>
> is it possible ? With splice you mean "weld" two parts 
> together ? The welding is smooth enough not to clog the 
> nozzle ? is strong enough not to tear ?

Yeah,  heat up the two ends until they're soft enough to fuse, and stick
them together. Clean up any resulting blob of plastic with a knife after
its' cooled.  It really only needs to be strong enough of a joint to
survive being pulled into the extruder.

I've considered using an aluminum block to make a jig (plus a
replacement heating element off ebay) ... just haven't gotten around to
it.  A soldering gun with a tip I don't care about works well enough
today.

>
>> 
>>> 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.
>
> the printer has an USB port. I'll format one in VFat [...]

Check what the printer can read from the SDCard -- most will do FAT or
NTFS since that's what they come preformatted as.  

The USB port is probably just a bog standard FTDI USB -> USART
converter; or one of the various chinese parts that're similar (such as
the CH340s that come on a lot of Arduino clones).  Easiest way to check
is probably the printer documentation, or a community forum.


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

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmMbL0QACgkQbWVw5Uzn
KGCy+w/9Hl6QLvz5H8y59U1C1YVV3jinxRAW83QTbsZK62VTTSaacp47te2ExIS2
yS7MMANW4AGq+4qArUczAiVQyugbocyf4wISvVhyZHfgxgOXhDoisRivYVnqaSrW
6MafXktolJhTcC8EVYuD1SVynVRDnd96LyYk2zSxqdEVlt41+asW7RqLLQrxzlMY
ILnaF8nwELSxOwfz/0HFB1LEWNW5S/2ZLTngEnfwWPt8GMC2Jz+qDQD2ZCbH7VYY
JDGGRB1uzVxg5km+CGduESDPj98XGV+NlMVmlV5OXQBPoD/n05hfD0F7uX8mAY6l
mtM80wMmCEzrVIELsdZrhtYK4SLJ3AWuJF6JCphqItmkpyVRVf77tJj0SGgRSbdF
DfNojsroBZIeHkRehdllj6qe3as4qBYwUdMPjVmRZCP96o74iB+dv0UNoAI8or75
U4gcbJWxRNP7kFG9RAjAvLKwAMbn/GdOa6vqSC3eE7xubmvJp/bzUJdxBwWK5OCL
rHwUjNUxhai0Rc4JZUkIAPi9uyd7Xa6DPNxYGUtf9GHB+Xl3iz7h8OGzf8nmdFmW
JZqPjcn/KcAtP93KOShqpF5PP76eFM4pbjhpIzmAzeaLn0vspJ/bgwqKtgWOOuc7
ISie/C8Snq/G+LMuWXvFCoEn+Zkw4krpgqOkRxrBqcLc5A0648s=
=DXHS
-----END PGP SIGNATURE-----

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

[toc] | [prev] | [next] | [standalone]

#76161 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

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

[toc] | [prev] | [next] | [standalone]

#76168 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

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



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

[toc] | [prev] | [next] | [standalone]

#76170 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

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

[toc] | [prev] | [next] | [standalone]

#76172 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

-----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
-----END PGP SIGNATURE-----

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

[toc] | [prev] | [next] | [standalone]

#76174 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

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.

You know, the way smartphones are still actually phones but are used
for lots of other things. ;)

-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#76190 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

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

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?


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

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmMfCfgACgkQbWVw5Uzn
KGANBBAAiqROqu6IBq2dcl4eEBVSZCin4hzorkgGd6q8g1Zyfa1HLmyLbhkEEPNQ
7Ni3ePbN33dCSwxj16VtChF9AHcsavT386HAgMXASwHcLLImWJFQiLuQQgP1chwJ
fhYhVG8USIhmaJTuMg5qAryaGivfK9dG2muSuwVhbXnRv7iRm4TblSN5t4O090iD
ctNWo9s2tVnIJsQRu/jFfaPvxPB7GuNAKuZq9bEfMG5QjNhIBQYHLke9++zWeWB+
bJSa9xIpBh3nWH+8s5AQNbAwPEMrFggrh1zImYsfWMRRBNEmCb/AmdNyU/S37inH
pSwnSajS5xAFNjpBX4qCYCOQeX+14WRS1kyDRrPTdMdD+la7M4fvcKkT1taVL1Tq
UlC2meuogjy/2rn/E+Mh3yb3hYQoalsE0mQRfDGp/ax3U2C5R9pi7lU3kXrkfJOq
MVeAwaIfkp6Lk6fGyUBSspEv25fT/9j4ynTWs8uCtHHhRvwvngNRvt9xqQ5lsO/6
TrySPYhTufTAhwpUTxx0rsEbFT7IAIFbx2KCF0Xix5gBFOvbFKt2uT1Bg40aFcss
ekBl3X8/hzgOY440EHxNAf69NsFFKLZaDMRtimHrGt61BLVs2ytu6Xak5dngi+Kc
nLdq3vAfdBUbcLMxAP6LcosC7drqu7HPaxrT0iISLpCc3TB8/14=
=AoAD
-----END PGP SIGNATURE-----

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

[toc] | [prev] | [next] | [standalone]

#76191 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

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

[toc] | [prev] | [next] | [standalone]

#76192 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

Dan Purgert <dan@djph.net> writes:

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

It  depends on  the crypto  that you're  mining. Bitcoin  has definitely
moved into  ASICs but  Ethereum is,  or rather was,  sucking up  the GPU
market. I believe  they're moving to a different way  of doing things so
the demand for GPU for mining might die down soon.

-- 
Pointless meanderings in a bleak and lonely world.

[toc] | [prev] | [next] | [standalone]

#76195 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

On 9/12/2022 9:29 AM, 5GyYap52yQ1UGMWD wrote:
> Dan Purgert <dan@djph.net> writes:
> 
>> 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?
> 
> It  depends on  the crypto  that you're  mining. Bitcoin  has definitely
> moved into  ASICs but  Ethereum is,  or rather was,  sucking up  the GPU
> market. I believe  they're moving to a different way  of doing things so
> the demand for GPU for mining might die down soon.
> 

Ethereum is done with ASIC too.

But I can't find any pictures to show you. And that's more than
a bit weird, as I thought by now there would be a picture of an
Ethereum ASIC board.

The whole idea behind Ethereum, was to use
memory bandwidth as a proof of work. That's what
constrains the coin creation rate. It's not compute power
limited, it's memory bandwidth limited. If you use your CPU,
the system memory has poor bandwidth, and a CPU can't really do that
many lookups per second. The CPU caches are useless. The Ethereum
method would presumably (on purpose) be a cache-buster.

A GPU has a nice memory array (need 4GB min to handle
proposed blockchain growth). It can have 300GB/sec of bandwidth, with
multiple accesses going on at the same time.

For an ASIC to compete, is simple. Connect a bunch of memory
chips to the ASIC, get some bandwidth. Rinse and repeat.
With enough "small ASIC chips", you can control a lot of memory,
and consequently, via parallelism, do a lot more memory
lookups than the GPU can do.

For Ethereum on a GPU, you crank down the core speed (since the core
is not a limiting factor), and crank up the memory clock. That
gives you the best power characteristic. But, you're competing
against an ASIC mining box, where those optimizations have already
been done.

*******

CPU  - flexible mining, reprogrammable, poor performance
FPGA - flexible mining, reprogrammable, meh performance (thermal limits)
GPU  - flexible mining, reprogrammable, modest performance
ASIC - inflexible mining, not typically reprogrammable, kickass performance

The big mining operations may select GPUs, so they can alternate
between mining Etherium and Monero. When Ethereum moves to Proof-of-Steak,
you just re-load with Monero mining code, without even blinking.
Or even Dogecoin, if there's a profit in it this week.

That to me, would be the main advantage of the GPU, is reprogramming.
Nobody wants to throw away all their Bitmain boxes, on a whim.
It takes a hell of a lot of mining, to pay for the box. Imagine
having a $25 million hardware investment being wiped out instantly.

Since Bitcoin is algorithmically stable, more boxes have been
made for that as a result (Intel making a box, this late in the
game, is an example). But it cannot stay that way forever.
Technology marches onward.

What's impressive about the Intel chip, is the 0.355V core voltage
to run it. A lot lower than my GPU at 0.9V core voltage. When I took
engineering, nobody dreamed back then, that we'd get under a volt.
It's getting ridiculous :-) This is one reason the power tracks
feeding these silly things, are getting wider and wider. You
could be talking hundreds of amperes, coming from the SMPS on
the board.

https://www.anandtech.com/show/17218/intels-next-gen-bitcoin-asic-called-bzm2-built-on-7nm-137-gigahashsec-at-25-w

    Paul

[toc] | [prev] | [next] | [standalone]

#76199 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

Paul <nospam@needed.invalid> writes:

> On 9/12/2022 9:29 AM, 5GyYap52yQ1UGMWD wrote:
>> Dan Purgert <dan@djph.net> writes:
>> 
>>> 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?
>> It  depends on  the crypto  that you're  mining. Bitcoin  has
>> definitely
>> moved into  ASICs but  Ethereum is,  or rather was,  sucking up  the GPU
>> market. I believe  they're moving to a different way  of doing things so
>> the demand for GPU for mining might die down soon.
>> 
>
> Ethereum is done with ASIC too.
>
> But I can't find any pictures to show you. And that's more than
> a bit weird, as I thought by now there would be a picture of an
> Ethereum ASIC board.
>

Odd. Maybe Ethereum did have ASIC  boards running on the network. Though
most of the people  that I knew who are doing  Ethereum mining are using
GPUs. Though I wouldn't blame them, ASICs is horribly expensive and it's
a long-term investment.  GPUs can  be repurposed for different tasks and
it's easier to unload them to the market.

> [...]
>
> The big mining operations may select GPUs, so they can alternate
> between mining Etherium and Monero. When Ethereum moves to Proof-of-Steak,
> you just re-load with Monero mining code, without even blinking.
> Or even Dogecoin, if there's a profit in it this week.
>

I  don't think  you  can mine  monero  using a  GPU.  RandomX is  highly
resistant to GPU mining.

> That to me, would be the main advantage of the GPU, is reprogramming.
> Nobody wants to throw away all their Bitmain boxes, on a whim.
> It takes a hell of a lot of mining, to pay for the box. Imagine
> having a $25 million hardware investment being wiped out instantly.
>

I agree.  But I  think ASICs  also contributed to  the stability  of the
Bitcoin hashrate over time. Having specialized hardware to do the number
crunching will  create dedicated  miners that  are "in  it for  the long
run."

There's pros and cons to that, of course, but I think the current steady
hashrate of Bitcoin had something to do with the miner market.

> Since Bitcoin is algorithmically stable, more boxes have been
> made for that as a result (Intel making a box, this late in the
> game, is an example). But it cannot stay that way forever.
> Technology marches onward.
>

This is what  you'd want on a  monetary good though. One  of the reasons
why I'm very averse with anything to  do with Ethereum is that they have
a track  record of being sporadic  with their design goals  and monetary
policies.

I mean, this  shift to proof-of-stake just shows this  trend. Though I'm
not that well  versed with smart contracts and if  this sporadic changes
in  design  has anything  to  do  with  that  since I'm  only  following
cryptocurrencies that aim to be digital cash (i.e: bitcoin and monero).

> What's impressive about the Intel chip, is the 0.355V core voltage
> to run it. A lot lower than my GPU at 0.9V core voltage. When I took
> engineering, nobody dreamed back then, that we'd get under a volt.
> It's getting ridiculous :-) This is one reason the power tracks
> feeding these silly things, are getting wider and wider. You
> could be talking hundreds of amperes, coming from the SMPS on
> the board.
>
> https://www.anandtech.com/show/17218/intels-next-gen-bitcoin-asic-called-bzm2-built-on-7nm-137-gigahashsec-at-25-w
>
>    Paul
>

That's cool.

What I find interesting, though, is  that intel is getting into the ASIC
game. I  wonder what  people will  think of that.  Maybe the  prices for
these things will  slowly drop as bigger  manufacturers produce hardware
for these applications.

-- 
Pointless meanderings in a bleak and lonely world.

[toc] | [prev] | [next] | [standalone]

#76200 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

On 9/12/2022 8:41 PM, 5GyYap52yQ1UGMWD wrote:
> Paul <nospam@needed.invalid> writes:
>>
>> https://www.anandtech.com/show/17218/intels-next-gen-bitcoin-asic-called-bzm2-built-on-7nm-137-gigahashsec-at-25-w
>>
> 
> That's cool.
> 
> What I find interesting, though, is  that intel is getting into the ASIC
> game. I  wonder what  people will  think of that.  Maybe the  prices for
> these things will  slowly drop as bigger  manufacturers produce hardware
> for these applications.

To Intel, that project is just something to fill a few slots
in the fab production schedule. Same as their GPU business.

The Bitcoin chips are interesting, because not only have they
managed to convince someone to buy some of the chips for
box manufacturing. They also look to be using the Bitcoin
chips as fab "pipe cleaner" designs. When tuning a process for
yield, you need a test chip, and normal test chips are pretty
boring. Why not make a test chip... you can sell. I can see
the attraction there.

    Paul

[toc] | [prev] | [next] | [standalone]

#76201 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

Paul <nospam@needed.invalid> writes:

> On 9/12/2022 8:41 PM, 5GyYap52yQ1UGMWD wrote:
>> Paul <nospam@needed.invalid> writes:
>>>
>>> https://www.anandtech.com/show/17218/intels-next-gen-bitcoin-asic-called-bzm2-built-on-7nm-137-gigahashsec-at-25-w
>>>
>> That's cool.
>> What I find interesting, though, is  that intel is getting into the
>> ASIC
>> game. I  wonder what  people will  think of that.  Maybe the  prices for
>> these things will  slowly drop as bigger  manufacturers produce hardware
>> for these applications.
>
> To Intel, that project is just something to fill a few slots
> in the fab production schedule. Same as their GPU business.
>
> The Bitcoin chips are interesting, because not only have they
> managed to convince someone to buy some of the chips for
> box manufacturing. They also look to be using the Bitcoin
> chips as fab "pipe cleaner" designs. When tuning a process for
> yield, you need a test chip, and normal test chips are pretty
> boring. Why not make a test chip... you can sell. I can see
> the attraction there.
>
>    Paul
>

That's interesting. It's nice to see it from that perspective.

-- 
Pointless meanderings in a bleak and lonely world.

[toc] | [prev] | [next] | [standalone]

#76198 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

On 12.09.2022 at 10:28, Dan Purgert scribbled:

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

Not according to what I've read on Slashdot only a few weeks ago.  But
your 1.6x-kilometerage may vary. :p

-- 
With respect,
= Aragorn =

[toc] | [prev] | [next] | [standalone]

#76202 — Re: recommended slicers for 3D printer and 'filled' volume estimation (drivers, consumes and so)

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

Aragorn wrote:
> On 12.09.2022 at 10:28, Dan Purgert scribbled:
>> Aragorn wrote:
>>> On 09.09.2022 at 11:34, Dan Purgert scribbled:
>>>> CUDA is nVidia's GPU tech.  Used a lot in heavy math [...]
>>>
>>> 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?
>
> Not according to what I've read on Slashdot only a few weeks ago.  But
> your 1.6x-kilometerage may vary. :p

Or I just don't pay attention to changing trends :)


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

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmMgV8YACgkQbWVw5Uzn
KGB1uQ//WgSTktcvHFePIL3FdKaT4Ej4vJ+E3Ljf1+u/8sTm1XTLWVOpLSDI4i4q
59Z5hjFrmyHGWc/M/hp+ZSabOOORwb8dcHm5q5Ly45se2u1HWkZd5PVR09q7sEVm
RMoUX4Gd+0XZqv1gDAlqH+7gnE3JTQNKOgR921Xjtfto9qktqrIoKbfDZ5+husIw
qNNI7lp9RpISABTGSAS1LfROirn6fVOeC7G+AFaPY2Msg/rmg9xYBPmL0iBMg5Hj
SQkd+gY3X57CP0qAdkdTer/K/PgGx19oeT6FDtFrFMkWJrvLkmi2Peh5+ssJuaEm
yjZHjEP6GJI4ZumkAVbEsHMv9dNhT2NGh7VPctPAyh4RXpUtU28nTw4asY5tivm+
xXdKQkdrRvHK9lEvN9syBt0d+Na80FEVWLC9Y0XqQzpRjAYGMd2SvSmuMn6AWJx0
s/Y4iVOD2svDqRAbnSesrMXMp9s4ZD/yTZzVvDHZmRHv8q5V2fiAsWjMcF25mI5i
WnO2oehU7ZtiedecsWdX7aFBNK3nAb119118VAOeTzN0sLjgVNRTdS14GO/jsyJp
Z7ue6CZAboDDpiGawcPB6nZ4eewn5Fe9whsMC0JyQgEbnPRW6n+bZEsjeF4UDOPx
4/kZqx7UD/Mn9meRy/9+K81s63ejE/Xk1a8P2ZmFeJ53r7V4QpI=
=1xsy
-----END PGP SIGNATURE-----

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

[toc] | [prev] | [next] | [standalone]

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

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.


At Wed, 7 Sep 2022 14:13:37 +0200 Soviet_Mario <SovietMario@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.
> 
> 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 ...
> 
> 
> 

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

[toc] | [prev] | [next] | [standalone]

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

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.

> 
> At Wed, 7 Sep 2022 14:13:37 +0200 Soviet_Mario <SovietMario@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.
>>
>> 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)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.os.linux

csiph-web