Redeem
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 • |
Release status: working
Description | a firmware for BeagleBone Black
|
License | GNU GPL v3
|
Author | |
Contributors | |
Based-on | |
Categories | |
CAD Models | |
External Link |
Current Version: 0.16.3~The Terminator Current develop version: 016.8~The Terminator
See Redeem on Bitbucket.
Works on Replicape.
Contents
Quick Information
Redeem (Replicape daemon) is the default firmware for Replicape. It is written mostly in Python, but since version 0.14, it has a native path planner based on the code from [Repetier]. It makes heavy use of the two Programmable Realtime Units (PRU) on the BeagleBone Black, one is dedicated to the stepper motor timing and operation, and the other is dedicated to monitoring end stops and posting that to the other PRU. This enables fast stepping and fast stops while freeing up the main CPU for other tasks.
While "firmware" is not the ideal name for this, since it runs in a full Linux environment and also has other related daemons (Toggle and Octoprint) running on the same board, it is a piece of software very much in the same regards as Marlin and Teacup etc. The web interface allows monitoring and restart of some important processes as well as basic editing of the configuration files. Octoprint is now standard on the latest BeagleBone flasher image distribution (Based on Angstrom) along with Redeem and Toggle.
Features:
- PRU based movement with constant acceleration
- Very high step rate
- Look ahead up to 128 steps
- Separate threads for each temperature PID
- Use of SI units wherever possible
- Separate 200 MHz PRU for end stop events/handling
- End stop lookup table configuration (enables easy end-stop config for each of the 5 axes)
- SD Card support and on board flash support.
- Communication through USB, Ethernet, and virtual TTY pipes (for other daemons on the BBB)
- Cascading configuration files enables printer and local overrides. Easily extendable (for hot ends etc.)
- Web interface for configuration files.
- Temperature oversampling
- Integration with Toggle, and Octoprint
- End stop trigger reporting to the host software.
In the develop branch:
- Automatic bed leveling
- PID autotune
Delta compatible
Yes, currently only in the develop branch.
CoreXY compatible
Yes
H-belt compatible
Yes
Configuring and compilation:
Compilation of the firmware for the PRUs is handled by Redeem on startup, if needed (Thanks Mathieu Monney). The latest version of Redeem can be installed directly on the BeagleBone by SSH-ing to it and fetching it from bitbucket. Use the setup.py script located in software/path_planner:
python setup.py install
Redeem uses cascading configuration files. That means that if a setting is found in a file with higher precedence, the setting is overridden. There are three layers by order of precedence: local, printer and default. Configuration files are located in /etc/redeem. default.cfg is the fall-back/catch all file, printer.cfg should be a symlink to any of the printers in the folder (Mendelmax.cfg, Makerbot_cupcake.cfg, etc). local.cfg should contain any "local" changes such as PID values, microstepping, stepper current etc.
Bug reports
Bugs are reported and processed through the bitbucket interface: [1]
Credits
Redeem was started by Elias Bakken where he made the first working implentation in Python and assembly for the PRU code. Mathieu Money has made significant contributions to the project, especially by writing a C implementation of the path planner (this changed the license from CC BY-SA to GPL V3.0 to be compatible with Repetier from which it was ported). Mathieu has also made a loadable G-code system resembling reflective loading of g-codes enabling cleaner G-code implementations by keeping each g-code in a separate file. Anthony Clay has done some great work with the implementation of the M400 G-code that enables buffered G-codes to be synchronized. This is important when using large buffering.