RepRap Firmware

From RepRapWiki
Jump to: navigation, search

Crystal Clear action run.png
RepRap Firmware

Release status: working

No image available.png
Description Object-oriented C++ firmware for 32-bit controllers
License GNU GPL v3
Author Adrianbowyer
Contributors Tony Lock, David Crocker (aka Dc42), Christian Hammacher (aka Chrishamm)
Based-on Marlin
CAD Models none
External Link


RepRap Firmware Use


3D printer RepRap Firmware runs on 32 bit, ARM-based microprocessors Atmel SAM3X8E, as found on the Arduino Due and ATSAM4E8E.

This firmware is pre-compiled and flashed on to the printer board. It is configured only with human editable files located on an SD-card plugged in to the printer board. As such, there is no need to compile the software nor install any development tools.

The software can receive G-Code from the USB serial port, the SD card and the Ethernet interface.

It can run from an interface connected via USB, but most users prefers to operate from a web interface, with the board connected to an Ethernet network, after uploading the file to be printed via this web interface.

The RepRap Firmware philosophy is that every operation is done with G-code, notably all configuration.

The set of RepRap Firmware G-Codes is more extended than other firmwares.

The configuration file is read on SD card at start-up.

All G-codes or macros could be send to the board while operating the printer, allowing instant feed-back for any configuration modification. As interactive modifications are lost at next board start-up, the successfully tested G-Codes shall be manually introduced in the configuration file, which can be edited directly in the web interface.

Motor current could be adjusted with a G-Code.

This interactive configuration makes the printer commissioning and tuning easier than with other firmware.

Some automation is possible through macros (in progress).

The software is evolving constantly. See RepRap Firmware FAQ

RRF Functional.png

RRF connection Duet WiFi.png

Printer geometries and adjustment

Miscellaneous geometries are handled

Automatic calibration

Automatic calibration can be done with a Z-sensor. For delta printers, there is an algorithm evaluating some geometry parameters. This is sufficiently fast to be run at each print during the heating phase, and so printer thermal expansion is taken into account.


RRF connection1.png
RRF connection2.png

When Duet board is connected via Ethernet, any Ethernet or WiFi device having access to your network can operate the printer with a web interface.

RepRapPro have released a video (outdated) showing the web interface in use with the Ormerod printer. Forum user dc42 has published a series of blog posts showing how to use the Duet to control a Mini Kossel printer. The web interface is independant of the Firmware and communicate with it via G-codes, getting data with querying G-codes (this is invisible for the user).

Loosing a connection to the printer does not have any effect on the print, but you cannot pause a print without having a connection (which could be with another device than the one which started the print).

Multiple printers could be operated from one browser.

One printer can be accessed simultaneously from multiple network devices, possibly through WiFi.

The image of any camera accessible on your network (IP camera) can be embedded in the web interface.

The web interface is available in English, French, Spanish, Swedish and Chinese.

SD-card file architecture

RRF SD Card files.png

To operate, the firmware need the following files to be present on the SD-card - names are case sensitive:

  • configuration file '/sys/config.g'
  • A set of system G-code macros with predefined names located in '/sys' directory
  • A set of user launchable macros located in '/macros' directory

See a typical set of RepRap Firmware macros

All these files shall be edited with any text editor for adaptation to a given machine. Kit sellers supply already configured SD image and/or pre-loaded SD-card. An SD-card supplied by user shall be formatted in FAT32 with 32 kB clusters prior use, manufacturer pre-formatting being often troublesome.

  • /gcodes

G-code print files are in '/gcodes' directory - with this exact orthography. Sub-directories can be defined.

  • /www directory for web interface (Duet 0.6 and 0.8.5)

All the web interface files are in '/www' directory. These files are served directly by the board to the browser and all interface processing is done by the browser (the web interface is programmed in Javascript).

Compatible hardware

  • Duet (all versions : 0.6 and 0.8.5)
  • RADDS, but without Ethernet connection, this can only be operated with a front-end program
  • Alligator Board – there was a port of DC42-1.09k, but there is no details about this port.

