attachment
<div dir="ltr">I agree that I went beyond the scope of the paper, especially in regards to specifics on how errors should be reported. It was not my intention to change the scope of the paper, but instead to make sure that current print flow was documented in the paper regardless of how it changes as a result of this group. I hope I haven't overstepped my boundaries and I apologize if if i did, this is my first real experience in a group like this.<br><br>I still maintain, however, that the slicing shouldn't/can't be done on the printer. You say that a raspberry Pi is able to handle slicing, and while it is technically possible to slice on that type of platform, the memory/cpu requirements for even moderately sized 3d printed objects far exceed any device in that category. As printers get bigger and become capable of higher resolution this problem will continue to escalate.<br><br>While I think the 3D printing world would be better if a generic driver would work for all printers, i think the reality of the situation on the ground right now means that this problem should at least be addressed. While I think a generic driver could be implemented for a subset of the gcode type printers using existing slicers, perhaps the design of the 3D print pipeline should include at least the ability to select other drivers.<div><br></div><div>Another option you mentioned is cloud services, which in MakerBot's experience is the most implementable solution to slicing printer-side or from a mobile device slaved to the printer. This option also introduces security risks though. Even more so than in 2d printing is security a key concern. It is possible to exploit most printers in such a way as to destroy the printer or even use it to start a fire since it contains many hot elements.<br><br>Please feel free to ask me questions directly or via this email list.</div><div><br></div><div><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 15, 2015 at 9:31 PM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Ryan,<div><br></div><div>Thank you for your detailed feedback.</div><div><br></div><div>Overall, I think you may have misunderstood the scope of what is being defined in the white paper - one of the primary purposes of our discussions is to advance beyond the simple "slicer, printer driver, and toolpath file" model that has been used for 3D printing. We know (from painful experience over the last 60+ years of computer-driven 2D printing) that the printer driver model does not scale and leads to bad output, security problems, and even safety issues. The same is true of 3D printing, with even more dramatic failures.</div><div><br></div><div>Given that inexpensive devices such as the Raspberry Pi are sufficient to perform machine control and slicing for "consumer" 3D printers, our focus is on a higher-level interface where the client sends the model geometry ("Object Information File") separately from the print options ("Job Template" attributes in IPP, also known as a Job Ticket). Slicing and device control happen in the printer (or some box connected to the printer or in a cloud service) so that the client does not need to have a device-specific "printer driver", just a generic one for all printers.</div><div><br></div><div>This focus may not be explicit enough in my white paper, so I'll make sure to provide more background in the next version I post...</div><div><br></div><div>....</div><div><br></div><div>Regarding exceptions, IPP (and the PWG Semantic Model) use keywords (strings) to report device state. Integers, while compact, are basically impossible to extend safely, and require client software to understand their meaning to report something meaningful to the user. So what we have in IPP's printer-state-reasons attribute is a list of keywords representing the device's current state, and should a vendor need to define a new state keyword we have a naming convention for doing so as well as a registry for well-known values and a way for the printer to provide the client with a translation dictionary so the keywords can be converted to a human-readable message.</div><div><br></div><div>The goal, of course, is to pre-define most of the needed state keywords so vendors do not need to define their own. And the list of common keywords (just like the white paper itself) can be updated periodically over time.</div><span class=""><div><br></div><div><span style="font-family:'Andale Mono'">_________________________________________________________</span></div><div><div><div><span style="font-family:'Andale Mono'">Michael Sweet, Senior Printing System Engineer, PWG Chair</span></div>
</div>
<br></div></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Ryan Howard<br></div><div>Software Engineer<br></div><div>
<br>
MakerBot<br></div>
241 37th Street, 6A<br>
Brooklyn, NY 11201<br>
T <a value="+13476763868">347 676 3868</a><br>
M <a value="+13473874681">347 387 4681</a><br>
<div>
<font color="#090801">W </font><a href="http://makerbot.com/" style="color:rgb(9,8,1)" target="_blank"><span style="color:rgb(0,0,0)">makerbot.com</span></a><font color="#090801"> | </font><a href="http://thingiverse.com/" target="_blank"><span style="color:rgb(0,0,0)">thingiverse.com</span></a><br>
<b>> </b>Leading the Next Industrial Revolution</div></div></div>
</div></div>
<br>
NOTICE: This email may contain information that is confidential or attorney-client privileged and may constitute inside information or trade secrets. The contents of this email are intended only for the recipient(s) listed above. If you are not the intended recipient, you are directed not to read, disclose, distribute or otherwise use this transmission. If you have received this email in error, please notify the sender immediately and delete the transmission. Delivery of this message is not intended to waive any applicable privileges.<br>