Olliver,
On Oct 2, 2014, at 10:31 AM, Olliver Schinagl <o.schinagl at ultimaker.com> wrote:
> Hey list,
>> firstly my apologies for the late reply. But do know we are interested and committed. I've been just very busy the last few days. I'll try to respond to all previous mails 'in order', hopefully that won't be too confusing ;)
Thanks!
> On 19-09-14 17:32, Michael Sweet wrote:
>> Olliver,
>>>> Welcome!
>>>> Organizationally we are still very early in the process - we've had one "BOF" (Birds of a Feather) session to talk about 3D printing at a very high level and determine our next steps, and are now working on a white paper that we can circulate to get interested people involved.
> I found the BOF Slides and the minutes thereof. I just wish I was available and knew of the meeting as I would have hopefully given some useful comments. I guess if you want my comments on the slide/minutes, you can always poke me and I'll respond as I can :)
Consider this a "poke", for this and the draft of the introductory article I posted yesterday.
>>>> I'm really interested in hearing your thoughts and experiences WRT adapting CUPS and IPP to support your printers - that's the kind of information we need right now to start scoping out what changes are needed for 3D printing in general.
> Well as I said, i had the idea and desire to go the CUPS route, as I see so many similarities between 2D and 3D printing. On the technical side of things, I also realize the many differences. So how detailed do you need to know things?
As detailed as you like, the more detailed the better at this point.
> ...
> My idea initially was to integrate the several stages to get 3D prints through CUPS. First I would just pass g-code through CUPS, as I consider it something similar to PostScript. True, G-code contains some machine specific stuff, but it would get the first proof of concept out. After that I was looking how to get the more generic STL through CUPS using our own slicer, CuraEngine as a printer filter. I was under the impression that you can feed more random data (bitmaps for example) into cups, where the printer filter would then generate the printer specific G-code.
That's the direction I've been looking as well, and it aligns nicely with IPP as well.
> A quick side note is, that at the moment, CuraEngine is one of the very few slicers that actually supports AMF, but as you said, AMF is not an open standard, and we need it to be an OpenStandard if we want to go this route. We already require changes to the standard (and are violating it because of these needs).
Please do post your issues and solutions; feedback like this will help make AMF better and is more ammo in our conversation with ISO about opening up AMF.
> The printer driver, would then be the bit that takes the printer specific G-code (or maybe generic g-code and then adds printer specific bits) and sends it via serial or whatever to the printer (usb-serial in the case of our current printers) and receives sensor information.
In the case of CUPS, we'd use a backend to handle the "last mile" to the printer. Ideally we'd either have printer-ready g-code or a gcodetogcode filter (much like we have a pstops filter) to get there before the backend. But given how much printer-specific stuff is implicitly in g-code already (layer height, print heads/extruders, etc.) I'm not sure it makes much sense to post-process the g-code.
> All sounds obvious and expected or completely impossible :) I don't know, I am just a CUPS user!
Yeah, it actually fits pretty well in our own testing.
> Now, what changes do I for see that are required to support 3D printing over 2D printing? For one, we have to think oldskool on one hand, but also anticipate that 3D printing is in it's early starting period (since 30 years) and many things are still evolving. For one, we treat 3D printers like matrix printers now. Old matrix printers had to be put 'online' via a button for example, to let the system know the paper was loaded and everything was ready. The out of paper (build platform full?) and out of ink (no filament) are statuses not yet available.
In IPP we have the "output-area-full" status for when the build platform has a printed object on it, and we'd likely define new "material-empty" and "material-needed" statuses for the filament supply status. Since those are just strings ("keywords" in IPP-speak) that is super-simple to add to CUPS.
> This is where the evolving part comes in, sensors like these will happen for sure. ;) Also, right now, the printer does not always know what filament it has. I'm sure in the future there will be sensors in the spools (cartridges) making it possible for the printer to know the type and color of the filament.
We also see a lot of "manual configuration" for current 2D printers - set with a control panel menu to specify media size and type for each tray, also through the web IF offered by the printer. And given the large variety of materials that are available, we probably want to be as flexible as possible.
> This is a big difference between printers then and now though. In the old days, you had monochrome printers, but only having black ink was common. Some hobbyist changed their inks to different colors, but still printed everything as if it where black. Now, we'd want to know which color of filament is currently in the printer, not just black or color. This can be especially important when you get 10 printers for your company, and each you have 5 colors and 2 different kind of materials. You want to be able to pick a printer based on color and material. And that brings us to the next thing that is different, multi-material.
IPP already has a notion of "ready" media and finishers, along with current capabilities. I'm certain we will need to extend this to include materials and other 3D-specific stuff, but ultimately the kind of "pick a printer that matches what needs to be produced" is exactly the sort of production workflow that is already supported by IPP.
> Multiple materials can be used in various forms, think of a 3D printed pen, where the handle is covered in soft rubber like material. Or water soluble support material. Now the first case can easily be handled by thinking of materials as different colors. How this can be done practically of course is something to be seen, and not a huge issue now, there's few multi-material printers right now. As for support material, that's something the filter would add to the g-code so shouldn't matter here.
But it would still be useful for the printer to return this information to the filter so that it knows what type of support materials are available, and where.
The key constraint I see for multi-material is the underlying file format. G-code handles this by letter you pick which extruder to move. AMF has its own concept of materials and color(s), which needs (IMHO) formalization/definition to be useful.
> Since this is already a pretty big wall of text, I leave these thoughts with you for now.
Thanks!
>> Once we have something concrete we can actually propose formation of a PWG workgroup...
> I'm looking very much forward an being a part of this.
>> Just for my information (and you may reply off list if you wish to keep this information private), a year or so ago, there where rumours that both Apple and Microsoft where working on a 3D printing 'standard'. I know Microsoft has something basic in windows 8.1, where is Apple herein? Or is your initial CUPS work the start of this all?
I hadn't heard of that particular rumor, but no Apple is not working with Microsoft on a standard. I (as PWG chair) have invited Microsoft to participate in these discussions, and MS is a long-time PWG member, so hopefully they will participate as we continue down this road. MS also released their own 3D model format (3DMF) as an open specification - I am not aware of any vendors that have adopted this format yet...
Apple has announced no official position or direction on 3D printing, and I am leading this effort in my role as PWG Chair.
(how's that for non-committal? :)
>> Olliver
>>>>>> On Sep 19, 2014, at 2:23 AM, Olliver Schinagl <o.schinagl at ultimaker.com> wrote:
>>>>> Hey list,
>>>>>> Let me start by introducing myself. My name is Olliver Schinagl and I work for Ultimaker in the Netherlands. I'm a Software engineer currently working on making our printers network enabled devices. It was a great finding out there is now a working group on standardizing 3D printing! A project item for me actually for march was to investigate the possibilities of leveraging CUPS for 3D printing.
>>>>>> I will now go over the documents and minutes generated in the last weeks to get up to speed, just wanted to say Hi and let everybody know that we from Ultimaker are very excited this is taking off.
>>>>>> --
>>> Met vriendelijke groeten, Kind regards, 与亲切的问候
>>>>>> Olliver Schinagl
>>> Research & Development
>>> Ultimaker B.V.
>>>http://www.ultimaker.com>>>>>> _______________________________________________
>>> 3d-printing mailing list
>>>3d-printing at pwg.org>>>https://www.pwg.org/mailman/listinfo/3d-printing>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>>>>>>>>> _______________________________________________
>> 3d-printing mailing list
>>3d-printing at pwg.org>>https://www.pwg.org/mailman/listinfo/3d-printing>> --
> Met vriendelijke groeten, Kind regards, 与亲切的问候
>> Olliver Schinagl
> Research & Development
> Ultimaker B.V.
>http://www.ultimaker.com> _______________________________________________
> 3d-printing mailing list
>3d-printing at pwg.org>https://www.pwg.org/mailman/listinfo/3d-printing
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/3d-printing/attachments/20141002/fce323c0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/3d-printing/attachments/20141002/fce323c0/attachment.p7s>