attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Olliver,<div><br><div><div>On Oct 2, 2014, at 10:31 AM, Olliver Schinagl <<a href="mailto:o.schinagl@ultimaker.com">o.schinagl@ultimaker.com</a>> wrote:</div><blockquote type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div text="#000000" bgcolor="#FFFFFF">
Hey list,<br>
<br>
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 ;)<br></div></blockquote><div><br></div>Thanks!</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 19-09-14 17:32, Michael Sweet wrote:<br>
</div>
<blockquote cite="mid:5EEFF423-1201-494C-8B5C-64F3244EEA68@apple.com" type="cite">
<pre wrap="">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.</pre>
</blockquote>
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 :)<br></div></blockquote><div><br></div>Consider this a "poke", for this and the draft of the introductory article I posted yesterday.</div><div><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
<blockquote cite="mid:5EEFF423-1201-494C-8B5C-64F3244EEA68@apple.com" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
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?<br></div></blockquote><div><br></div>As detailed as you like, the more detailed the better at this point.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">...<br>
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.<br></div></blockquote><div><br></div>That's the direction I've been looking as well, and it aligns nicely with IPP as well.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
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).<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
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.<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
All sounds obvious and expected or completely impossible :) I don't
know, I am just a CUPS user!<br></div></blockquote><div><br></div>Yeah, it actually fits pretty well in our own testing.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
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.</div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"> 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.</div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"> 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.<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
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.<br></div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
Since this is already a pretty big wall of text, I leave these
thoughts with you for now.<br></div></blockquote><div><br></div>Thanks!</div><div><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
<blockquote cite="mid:5EEFF423-1201-494C-8B5C-64F3244EEA68@apple.com" type="cite">
<pre wrap="">Once we have something concrete we can actually propose formation of a PWG workgroup...</pre>
</blockquote>
I'm looking very much forward an being a part of this.<br>
<br>
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?<br></div></blockquote><div><br></div>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...</div><div><br></div><div>Apple has announced no official position or direction on 3D printing, and I am leading this effort in my role as PWG Chair.</div><div>(how's that for non-committal? :)</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF">
<br>
Olliver<br>
<blockquote cite="mid:5EEFF423-1201-494C-8B5C-64F3244EEA68@apple.com" type="cite">
<pre wrap="">
On Sep 19, 2014, at 2:23 AM, Olliver Schinagl <a class="moz-txt-link-rfc2396E" href="mailto:o.schinagl@ultimaker.com"><o.schinagl@ultimaker.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
<a class="moz-txt-link-freetext" href="http://www.ultimaker.com/">http://www.ultimaker.com</a>
_______________________________________________
3d-printing mailing list
<a class="moz-txt-link-abbreviated" href="mailto:3d-printing@pwg.org">3d-printing@pwg.org</a>
<a class="moz-txt-link-freetext" href="https://www.pwg.org/mailman/listinfo/3d-printing">https://www.pwg.org/mailman/listinfo/3d-printing</a>
</pre>
</blockquote>
<pre wrap="">_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
3d-printing mailing list
<a class="moz-txt-link-abbreviated" href="mailto:3d-printing@pwg.org">3d-printing@pwg.org</a>
<a class="moz-txt-link-freetext" href="https://www.pwg.org/mailman/listinfo/3d-printing">https://www.pwg.org/mailman/listinfo/3d-printing</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Met vriendelijke groeten, Kind regards, 与亲切的问候
Olliver Schinagl
Research & Development
Ultimaker B.V.
<a class="moz-txt-link-freetext" href="http://www.ultimaker.com/">http://www.ultimaker.com</a></pre>
</div>
_______________________________________________<br>3d-printing mailing list<br><a href="mailto:3d-printing@pwg.org">3d-printing@pwg.org</a><br>https://www.pwg.org/mailman/listinfo/3d-printing<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></body></html>