Filament Motion Sensor Signal Type

Hopefully someone can help, but I cant seem to find it documented anywhere, what type of signal is Klipper expecting for a FIlament Motion Sensor?

I assumed its a constant on/off binary switching, so its on,off,on,off whenever the extruder is in motion.

If this is the case, how many pulses per mm is it expecting, and where can this be adjusted or configured?

I have spent over a week testing 3 different types of motion sensors, all do not behave as I expected, they will work once, then will not work correctly again until I do a firmware reset.

The first one is the infamous BTT Smart Filament Sensor (v1) this one tests fine, but in use, it will detect filament, if I cut the filament and wait, it sometimes detects no filament, but when it does, nothing will make it detect again, not until I reset the firmware, the senor isnt faulty as I can probe it and check the signal is working

I have tried changing input pins increasing and decreasing detection time, but it just doesnt seem to function as expected.

The next sensor is a prototype laser based sensor, this just sends on/off/on/off as the filament passes through, roughly 1mm of filament to change the output state, if I set this one up as a switch instead of motion, you can watch it alternate back and forth from detected to empty as the extruder operates, so I know its working just fine, but again, when setup as a motion sensor, it fails to function as expected, it will detect, then when it trips as empty, it will not reset and operate again until I reset the firmware.

The third sensor is one I designed using a standard optical switch and a rotary encoder, this aslo just sends on/off/on/off as the filament passes through, roughly 1mm of filament to change the output state, if I set this one up as a switch instead of motion, you can also watch it alternate back and forth from detected to empty as the extruder operates, so I know this one is also working just fine, but again, when setup as a motion sensor, it fails to function as expected, it will detect, then when it trips as empty, it will not reset and operate again until I reset the firmware, no amount of extruder motion will make it detect again, this sensor also has a second optical switch inside for filament presence detection, this funtions as expected, filament goes in, it detects, filament runs out is shows empty, I have LED status lights in this one, so I can see if filament has been detected and I can see the rotary encoder pulse with filament moving through it.

Debugging and testing would be much easier if there was a test mode for a filament motion sensor that did not require the extruder to be operating, testing a filament switch is very easy, shove the filament in and it shows detected, pull it out and it shows empty, the motion sensor will not work like this.

If anyone else is having trouble with this type of sensor, I have figured out that the sensor will only be responsive in the extrude direction and not on retract, which I dont think I seen mentioned anywhere in the documentation, this has most likely been my issue with confusing/mixed results.

So only forward/extrude direction will trigger the sensor, in reverse it will remain frozen on its last known condition, this can be problematic if you are using these sensors for filament changing, which I was intending to do.

Also, I found that 5 works properly for detection_length (Not sure if this time, pulse per mm or change state over 5mm length) if you are using a sensor that changes state over 1mm, anything less and it wont work, anything more and it is slow to respond, my sensor operates like this, it sows Detect then move 1mm → Emtpy, move 1mm → Detect, move 1mm → Empty, I tried 1, 2, 3, 4, 5 and higher, 1 will make it operate like its setup as a filament switch, so constantly changing states, 2, 3, 4 all read Detected but will not switch to Empty, but 5 operates as expected, but obviously in the positive/extrude direction only.

I think some additional features/enhances might bo good for this module:

  1. Calibration, pulse per rotation distance? (Would Nice to be able to calibrate it for accuracy)
  2. Function in both directions
  3. The ability to dynamically enable/disable “pause_on_runout”
  4. Option to function indipendant of the exturder (This would be good for testing and useful for other Macro calls)
  5. Ability to display a filament counter.

Number 3 is must in my opinion, I dont like having to disable the entire sensor for loading and unloading, same for the standard filament sensor module, disabling the sensor for unload and load, should not be the norm, it should be disable the runout code or pause feature, this way you can utilise the sensor in monitor mode for other tasks in your macro, so currently I cant use any of the sensors for jam self correction during automated loading and unloading as all of my sensors are disabled during this process.

Filament motion sensors are non-trivial devices to implement and difficult to create a good working model but I think they would be useful IFF it could detect no filament movement (filament has run out) before the filament that is remaining between the filament motion sensor and the extruder stepper is used up by the current gcode command.

As I understand the operation of Klipper, gcode operations cannot be stopped so there needs to be an assumption of what is the maximum amount of filament that can be extruded in a single command.

I believe the worst case length would be (assuming a square build surface):

LongestFilamentLength = BedWidth * sqrt(2) * NozzleArea / FilamentCrossSectionalArea

For a 300mm bed with a 0.4mm diameter nozzle and 1.75mm filament
NozzleArea = 0.126mm^2
FilamentCrossSectionalArea = 2.405mm^2

