Firmware/Alternative

From RepRap
Revision as of 11:47, 27 November 2010 by DavidCary (talk | contribs) (alternatives to G-code)
Jump to: navigation, search

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.

rECTANGULARsPIRAL action

Download the Test_code.zip file.

FiveD on Arduino

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.

wiki article Blog Post Forum Thread Git Repository

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.