Automatic bed leveling helps improve first layer height above bed. That is very useful, because if the first layer does not stick, the rest of the print does not matter. It also lowers the bar for first times to get started, and it saves a bunch of time for old-timers that have moved their printer.

But bed probing, the pre-cursor to automatic bed leveling can be done in a lot of ways. There are a bunch of probes available for the actual probing, but choosing the right probe depends on the type of bed, the weight of the sensor, the cost etc. In addition, different printers have different ways of doing the probing.

Redeem has gotten some much needed attention on the bed probing, leveling and visualization of the process and results lately. This blog post aims to go over the new interface, including some helper G-codes for quickly getting started.

TL;DR – See the video

G29 interface documentation

The interface (how to use the command) is pretty straight forward. The G29 code itself is only a macro, meaning that it does almost nothing except execute all the G-codes in it’s macro definition. The only parameter that can be supplied, is the letter “S”, for Simulate. If an S is added, all lines with the letters “RFS” (Remove For Simulation) is removed from the macro. The G29 macro is defined in the config file hierarchy, and can be generated using the G-codes G29S and G29C. See further down. Here is the interface definition.

Send: G29?
Recv: Probe the bed at specified points and update the bed compensation matrix based on the found points. Add 'S' to only simulate and thus remove all lines containing the letters 'RFS' (Remove For Simulation).

Ok, but if it’s a Macro, what commands can be put in there?

You can put pretty much any G-code that is implemented in Redeem. The reason the G29 is implemented as a macro is to facilitate all the different ways 3D-printers, CNC mills and lasers are built, with all their quirky ways of probing. Here is a list of G-codes that might be useful.

M561 – Reset, update or show bed matrix

This is a utility function for manipulating the bed matrix. M561 is defined to “reset the bed matrix” according to the reprap wiki. To maintain compatibility with that definition, the M561 without parameters will do just that. It has also been extended with some functionality. If a “U” is added as a parameter, the bed calibration matrix is updated based on the data from a probe. If “S” is added as parameter, show the current matrix. The reason for having this as a separate G-code and not as a part of the G29 inner workings is so that is can be removed during a simulation and also used in different places in the macro.

Send: M561?
Recv: This cancels any bed-plane fitting as the result of probing (or anything else) and returns the machine to moving in the user's coordinate system.
Recv: Add 'S' to show the marix instead of resetting it.
Recv: Add 'U' to update the current matrix based on probe data

M557 – Set probe point

This is used to pre-define which points to probe. No probing occurs, just a definition of a probing point which can later be recalled using the G30 command.

Send: M557?
Recv: Set the points at which the bed will be probed to compensate for its plane being slightly out of horizontal. The P value is the index of the point(indices start at 0) and the X and Y values are the position to move extruder 0 to to probe the bed. An implementation should allow a minimum of three points (P0, P1 and P2). This just records the point coordinates; it does not actually do the probing.
Recv: P = Probe point number.
Recv: X = X-coordinate
Recv: Y = Y-coordinate
Recv: Z = Z-coordinate. If missing, set to 0

G30  – Probe point – Execute a bed probing of a single point.

The G30 command is used to perform the actual probing. In the G29 macro, this is the meat and potatoes of the routine. During a testing phase, this can also be a very useful command to try when just trying the probing to make sure it works.

Send: G30?
Recv: Probe the bed at the current position, or if specified, a point previously set by M557. X, Y, and Z starting probe positions can be overridden, D sets the probe length, or taken from config if nothing is specified.
Recv: F sets the probe speed. If not present, it's taken from the config.
Recv: A sets the probe acceleration. If not present, it's taken from the config.
Recv: B determines if the bed marix is used or not. (0 or 1)
Recv: P the point at which to probe, previously set by M557.
Recv: P and S save the probed bed distance to a list that corresponds with point P

G32 – Undock probe

Activate whatever probing mechanism you have. This is itself a macro, so typically you would put some G-code that will move a servo with a switch in place, apply power to a solenoid, or simply define an end-stop to be active through the M574 command.

G31 – Dock probe

This should reverse the action done by the G32 command.

Pattern generator

The G29 command is implemented as a macro. That means that it is simply a bunch of G-codes read and executed in an orderly fashion. This is useful, because it makes it easy to adjust how the G29 code works for each individual printer. The downside is that it can be meticulous to write the G-codes by hand. Therefore a nifty G29 generator has been made and implemented in Redeem. It can be invoked by the command G29S (S is for Square) or G29C (C is for Circle).

