Authors:
	Ryan Howard, Software Engineer at MakerBot Industries Brooklyn, NY
ryan.howard@makerbot.com
	Quynh Dinh, Senior Software Engineer at MakerBot Industries Brooklyn, NY
quynh.dinh@makerbot.com
	Chris Moore, Senior Software Engineer at MakerBot Industries Brooklyn, NY
chris.moore@makerbot.com
Purpose
Throughout this document the section numbers are referencing the August 12, 2015 version of IPP 3D Printing Extensions (3D) available from the Printer Working Group at http://ftp.pwg.org/pub/pwg/BOFs/3d-printing/wd-apple-ipp3d-20150812.pdf
	The intent of this document is to provide edit suggestions that can be discussed at the next BOF meeting. Suggestions are given based on experiences with internal printer services and the Microsoft 3d printer driver API. 
2.1 Suggested Additional Terms
 •	Computer Aided Design [CAD]
 o	Software used to generate all of the various digital files representing 3D models.
 o	(Dozens of products that work on different platforms mostly proprietary, no universal output)
 o	Examples OpenSCAD, TinkerCAD and MeshMixer
 •	Object Information File
 o	Output file formats from CAD programs. These files describe the geometry, color, orientation, size of digital object(s), and other meta-data such as part number, material, authorship.
 o	Come in both proprietary and open source formats
 •	Machine Toolpath File
 o	Files that can be sent directly to machines, are highly machine specific. They describe the path the different axis motors and tool heads should take, the speed at which these paths are taken, and the extrusion speed.
 o	Print metadata is also stored in these files, such as build time, temperature settings, color settings etc. 
 o	Examples are GCode and .s3g/.makerbot
 •	Slicer
 o	 The most complicated piece of software directly related to this print pipeline. It performs the critical function of converting different Object Information Files into Machine Toolpath Files.
 o	This is the program is also responsible for accepting printer hardware information from the printer in order to display print options to the user and choose the right settings for creating the toolpath.
 o	 Examples CuraEngine, Makerbot Slicer Slic3r, Netfab, KISSlicer, and Simplify3D
3.1 Use Cases
 •	In all use cases there is no mention of any kind of user feedback between settings selection and printing. There should be some sort of print preview option here so the user can confirm the print.
 •	In between the ‘printer selection’ and ‘materials and print settings’ there should be a slicer selection step. Many users use multiple types of printers and sometimes different slicers for the same printer based on preference.
3.1.3 Print a 3D object with Multiple Materials
	The software referred to in this step is the slicer application that will be chosen. This is more clearly stated by saying that ‘The ability to create a predefined pause is expected to be one of the standard behaviors of a slicer.’ However this idea of stopping a printer so a user can change materials is not universal for all printers or slicing applications. Some printers are capable of printing in multiple colors without changing anything and some are simply unable or don’t implement a pause routine.

3.2 Exceptions
This list can never be comprehensive. Each make/model of printer will end up needing different and sometimes unique error codes. This section of the document would be of more useful if it could describe a numbering scheme and some common values for error codes.
	The following table depicts what should be created to organize the list of errors already compiled and adding new errors. Current numbers are examples.
Start	End	Reserved For	
0	100	Already in use for 2d printers	
101	200	universal additive manufacturing errors	
201	300	FDM specific errors	
301	400	SL specific errors	
401	500	Material Jetting errors	
501	600	Digital Light processing errors	
601	700	Laser Sintering errors	
700	MAX/2	Reserved for new technologies	
Max/2+1	MAX	Available for individual vendor errors	

4.2 Coordinate System
	It’s worth mentioning that some printers implement the coordinate system differently, there are both polar and parametric-delta type printers.

5. New Attributes 
	This is the section of the IPP 3D Printing Extensions white paper where the idea of universality begins to break down and the paper begins to go beyond the scope it stated. In section 3.3.1 it is stated that there will not be a definition of a new file format. The number of the attributes outlined in Section 5 of the IPP 3D Printing Extensions white paper is not scalable and begins to resemble a file format API which is outside the scope of the white paper. A specification of 3D printing attributes have been implemented by several different slicers already. 
	This section should be re factored into the scope of this paper, which is to provide a flexible way to connect to many different makes, models and technologies.  
5.0 The User story from the program’s point of view:
	Jane triggers a 3D print event. The system queries for connected 3d printers, and returns connected printers and their current status.  This information will come from whatever printer drivers will be installed on the system. A dialogue is displayed to Jane with printer information and status so she can choose a printer. After Jane has chosen a printer the system checks to see if that printer has a default slicer, if none have been set the system should display a list of compatible slicers to Jane. 
	Once the slicer has been chosen the print dialogue loads the available settings for that slicer, preloaded with their default values and information about accepted values. This information is consumed by the slicer when outputting the Machine Toolpath file (which could be in many formats depending on the slicer/machine). Once the toolpath is prepared we double check that the printer is still in a valid state to send the toolpath, and send the file via the connection to the printer driver associated with that printer.
	A print monitor daemon will be spawned that watches the status of the printer and alerts the user if something goes wrong. If the printer driver supports it, it will also provide a camera feed of varying frame rates.