LongestFilamentLength = 300mm * sqrt(2) * 0.126mm^2 / 2.405mm^2
                      = 22.227mm

This means that, for my Voron 2.4, the filament motion sensor would have to be at least 25mm away from the toolhead stepper (adding a few mm to detect a definite motion stoppage). Not an unreasonable distance.

Now, when I look at your list of requirements, I would simplify them to:

  1. The ability to dynamically enable/disable “pause_on_runout”

I’m not really sure of the reasons for the other list items - I would expect that the only time the filament runout sensor is operating is when a print operation is taking place.

As far as my understanding goes:

  • The run-out sensor is only evaluated during printing, aka extrusion moves
  • A run out is detected if a certain distance should have passed the sensor but no matching pulses have been received
  • After raising a run-out condition, it is only reset when again the moving filament is creating pulses → There is no reset command or anything like this
  • Nothing prevents a paused printer from being operated manually
  • If the sensor is not needed or interfering with any macro operations, it can be deactivated

Thanks for the reply guys,

@mykepredko Calibration would be nice so the motion sensor could be used as a counter, which is related to 5, these are just nice to have, not a requirement.

2 and 3 are needed, as I would like to use all of my sensors in Macros for filament changing, disabling them is not the best way to do it, I would prefer to switch the motion and any other filament detection sensors to monitor mode during filament changes, but at the moment I am just disabling them, yes this works, but its not ideal.

Say the machine is retracting a filament to load a another, and for some reason it has snapped, some retracts back, but the fact that the motion sensor is disabled, the printer wont know this, and will try to load the next filament causing a jam.

I have a multi extruder setup with a 4 into one manifold, optical filament presence sensors and optical based rotary motion encoders on each line before the manifold and another after, I would like to take advantage of all these sensors to properly manage any of the many issues that arise during automated filament swaps.

So number 3 definately is the big one on the list and would allow me to create more advanced Macros for handling filament changes, jams etc.

The system is fully functional now, I do have the rotary encoders working, but obviously, if some random event causes a jam, there is no way to detect it, not without having the sensors enabled during the filament change.

Below is the system Im in the middle of developing:

2 Likes

Maybe you could work around this with some macro shenanigans:

  • Define some global variable like run_out_monitoring true or false
  • Set this variable according to the state you wish
  • From runout_gcode call some macro the queries run_out_monitoring and acts according to its state like executing additional command, cancelling pause or whatever your workflow requires

So something like, runout code when triggered runs a macro, and that macro should have something like, if the printer is printing, then run PAUSE, if the printer is not printing then do nothing?

Something like below?

[gcode_macro Runout_Event]
gcode:
{% if printer.(NOT SURE WHAT TO CALL) == True %}
PAUSE
{% else %}
M117 Monitor Mode
{% endif %}

Not sure how to check if the machine is printing, will have to read more I think.

Something along these lines yes. Not sure if you have to get a bit more sophisticated and e.g. intercept already on PAUSE level.

See Example: Search Printer Objects how to get all Klipper internal variables.

Oh thats a clever Macro, I just through it on another machine quickly to test, this will be very helpful indeed, if I get something working I’ll post it here for others.

Looks like all I needed to do is is have “Printing” displayed via M117 while its printing, and clear it for any other tasks.

So I used M117 to display somthing other than Printing for all filament changing Macros, this allows all sensors to operate in monitor mode, and when they finish, the status is then changed back to “Printing” and now if there is a runout event, the Printer will pause.

[gcode_macro Runout_Event]
gcode:
{% if printer.display_status.message == Printing %}
PAUSE
M117 Filament_Feed_Issue
{% endif %}

Tested and seems to work as intended, still cant use the motion sensor in reverse, but this has been a huge help still, I can now work on more complex Macro’s :slight_smile:

Update: This didnt work, looks like my syntax is incorrect, will need to look into this more when I have the time.

I just wanted to share for anyone interested in this topic that I made a high precision filament sensor: GitHub - EiNSTeiN-/roadrunner-filament-sensor: High resolution filament sensor for 3D printers based on the AS5600 magnetic rotary encoder. If you’re still looking for an appropriate high-resolution sensor for your project, check out the AS5600 magnetic rotary encoder on which my sensor is based, it should fulfil all your requirements. It has 12 bits of resolution and this means (in my sensor anyway) that it can measure in the range of 0.05mm movements. I had to write my own klippy plugin because the existing filament sensors are just too naive for high-resolution sensors. I’ve also written a small script to pull live and recorded data from the moonraker api which is super useful for debugging.

I’m sharing mainly because I’d be very happy to find more use-cases for these high resolution sensors so support can eventually be adde directly in klipper.

3 Likes

FYI, there were some changes and some proposed changes to the code recently that may impact the report here:

-Kevin

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.