
CUPS 2.1 Is Adding Basic 3D Printer Support - tomkwok
http://www.cups.org/blog.php?L1087
======
TazeTSchnitzel
This makes more sense than it might first appear. By adding this to CUPS, you
can take advantage of its print spooler, filter pipeline, and OS connectivity
support (USB, parallel, etc.).

~~~
contingencies
Also logical is integration with existing program UI dialogs, print to file
and other features.

 _Added support for 3D printers (basic types only, no built-in filters) based
on PWG white paper._ ... can anyone find the white paper?

~~~
rasz_pl
No, it makes no sense. Right now 3D printers eat files, so printing to file is
tautology. 3D printers also tent to be very unreliable, you need ability to
pause the print (jams, skips). How is putting CUPS between you and the printer
helpful?

~~~
jonhohle
In addition to the other replies, there is also the ability to unify slicing
from common formats into the data necessary for each individual printer.

I'm not up to date on the current state of the art, but 15 years ago
industrial 3D printers required solid model generation, slicing using either
some proprietary software or solidworks, and transmission to the device over
network share, ftp, or sneakernet. Some or all of those parts could be common
to a print system, reducing the scope for machine vendors, and allowing
operators to mix and match components in interesting ways.

~~~
Vendan
> 3D printers required solid model generation, slicing using either some
> proprietary software or solidworks, and transmission to the device over
> network share, ftp, or sneakernet.

