CUPS states “Added support for 3D printers (basic types only, no built-in filters) based on PWG white paper.” on http://www.cups.org/blog.php?L1087 - Does anyone have a clue what does that actually mean?
I’ve been wondering this myself. Are we talking loading gcode here? User interface? What’s the deal?
I think what they are trying to say is that support was added to recognize gcode, at least the common 3d printer elements of gcode. And that none of the model specific variations are recognized.
having skimmed through the paper @rexmo_gill linked to it sounds like they’re implementing a language, or perhaps better labelled a protocol, in CUPS for talking to 3d printers. I’m guessing - totally a guess and possibly incorrect - that people still need to write CUPS drivers for their individual printers types, just like in 2d printer land, that utilize this protocol.
Then one could setup a CUPS 3d printer much like a 2d printer and use CUPS interfaces to print with it.
The CUPS model is shown on the wikipedia page: https://en.wikipedia.org/wiki/CUPS
It sounds like this support is mostly on the ‘backend’ (and I’d imagine the ‘scheduler’ can mostly (completely?) use what already exists in CUPS), and the ‘filters’ - which are probably yet to be written - would be responsible for transformer whatever 3d file your sending into ‘Printer data’, which is what seems to have been implemented here - the protocol for sending 3d printing information to the printer. There is nothing in the PWG white paper that specifies filter development, other then a small section on the end mentioning common 3d printing file formats.
So I don’t think CUPS is currently a drop-in replacement for the existing 3d printing tool chain. But this is the first step in this direction.
To be sure all this guessing is correct one would have to go look at the CUPS source code, an endeavour which could potentially take quiet a bit of time to understand.
uh, yea, it says right there in the CUPS change log (and in OP) that there are no filters.
So, yea, no filters (which transform the 3d file data into the CUPS 3d printer protocol). No printer drivers (which transform the 3d printer protocol into a binary stream the printer understands - and vis versa, printer status/errors coming from the printer into standard CUPS status/errors which can be displayed by your CUPS client).
But this puts in the infrastructure needed to start developing both of those.
Is CUPS the right tool to extend for 3D printers? I made a joke about it once in a conference talk.
@Miro_Hroncok I’m not that experienced in 3d printer development, so take everything I say with a grain of salt.
But I think it probably is - eventually. After all fundementally 2d and 3d printing are awfully similar. I mean, sure, there’s more information for a 3d printer, but they both need application support, network support, printing spools, and status and error information.
“Any problem in computer science can be solved with another layer of indirection.”
- David Wheeler
CUPS is a layer of indirection that provides a lot of use.
To start with, and perhaps most fundamentally it provides for the division of labour. Printer developers and driver writers no longer have to target individual applications or file formats. Someone developing a new 3d printer just has to write a CUPS driver and everything else is automatically supported.
(Well, for non-Microsoft operating systems anyway. Microsoft, of course, has its own proprietary printing system, so everything I say doesn’t apply to Windows.)
Meanwhile application developers merely have to provide CUPS support for 3d objects/file formats. If it’s a object/file format which isn’t already supported they’ll also have to write a new filter, but that’s still easier then writing a new translation layer for every 3d printer out there.
By using CUPS you also automatically get stuff like printer spools, status and error handling, permissions handling, network support, and ready made printer-handling GUIs and so on. That’s a lot of benefit.
I can imagine a future where your making a 3d model in Blender and then select “Print…” and if you select a 2d printer it automatically prints a 2d image of your model from your current perspective but if you select a 3d printer it prints, well, a 3d model.
Or if your in a text editor working on an OpenSCAD file if you select a 2d printer it prints the text your working on, but if you select a 3d printer it prints the 3d model the file is representing. (In that case the 3d filter would have to auto-compile the file, and send back an error if it doesn’t compile.)
@Presley_Perswain Well the idea is nice and was exactly the thing I was talking about in the talk. However, i think 2D and 3D printing has not much in common and thus using a 2D printing tool, that manages e.g. a printer job queue, might not be the best idea. Let’s see.
I’m with @Miro_Hroncok here. Trying to apply the same concepts to a 3d printer that are established for 2d printer does not do justice to the very much different challenges, usage scenarios etc. The problem I think is that people get tricked into doing this by the term “printer”, which does the complex production process taking place when we replicate a 3d model in plastic “out of thin air” no real justice. There a simply too many things that can go wrong that are currently not automatically detectable, not enough automation within the process itself (print spools are nice and well when you can clear the build plate automatically, when not, well, let’s hope it will wait for user input before starting the next job ;)), etc. Both 2d and 3d printers turn digital data into a physical representation of sorts, but that’s about it with the similarities of the process.
I took a look at the document a week or so ago and from what I saw it boils down to moving the slicing step into the responsibility of the printer driver, without much of a feedback loop (or I overlooked that). So basically a standardized version of the file upload, print job and slice API of OctoPrint, without defining the back channel. I’m not sure that’s going to work with the current generation of 3d printers (and many more to come), I’ll happily be proven wrong however.
As long as the custom variants all speak a common standardized protocol that can work in principle (there are also hundreds of custom variants of http clients and servers out there and the internet still does work just fine). But the process within CUPS is focused on the necessities of having on or more 2d printers work reliably (and let’s be honest, THAT can fail spectacularly too), and those just have completely different needs from 3d “printers”. It’s somewhat easy to detect a paper jam. It’s not so easy to detect a print that has gotten loose from the bed. And while annoying, a failed print on paper means I have lost maybe 20min of my life and a couple of cents in terms of material, whereas for a 3d “printer” I’m now looking at possible hours lost and a lot of filament wasted on top of that, plus maybe even more tricky problems that will have me disassembling the whole thing (let’s face it - 3d “printers” refuse to cooperate way more often than your average 2d printer). It’s two completely different problem domains. I don’t see how a tool absolutely fine tuned to serve the needs of one of those problem domains can solve the problems from another “over night”, so I wouldn’t hold my breath for now that this will change anything in the short term (= a couple of years).
I’m for changing the term 3d printer to 3d “manufacturer”
Depends… they are pretty good if “thing” is defined as “filament spaghetti” 
@foosel I don’t think anyone is proposing CUPS replace existing tools tomorrow. This is the first step on a long road towards that goal. Writing filters and drivers will take months - maybe years - longer.
Yes, the current generation of 3d printers aren’t as reliable as 2d ones. But they’ll improve over time. Maybe they’ll never be reliable as 2d printers because, well, 3d is more complicated then 2d. But they just have to be ‘reliable enough’ (whatever that ends up being) and have an onboard sensor suite capable of detecting the vast majority of failure modes. (The PWG White Paper even includes in the protocol space for a camera that monitors prints - something most 3d printers currently don’t have.)
And yea, the huge variety of hobby printers means most of them will never have CUPS support, but there will, eventually, be commercial 3d printers aimed at markets beyond hobbists. Makerbot tried and mostly failed. Dremel has a 3d printer, although I haven’t heard how reliable it is. Eventually there will be others.
Remember that CUPS is now an Apple project. This could be (but isn’t necessarily) Apple laying the foundations for their own support for 3d printing in MacOS X.
Anyway, I agree, there’s lots of good points against using CUPS - now. But these points won’t necessarily always hold up for ever. Maybe, maybe not. I’m not saying using CUPS is the greatest idea ever, but its also not necessarily the worst idea ever. But it may be worth trying out. If it doesn’t pan out people just won’t use it and eventually that code will be dropped.
Looking at the PWG white paper that rexmo linked above, it looks pretty thoroughly thought out, at least at a glance.