<p>While I answered your more general question about runout sensors at <a href="https://3dprinting.stackexchange.com/questions/21601/which-detection-mechanisms-can-a-filament-sensor-use/23322#23322">Which detection mechanisms can a filament sensor use?</a>, I can try to add more details in this answer specific to the design of encoders.</p>
<p>As stated in the linked answer, yes, the (Marlin) firmware has to compare the encoder movement with the expected extruder movement. This is exactly what you gleaned from the YouTube video since the controller has both pieces of information. From my perspective as a hardware engineer, I would highly prefer this function to reside in firmware instead of any other part of the print chain such as Octoprint. This comes down to detection speed and latency.</p>
<p>Rotary encoders rely on a light source that is energizing a photodiode. The wheel either makes or breaks the light so the output signal toggles on-off as the wheel spins. Right off the bat, we can assume a few behaviors:</p>
<ol>
<li>The signal toggle rate is dependent on the speed of the wheel</li>
<li>The wheel can stop at either state (on or off)</li>
<li>The design of the wheel gaps will affect the toggle rate</li>
<li>The encoder can't tell which direction the wheel is moving</li>
</ol>
<p>The encoder output has limits, if the wheel is moving too fast the output signal might not be able to keep up. This is not because light is slow, but the photodiode has a finite response time. On top of that, the printer controller might also not be able to read the changes fast enough to be accurate. On the flip side, a very slow movement might stay in one state for a long time if the wheel gaps are very large. In both cases, the result is a less than ideal representation of the actual movement. But filament sensing is generally about detecting fault and not measuring exactly what the filament is doing, so a &quot;good enough&quot; design is the goal.</p>
<p>In Marlin, the intent is to detect some filament movement within a specified amount of extruder movement. In effect, the specified amount of extruder movement is the minimum needed to see at least one toggle of the encoder. I believe that is what happened between the BTT smart sensor V1 and V2. The smaller the gaps on the wheel (or larger the wheel), the higher the resolution when sensing movement and the sooner the firmware can detect a change. As long as the controller and firmware can keep up with the more frequent toggle rate this is an improvement. The idea that it can act as a &quot;correction wheel&quot; is IMO asking a runout sensor to be more than it needs.</p>
<p>When the extruder moves and the encoder returns some sign of change, the firmware can assume things are moving along regardless of forwards or backward, fast or slow. This also means the firmware will ignore a still encoder if it hasn't asked the extruder to move. The need to correlate the extruder to filament movement also means a delay when detecting a fault. This delay might be acceptable in most cases but it does add some risk of a clogged extruder wheel that has to be cleaned for a full recovery. It is also where we see people getting false positives and needing to debug the sensor.</p>
<p>I think as people push the print speed ever higher, the encoders themselves can likely keep up. The controllers might set some limits to encoder performance depending if the firmware can keep up with every toggle it generates and how much processing is consumed in keeping up with the encoder. Or the encoder will get even smarter and divorce itself from the controller. If the encoder had its own microcontroller and could snoop the extruder control signals, then it could go back to just being a simple on-off signal back to the controller.</p>

