diff options
| -rw-r--r-- | README | 143 | ||||
| -rw-r--r-- | README.md | 24 |
2 files changed, 24 insertions, 143 deletions
diff --git a/README b/README deleted file mode 100644 index 109e9dbe..00000000 --- a/README +++ /dev/null @@ -1,143 +0,0 @@ -This firmware is intended to be a fully object-oriented highly modular control program for -RepRap self-replicating 3D printers. - -It owes a lot to Marlin and to the original RepRap FiveD_GCode. - -This is the version for the RepRap Duet: - - http://blog.think3dprint3d.com/2013/12/Duet-Arduino-Due-compatible-3DPrinter-controller.html - -A complete uploadable executable version is in the directory Release/RepRapFirmware.bin in this -repository. For details of how to flash it to a Duet see here: - - https://reprappro.com/documentation/commissioning-introduction/maintenance-duet/#Installation_8211_Flashing_the_Firmware - -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 definitions 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. - - -Naming conventions: - - * #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 - - -Structure: - -There are six main classes: - - * RepRap - * GCodes - * Heat - * Move - * Platform, and - * Webserver - -RepRap: - -This is just a container class for the single instances of all the others, and otherwise does very little. - -GCodes: - -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. - -Heat: - -This class implements all heating and temperature control in the RepRap machine. - -Move: - -This class controls all movement of the RepRap machine, both along its axes, and in its extruder drives. - -Platform: - -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). - -Webserver: - -This class talks to the network (via Platform) and implements a simple 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. - - -Timing: - -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: - -As of version 057r-dc42 the tick interrupt (which is set up by the Arduino core) is also used to set up ADC conversions, -read the result of the last conversion, and shut down heaters when temperature errors are detected. - -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 - -See separate file BuildInstructions.txt. - -Licence: GPLv3, see http://www.gnu.org/licenses/gpl-3.0.en.html diff --git a/README.md b/README.md new file mode 100644 index 00000000..2bdfe5f1 --- /dev/null +++ b/README.md @@ -0,0 +1,24 @@ +This is firmware for controlling 3D printers and related devices using electronics with Atmel ARM main processors. The minimum specification processor it is intended for is ARM Cortex M3 with 96Kb RAM such as the SAM3X8E. + +General design principles: + +* Unlike most other 3D printer firmwares, this is not intended to be portable to outdated processors with limited CPU power. So make good use of the power of modern inexpensive ARM processors to implement advanced features. +* "One binary to rule them all". For a given electronics board, all features if interest to many 3D printer owners are supported by a single binary. Users do not need to recompile the firmware unless they have unusual requirements. +* "G-code everywhere". All firmware configuration is done using gcodes in the config.g file. Most type of change can be done on the fly so that you can experiment with different configurations without even having to restart the printer. +* Use high-integrity coding standards to help ensure that the firmware is reliable. In particular, don't use dynamic memory allocation after the initialisation phase. The MISRA-C++ 2008 coding standard serves as a guide as to what is acceptable practice, but compliance to it is not rigidlty enforced in order to allow features from later versions of the C++ language to be used. +* Use an appoprriate degree of modularity. Too little modularity makes the code hard to understand and maintain. Too much makes it hard to intruduce new features when the exising module boundaries turn out to be inappropriate. +* Use object-based and object-oriented design principles where it is appropriate. In particular, class data should normally be private. Use 'friend'# sparingly or not at all. + +RepRapFirmware has pioneered a number of advances in 3D printing including: + +* Support for mixing extruders (July 2014) +* Precise timing of step pulses, even during acceleration (Janury 2015) +* Segmentation-free delta motion (January 2015) +* Least-squares auto calibratoin of delta printers (April 2015) +* Accurate extruder pressure advance, including retraction before the end of a move when needed (January 2015) + +For documentation on supported gcodes and configuration, see https://duet3d.com/wiki. There is a tool for generating the config'g file and homing files at https://configurator.reprapfirmware.org/. + +Compiling from source: see separate file BuildInstructions.txt. + +Licence: GPLv3, see http://www.gnu.org/licenses/gpl-3.0.en.html |