English • العربية • български • català • čeština • Deutsch • Ελληνικά • español • فارسی • français • hrvatski • magyar • italiano • română • 日本語 • 한국어 • lietuvių • Nederlands • norsk • polski • português • русский • Türkçe • українська • 中文（中国大陆） • 中文（台灣） • עברית • azərbaycanca •
THIS page is an extremely rough draft. You can help us improve it. (Someday this page will document many of the known-working systems. A few known-working systems are already documented at RepRap Options).
If you have written microcontroller firmware for the RepRap for any microcontroller this is the place to document it.
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.
Download the Test_code.zip file.
Some people think that an extended suite of test firmware might be helpful:
- SetupTest - doesn't move any motors. Turns on the power supply, blinks the LED of HEATER1 ten times, then turns off the power supply.
- RepRap forums: "Test Suite to begin with a RepRap".
- Firmata is a generic protocol that allows people to completely control the Arduino from software on a host computer. Arduino reference for Firmata; Firmata wiki.
Most people writing and tweaking firmware apparently test the new code by running it on real hardware. At least one person uses SimulAVR for testing -- for example, Teacup Firmware#Running Teacup in a simulator.
Many parts we want to print out have circles and other gentle curves.
Most current firmware only supports extruding straight lines, so the slicer converts those curves into thousands of tiny straight lines -- so small that they can be printed faster than some drip-feeders can send them from the host to the RepRap, leading to buffer underflow. (Other proposals for fixing this buffer underflow problem: #SD card, #alternatives to G-code).
Perhaps it would be better if the firmware implemented some sort of curve -- perhaps the standard
- "G5.1" command (quadratic B-spline).
- "G2" command (clockwise arc).
- "G3" command (counterclockwise arc).
- Is there a standard G code for a cubic curve, perhaps represented as the 4 points of a cubic Wikipedia: Bézier curve familiar to anyone who has used Inkscape, CorelDRAW, Adobe Illustrator, or etc.?
One practical guide to implementing such curves in firmware: Steve Noskowicz. "Interpolation and Curves for Graphics".
A theoretical guide to gear design with Bézier curves: Fumitaka Higuchi, Shuuichi Gofuku, Takashi Maekawa, Harish Mukundan, Nicholas M. Patrikalakis. "Approximation of Involute Curves for CAD-System Processing": "Bézier Approximation of Circle Involute Curves". 2006. </ref>
Then a post-processor after the slicer converts those thousands of tiny straight lines into a few dozen circular arcs (a circular spline) or a handful of B-splines. It should be much easier for the drip-feeder to send a few dozen G codes representing curves through the USB cable than to send thousands of tiny straight lines.
Fabien Chouteau, "Make with Ada: ARM Cortex-M CNC controller" (2016) wrote a Gcode interpreter for the ARM Cortex-M4F, including implementations of G02 and G03 circular motion.
Most RepRap firmware implements G-code by executing one line at a time as it is "drip-fed" out from a host (perhaps with a small buffer of a few lines).
Some RepRap firmware reads ".gcode" files off a SD card, with no host intervention necessary. The two main approaches:
- The host sends the an entire layer or perhaps the entire print, and the RepRap firmware saves it to the SD card, which acts as a large buffer.
- The host saves the ".gcode" file to a SD card, which a person manually carries and plugs into a completely stand-alone printer.
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.
- Wikipedia: STEP-NC: "STEP-NC was designed to replace ... G-codes ... adding tolerance data ... [with a] XML format."
- "Implementing Postscript as firmware" on the RepRap forums.
- GCODE buffer multiline proposal discusses a small change to the G-code protocol that is forwards- and backwards- compatible.
- Granite Host
- EMCRepRap converts most G-code to simple "step, direction" pulses on the PC.
- 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, while apparently (?) the current RepRapGCodes requires hundreds of tiny straight line segments to approximate the same circle.
- Elegant multispline motion controller and RepOlaRap and Repic5D mention such splines.
- Elegant multispline motion controller "will not use G-code. It will use a custom language based on cubic Bezier curves. This allows for much better description of arcs and will result in much higher quality prints with a much lower data throughput requirements."
- 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.
- ".gcode versus .s3g" discusses the ".s3g" format file produced by replicatorG. It also mentions that USB seems to have high latency.
- "latency and jitter concerns" has yet another discussion of latency and jitter in USB-to-Arduino communication.
- "Bluetooth working, but pauses after each gcode line" says that Bluetooth has even more latency than USB.
- "firmware free hardware" have some discussion on doing all G-code interpretation on the host -- perhaps using the EMC G-code interpreter -- and then driving the RepRap motors without any RepRap-specific firmware:
- perhaps using the generic Firmata Arduino firmware on the Arduino, or
- perhaps mis-using an "Arduino programming cable" (basically a FTDI FT232 chip and some connector hardware) or two in bit-bang mode without an Arduino, or
- perhaps connecting the parallel printer port pins directly to the "step, direction" pins of the motor drivers directly, without any IC at all.
- "Pacemaker" is intended to simplify the client. The host translates G-Codes into Pacemaker protocol.