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
- Control by RepRap G Codes. These are taken to be machine independent, though some may be unsupported.
- Full use of C++ OO techniques,
- Make classes hide their data,
- Make everything except the Platform class (see below) as stateless as possible,
- 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,
- Concentration of all machine-dependent defintions and code in Platform.h and Platform.cpp,
- No 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.
- #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 eight main classes:
- Platform, and
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, 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? Yes read it and add it to my buffer Is my buffer complete? Yes Act on the contents of my buffer No Return No Return
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.
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.
- Duet Firmware Update
- RepRap Firmware G-Codes
- Updating RepRap Firmware config.g file
- Configuring RepRapFirmware for a Cartesian printer
- Configuring RepRapFirmware for a CoreXY printer
- Configuring and calibrating a delta printer using the dc42 fork of RepRapFirmware
- Duet Web Control
- RepRap Firmware macros
- Using thermocouples with the Duet and RepRapFirmware