Gcode Modularity

Gcode is commands that most RepRap firmware understands. To make a RepRap do a certain action, you need to tell it the corresponding gcode or sequence of gcodes. A slicer program is a program that translates a 3D model, such as an STL file, into a sequence of gcodes. See RepRap Wiki on Gcode for more.

Modularity, Portability, Interface view on Gcode Usage

Slicer programmers have been eager to improve print quality, and have therefore implemented many features that compensate for the mechanical specifics of RepRap FFF 3D printers. So gcode output of slicers depend not only on input files (STL files), but also on the mechanical specifics that the user configures the slicer program to compensate for. This makes gcode non-portable, and gcode files are in general not distributed within the RepRap community.

Examples of non portable slicer functionality are:

1. Filament retraction
2. Wipe of nozzle
3. Extruder enumeration (There's no standard, and users configure this within slicer program.)
4. XY size compensation (Hysterisis compensation. Constant errors like play in gears are compensated.)
5. Filament diameter
6. Extruder and bed temperatures
7. Z offset
8. Pressure advance setting (Extrusion hysterisis. Lagging pressure within nozzle compensated.)
9. Vibration limit
10. Nozzle diameter
11. Extruder offset

All of these are machine-specific parameters, which in principle could reside within the printer firmware, that are most commonly baked into sliced gcode. Hence every Reprapper needs to learn how to slice for him/herself.

It's natural that new compensation strategies are first prototyped in raw gcode, since gcode is easier to produce and debug than new versions of firmware. It's also understandable that slicing experts that are not also firmware experts fit their gcode generation to their machine/firmware and not the other way around. Putting advanced compensation functionality into the slicing program also offloads computations from the RepRap microcontroller.

However, allowing beginners to print without learning to slice first would make the benefits of RepRapping alot more accessible.

Steps Towards Portable Gcode

Note that alternatives to gcode has been widely discussed in the RepRap community already: [1]

1. Filament retraction: Already implemented in Marlin firmware (have not checked the others)
2. Wipe of nozzle: ?
3. Extruder enumaration: Tool heads are numbered, but firmwares and slicers does not agree if enumeration starts on 0 or 1 (see [2]). Mapping from number to tool function is not standardized.
4. XY size compensation: This is very easy to implement in principle. RepRap wiki page specifies M99, but says that it's not implemented.
5. Filament diameter: Should be set in printer's own config file. Currently not implemented in firmware? Both the filament diameter sensors and firmware commands have been developed to do this automatically.
6. Extruder and bed temperatures: Should be set in printer's own config file and via host software. Currently not implemented in firmware?
7. Z offset: Already implemented in all firmwares.
8. Pressure advance setting: Automatic solutions exist, see 3D_Printer_Filament_Load_Sensor.
9. Vibration limit: Deprecated in Slic3r. Jerk settings in Marin does similar things.
10. Nozzle diameter: Should be set in printer's own config file. Currently not implemented in firmware?
11. Extruder offset: Should be set in printer's own config file. Implemented.