CC BY-SA 4.0
2024-05-26T06:06:27.903Z
Thank you, very clear answer. The last suggestion about its own microcontroller, as well as using a very high resolution and/or speed made me think about using the (already connected) Pi. I just need to find out a proper way to connecting it either software wise or hardware wise. The main unknown for me as of yet, knowing when the extruder is expected to move, and determining the proper delay. I expect that in theory with this you could make an educated guess about the movement speed of filament too, but not sure of the use case for that.
Bob Ortiz
CC BY-SA 4.0
2024-05-26T13:45:55.143Z
I have seen Marlin feature requests asking for extruder signals. But I would consider directly snooping the motor signals with an inline current sensor similar to this project: https://vector3d.shop/products/stepper-motor-analyser If your pi is running octoprint, I would be careful about the processing load and test thoroughly.
BrChan
CC BY-SA 4.0
2024-05-26T17:24:25.497Z
That Stepper Motor Analyser is very interesting I didn't know about its existence, thanks for the suggestion. The Pi 4 usually runs far below 10% CPU utilization at normal printing operation.
Bob Ortiz
CC BY-SA 4.0
2024-05-26T01:59:15.280Z
2024-05-26T02:46:22.490Z
2024-05-26T02:46:22.490Z
BrChan
<p>I am trying to understand the concept of the encoder wheel that is used as a filament sensor, as shown below. It can detect if filament is moving, making it suitable for <strong>filament runout</strong> and <strong>filament jam</strong> detection, although it wouldn't be able to distinguish the two events.</p>
<p><a href="https://i.sstatic.net/ZVCbw.jpg" rel="nofollow noreferrer" title="DIY Filament Sensor using Encoder Wheel"><img src="https://i.sstatic.net/ZVCbw.jpg" alt="DIY Filament Sensor using Encoder Wheel" title="DIY Filament Sensor using Encoder Wheel" /></a></p>
<p><sup>Source: <a href="https://www.thingiverse.com/thing:4712966" rel="nofollow noreferrer">Thingiverse.com</a></sup></p>
<p><strong>Filament runout detection</strong> is easy to understand, there is no filament passing (anymore), so the wheel isn't moving when it should.</p>
<p><strong>Filament jam detection</strong>, the filament is not moving when it should, but how does the firmware know when it should expect the encoder wheel to move? Does it compare some last move time with an expected move time and some threshold time?</p>
<p>In addition to microswitch variants, such as shown in my question <a href="https://3dprinting.stackexchange.com/q/21755/36802">How to distinguish filament runout and filament jam using a microswitch-based filament sensor in Marlin?</a>. I think an Encoder Wheel variant does add two more types of detection that a microswitch variant can't detect:</p>
<ul>
<li><strong>Filament break detection</strong>: It is probably the only way to detect the rare case where the filament breaks (<em>after it passed the sensor</em>), where one or two microswitches would both possibly not be triggered (as the filament is still present in the sensor), resulting in a false-negative where the printer keeps printing when it should stop.</li>
<li><strong>Clogged nozzle detection</strong>, a clogged nozzle would also be detected as the filament simply stops flowing.</li>
</ul>
<p>However, I think both 'filament break' and 'glogged nozzle' detection would not be distinguishable from a 'Filament Jam' or 'Filament Runout' event for an encoder wheel sensor as in both cases, the filament simply stops running the wheel when it's expected to run.</p>
<p>Additionally, under a <a href="https://m.youtube.com/watch?v=v2mQ4X1J3cs" rel="nofollow noreferrer">YouTube video</a> about this particular sensor a user 'hd-be7di' commented:</p>
<blockquote>
<p>This sensor could work better if it shared data with the extruder. It could act like an &quot;<strong>error correction wheel</strong>&quot; by comparing the extruder's parameters to the sensor's to detect very tiny under-extrusions (and over-extrusions too!) instead of acting like a simple on-off switch.</p>
</blockquote>
<p>Is my understanding correct, or are there other ways these encoder wheels can be used for 3D printers? How can printer firmware use encoder wheel data, and how does the firmware know when to expect a rotating wheel (with some delay or trigger threshold, I suppose) as well as ignoring retractions?</p>

CC BY-SA 4.0
2023-12-06T08:01:15.553Z
Filament break detection, I quote: `as the filament is still present in the sensor` not necessarily, old PLA frequently breaks at the spool, so you will experience a run-out of material.
0scar
CC BY-SA 4.0
2023-12-06T08:35:40.660Z
Ah, I wrote that from the perspective of a break after the sensor, which I experienced only once. But, a break before the sensor would indeed be detected as a runout. Thanks for pointing that out.
Bob Ortiz
CC BY-SA 4.0
2023-12-06T10:51:35.877Z
No prob, especially PLA and even more the 2.85 mm variant is very brittle if not kept correctly and is prone to break near the spool.
0scar
<diy-3d-printer><filament-jam><filament-sensor><sensors><runout-sensor>
How can printer firmware use encoder wheel data?
Bob Ortiz
# How can printer firmware use encoder wheel data?

(Asked by: username_0 on 2023-12-06)

I am trying to understand the concept of the encoder wheel that is used as a filament sensor, as shown below. It can detect if filament is moving, making it suitable for **filament runout** and **filament jam** detection, although it wouldn't be able to distinguish the two events.

