Firmware/Alternative
See also a Comparison chart of Firmwares on page Comparison_of_RepRap_Toolchains
Arduino Test Code
Simple tests to help debug and check your arduino and cartesian robot.
- pRINToPTO - doesn't move any motors, only prints the status of the opto switches to the arduino IDE terminal.
- hOMING - brings back all the axes one by one to the home position using only the opto switches as feedback (no sanity checks).
- rECTANGULARsPIRAL - prints the above rectangular spiral from the current position (no homing). width height and margins are easily modifiable.
YouTube Video of the rECTANGULARsPIRAL program in action.
Download the Test_code.zip file.
Teacup Firmware
Rewrite of FiveD firmware for the Arduino by Triffid Hunter and more. It avoids C++ in favour of plain C, and uses 100% integer math.
alternatives to G-code
Several people have suggested designing a host-to-microcontroller communication protocol much simpler and easier to interpret than G-code. At the moment, these are all highly experimental, but they could potentially reduce the net cost of a RepRap (simpler protocols can be decoded by lower-cost electronics) and improve the speed and quality of printed parts (less time decoding and interpreting commands may result in more time extruding plastic).
As a first step, and to remain compatible with the many tools that produce G-code, software on the PC can pre-interpret G-code files to produce motion commands in a simpler format, something like the way 3D-to-5D-Gcode.php converts one kind of G-code to a simpler-to-interpret kind of G-code.
- Granite Host
- EMCRepRap converts most G-code to simple "step, direction" pulses on the PC.
- SNAPComms
- Much of the ""Firmware - experimental" RepRap discussion forum discusses protocols that are hopefully easier to interpret than G-code.
- splines and circles: By describing every move in the form of curved cubic splines, not only do we reduce the volume of data required to describe a curved part, but it may also make the microcontroller firmware simpler and faster. Faster: only integer arithmetic required. Simpler: the firmware only needs a single subroutine to handle cubic splines, rather than several subroutines to handle straight lines, circles, arcs, and the involute curve used for twice for each gear-tooth. Less volume: 8 cubic splines per circle are more than adequate for high precision CAD/CAM machines[1], while apparently (?) the current RepRapGCodes requires hundreds of tiny straight line segments to approximate the same circle. Elegant multispline motion controller and RepOlaRap mention such splines.
- Flutterwumper Library generally focuses on generating shapes in PostScript format, and then converting directly from PostScript to "step, direction" pulses, without ever going through G-code.