IPP 3D Layer Format Ideas

The IPP 3D specification requires support for the 3MF file format and recommends support for PDF. While commodity hardware like the Raspberry Pi is capable of slicing such formats into layers suitable for printing on FDM printers, the controllers shipped with many of these printers is significantly less powerful making support for IPP 3D problematic.

The IPP Shared Infrastructure Extensions offer a potential solution where the slicing happens on a separate server and the printer fetches the sliced data at time of printing. However, there is no standard slice format aside from the defacto-standard G-code which is really a machine control format.

This page explores ideas for a standard 3D layer format for printing.

Requirements:

• Multiple extruder support
• Mixing/color support
• Basic move/extrude with flow volume control
• No machine control or remote storage control (dangerous/non-portable parts of G-code)

Recommendations:

• Minimal mapping complexity from new 3D layer format to existing supported technologies (e.g. G-code)
• Streamable
  • Is this really needed? I/O speed is usually not the bottleneck...
  • But IPP has built-in transport compression, which may provide good enough compression and still support streaming, which could be useful
• Minimal computational complexity

Idea 1: Define a Safe Subset of G-code

Probably the simplest solution is to define a portable subset of G-code without the machine control or remote storage commands. IPP Job Template attributes would provide the head temperatures, build platform temperature, and other device settings, and the printer would do its job startup process. This is similar to how many printers work when printing from SD cards.

G-code Subset

Based on the RepRapWiki information, the following subset of G-code commands is universally supported:

• G0: Rapid linear move
• G1: Linear move
• G4: Dwell
• G21: Set units to millimeters
• G28: Home
• G90: Set absolute positioning
• G91: Set relative positioning
• G92: Set position
• Xnnn, Ynnn, Znnn: Set X, Y, and Z positions
• Ennn: Extrude amount
• Fnnn: Feed rate
• Tnnn: Tool (head/material) select

There are also the controlled arc commands (G2 and G3) with Innn and Jnnn (X and Y space) parameters which are widely (but not universally supported). IPP attributes could be defined to provide a Client with information on whether the Printer supports G-codes such as G2 and G3.

All of the M commands provide machine-control and so need to be generated by the printer based on the Job Template attributes (and not included as part of the document data).

Idea 2: Define a Safe Subset of a G-code Binary Format Optimized for Size/Speed

Makerbot has their binary version of G-code - S3G - and Packed Binary G-Code is another alternative but doesn't seem to have a lot of adoption.

Conceptually the same subset from idea 1 can be used, just with the corresponding binary encoding. However, when comparing the sizes of G-code to these binary encodings it is not a huge win. Utilizing gzip compression (as provided by IPP) provides a much better reduction in file size (3-4:1), and gzip is well within the capabilities of a network-capable printer controller.

File	G-Code Size	gzip G-Code	P-B G-Code	S3G
Cassini.gcode	22692469	7108289	18370093	???
IPP3D-keychain.gcode	845588	207636	684523	???
Lego_Railroad_Crossing.gcode	6164340	1568242	4990180	???

Idea 3: Define Alternate Encoding Supporting Only Safe G-Code

This is conceptually similar to Idea 1 and Idea 2 but defines a new encoding that ONLY supports the safe set of G-Code operations. This would hopefully allow a trivial mapping to the G-Code equivalents, while sanitizing away the unsafe G-Code codes. This would require new code to be added to the printer, but might better protect against unsafe code problems. The encoding could be optimized for size / processing speed (CBOR?).