How can printer firmware use encoder wheel data?

Question

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.

^{Source: Thingiverse.com}

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?. 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 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?

Answer 1

While I answered your more general question about runout sensors at Which detection mechanisms can a filament sensor use?, 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.