Extrusion Code

From RepRap
Revision as of 12:32, 21 October 2011 by Keegi (talk | contribs) (Created page with '= Introduction = == THIS IS CURRENTLY ONLY DRAFT IDEA == With worry I have watched the dichotomy and complexity growth in the reprap community on two fronts. First there is co…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

THIS IS CURRENTLY ONLY DRAFT IDEA

With worry I have watched the dichotomy and complexity growth in the reprap community on two fronts.

First there is complexity in the slicers, that have to take into account lot of machine-specific parameters, generating the code that is usable only once.

Then there is complexity in the firmware, that have to calculate in real-time the constrained dynamic movement properties, applying look-ahead, acceleration/deceleration profiles and even extrusion advance calculations.

So this all has made me think that the G-code, as it is currently, is not best suited to describe the intermediate output between the slicer and the firmware.

So here is rough outline of something else that might be more suitable as semantical slicer output code:

All commands are packetized, falling into following "command" categories. Most of the flags are optional and specific to the command category or command itself.

For textual output, the packet consists of single line, first character describes the command category.

There could be some binary format that closely shares the extensibility and style of the textual format, so that the translation would be straightforward and simple.

Number (optional for some categories) after the category character describes specific command.

The basic idea behind this command set was to maximize meaningful information, that is easy for a slicer to generate, and that will make it relatively simple to split up and translate into real machine movements.

Commands

P: print commands:

These will generally cause the printer to proceed through pre-defined, configurable routines, that the slicer does not necessarily have to worry about in detail - homing, heating up/down, wiping etc. Basically, they will be just a trigger certain macros.

  • P0 - start of print (run predefined start command routine)
  • P1 - end of print (run predefined end command routine)
  • P2 - pause print
  • P3 - resume print
  • P4 - continue partial print
  • P5 - abort print
  • P6 L## - pause print after layer ## (without layer parameter, pause before next layer change)

L: layer definition

These are generally just descriptors that allow movement commands to refer to the appropriate Z-height and extrusion parameters with just a single number, without having to specify all of them during each move. They should be provided any time after Z movement, before sending G commands

Format: L###

  • ### is layer absolute index

Parameters:

  • T# - layer type:
    • T0 - raft,
    • T1 - base layer,
    • T2 - regular layer,
    • T3 - partial layer (for more fine-grained outlines)
  • R# - layer relative index (raft-0, raft-1, ...)
  • Z### - z height

G: movement commands

These are bulk of the data.

  • movement type:
    • G0 - travel
    • G1 - stand-alone extruded filament
    • G2 - support structure (raft, support)
    • G3 - perimeter
    • G4 - shell
    • G5 - infill, inner shell layer infill
    • G6 - infill, outer shell layer infill
    • G7 - infill, diaphragm
    • G8 - pattern infill
  • X/Y: coordinates to move to
    • X### Y###
  • L/Z: layer reference (absolute index of the layer) or new Z coordinate
    • L### or Z###
  • B: overhang/bridge flags:
    • B0 - shrinking perimeter - perimeter for layer smaller than previous one (underhang)
    • B1 - lines up and fully supported underneath (vertical wall perimeter)
    • B2 - partially unsupported underneath (overhang)
    • B3 - fully unsupported underneath (bridge)
  • A: "top" layer flags
    • A1 - will not provide support to above layers
  • C: curvature value
    • C### (units: degrees? sine of the degree? some other formula? based on the difference to the previous extruded segment direction)
    • - positive value: along positive outside curvature (e.g. outer shell on circular object)
    • - negative value: along negative outside curvature (e.g. inner hole)
  • M: deposition material ID (in case of multiple material extrusion)
    • M###
  • E: deposition rate volume / movement unit
    • E### (non-negative value, zero (or omitted E parameter) means travel without intended extrusion)
  • D: distance (optional helper information, to reduce need
    • D### length of movement

C: configuration commands

These are meant to set configuration parameters. Slicer does not output them, but they should probably be preloaded from configuration storage for the processor

Code processing in the toolchain

It is the responsibility of the slicer to generate this code. It should split the object into layers, generate movements, calculate volumetric extrusion, generate infill patterns, order, optimize and categorize the movement/extrusion command, to generate raft, skirt and support structures.

This can be done in relatively machine non-specific manner, only knowing the nozzle diameter and types of .

It is the responsibility of some kind of post-processor to generate segments of movement, look back and forward over several movements, calculate appropriate feed/extrusion rates and temperatures, also perform offset calculations or switches between nozzles and materials. This is already based on parameters, specific to the machine and material(s).

This pre-processing could be implemented as separate step, in the host or in the firmware. The output of this pre-processing stage is not specified here, but it could be in the form of G-code. This is roughly equivalent of the output of current slicers. (maybe we can modify the specification of this data format to incorporate everything needed for that)

Second step of pre-processing involves calculation of acceleration/deceleration, extrusion priming and retraction, including any advance calculation (by splitting up movements).

This functionality can be implemented in firmware or in the host as pre-processing step (in case mathematical calculations involved are too slow in the firmware)

These split up movements should be combined in the firmware that supports at least look-ahead capabilities that allow movements along the same direction to continue with the current rate, without intermediate deceleration.