SD card

An SD card is in principle delivered with boards (Duets), but as the Ethernet speed depends mostly from the performance of the SD-card, it may be wise to buy a better performing SD card. Sustained transfer speeds for large files go from 200 to 900 kB/sec (for DC-42 fork > 1.12).

Note that the performance of the boards indicated by the manufacturers are for long files, while the firmware proceeds with short burst which may prove slow on supposedly fast cards, so your experience may vary.


If building your own machine, you shall first choose the Firmware fork you want to use. There are three up-to date forks available :

  • DC42 fork for Duet board
  • Chrishamm fork, derived from the DC42 fork and very close to it (Chrishamm develop the web interface)
  • Dan Newman fork, to be used with RADDS board, development stopped on April, 21, 2016.

Each fork propose a complete SD-card image, with files that you will adapt to your own machine, using any text editor.

Boards are delivered with a firmware flashed, however you shall systematically update it before starting the commissioning of your machine.

Recent firmware can be updated with simple file uploading over the network.

Macros files could be uploaded through web interface. System macros are automatically uploaded in '/sys' directory, others in '/macros' directory

Configuration file can be uploaded through web interface or edited directly in the interface.

Image update or multiple file manipulation could be done with FTP without removing the SD card.

For common operation, there is no need to edit any file of the web interface, however depending browser configuration, users may prefer to configure some files for better usability.

Configuration & commissioning

Firmware binaries

Further reading

Firmware design


RepRap Firmware is intended to be a fully object-oriented highly modular C++ control program for RepRap self-replicating 3D printers.

It owes a lot to Marlin and to the original RepRap FiveD Firmware.

It was written by Adrian at RepRapPro Ltd.

It is on Github here.

A complete uploadable executable version for the Duet is in the directory Release/RepRapFirmware.bin in that repository. For details of how to flash it to a Duet see here.

For details of how to compile the source code, see below.

General design principles

  1. Control by RepRap G Codes. These are taken to be machine independent, though some may be unsupported.
  2. Full use of C++ OO techniques,
  3. Make classes hide their data,
  4. Make everything except the Platform class (see below) as stateless as possible,
  5. No use of conditional compilation except for #include guards - if you need that, you should be forking the repository to make a new branch - let the repository take the strain,
  6. Concentration of all machine-dependent defintions and code in Platform.h and Platform.cpp,
  7. No specials for (X,Y) or (Z) - all movement is 3-dimensional,
  8. Except in Platform.h, use real units (mm, seconds etc) throughout the rest of the code wherever possible,
  9. Try to be efficient in memory use, but this is not critical,
  10. Labour hard to be efficient in time use, and this is critical,
  11. Don't abhor floats - they work fast enough if you're clever,
  12. Don't avoid arrays and structs/classes,
  13. Don't avoid pointers,
  14. Use operator and function overloading where appropriate.

Naming conventions

  2. No underscores in other names - MakeReadableWithCapitalisation
  3. Class names and functions start with a CapitalLetter
  4. Variables start with a lowerCaseLetter
  5. Use veryLongDescriptiveNames


There are eight main classes:

  1. RepRap
  2. GCodes
  3. Heat
  4. Move
  5. Tool
  6. Platform, and
  7. Webserver
  8. PrintMonitor


This is just a container class for the single instances of all the others, and otherwise does very little.


This class is fed GCodes, either from the web interface, or from GCode files, or from a serial interface, Interprets them, and requests actions from the RepRap machine via the other classes.


This class implements all heating and temperature control in the RepRap machine.


This class controls all movement of the RepRap machine, both along its axes, and in its extruder drives.


This class allows the definition of tools. A tool is zero or more heaters associated with zero or more drives. The heaters can be set to different temperatures, and the drives can be set to go at different (and varying) speeds. This allows the easy implementation of multiple-head machines, mixing-head machines and so on.