A quick view of what the two pattern generators look like:

Send: G29C?
Recv: Generate a circular G29 Probing pattern
Recv: D = bed_diameter_mm, default: 140
Recv: C = Circles, default = 2
Recv: P = points_pr_circle, default: 8
Recv: S = probe_start_height, default: 6.0
Recv: Z = add_zero, default = 1
Recv: K = probe_speed, default: 3000.0

Send: G29S?
Recv: Generate a square G29 Probing pattern
Recv: W = bed depth mm, default: 200.0
Recv: D = bed depth mm, default: 200.0
Recv: P = points in total, default: 16
Recv: S = probe start height, default: 6.0
Recv: K = probe_speed, default: 3000.0

Here is  visual representation of what that looks like.

For many users, using the pattern generator directly can work, but for users with special probing routines, they can work as starting points for further improvements to the macro.

Visualizing the result

Using Toggle

There are several ways to visualize the results of a probing. Toggle will give an online (real time) view in 3D of the probing as it occurs using color coded pointers. This is useful to get a glimpse of the skewedness of the bed during a probing, and quickly determine if a probe point is registered as an outlier. That can happen if the probe is triggered too soon. It might be considered too coarse to do any optimization of the bed, but it’s good for getting an indication.

Looking at the results from the below probing for instance, done on my Thing Delta , it’s clear that the bed is really pretty slanted, having the highest point at +1 mm and the lowest at -1.94 mm. Still, looking at the pattern it appears to be pretty linear with the highest towards the front and the lowest towards the back.

Running the same probe with the command “G29 S” reveals the flatness of the bed using the currently implemented bed calibration matrix. The hight map generated by the probing points should now be more or less random, but with a much lower difference between the highest and the lowest probing point. In the testing probe run, the total height difference is only 0.17 mm, which is not great, but good enough for most prints.

Using Review

Second is using the review website to view the results of the probing. After a probing routine has been completed, a small info box will appear in OctoPrint, with a prompt to view the result of the probing. This link will upload the probing data to a website for viewing in a 3D-preview. Historical data is kept and can be added as an overlay to the previous probing results, giving an indication of whether or not the probing is improving. The review app differs between probing and testing data, depending on whether or not the “S” was added during the probing, so it is easy to compare the results before and after.

The post Improved automatic bed leveling in Redeem appeared first on www.iagent.no.

Redeem is quickly becoming the standard in 3D printer firmwares with self documenting G-codes and pre-processing path planner. Up until recently, two fairly standard features have had somewhat sub-par performance: PID auto-tune and automatic bed calibration. A recent poll on the Thing-printer G+ page revealed that these two things were on the top of list of things to improve, so in this article and the next, the new improvements will be documented.

When work started on the PID auto tune code, a few bugs and issues were discovered. Here is a quick rundown of the most important changes.

• Non standard implementation of the PID algorithm.
• Got rid of the ‘derivative kick’
• Implemented Steinhart-Hart algorithm
• Decimal numbers on temperature
• Current set point reported.
• Implemented M301

The old implementation had something akin to a mix between the standard and the ideal form. The PID algorithm is quite robust to tuning errors, so it was still possible to tune it well with the old implementation, but the current implementation is now a clean standard form implementation, which is what is most used in the industry. That makes it easy to test out new auto tuning calculations, if one was so inclined. Here is the standard formula for reference, taken from Wikipedia:

Due to this switch, some parameters in the config files have changed:

“pid_p_E” changes to “pid_Kp_E”

“pid_i_E” changes to “pid_Ti_E”

“pid_d_E” changes to “pid_Td_E”

Furthermore, some nice improvements to the code were added, like decimal temperature reporting and set point reporting. Mainly these improvements were for debugging during testing, but they are nice to have either way.

A big change for anyone doing configuration of their printer is the change from table based lookup of temperature to using the Steinhart-Hart algorithm for calculating temperature. This should add accuracy to the temperature and also simplify adding new sensors, since it is no longer necessary to generate a lookup table with a script.

As a result of this, some other important settings have been changed in the config files.

“temp_chart_E” changes to “sensor_E”

All the config changes are present in the new default.cfg file. If one of the old style configs are found in either printer.cfg or local.cfg, a warning will be given during startup. Please check the log after upgrading.

