Pleased to see the discussion. A few comments.
1. I agree that the current print flow (and existing variations) should be documented, although perhaps not necessarily in Michael’s whitepaper. I think it useful in considering a more ideal solution that all interested parties understand the current approach, and its advantages and problems.
2. The “reality of the situation on the ground right now” should be addressed, both to facilitate development and to provide a pathway to the future. I suggest that that includes considering both relatively simple devices and those which, perhaps in the future, have significant memory/cpu resources locally accessible.
3. As observed, security concerns, both from the safety and information protection perspectives, are critically important and are significant for both simply networked machines as well as cloud serviced machines.
4. Standards work differs from basic engineering in that it must attempt to anticipate the future while still addressing present problems. Although difficult and often unsuccessful, it is important in allowing the orderly evolution of a technology. The alternative is usually a de facto standard doing whatever the most successful company has done, which is often suboptimum for others in the industry.
Thanks,
Bill Wagner
From: Ryan Howard
Sent: Monday, October 19, 2015 2:21 PM
To: 3d-printing at pwg.org
Subject: Re: [3D Printing] Response to the latest white paper
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.
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.
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.
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.
Please feel free to ask me questions directly or via this email list.
Ryan Howard
Software Engineer
MakerBot
241 37th Street, 6A
Brooklyn, NY 11201
T 347 676 3868
M 347 387 4681
W makerbot.com | thingiverse.com
> Leading the Next Industrial Revolution
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/3d-printing/attachments/20151019/180493fa/attachment-0001.html>