attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ryan,<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Oct 19, 2015, at 2:21 PM, Ryan Howard <<a href="mailto:ryan.howard@makerbot.com" class="">ryan.howard@makerbot.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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 class=""></div></div></blockquote><div><br class=""></div>You definitely haven't overstepped any boundaries - I think we need to spend a little more time talking about the current state of the art and why we want something different. The whole purpose of these discussions is to make sure that a) we have consensus on a direction and b) implementors are able to make something from what we write/publish.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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.</div></div></blockquote><div><br class=""></div>I disagree - current slicing software has a lot of room for improvement, particularly to better utilize multiple processor cores, do GPU offloading, and do better memory management (perhaps at the expense of speed). As long as the slicing is faster than the printing, it is fast enough.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">As printers get bigger and become capable of higher resolution this problem will continue to escalate.<br class=""></div></div></blockquote><div><br class=""></div>CPU price/performance improvements continue to outpace printer speeds.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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></div></blockquote><div><br class=""></div>The issue with trying to do something with the current g-code/s3g based tool path solutions is that they actually expose too much device stuff, making it possible to damage the printer, read/write data on SD cards, etc. (security and safety issues)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">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 class=""></div></div></div></blockquote><div><br class=""></div>Exactly the reason why we don't want to encourage continued use and standardization of g-code and s3g...</div><div><br class=""></div><div class="">
<div class=""><span style="font-family: 'Andale Mono'; orphans: 2; widows: 2;" class="">_________________________________________________________</span><br class="" style="font-family: 'Andale Mono'; orphans: 2; widows: 2;"><span style="font-family: 'Andale Mono'; orphans: 2; widows: 2;" class="">Michael Sweet, Senior Printing System Engineer, PWG Chair</span></div>
</div>
<br class=""></div></body></html>