Documentation of new M303 interface

The G-code M303 has a slightly updated interface compared to the previous versions. Btw, if at any time you need the most up to date documentation for a G-code in Redeem, simply write add a question mark after the G-code, for example: “M303?”

Send: M303?
Recv: PID Tuning refers to a control algorithm used in some repraps to tune heating behavior for hot ends and heated beds. This command generates Proportional (Kp), Integral (Ki), and Derivative (Kd) values for the hotend or bed (E-1). Send the appropriate code and wait for the output to update the firmware. E overrides the extruder. Use E-1 for heated bed.
Recv: Default is the 'E' extruder with index 0.
Recv: S overrides the temperature to calibrate for. Default is 200.
Recv: C overrides the number of cycles to run, default is 4
Recv: P (0,1) Enable pre-calibration. Useful for systems with very high power
Recv: Q Tuning algorithm. 0 = Tyreus-Luyben, 1 = Zieger-Nichols classic

Improvements over other implementations

When doing experiments with the new auto tune routine, much advice and inspiration was drawn from the works of Ryan Carlyle, an eager Replicape user and RepRap contributor. One thing in particular he recommended was to add a pre-calibration routine, to figure out the rise time and fall time for the temperature of the hot end. This in turn can be used as a better starting point for the actual calibration cycles by estimating the rise and fall times ahead. A positive side-effect of the pre-calibration is that the amount of over-shoot typically experienced in a naïve bang-bang auto tune cycle diminishes. This can prevent filament from charcoaling due to excess temperatures.

The experiment did work, and can be tested out with the P-parameter added to M303. However, the formula relies on Newton’s law of cooling which breaks in the face of forced convection (IE a fan blowing on  or near the hot end). Thus to get good results, make sure you disable the automatic cold end fan that most hot ends use.

The result of the experimental tuning method can be seen in the header image. The important part is the pre-calibrate routine, something along the lines of:

1. Heat with 25% power to determine the maximum heat-up rate and dead-time.
2. Heat with full power until calibration temp is reached, minus the dead time.
3. Wait until peak temp is reached, then record the slope of the falling temperature graph a number of times.
4. Calculate the relationship between the heat-up rise time and the cool-down time to get a starting point for calibration.

The routine in the header image goes on to try and set the steady state temperature using the calculated values before calibrating with a bang-bang type calibration and the finally testing the resulting values.

The new algorithm also allows for specifying which type of tuning parameters are used. Right now, only Tyreus-Luyben and Zieger-Nichols classic are implemented, but other values are easily added, and pull requests are welcome!

The post PID autotune algorithm improvements appeared first on www.iagent.no.

Increased reliability with a filament sensor

One of the most annoying things that can happen when printing with 3D-printers is running out of filament or a filament jam. Both are almost unavoidable. There is no infinite filament (yet) and even the best filament manufacturers some times end up with foreign objects in their plastic batches. The thing that will separate current and future 3D-printers is most likely more sensors for monitoring stuff. Take a leap into the future right away by adding a rotary encoder based filament monitor to your Replicape controlled 3D-printer!

Replicape has support for incremental rotary encoders that can be used to monitor the movement of filament past the encoder. Typically a rotary encoder will give off discrete signals as a result of angular movement in one direction. The signals can be used to sense the direction and amount of angular movement the rotary encoder has done, which in turn can be converted into amount of filament consumed by knowing the diameter of the rotary encoders shaft. This information will need to be given to Redeem, in the section Rotary-encoders.

Software side
Behind the scenes, Redeem uses Linux’s rotary encoder kernel driver, which simplifies the development and maintainability of this feature. In order to enable this, you will need to know the number of cycles pr. revolution your encoder emits (cpr-e), the diameter of the wheel brushing against the filament and (diameter-e), and the device on which the events are reported, typically /dev/event/input1 (event-e). The big problem with the current setup is that you you need to reconfigure the devicetree in order to activate the rotary encoder kernel module. There is a document for the Linux kernel describing this binding: http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/input/rotary-encoder.txt.

           rotary@0 {
                compatible = "rotary-encoder";
                gpios = <&gpio3 17 0>, <&gpio0 4 0>;
                linux,axis = ; /* REL_X */
                rotary-encoder,relative-axis;
            };

Since the input device needs to be mentioned in the config file, it might be a good idea to also set up a udev rule symlinking the rotary encoder to a known name. That way, it will always get the same device name. Here is an example:

