Add BigTreeTech SFS V2.0 support
This is just to track and not forget for the next version to add this: https://github.com/bigtreetech/smart-filament-detection-module
[filament_switch_sensor switch_sensor]
switch_pin: gpio_xx
pause_on_runout: False
runout_gcode:
PAUSE # [pause_resume] is required in printer.cfg
M117 Filament switch runout
insert_gcode:
M117 Filament switch inserted
[filament_motion_sensor encoder_sensor]
switch_pin: gpio_xx
detection_length: 2.88
extruder: extruder
pause_on_runout: False
runout_gcode:
PAUSE # [pause_resume] is required in printer.cfg
M117 Filament encoder runout
insert_gcode:
M117 Filament encoder inserted
Hello!
Thanks for raising this issue! I will need to think about how to get it integrated properly since it's two pins that are needed for this sensor to work properly and currently Klippain only support the standard "one pin runout sensors" that are either a motion sensor or a switch sensor and not both at the same time. However. I'm not sure about the real advatage of having both at the same time and suspect that only the motion part is enough to have something working correctly.
Hello!
Thanks for raising this issue! I will need to think about how to get it integrated properly since it's two pins that are needed for this sensor to work properly and currently Klippain only support the standard "one pin runout sensors" that are either a motion sensor or a switch sensor and not both at the same time. However. I'm not sure about the real advatage of having both at the same time and suspect that only the motion part is enough to have something working correctly.
Hi! @Frix-x
Maybe I can help clarify here on what makes this sensor different from the classic "one pin" runout sensors. This sensor uses a micro switch for runout detection (filament spool is empty) and an encoder wheel for clog detection (filament is present but not moving properly through the nozzle) so you get both types sensors in one compact package. The main advantage here is redundancy in my opinion. If one sensor fails, you're getting at least partial protection from the other sensor. It also offers 2 novel detection methods that are completely independent so that you're unlikely to run into any edge cases that cause the printer to miss a filament feeding error.
For the BTT Octopus board for example, it indicates how this device should be hooked up in it's wiring diagram (labeled "Smart Filament Sensor"). So those pins for the BTT Octopus would be PG_13 (J32) for the switch sensor and PG_12 (J28) for the motion sensor, but these are arbitrary and could be mapped to any open pins as long as the user selects appropriate voltage and ground points.
Both config sections are required at the same time to use the device as intended (klipper supports this as written), and either sensor can trigger the PAUSE command independently of each other. If you really only wanted to use only one for some reason, the motion sensor would be the one to pick.
The SFS 1.0 and SFS 2.0 are very similar in operation and configuration. The major differences between the two is that SFS 2.0 has a shorter detection distance for clogs (2.88 mm theoretical vs 7mm theoretical) and the SFS 2.0 is more compact in design. The config sections to implement both sensors would be nearly identical with the exception of "detection_length" in the "[filament_motion_sensor encoder_sensor]" section. I'd advice replacing that with a user variable so the user can calibrate their specific detection length as it's slightly different for each individual sensor based on encoder quality.
I have/use one of these sensors on my Voron 2.4 and it works great! I hope this helps, please fell free to ask me any questions! I have klippain installed and I have the sensor config in my printer.cfg file. Let me know if you want a peek at it, but it should be almost as easy as copy and pasting the config sections from the BTT repo and including the file.
Hi @austinrdennis Do you use the stock Klippain pause_resume macros or do you use something like what Ellis recommends, https://ellis3dp.com/Print-Tuning-Guide/articles/useful_macros/pause_resume_filament.html#smart-filament-sensor, that includes disabling the sensors at startup and during the pauses? I would be interested to see the relevant portions of your configs. Thanks
Hi @austinrdennis
Do you use the stock Klippain pause_resume macros or do you use something like what Ellis recommends, https://ellis3dp.com/Print-Tuning-Guide/articles/useful_macros/pause_resume_filament.html#smart-filament-sensor, that includes disabling the sensors at startup and during the pauses? I would be interested to see the relevant portions of your configs.
Thanks
I'm using the standard Klippain Pause/Resume macros. I already worked with Frix to ensure the filament sensor is disabled during extruder movements that are done outside a normal print. That's not out quite yet, but it is coming next release. You should only need to disable the sensor for certain events and not the entire startup sequence.
I'll post a link to my config repo sometime today. It's not stock Klippain, but it's very similar. I just removed all the stuff that wasn't applicable to my printer.
I also got one of these two weeks ago, and had started to implement it. For now, I've commented it out as Klippain still needs some tweaking to support it. (e.g. !! The value 'runout_sensor' is not valid for SENSOR).
#===================================================================================================
switch_pin: PG12
pause_on_runout: False
runout_gcode:
RESPOND PREFIX=Sensor MSG="Switch detects filament runout"
PAUSE # [pause_resume] is required in printer.cfg
#M117 Filament switch runout
insert_gcode:
RESPOND PREFIX=Filament MSG="Switch detects filament inserted"
#M117 Filament switch inserted
[filament_motion_sensor encoder_sensor]
switch_pin: PG14
detection_length: 5 # Accuracy is 2.88mm at lowest, recommend increasing in 1mm increments
extruder: extruder
pause_on_runout: False
runout_gcode:
RESPOND PREFIX=Sensor MSG="Encoder detects filament not moving"
PAUSE # [pause_resume] is required in printer.cfg
#M117 Filament encoder runout
insert_gcode:
RESPOND PREFIX=Sensor MSG="Encoder detects filament movement"
#M117 Filament encoder inserted
[gcode_macro _USER_VARIABLES]
variable_filament_sensor_enabled: True
gcode:
#---------------------------------------------------------------------------------------------------
@austinrdennis @Frix-x Is there a particular branch that the fix is in? I would be happy to test it out. Thanks
@austinrdennis @Frix-x Is there a particular branch that the fix is in? I would be happy to test it out.
Thanks
I don't think anything has been pushed for this yet as far as including both sensor types. The SFS 2.0 will still function, but you'll have to pick which sensor os being used or write your own config file and include it in overrides.cfg to override the built in sensor settings.
I had an idea for integration (make both sensor modules unique, so both can be activated for SFS), but first i need to understand it more. Which sensor takes precedence? As klipper knows two different types of sensors, you have two gcode "runout_gcode" sections independently. (and you need to override both sensors with the runout_gcode section)
I had an idea for integration (make both sensor modules unique, so both can be activated for SFS), but first i need to understand it more. Which sensor takes precedence? As klipper knows two different types of sensors, you have two gcode "runout_gcode" sections independently. (and you need to override both sensors with the runout_gcode section)
Neither take precedence, they just run whatever is in their respective "runout_gcode" section when the sensor detects a runout event. Either one can trigger a runout event individually without regard to the other and they can be active at the same time. I have mine run a common macro from the runout_gcode section of each sensor, but they could do different things depending on which one is triggered.
The main barrier to using both right now isn't the config for the sensors (just include both types) but rather how the sensor is referenced in certain macros to deactivate the encoder during filament operations that will likely cause under-extrusion (ex. loading filament) and thus avoiding eroniuos runout event triggers.
The path forward would be to name each sensor a unique name in the config section and only deactivate the encoder sensor in the macros section. Easiest way to do this in practice is to leave the encoder sensor named what it is currently and rename the switch sensor to something unique as it never needs to be deactivated. Then both configs could be active at once and no changes are needed for the macros.
Hello, I bought a sensor SFS2.0.Je would like to put it on my ender 3 (it's under Klipper). The connector for filament control is a 3 pin. On the sf2.0 I have two 3-pin connectors. How do I install it? I don't use the Z-Stop input anymore because I put a CR Touch
This works almost out of the box, already using it on my setup. The only issue with the klippain config is that both pins are aliased as RUNOUT_SENSOR in the configs, so you can only enable one, and then you just need to add the other one in the overrides with the second pin config.
I guess that could be fixed by renaming one of the two to eg MOTION_SENSOR, adding a default alias from MOTION_SENSOR to RUNOUT_SENSOR to maintain backwards compatibility. If @Frix-x thinks this is useful I could try opening a PR.
The question would be what is a real usage scenario for having two sensor checks for 'filament issues' resulting in the requirement to have two different macros run.
I guess redundancy and more peace of mind? The important is the motion one, as it will detect both underextrusion and runout. Truth be told though if it fails it will probably fail as "no motion detected", so it should still be safe. But well, when you get hardware with two sensors, it feels weird not to connect and use both, OCD is a thing 😁
I was thinking about it @Surion79 and there is actually a good use case. In cases of materials like TPU, where you are now able to disable the motion runout sensor per material to avoid false underextrusion triggers, you would still want to keep the on/off runout sensor enabled to detect actual filament runout.
Though the complexity to support it natively might not be worth it, this is still easy to achieve by enabling the motion sensor through the main config and just adding the on/off sensor as an additional entry in overrides
That is indeed a good use case. That would require a bit more to disable encoder when material 'tpu' is used?
Now both switch and motion are configured to be called runout_sensor and scripts depend on finding the active one just by its name. As it is now, you can just enable the encoder using the builtin motion support, so that one becomes the "runout_sensor" which can be disabled per filament, and then you just add the switch sensor through overrides with a different name, should all just work in the expected way.
Is there any progress on this topic? I want to use my SFS V2.0 with both sensors.
I see it's still not compatible, so I made quick hack (works in case there's only 1 filament sensor on printer):
[gcode_macro _USER_VARIABLES]
variable_filament_sensor_enabled: True
gcode:
[filament_switch_sensor switch_sensor]
switch_pin: ^RUNOUT_SWITCH_SENSOR
pause_on_runout: True
# runout_gcode:
# PAUSE # [pause_resume] is required in printer.cfg
# M117 Filament switch runout
# insert_gcode:
# M117 Filament switch inserted
[filament_motion_sensor motion_sensor]
switch_pin: ^RUNOUT_MOTION_SENSOR
detection_length: 7
extruder: extruder
pause_on_runout: True
event_delay: 3.0
pause_delay: 0.5
# runout_gcode:
# PAUSE # [pause_resume] is required in printer.cfg
# M117 Filament encoder runout
# insert_gcode:
# M117 Filament encoder inserted
[gcode_macro SET_FILAMENT_SENSOR]
rename_existing: BASE_SET_FILAMENT_SENSOR
description: Sets SFS v2 filament sensors
gcode:
BASE_SET_FILAMENT_SENSOR SENSOR=motion_sensor ENABLE={params.ENABLE}
BASE_SET_FILAMENT_SENSOR SENSOR=switch_sensor ENABLE={params.ENABLE}