Beaglebone | Redeem | Replicape

Filament sensor on 3D printer with Replicape

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.
2016-04-23 17.58.17

Similar Posts

6 Comments

    1. I’ll ask for forgiveness in advance if this is a stupid question… From my experiences with my stock Cubex Duo when the filament runs out on the 8th hour of a 12 hour print, it’s considered a failed print…

      Is it possible for the software to pause the printing if the sensor reports that the filament has run out? I understand that this may be a bad idea in some cases.

      1. Oops, I just realized the question was answered above: Currently, if an alarm is triggered, it will send a “pause” action command to OctoPrint.

      2. That is not a bad idea at all. Pressing pause in OctoPrint when the filament runs out seems like a great idea! Implementing this does require some manual medling on Redeem, but get back to me when you have a working sensor set up, and we can get that fixed!

  1. Has there been any work done to differentiate between skipped steps/blockages and filament runout?

Leave a Reply to Dan Cook Cancel reply

Your email address will not be published. Required fields are marked *