nano  /etc/udev/rules.d/99-rotary.rules

Place this into that file:

SUBSYSTEM=="input", ACTION=="add", ATTRS{name}=="ocp:rotary@2", SYMLINK+="rotary0"

A working rotary encoder setup for extruder E will look like this:

[Rotary-encoders]
enable-e = True
event-e = /dev/rotary0
cpr-e = -360
diameter-e = 0.003

Place this into:

/etc/redeem/local.cfg

Notice that the event device name (event-e) corresponds to what was set up with the udev rule.

It is also possible to set up an alarm that will trigger if the sensor deviates too much from what it should be.
If you want an alarm for that, set that up like the following:

[Filament-sensors]
# If the error is > 10 cm, sound the alarm
alarm-level-e = 0.1

Currently, if an alarm is triggered, it will send a “pause” action command to OctoPrint.

To visualize the filament use, Toggle now has a built in filament graph. To show it, simply tap the temperature graph to toggle between temperature and filament. To enable the streaming of data from Redeem, use the G-code (or M-code) M409. The token E enables all filament sensors connected, while D disables all. You can also specify which sensor to stream for by using an index after the “E”, so M409 E0 enables streaming for extruder 0 (E).

Electronics part
On the hardware side, two end-stop inputs are needed since a rotary encoder has two outputs. In addition to this they typically need a 5V-ish power source (+5V and GND). All of this can be taken from two end stops on Replicape. In the video posted, I’m using a rotary encoder left by a master student. A quick google search reveals that it is a s4-360-125-b-d, a $100 super smooth optical encoder. While doing research, I also ordered a few cheap rotary encoders from Digi-key, but soon realized that “retention” is not something you want, since it causes “drag” on the encoder. Useful if you want to use it for a user interface, but not so great if you want no additional force for your extruder. These from Digi-key work, but are not recommended for this particular purpose:
http://www.digikey.no/product-detail/en/C14D32P-A3/102-1923-ND/2039183
http://www.digikey.no/product-search/en?keywords=102-1763-nd

Mechanical part
So using the US digital rotary encoder, I created a simple “slide along” filament sensor. It relies on the filament being pushed towards the rotary encoder shaft causing it to rotate. This solution is not ideal, and will easily cause wrongful measurements, from what i have experienced, but it does suffice for a simple experiment.

The post Filament sensor on 3D printer with Replicape appeared first on www.iagent.no.

Finally a video that is specific to getting started with Replicape Rev B using the Kamikaze eMMC flasher!

There is a new Kamikaze image out that addresses some of the issues that have become apparent after people started to get their capes. To name a few:

If I access my printer on IP whatever, the OctoPrint link does not work.

The link is now gone. Instead, if you access your printer through your prowser you will be directed to OctoPrint directly.

How do I configure my printer?

The easiest way is to use OctoPrint for this. Upload the file you want to use through the redeem plugin interface in OctoPrint.

I can access OctoPrint, but I cannot connect!

When flashing your BeagleBone with Kamikaze, the flasher will check the signature of the EEPROM on the Replicape. If the signature is invalid, it will update it with the Replicape Rev B3 EEPROM file.

Something has gone wrong, where do I start to debug?

The log for Redeem is now placed in the “logs” section in OctoPrint, so that is a good place to start.

Once you are done with this video, go on to end stop configuration

The post Getting started with Kamikaze on Replicape Rev B appeared first on www.iagent.no.

The Reach board was ready for review over two years ago, but only now the software for it was ready. Some people have made their own versions of the board, but as far as I know, no one has ever gotten it to work! Well, that all ended on Tuesday, when the Reach board was running for full capacity.

Reach A0 is an add-on board for Replicape A4A, the pre-runner for the Rev B board. Many people have asked for a Reach rev B, one that is compatible with Replicape Rev B. All I can say is that it will be designed, but the volume will likely not make it a viable product for sale. Best case will be small production run, but as you know that really increases the price.

The cool thing about this is that Redeem now has support for up to 8 axes that can be operated at the same time. Previously, one had to chose an extruder, but now you can be fancy and use this G-code:

G0 X10 Y10 Z10 E10 H10 A10 B10 C10

That is if you are one of the three-ish people that have a Reach board. The fans can be connected to the thermistors, so the fan on the extruder starts when the extruder temperature goes above 60 degrees celsius. The M104 command now also supports higher number extruders as well.

