4 ms·
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
by rasz_pl 11y ago
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?
- TazeTSchnitzel 11y ago> Right now 3D printers eat files, so printing to file is tautology. "Print to file" is a widely-supported printing operation, where the spooler saves the prepared document (in whatever format the printer uses: PostScript, Diablo 630, XPS, PDF, something proprietary...) to a file, rather than sending it down USB/parallel/etc. > 3D printers also tent to be very unreliable Plenty of regular printers are too, particularly older ones. Printing systems can handle it. > you need ability to pause the print (jams, skips). This is also needed, and supported, for regular printers. > How is putting CUPS between you and the printer helpful? Well, otherwise, you need some other software. Unless you're proposing people do `cat file > /dev/usb001`?
- zymhan 11y ago"integration with existing program UI dialogs, print to file and other features." Because of the existing software support for integrating with CUPS. You know, the Common Unix Printing System.
- jonhohle 11y agoIn 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 11y ago> 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.