From RepRap
Jump to: navigation, search

THIS page is an extremely rough draft. You can help us improve it. (Someday this page will document many of the known-working systems. A few known-working systems are already documented at RepRap Options).

Alternative Build Documentation Build Documentation

This page has been flagged as containing duplicate material that Comparison_of_RepRap_Toolchains also attempts to cover.
These pages should be merged such that both pages do not attempt to cover the duplicate topics.

See also a Comparison chart of Firmwares on page Comparison_of_RepRap_Toolchains

If you have written microcontroller firmware for the RepRap for any microcontroller this is the place to document it.

Arduino Test Code

Simple tests to help debug and check your arduino and cartesian robot.

  • pRINToPTO - doesn't move any motors, only prints the status of the opto switches to the arduino IDE terminal.
  • hOMING - brings back all the axes one by one to the home position using only the opto switches as feedback (no sanity checks).
  • rECTANGULARsPIRAL - prints the above rectangular spiral from the current position (no homing). width height and margins are easily modifiable.

YouTube Video of the rECTANGULARsPIRAL program in action.


Download the file.

Some people think that an extended suite of test firmware might be helpful:

Most people writing and tweaking firmware apparently test the new code by running it on real hardware. At least one person uses SimulAVR for testing -- for example, Teacup Firmware#Running Teacup in a simulator.

Has anyone used the "Simulavrxx" simulator[2] or the "Searduino" simulator[3] for RepRap firmware?

How do I install the Virtual Mendel (Repic#Repic Host Software) simulator?

Teacup Firmware

Teacup Firmware is a Rewrite of FiveD firmware for the Arduino by Triffid Hunter and more. It avoids C++ in favour of plain C, and uses 100% integer math.


Many parts we want to print out have circles and other gentle curves.

Most current firmware only supports extruding straight lines, so the slicer converts those curves into thousands of tiny straight lines -- so small that they can be printed faster than some drip-feeders can send them from the host to the RepRap, leading to buffer underflow.[4] (Other proposals for fixing this buffer underflow problem: #SD card, #alternatives to G-code).

Perhaps it would be better if the firmware implemented some sort of curve -- perhaps the standard

One practical guide to implementing such curves in firmware: Steve Noskowicz. "Interpolation and Curves for Graphics".

A theoretical guide to gear design with Bézier curves: Fumitaka Higuchi, Shuuichi Gofuku, Takashi Maekawa, Harish Mukundan, Nicholas M. Patrikalakis. "Approximation of Involute Curves for CAD-System Processing": "Bézier Approximation of Circle Involute Curves". 2006. </ref>

Then a post-processor after the slicer converts those thousands of tiny straight lines into a few dozen circular arcs (a circular spline) or a handful of B-splines. It should be much easier for the drip-feeder to send a few dozen G codes representing curves through the USB cable than to send thousands of tiny straight lines.

Fabien Chouteau, "Make with Ada: ARM Cortex-M CNC controller" (2016) wrote a Gcode interpreter for the ARM Cortex-M4F, including implementations of G02 and G03 circular motion.

SD card

Most RepRap firmware implements G-code by executing one line at a time as it is "drip-fed" out from a host (perhaps with a small buffer of a few lines).

Some RepRap firmware reads ".gcode" files off a SD card, with no host intervention necessary. The two main approaches:

  • The host sends the an entire layer or perhaps the entire print, and the RepRap firmware saves it to the SD card, which acts as a large buffer.
  • The host saves the ".gcode" file to a SD card, which a person manually carries and plugs into a completely stand-alone printer.

alternatives to G-code

Several people have suggested designing a host-to-microcontroller communication protocol much simpler and easier to interpret than G-code. At the moment, these are all highly experimental, but they could potentially reduce the net cost of a RepRap (simpler protocols can be decoded by lower-cost electronics) and improve the speed and quality of printed parts (less time decoding and interpreting commands may result in more time extruding plastic).

As a first step, and to remain compatible with the many tools that produce G-code, software on the PC can pre-interpret G-code files to produce motion commands in a simpler format, something like the way 3D-to-5D-Gcode-php converts one kind of G-code to a simpler-to-interpret kind of G-code.

  • Wikipedia: STEP-NC: "STEP-NC was designed to replace ... G-codes ... adding tolerance data ... [with a] XML format."
  • "Implementing Postscript as firmware" on the RepRap forums.
  • GCODE buffer multiline proposal discusses a small change to the G-code protocol that is forwards- and backwards- compatible.
  • Granite Host
  • EMCRepRap converts most G-code to simple "step, direction" pulses on the PC.
  • SNAPComms
  • Much of the ""Firmware - experimental" RepRap discussion forum discusses protocols that are hopefully easier to interpret than G-code.
  • splines and circles: By describing every move in the form of curved cubic splines, not only do we reduce the volume of data required to describe a curved part, but it may also make the microcontroller firmware simpler and faster. Faster: only integer arithmetic required. Simpler: the firmware only needs a single subroutine to handle cubic splines, rather than several subroutines to handle straight lines, circles, arcs, and the involute curve used for twice for each gear-tooth. Less volume: 8 cubic splines per circle are more than adequate for high precision CAD/CAM machines[5], while apparently (?) the current RepRapGCodes requires hundreds of tiny straight line segments to approximate the same circle.
  • Flutterwumper Library generally focuses on generating shapes in PostScript format, and then converting directly from PostScript to "step, direction" pulses, without ever going through G-code.
  • ".gcode versus .s3g" discusses the ".s3g" format file produced by replicatorG. It also mentions that USB seems to have high latency.
  • "latency and jitter concerns" has yet another discussion of latency and jitter in USB-to-Arduino communication.
  • "Bluetooth working, but pauses after each gcode line" says that Bluetooth has even more latency than USB.
  • "firmware free hardware" have some discussion on doing all G-code interpretation on the host -- perhaps using the EMC G-code interpreter -- and then driving the RepRap motors without any RepRap-specific firmware:
    • perhaps using the generic Firmata Arduino firmware on the Arduino, or
    • perhaps mis-using an "Arduino programming cable" (basically a FTDI FT232 chip and some connector hardware) or two in bit-bang mode without an Arduino,[6][7][8] or
    • perhaps connecting the parallel printer port pins directly to the "step, direction" pins of the motor drivers directly, without any IC at all.
  • "Pacemaker" is intended to simplify the client. The host translates G-Codes into Pacemaker protocol.