Any of the additional axes can also be used in “slave mode” so there is no need for a splitting cable if you happen to have an additional stepper driver.

Fun project! Hopefully someone will try this out with a diamond hot-end or Kraken.

The post Get Quad extruders for Replicape by adding Reach appeared first on www.iagent.no.

Over the weekend, I’ve been working on some quite important features: Safety! The most important being disabling the heaters if anything goes wrong with the thermistor readings.

It’s boring, but it’s necessary. Safety features does nothing to improve the print quality, but it might prevent your house from burning down. It’s still necessary to keep an eye on the printer when it’s running and always install a smoke detector near by.

The most important feature is the min_temp alarm. This is an alarm that will trigger if the temperature drops below the current target temperature. That means it has to be activated with an M151. So if you want to use this feature, add a M151 to the end of your start.gcode in the slicer profile.

If you do happen to trigger an alarm for some reason, all the heaters will go into an error state. This state can be returned to normal by issuing an M562 command.

Eventually we might automate the enabling of the min_temp alarm, but for now it will have to be enabled “manually”.

There are four other alarms related to temperature:

Max_temp reached, triggered if the temperature goes above a certain threshold, currently 250 degrees celsius.

Temp_rising_quickly: If there is a short on the thermistor wires , this will get triggered.

Temp falling quickly: Triggered if a thermistor wire breaks or the connector comes loose.

Thermistor error: If there is an error reading the temperature from the ADC, this is triggered. If this has happened, the board will actually need a complete reboot. This was an error that occurred from time to time on the Rev A boards, but with the new, less noisy Rev B boards, it has not been seen so far.

The new changes are now in the develop branch, and will be packaged into the Debian package of redeem as soon as some more people have tested it.

The post Some new safety features in Redeem appeared first on www.iagent.no.

It really not that difficult if one wants to use G-codes for it. These are the G-codes you’ll need:

M574 – this connects an end stop to one or more stepper motors. Use the form “M574 X1 x_cw” if you want end stop X1 to stop stepper X from going clockwise.

M270 – Set coordinate system, this might be useful for figuring out which axis does what on delta printers.

M206 – Set offset for each of the axes. After an end stop is hit, it will move to this offset. Remember that the travel distance can be negative, in which case, the offset would most likely be negative also.

M119 – Get current end stop state. Can also be used for inverting end stops. Non-inverted is NC switches, inverted is NO switches.

M569 – Set the direction of a stepper. You could just flip the connector, but where is the fun in that?

What is not yet implemented with a G-code interface is “travel” for each of the axes. This defines the direction and length each axis should search for an end-stop. Sometimes the end-stop is not located near the 0, 0 origin of the  of the bed, so you might try a negative travel value.

The post End stop configuration for Redeem appeared first on www.iagent.no.

Redeem, the Replicape Daemon, is the “firmware” that accepts g-codes and makes the 3D-printer move. What is special about this firmware is that it is mostly written in a high level language. Python is not the fastest language around, but offers a large array of libraries optimized in C, garbage collection, favours readability and has very good integration with C/C++. That way most of the code base can be kept in Python, with only a small core optimized in C.

The native path planner, was originally ported from Repetier firmware. The porting was done by Mathieu Monney, and although it has worked great, there have been certain short comings with the code base. Looking through any firmware for 3D-printers, you will see a well of pre-processor directives to optimize the code at compile time based on what type of machine the code will be running on. That is necessary when you have 16 MHz of processing power, 256 KB of total flash storage and 8 KB of SRAM. However, using a modern day platform with 1000 MHz of processing power, 4 GB of flash storage and 512 MB of DDR3 SRAM, the need for compile time optimizations diminishes severely. Add to that a floating point unit, and you no longer have to weigh every use of floats in the code.

An effort has therefore been to move the native path planner into something more suited for BeagleBone Black and similar speced platforms. A side effect to this has been to make the whole path planner more stepper agnostic, meaning that the path planner no longer has any concept of what each axis does what, and will simply merge each axis using the Bresenham algorithm. This enables doing some pretty fancy things, such as having one or more steppers operate in “slave mode“, easily adding more stepper motors, in order to facilitate color mixing etc. It could also be used to specify what each axis does in run time, if one was so inclined.

I’ve recently done some development on this, and although it’s still a fairly early proof of concept, printing objects do work and slave mode seems to behave as it should. I made a quick video showing a demo, along with an explanation.

