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.
On Thu, Oct 15, 2015 at 9:31 PM, Michael Sweet <msweet at apple.com> wrote:
> Ryan,
>> Thank you for your detailed feedback.
>> 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.
>> 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.
>> 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...
>> ....
>> 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.
>> 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.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
--
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/4f355e1f/attachment.html>