[![DIY Filament Sensor using Encoder Wheel](https://i.sstatic.net/ZVCbw.jpg "DIY Filament Sensor using Encoder Wheel")](https://i.sstatic.net/ZVCbw.jpg "DIY Filament Sensor using Encoder Wheel")

Source: [Thingiverse.com](https://www.thingiverse.com/thing:4712966)

**Filament runout detection** is easy to understand, there is no filament passing (anymore), so the wheel isn't moving when it should.

**Filament jam detection**, the filament is not moving when it should, but how does the firmware know when it should expect the encoder wheel to move? Does it compare some last move time with an expected move time and some threshold time?

In addition to microswitch variants, such as shown in my question [How to distinguish filament runout and filament jam using a microswitch-based filament sensor in Marlin?](https://3dprinting.stackexchange.com/q/21755/36802). I think an Encoder Wheel variant does add two more types of detection that a microswitch variant can't detect:

* **Filament break detection**: It is probably the only way to detect the rare case where the filament breaks (*after it passed the sensor*), where one or two microswitches would both possibly not be triggered (as the filament is still present in the sensor), resulting in a false-negative where the printer keeps printing when it should stop.
* **Clogged nozzle detection**, a clogged nozzle would also be detected as the filament simply stops flowing.

However, I think both 'filament break' and 'glogged nozzle' detection would not be distinguishable from a 'Filament Jam' or 'Filament Runout' event for an encoder wheel sensor as in both cases, the filament simply stops running the wheel when it's expected to run.

Additionally, under a [YouTube video](https://m.youtube.com/watch?v=v2mQ4X1J3cs) about this particular sensor a user 'hd-be7di' commented:

> This sensor could work better if it shared data with the extruder. It could act like an "**error correction wheel**" by comparing the extruder's parameters to the sensor's to detect very tiny under-extrusions (and over-extrusions too!) instead of acting like a simple on-off switch.

Is my understanding correct, or are there other ways these encoder wheels can be used for 3D printers? How can printer firmware use encoder wheel data, and how does the firmware know when to expect a rotating wheel (with some delay or trigger threshold, I suppose) as well as ignoring retractions?

**Tags:** diy-3d-printer, filament-jam, filament-sensor, sensors, runout-sensor

> **Comments:**
> **username_1**: Filament break detection, I quote: `as the filament is still present in the sensor` not necessarily, old PLA frequently breaks at the spool, so you will experience a run-out of material.  
> **username_0**: Ah, I wrote that from the perspective of a break after the sensor, which I experienced only once. But, a break before the sensor would indeed be detected as a runout. Thanks for pointing that out.  
> **username_1**: No prob, especially PLA and even more the 2.85 mm variant is very brittle if not kept correctly and is prone to break near the spool.  

---

## 1 answers

### Answer by username_2 on 2024-05-26. Score: 2 | Accepted answer

While I answered your more general question about runout sensors at [Which detection mechanisms can a filament sensor use?](https://3dprinting.stackexchange.com/questions/21601/which-detection-mechanisms-can-a-filament-sensor-use/23322#23322), I can try to add more details in this answer specific to the design of encoders.

As stated in the linked answer, yes, the (Marlin) firmware has to compare the encoder movement with the expected extruder movement. This is exactly what you gleaned from the YouTube video since the controller has both pieces of information. From my perspective as a hardware engineer, I would highly prefer this function to reside in firmware instead of any other part of the print chain such as Octoprint. This comes down to detection speed and latency.

Rotary encoders rely on a light source that is energizing a photodiode. The wheel either makes or breaks the light so the output signal toggles on-off as the wheel spins. Right off the bat, we can assume a few behaviors:

1. The signal toggle rate is dependent on the speed of the wheel
2. The wheel can stop at either state (on or off)
3. The design of the wheel gaps will affect the toggle rate
4. The encoder can't tell which direction the wheel is moving

The encoder output has limits, if the wheel is moving too fast the output signal might not be able to keep up. This is not because light is slow, but the photodiode has a finite response time. On top of that, the printer controller might also not be able to read the changes fast enough to be accurate. On the flip side, a very slow movement might stay in one state for a long time if the wheel gaps are very large. In both cases, the result is a less than ideal representation of the actual movement. But filament sensing is generally about detecting fault and not measuring exactly what the filament is doing, so a "good enough" design is the goal.

In Marlin, the intent is to detect some filament movement within a specified amount of extruder movement. In effect, the specified amount of extruder movement is the minimum needed to see at least one toggle of the encoder. I believe that is what happened between the BTT smart sensor V1 and V2. The smaller the gaps on the wheel (or larger the wheel), the higher the resolution when sensing movement and the sooner the firmware can detect a change. As long as the controller and firmware can keep up with the more frequent toggle rate this is an improvement. The idea that it can act as a "correction wheel" is IMO asking a runout sensor to be more than it needs.

When the extruder moves and the encoder returns some sign of change, the firmware can assume things are moving along regardless of forwards or backward, fast or slow. This also means the firmware will ignore a still encoder if it hasn't asked the extruder to move. The need to correlate the extruder to filament movement also means a delay when detecting a fault. This delay might be acceptable in most cases but it does add some risk of a clogged extruder wheel that has to be cleaned for a full recovery. It is also where we see people getting false positives and needing to debug the sensor.

I think as people push the print speed ever higher, the encoders themselves can likely keep up. The controllers might set some limits to encoder performance depending if the firmware can keep up with every toggle it generates and how much processing is consumed in keeping up with the encoder. Or the encoder will get even smarter and divorce itself from the controller. If the encoder had its own microcontroller and could snoop the extruder control signals, then it could go back to just being a simple on-off signal back to the controller.

> **Comments:**
> **username_0**: Thank you, very clear answer. The last suggestion about its own microcontroller, as well as using a very high resolution and/or speed made me think about using the (already connected) Pi. I just need to find out a proper way to connecting it either software wise or hardware wise. The main unknown for me as of yet, knowing when the extruder is expected to move, and determining the proper delay. I expect that in theory with this you could make an educated guess about the movement speed of filament too, but not sure of the use case for that.  
> **username_2**: I have seen Marlin feature requests asking for extruder signals. But I would consider directly snooping the motor signals with an inline current sensor similar to this project: https://vector3d.shop/products/stepper-motor-analyser If your pi is running octoprint, I would be careful about the processing load and test thoroughly.  
> **username_0**: That Stepper Motor Analyser is very interesting I didn't know about its existence, thanks for the suggestion. The Pi 4 usually runs far below 10% CPU utilization at normal printing operation.  

---