The post Redeem new features preview appeared first on www.iagent.no.

What it does
Without cape manager, you basically have one single device tree blog that is loaded when the kernel starts. If you want to change which peripherals are enabled, you need to recompile the device and reboot. With cape manager, you can choose to change parts of the device tree in a running kernel. This enables loading cape-specific overlays based on the cape that is attached (read from the EEPROM of the cape) or via command line to enable a specific peripheral or mux the pins to a specific function. This is what the Adafruit BBIO library does behind the scenes.

Get started with cape manager
Start with a fresh Debian distro. The official Debain image form March should do.
Install the newest kernel:

apt-cache search linux-image

Pick one of the latest, for instance “linux-image-4.1.1-bone10”:

apt-get install linux-image-4.1.1-bone10

Clone the bb.org device tree overlay repository:

cd /usr/src
git clone https://github.com/RobertCNelson/bb.org-overlays
cd bb.org-overlays

Follow the instructions on how to use upgrade and use the cape manager from there. The instructions are good, basically:
– Upgrade the DTC
– compile the overlays.

Tools for checking your work
The cape manager is now located in a more static location in the sys fs than before. The new location is:

cat /sys/devices/platform/bone_capemgr/slots

To see which capes are loaded, cat it.
If you are working on pin-muxing there are a couple of files that can be useful to cat:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins

This file will give you the pin number, the adress of the pin in physical memory and to which function it has been muxed (1 to 7). It will also tell you if it is set up as input/output in the case of GPIO (function 7) and if it has pull-up or pull-down.
Another useful sysfs file is this:

cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups

This can be used to check that a pin has been claimed in the overlay. Very useful for making sure that the groups you add to the am33xx_pinmux node are actually set up as you want them to be.

Helpful #define files
A while back I posted a table with the mapping from the headers exposing the different pins on the BeagleBone to the physical address of the pins. For a while now there has been a header file defining this mapping and providing user friendly names that can be used for pin muxing. By adding the following includes to the header of your device tree overlay source files, you can use the pin names from the exposed headers verbatim:

#include <dt-bindings/board/am335x-bbw-bbb-base.h>
#include <dt-bindings/pinctrl/am33xx.h>

Instead of writing

    dallas_w1_pins: pinmux_dallas_w1_pins {
        pinctrl-single,pins = < 0x150 0x37 // Dallas 1W >;
    };

You can now write

    dallas_w1_pins: pinmux_dallas_w1_pins {
        pinctrl-single,pins = < BONE_P9_22 (INPUT_EN | PIN_PULLUP | MUX_MODE7) >;
    };

so this saves you from having to look up the pins in a table.

caveats in porting old overlays
A while back I ported the patches for the cape manager to a kernel 3.12 for use in an Angstrom based distro. If you want to port an old cape from the kernel 3.8 era, you will notice that there are a couple of changes. Most importantly that the GPIO banks used to go from 1 to 4, but now go from 0 to 3. Also, the UARTs/serials go from 0 to 6 to match /dev/ttyO* in the file system. You can see this by peeking into the am33xx.dtsi (device tree source inclue file) in the mainline kernel repository: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/am33xx.dtsi#L168

The post Cape manager is back baby! appeared first on www.iagent.no.

Kamikaze is a Debian-based eMMC flasher image for BeagleBone Black. It is a complete solution for Replicape and Manga-Screen aiming to contain all software needed to slice a model and print it without installing any additional software. And it has now been updated!

The latest image has an updated Octoprint 1.2 which now has CuraEngine as a plugin simplifying the slicing of models. So now, you can upload Cura slicer profiles directly from Octoprint.  Further, I’ve made a plugin for Redeem, meaning that you can also import Redeem config files and restart redeem from the Octoprint settings window.

The new image also has the ADC bug removed that was present in the last release. There is also support for Replicape Rev B1, of which there only exists one prototype 🙂 This image also has Linux kernel 4.1.0-bone9 with cape manager, so the right device tree is loaded based on the EEPROM on your cape.

There are still a few things I want to fix in an upcoming version, namely having the zeroconf plugin for Octoprint work out of the box, so there will probably be another distro coming in a while. Also, a big project will be better integration between Octoprint and Toggle so it is possible to see which model is printing and progress on both screens.

The post New Kamikaze CNC image released appeared first on www.iagent.no.