CUPS 2.1 Is Adding Basic 3D Printer Support

[phoronix]

Phoronix: CUPS 2.1 Is Adding Basic 3D Printer Support

CUPS 2.1 Release Candidate 1 was released yesterday as the newest test version of this open-source printing system supported by Apple. With this new release comes basic support for 3D printers...

http://www.phoronix.com/scan.php?page=news_item&px=CUPS-2.1-RC1-3D-Printer

[tiwake]

This does not make much sense to me. Sure it would be nice to have a standard way to communicate with rapid prototyping machines (3D printers), but there are so many different kinds and most of them are in some sort of patent lockdown (esp. laser sintering, SLS). Right now the three most common rapid prototyping machines are FFF/FDM, SLA, and SLS with many many different kinds of controllers. Many of these take G and M code of some sort, and even that is kind of a horrible standard (I work with it every day).

I guess I'm not seeing how CUPS can standardize such a thing. From the linked CUPS 2.1 RC1 page comes only this blurb "Added support for 3D printers (basic types only, no built-in filters) based on PWG white paper.", which I believe is referencing this page https://www.pwg.org/bofs.html
Reading though that most recent white paper right now, but I'm not seeing how this would work very well.

[uid313]

Windows 10 also got a new application called 3D something for making 3D models and 3D printing.

[toyotabedzrock]

This sounds like a security issue in the making. This should be separate so it can be disabled by default unless needed.

[wizard69]

This does not make much sense to me.

Why not? Consider the massive number of drivers needed for todays 2D printers.

Sure it would be nice to have a standard way to communicate with rapid prototyping machines (3D printers), but there are so many different kinds and most of them are in some sort of patent lockdown (esp. laser sintering, SLS). Right now the three most common rapid prototyping machines are FFF/FDM, SLA, and SLS with many many different kinds of controllers.

Seriously it isn't any worst than todays printers. You have hundreds of models supporting various page description languages and the like. This especially when you get away from PostScript and HP based printers and start to try to support more industrial printers.

Many of these take G and M code of some sort, and even that is kind of a horrible standard (I work with it every day).

Well it is a very old standard in that case you can't call it horrible. In fact the use of G-code in a wide array of printers means that there is a defacto base standard. Considering the number of features common in larger laser printers / copiers I don't see G-Code and the limited device configurations as a huge problem.

I guess I'm not seeing how CUPS can standardize such a thing.

The printers now supported by CUPs are far more diverse than the current line up of 3D printers. If you only focus on low end 3D printers the diversity of configurations to support is even smaller. G-Code can be a good """ page description language """ .

From the linked CUPS 2.1 RC1 page comes only this blurb "Added support for 3D printers (basic types only, no built-in filters) based on PWG white paper.", which I believe is referencing this page https://www.pwg.org/bofs.html
Reading though that most recent white paper right now, but I'm not seeing how this would work very well.

Well I'm not going to look through it today but don't dismiss this out of hand. The whole idea of a working group is to come up with a workable😉 solution.

[DeepDayze]

Perhaps to support 3D printers on CUPS there needs to be a common application interface to these devices so that 3D applications such as Blender or any CAD/CAM program can easily generate physical 3D printed objects merely by selecting Print (then selecting the 3D printer device. If a standard driver interface can be developed that can solve a lot of headaches in interfacing 3D printers to applications.

[DrYak]

This does not make much sense to me.

Same for me. The only things in common between CUPS and 3D Printer is that they have "Print" in their name. (And not even for the same reasons. 3D printing is called "print" as a metaphor).

I indeed see the need of a common interface.

To have a "Send to printer" available in 3D oriented application. and software abstracting all the work behind the scene.

To be able to send a model from a medical imaging station working on a MRI directly to the 3D printing station, without needing to invent a whole pipeline just for that.
(Been there, done actually that.)

But CUPS handles a lot of things which is very specific to paper printing, and are absolutely NOT relevant in a 3D print context.
CUPS isn't simply a format convert (in the sense of ghostscript, for example) but is designed to handle printing queues.

A "CUPS for 3D Printers" would need to handle an API for enabling generic "Send to 3D printer" in application.
(in practice, already different from the precise way CUPS does it).
It would need to handle format conversion (the only real common point).
It would need to send jobs to printers (again the way it works is completely different).

It would make sense to create a separate framework for solid object synthesis, implementing all the new stuff needed, and maybe sharing the 3 lines of code of CUPS which do make sense.

I'm half wondering why apple hasn't announced a "SolidKit" yet...

[Patola]

What is so strange about adding 3D printing support? An engine for queueing and filtering is very welcome for 3D printing. Besides, the PWG papers have the rationale and a few user cases showing where it would be useful (like networked 3d printers or printing with multiple materials).