These days(for me, and most of the stuff I've seen) it's solid model
generation, slicing using free/open source(slic3r or equivalent), transmission
over usb.

It's an interesting idea, but part of the problem is slicing is currently a
tricky operation. I change settings based on a variety of things. I'm not
certain what this is cutting out, cause I doubt they made their own slicer. If
this is just taking pre-sliced data files, then you have to run everything
through your slicer before you can send it to CUPS anyways. If they are
integrating a slicer into CUPS, that'd be interesting, but I'd be really
interested to see how they handle the many many settings that you can(need) to
configure to get your slicer to output a file that the printer will work with.

Another issue is quality of progress display. I like to be able to see the
print while it's printing, and track variables like temp of the printhead and
progress through the print. Bear in mind, the average hobbyist 3d printer is
going to take more then a couple hours to print anything of halfway decent
size, so "oh you can just sit and watch it" isn't an answer. I personally use
OctoPrint, which lets me track the print, and even see it using a webcam.

------
dekhn
I stopped printing on Linux when it switched from the old printcap based tools
(which while hard to configure, mostly worked) to CUPS. I was an experienced
sysadmin, but no amount of configuration could make CUPS print anything but
the text of postscript files to my laser printer.

I'm sure it's gotten much better, but CUPS is pretty opaque, and when you're
doing 3D printing, controlling the conversion pipeline from model to print
code is typically done manually with a great attention to detail.

~~~
kitsunesoba
I'm kind of surprised to hear that CUPS gives some people so much trouble.
I've been using OS X and Linux since around 2001 and neither have given me any
mentionable trouble with printing. It's always been install drivers ->
flawless printing. In the case of my newest printer, I didn't even need to
install drivers since it's AirPrint compliant. CUPS has been great for me.

~~~
TD-Linux
This mirrors my experience. When I was in college I was always able to plug
some random person's printer in via USB and it "just worked". I'm also able to
autodiscover and print to all of the laser printers at work. (this is on
Linux)

~~~
avian
Have you tried debugging things when cups doesn't "just work"? printcap was
much simpler, which made it easier to understand and diagnose problems.

In general I think there's a positive correlation between the precentage of
cases where software "just works" with no manual intervention and the effort
required to diagnose the cases where it doesn't.

~~~
dekhn
Yes, I spent plenty of time debugging CUPS in the old days. But I haven't, in
ages. printcap may have been simpler, but shortly before CUPS was released,
the linux implementation had matured significantly and could do many basic
conversion operations. Distros supported this and handled things like
ghostscript conversion.

These days, I print in a number of ways that work fine, including Mac OS X (a
version of CUPS which has already been debugged and polished for many printers
I use), Windows (my preferred printing system since it supports the largest
number of printers), and Google Cloud Print (for the set of printers I use
that have that as their access protocol).

------
decktech
Maybe someone can explain how this works to me: In the white paper
([http://ftp.pwg.org/pub/pwg/BOFs/3d-printing/wd-apple-
ipp3d-2...](http://ftp.pwg.org/pub/pwg/BOFs/3d-printing/wd-apple-
ipp3d-20150123.pdf)) section 5, it lists a bunch of attributes ("material-
type", "filament-retraction-speed", etc.) These are all attributes that would
be inputs to a slicer. Furthermore, there are a million such parameters (CUPS
will never cover them all), are different between different slicers, are ever-
changing, and sometimes undocumented.

Why would cups concern itself with these parameters, versus, for example, just
acting as a transport for the actual print file (gcode, x3g, etc.)? I feel
like this is akin to having CUPS assemble a PDF, versus just acting as a
transport for postscript file that gets printed.

~~~
marcosdumay
Well, CUPS does assembly PDFs nowadays.

------
cmurf
OS X's been using CUPS for a long time and, as other OS X users have noted,
doesn't have the reliability problems people are reporting here on Linux. So
those problems must have to do with things that aren't directly CUPS related,
like possibly an application, PPD, Ghostscript, backend, or network or USB
problem. Each distro packages this up a bit differently and with different
versions so that could also be part of the inconsistency.

------
bitL
Offtopic: What is currently the best home 3D printer? I am looking for
something that produces reasonable level of detail and items that aren't
easily destroyed by applying slight rotational forces.

~~~
ZenoArrow
What's your budget? 3D printers for home use vary in price from a few hundred
dollars to many thousands of dollars. Also, they vary quite a bit in terms of
the materials they support printing.

If you want one example of a good high end 3D printer for the home market, I'd
say take a look at the Form 1+:

[http://formlabs.com/products/form-1-plus/](http://formlabs.com/products/form-1-plus/)

~~~
dekhn
When I visited Autodesk, they had a ton of broken Form1+'s on the shelf. They
said they always broke.

~~~
ZenoArrow
Good to know, thanks.

------
fake-name
Can we first stop making fucking ANY x support depend on the entire CUPS
subsystem?

I have a LOT of different computers/VMs that need X in some form, and will
never, ever EVER print anything. Why do I need the 10+ CUPS packages to
install a minimal desktop environment?

This is also true for audio bullcrap.

------
joosters
...why, was printer software becoming too reliable?

~~~
TazeTSchnitzel
Why would this addition hurt reliability?

~~~
joosters
While my comment was a bit glib, new features do have a tendency to introduce
complexity & bugs on seemingly entirely unrelated parts of software. If CUPS
is going to make a big push on integrating 3d printing, I'd bet you that it
causes more than one bug with the normal 2d printing, even if it is a compile-
time option.

I just hope that the 3d part of CUPS is easily removable... I'd hate to see it
part of the common user experience, CUPS already has a reputation for a
complex and bewildering UI as-is.

~~~
TazeTSchnitzel
> While my comment was a bit glib, new features do have a tendency to
> introduce complexity & bugs on seemingly entirely unrelated parts of
> software.

This is true. Given CUPS's modularity, I think this won't add too much
complexity, though.

> I just hope that the 3d part of CUPS is easily removable... I'd hate to see
> it part of the common user experience, CUPS already has a reputation for a
> complex and bewildering UI as-is.

I don't imagine it affecting the normal user experience at all. 3D printers
are still printers and presumably configured similarly.

~~~
Vendan
meh, the only similarities between 3d printers and "normal" printers is the
word printer in the name and the fact that they are output devices. 3d
printers have much more in common with 3 axis CNC machines then with printers.
In fact, the control code that many hobbyist 3d printers use is actually based
on the control code used by CNC machines.

~~~
zokier
I thought that too first, but actually they do seem quite similar. Main
difference from computers point of view is that paper printers take in
postscript and 3d printers take in gcode. Of course the printer itself is
completely different but that is all quite opaque to the computer.

~~~
Vendan
If you want to be that pedantic, there is little difference between a monitor
and a printer. There are a lot of configuration differences between 3d
printers and normal.