This is the only class that knows anything about the physical setup of the RepRap machine and its controlling electronics. It implements the interface between all the other classes and the RepRap machine. All the other classes are completely machine-independent (though they may declare arrays dimensioned to values #defined in Platform.h).


This class talks to the network (via Platform) and implements a webserver to give an interactive interface to the RepRap machine. It uses the Knockout and Jquery Javascript libraries to achieve this.


When the software is running there is one single instance of each main class, and all the memory allocation is done on initialization. new/malloc should not be used in the general running code, and delete is never used. Each class has an Init() function that resets it to its boot-up state; the constructors merely handle that memory allocation on startup. Calling RepRap.Init() calls all the other Init()s in the right sequence.

There are other ancillary classes that are declared in the .h files for the master classes that use them. For example, Move has a DDA class that implements a Bresenham/digital differential analyser.


There is a single interrupt chain entered via Platform.Interrupt(). This controls movement step timing, and this chain of code should be the only place that volatile declarations and structure/variable-locking are required. All the rest of the code is called sequentially and repeatedly as follows:

All the main classes have a Spin() function. These are called in a loop by the RepRap.Spin() function and implement simple timesharing. No class does, or ever should, wait inside one of its functions for anything to happen or call any sort of delay() function. The general rule is:

  Can I do a thing?
    Yes - do it
    No - set a flag/timer to remind me to do it next-time-I'm-called/at-a-future-time and return.

The restriction this strategy places on almost all the code in the firmware (that it must execute quickly and never cause waits or delays) is balanced by the fact that none of that code needs to worry about synchronization, locking, or other areas of code accessing items upon which it is working. As mentioned, only the interrupt chain needs to concern itself with such problems. Unlike movement, heating (including PID controllers) does not need the fast precision of timing that interrupts alone can offer. Indeed, most heating code only needs to execute a couple of times a second.

Most data is transferred bytewise, with classes' Spin() functions typically containing code like this:

  Is a byte available for me?
      read it and add it to my buffer
      Is my buffer complete?
           Act on the contents of my buffer

Note that it is simple to raise the "priority" of any class's activities relative to the others by calling its Spin() function more than once from RepRap.Spin().

Compiling from Source

The following instructions relate to the original RepRapPro version of RepRapFirmware, which is no longer maintained. The current maintained forks by dc42, chrishamm and dcnewman all use different (and generally simpler) build procedures, as described in the corresponding github repositories.

The Think3dPrint3d blog has a post on how to setup Eclipse to modify and compile the firmware with printer specific options, the ultimate aim to to have all printer specific options set by g-code. See also this [thread about compilation].

RepRap Firmware was developed using the Eclipse IDE, which is much more powerful for big software projects than the Arduino IDE.

We use Eclipse Juno, which is available here.

You will also need the Eclipse Arduino support available here.

And the Arduino IDE itself (make sure you get the latest stable one for the Due/Duet), which is available here.

Start by getting the Arduino IDE programming your Duet with a simple Hello World program that prints to the USB (SerialUSB.print("Hello World"); on the Due/Duet, not Serial.print("Hello World");... )

Then install Eclipse and the Arduino plugin.

Make temporary copies of RepRapFirmware.cpp and RepRapFirmware.h from your download in another folder (you will only need to do this once).

Finally use Eclipse to open the Arduino project called RepRapFirmware in the folder where you have downloaded the RepRap Firmware code. Tell Eclipse to use the Arduino-libraries files you downloaded as the local libraries. Eclipse will complain that the project already exists (which it does - it is your download). Ignore this and it will open the project anyway.

Annoyingly the first time it may also overwrite RepRapFirmware.cpp and RepRapFirmware.h. So close the project, overwrite its overwrites with the two files you saved, open the project again and refresh it. Everything should now be ship-shape. Add the libraries


to your project. Under no circumstances be tempted to add standard Arduino libraries for devices like Ethernet - these are for the Due, and will not work on the Duet.

You should now be able to compile the code and upload the result to the Duet.