- 1 RepRap Firmware Use
- 1.1 Overview
- 1.2 Generations
- 1.3 Innovative features
- 1.4 Printer geometries and adjustment
- 1.5 Automatic calibration
- 1.6 Connectivity
- 1.7 SD-card file architecture
- 1.8 Compatible hardware
- 1.9 SD card
- 1.10 Configuration
- 1.11 Further reading
- 2 Firmware design
RepRap Firmware Use
3D printer RepRap Firmware runs on 32 bit, ARM-based microprocessors Atmel SAM3X8E, as found on the Arduino Due and Duet 0.6 and 0.8.6 electronics, and on ATSAM4E8E as found in the Duet WiFi and Duet Ethernet electronics.
This firmware is pre-compiled and flashed on to the printer board. It is configured with human editable files located on an SD-card plugged into the printer electronics. As such, there is no need for ordinary users to compile the software nor install any development tools.
The software can receive G-Code from the USB port, the serial port, the SD card, the Ethernet or WiFi interface via http, and the Ethernet interface via Telnet.
Although it can run from an interface connected via USB, most users prefers to operate from a web interface, with the board connected to an Ethernet or WiFi network. Files to be printed are uploaded to the SD card via the web interface.
The RepRapFirmware philosophy is that every operation is done with G-code, including configuration. For this reason, RepRapFirmware supports a number of GCodes, mostly in the M500-M599 and M900-M999 range, that are not currently supported by most other firmwares. See RepRap Firmware G-Codes.
The configuration file is read on SD card at start-up.
Any G-code or macro could be sent 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 can be adjusted with a G-Code.
This interactive configuration makes 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
RepRapFirmware 1.x was written originally for the Duet 0.6 electronics using the ATSAM3X8E microcontroller. It was ported to other processors, but those ports have since moved on to RepRapFirmware 2. It services the machine by executing a loop that calls the Spin function of each module, just like almost all other 3D printer firmwares do.
RepRapFirmware 2 uses the FreeRTOS Real Time Operating System with pre-emptive multitasking, in order to run high-priority processes for critical tasks such as maintaining temperature, and lower priority tasks for other functions. The networking subsystem is more modular to allow different types of network interfaces to be used, even multiple network interfaces on the same board.
RepRapFirmware 3 also use FreeRTOS. It has a more flexible system to allow almost all I/O port connections on the electronics other than stepper motor connections to have their functions reassigned at start-up, or even when the system is running. It also supports stepper motors, heaters, fans, temperature sensors, endstop inputs etc. on expansion boards connected to the main board via CAN bus. It also supports offloading the storage, networking and user interface functions to a single board computer (e.g. Raspberry Pi) via a dedicated SPI connection.
RepRapFirmware has been a platform for introducing innovation in 3D printer firmware. It is believed to be the first to introduce the following technologies into open-source 3D printing firmware, and most of these are still not provided by any other firmware as at December 2019:
- Precise step time generation, not only during constant-speed motion but also during acceleration (since January 2015)
- Precise carriage motion on delta printers, without using segmentation to approximate linear motion on a delta printer (since January 2015)
- Least-squares auto calibration of 7 geometry factors (since extended to 9) of delta printers (since April 2015)
- True pressure advance with accurate timing, including retraction of filament towards the end of a decelerating move when it is called for (since January 2015)
- High speed (typically 1Mbytes/sec) file upload to the SD card over Ethernet or WiFi, making it practical to use the web interface for all common printing operations
- Configuration file editing and updating in the web interface
- Firmware updating through the web interface
- Comprehensive reporting of printer status and configuration using an extensible JSON-based response
- Mesh bed compensation with a 3D representation of the bed height map in the web interface (since December 2016)
- Heater auto-tuning that measures separately the gain, time constant and dead time of the heater, allowing for different PID parameters to be used while heating up (to minimise overshoot) and while printing (to react faster to changes in heating demand)
- Dynamic Acceleration Adjustment to mitigate ringing
- Support for any kinematics with up to 9 axes for which the motion of each axis is a linear combination of the motion of the motors
- Support for additional towers on delta printers, for example to carry flying extruders
- Support for CAN-bus connected expansion boards, allowing large numbers of motors, heaters, sensors, fans etc. to be controlled
Printer geometries and adjustment
A single build of RepRapFirmware handles multiple geometries:
- CoreXY, CoreXZ, CoreYZ, MarkForged, CoreXYU, CoreXYUV
- Any other kinematics with up to 9 axes for which the motion of each axis is a linear combination of the motion of each motor
- Linear delta (trajectories are calculated without segmentation), with fast least-squares auto calibration and X,Y,Z scaling correction
- Linear delta with up to 3 additional towers (e.g. for flying extruders)
- Linear delta with additional linear or rotary axes
- Rotary delta
- Serial SCARA
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.
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
To operate, the firmware need the following files to be present on the SD-card - names are case sensitive:
- configuration file
- A set of system G-code macros with predefined names located in
- A set of user launchable macros located in
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.
G-code print files are in
/gcodes directory - with this exact orthography. Sub-directories can be defined.
/wwwdirectory for web interface (Duet 0.6 and 0.8.5)
All the web interface files are in
- Duet (all versions : 0.6 and 0.8.5)
- Duet 2 Wifi, Ethernet, Maestro
- Duet 3
- 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.
- LPC1768/1769-based boards (port maintained by [sdavi])
An SD card is delivered with each Duet. Sustained transfer speeds have gradually improved as the firmware has been further developed, and for large files are typically in the range 500kbytes/sec to 1.1Mbytes/sec using firmware version 1.17.
Note that the performance claimed by the SD card manufacturers is for short bursts of writing large blocks. RepRapFirmware has limited buffer memory, so it does longer bursts of smaller blocks, which may prove slower on supposedly fast cards. 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
Note: Most of the following have been superseded by more recent content on the Duet3D wiki.
- Configuring RepRapFirmware for a Cartesian printer
- Configuring RepRapFirmware for a CoreXY printer
- Configuring and calibrating a delta printer using the dc42 fork of RepRapFirmware
- T3P3 guide to the config.g and homing files for Cartesian printers
- Preconfigured config.g files for various printers: https://github.com/reprappro/RepRapFirmware/tree/test/SD-image and https://github.com/dc42/RepRapFirmware/tree/dev/SD-image
- RepRapPro guide for commissioning Duet-based printers, including updating firmware: https://reprappro.com/documentation/commissioning-introduction/commissioning-duet/. You may also find their wiring diagrams for the Ormerod, Huxley and Mendel useful.
- Duet troubleshooting guide: https://reprappro.com/documentation/troubleshooting-introduction/electronics-problems/
- DC42 fork allow external driver to be connected on the expansion connector and remapped with M569 . See http://forums.reprap.org/read.php?178,552124,552305
- Using Duet with wifi router on blog.think3dprint3d.com
- Useful RepRap Firmware macros
- RepRap Firmware heating for configuration and tuning of heating loops
- Using thermocouples with the Duet and RepRapFirmware
- Using PT100 temperature sensors with the Duet and RepRapFirmware
- RepRap Firmware release notes
- Original RepRapPro firmware binaries (no longer maintained, and not for deltas or CoreXY machines): https://github.com/reprappro/RepRapFirmware/tree/master/Release
- dc42's fork firmware binaries: https://github.com/dc42/RepRapFirmware/tree/dev/Release
- Chrishamm's fork firmware binaries: https://github.com/chrishamm/RepRapFirmware/tree/dev/Release
- Chrishamm's DuetWebControl web interface (works with dc42 fork and chrishamm fork of RepRapFirmware): https://github.com/chrishamm/DuetWebControl
- Dan Newman port on RADDS board
- Release notes for DC42 firmware fork and Duet Web Control
RepRap Firmware is intended to be a fully object-oriented highly modular C++ control program for RepRap self-replicating 3D printers.
It was written by Adrian at RepRapPro Ltd.
It is on Github here.
For details of how to compile the source code, see below.
General design principles
These have been modified somewhat since Adrian Bowyer write them initially.
- Control by RepRap G Codes. These are taken to be machine independent, though some may be unsupported.
- No use of dynamic memory allocation after the initialisation phase (this is standard practice in high-integrity real-time embedded software development).
- Code shall compile without warnings, with all warning messages enabled, except where this is not practical in third-party library code.
- Use C++ OO techniques, and make classes hide their data.
- Minimise the use of conditional compilation. The standard distribution binary should support all features.
- Make full use of the processor resources available - RepRapFirmware is never going to use a processor that is slower/less powerful than the SAM3X8E.
- As far as reasonably practical, processor-dependent code should be in the hardware abstraction layer project (originally the Arduino Due core, now the CoreNG project).
- Concentration of all machine-dependent definitions and code in Platform.h and Platform.cpp.
- Avoid specials for (X,Y) or (Z) - all movement is 3-dimensional,
- Except in Platform.h, use real units (mm, seconds etc) throughout the rest of the code wherever possible.
- Try to be efficient in memory use, but this is not critical.
- Labour hard to be efficient in time use, and this is critical.
- Don't abhor floats - they work fast enough if you're clever.
- Don't avoid arrays and structs/classes.
- Don't avoid pointers.
- Use operator and function overloading where appropriate.
- Minimise the use of #define. Use C++ constant declarations and inline functions instead wherever possible.
- #defines are all CAPITALS_WITH_OPTIONAL_UNDERSCORES_BETWEEN_WORDS
- No underscores in other names - MakeReadableWithCapitalisation
- Class names and functions start with a CapitalLetter
- Variables start with a lowerCaseLetter
- Use veryLongDescriptiveNames
There are nine main classes:
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).
When the software is running there is one single instance of each main class. For code safety reasons, and all the memory allocation is done on initialization and new/malloc should not be used in the general running code. In addition, 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.
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
Wire EMAC Lwip MCP4461 SamNonDuePin SD_HSMCI
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.