5.1 Job Template Attributes
The Job Template should represent the job attributes from Jane’s perspective this includes,
 o	Printer driver
 •	 List the printers currently available for printing 
 •	 Establish a connection with a printer selected from the list of available printers
 o	Printer Connection
 •	Send toolpath file to printer
 •	Get printer metadata that will be consumed by the slicer
 •	Get the feedback from this printer in the form of status and camera feeds
 •	Set any user overrides to hardware settings.
 o	Slicer
 •	Get the settings API which should be a list of settings in the form of [setting ID, value-type, default-value, accepted-values, description/tooltip]
 •	Slice a given input file using the settings defined in the API plus any overrides provided by the user. The output file generated will be feed back into the printer connection
 •	User-specified Slicer settings
 o	File being printer
5.2 Printer Driver (an element of the Job Template Attributes)
	This API should provide a standard for asking for a list of available printers that are supoorted by this driver. It should also be able to establish a connection with any of the printers that it lists as available and return it to the print pipeline.
	Each implementation of this API will install an executable to a system standard location providing these functions. When a user initiates a print event an aggregated list of printers is displayed by appending the result of each implementation to a common list. A decision will have to be made on how to handle the event when two drivers return different implementations connected to the same bot. conflicts could result in undefined behavior when two drivers connect at the same time.
5.3 Printer Connection (an element of the Job Template Attributes)
	This layer acts a messenger between the print service and the printer. Each driver will implement how it establishes a printer connection depending on how the bot is connected (usb/serial, wifi, cloud, etc)  In order to establish a standard that will work across all kinds of connection types and different printer technologies, Printer connection should be a lightweight and flexible set of functions.
5.4 Slicer settings (an element of the Job Template Attributes)
	All of the other attributes listed in this section are really slicer settings when you add the settings that were combined with what was listed in section 5.1 and 5.2 before.
	Slicer API should consist of a list of elements with [name, type, default, accepted-values, description, category] Each slicer will be free to define settings how they like or a commen set of universal settings can be defined and slicers can build off this list as needed.

Implementation of Printer Driver/Printer connection and slicer using CURA and CuraEngine
Available at https://github.com/daid/Cura 
Printer driver
Function	Implemented by	Returns				
List printers()	Cura/util/PrinterConnection python module	Networked Doodle3d and usb/serial connected printers that respond the ‘M105’ GCode command (which is specific to FDM)	
Get printer by ID(string)	This can be implemented easily by adding a function the PrinterConnectionGroup base class that returns a PrinterConnection based on a string name	A printer connection that at least implements the PrinterConnectionBase API.	

Printer connection
Function	Implemented by	returns				
sendFile(toolpath)	PrinterConnectionBase.loadGCodeData()	Failure/success	
getStatusAPI()	There is currently not a function that wraps the API in an xml/JSon format but it is documented in code via the methods available in the PrinterConnectionBase class	Xml/json blob	
getCurrentStatus():	The PrinterConnectionBase class implements each status item individually, all that is needed is a helper function that calls each function and adds it to a xml/JSon.	Xml/json blob	

Any subclass of PrinterConnectionBase is responsible for the implementations of each function and return values directly related to that subclass, these will be aggregated in the base class to form a complete list.
getStatusAPI() and getCurrentStatus() are implemented as two different functions in order to eliminated repeatedly sending redundant data.

Slicer
Function	Implemented by	returns				
getSettingsAPI(printer-metadata)	The util/profile.py 	Returns lists of settings with all of the required fields that the slicer needs for the type of printer being used.	
Compatible(printer-metadata)	This is implied by the PrinterConnection class, since it will only establish connections with printers that answer to GCode commands. Consider writing a helper method in the sliceEngine.py file that confirms the GCode flavor is compatible with the currently running version of the Engine	True/false	
sliceFile(object-file, slicer-settings output-filepath)	The Slice Engine is capable of taking in a profile in the format of the API defined in profile. The range of files that it can print is defined in util/meshloader.py	The file at output-file path will be a GCode file that is ready to be sent	

When multiple slicers are compatible with the same printer there will need to be a user action prompt. Alternatively each printer could have a default slicer assigned to it when the printer is installed.

7 Object Definition Languages (ODLs)
	Here should be a more complete distinction of the differences between a CAD program output file and a slicer output file and what the difference is. 
7.1 Object Information File
The old 7.1 And 7.2 represent two of the most popular cad output formats used with 3D printing and should go here as 7.1.1 and 7.1.2
7.2 Machine Toolpath File
7.2.1 GCode
	Open source 3d printer standard language. It had been used as a standard for running hardware since the 50’s but lacks many modern optimizations
7.2.2 .s3g/.makerbot 
	File format used by MakerBot Industries, they offer optimizations and metadata for MakerBot hardware.