169 lines
6.3 KiB
Text
169 lines
6.3 KiB
Text
RepRapFirmware - Main Program
|
|
|
|
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.
|
|
|
|
|
|
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 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,
|
|
* 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, particularly for vector algebra.
|
|
|
|
|
|
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, interprests them, and requests
|
|
actions from the RepRap machine via the other classes.
|
|
|
|
Heat:
|
|
|
|
This class imlements 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 initialisation. 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 ancilliary 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:
|
|
|
|
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 synchronicity,
|
|
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 typically containg 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().
|
|
|
|
--------------------------------------------------------------------------------
|
|
|
|
This version is for the Arduino Due with an Ethernet shield with an SD card and
|
|
the RepRapPro Ltd Arduino DUE to Sanguinololu Adaptor.
|
|
|
|
(See https://github.com/reprappro/ARMadaptor)
|
|
|
|
Test compiling was with Arduino 1.5.2.
|
|
|
|
Upload it to your Due, put the ether shield on it, plug in a
|
|
network cable, and copy the files in the SD-image folder onto the SD.
|
|
|
|
The IP address for your browser is 192.168.1.14.
|
|
|
|
You can change that in Platform.h if you need to:
|
|
|
|
#define IP0 192
|
|
#define IP1 168
|
|
#define IP2 1
|
|
#define IP3 14
|
|
|
|
The password when the web browser asks for it is "reprap" with no quotes.
|
|
|
|
The password is intended to stop fidgety friends or colleagues from playing
|
|
with your RepRap. It is not intended to stop international cyberterrorists
|
|
hiding in a hollowed-out volcano from controlling your RepRap from the next
|
|
continent. For example, it is transmitted unencrypted...
|
|
|
|
If you open the Arduino serial monitor (115200 baud) you should see a
|
|
log of incoming HTTP requests and a record of any G Codes it thinks it
|
|
has to act upon.
|
|
|
|
Actually acting upon them will be added shortly :-)
|
|
|
|
-------------
|
|
|
|
Version 0.2 pre-alpha
|
|
|
|
Started: 18 November 2012
|
|
This date: 12 June 2013
|
|
|
|
Adrian Bowyer
|
|
RepRap Professional Ltd
|
|
http://reprappro.com
|
|
|
|
Licence: GPL
|