BTT SFS v2 Motion Doesn't work
I have setup the BTT smart filament sensor (v2) a few different ways, the RUNOUT sensor works, the MOTION sensor doesn't work no matter what I do. At this point I'm just trying to figure out how I can manually check that the sensor works, so I don't have to go through the entire printing process for each check.
The sensor has a 4-pin branched cable going from the sensor, one branch to PG15 and +5V (GND empty), and the motion cable going to PG11 and GND (+5V empty). I assume that the empty slots don't matter, it just needs one +5V between the two, and one GND, and then 1 signal for each. I have tried with and without
The sensor has a 4-pin branched cable going from the sensor, one branch to PG15 and +5V (GND empty), and the motion cable going to PG11 and GND (+5V empty). I assume that the empty slots don't matter, it just needs one +5V between the two, and one GND, and then 1 signal for each. I have tried with and without
^ and !, and nothing seems to work. My config is based on this: https://wiki.circuitlaunch.com/circuitlaunch/BTT-V2-SFS-Smart-Filament-Sensor-on-Ratrig-6d153a7734e14531a74e5e2cc28e1c38
Any ideas what to try next, or how I can manually verify this thing isn't defectiveCircuit Launch on Notion
BTT V2 SFS Smart Filament Sensor on Ratrig | Notion
Getting this to work was more than a bit Tricky for me. Hopefully my settings will help. In the Manual (PDF) linked in the references it shows what the best place to plug it in for your MCU. I have the Octopus Pro V1.01
Solution:Jump to solution
I ended up ordering a new BTT SFS v2 and it works. I double checked the voltages on the new one and it was as I expected: as I move the filament, it switches between 0V and 4.4V every few mm. There must've been something wrong with the electronics of the old one. I have processed an Amazon return for it.
I tested both filament runout and filament jam capability of the new one, and it works fine with the following in my printer.cfg:
```...
18 Replies
I forgot to mention that it pause immediately on starting the print, then when I resume, it will continue printing to the end with no issue. However, it does not detect the "jam" if I manually stop it from feeding.
Also, in the Mainsail UI, it will show either "empty" or "detected" for that particular sensor, but doesn't change when the filament moves. I was under the impression it should switch every 2.88mm
With a multimeter between GND and one of the sensor pins, play with filament and verify the voltage changes
Seems kinda obvious in hindsight.
RUNOUT wires goes from 0V (empty) to 3.77V (filament present) ✅ MOTION wires, oscillates between 2.4V and 2.9V as filament moves ❌ Is the 2.9V switching enough for the microcontroller to detect? I guess not since the Octopus Pro board is not detecting the change
RUNOUT wires goes from 0V (empty) to 3.77V (filament present) ✅ MOTION wires, oscillates between 2.4V and 2.9V as filament moves ❌ Is the 2.9V switching enough for the microcontroller to detect? I guess not since the Octopus Pro board is not detecting the change
Dunno what it is supposed to do, but now you can compare what you got with what the documentation says
I'm fairly certain it's supposed to switch voltage ever 2.88mm of filament movement. But maybe this is defective, because that's not enough
Maybe it is suppose to have a pull up or pull down resistor
Isn't that what the
^ is for in ^PG11?My original picture was in the little sheet that came with the sensor. But their manual has this specific board:
I have plugged it into different ports, but made sure PG11 was correct
Is there a console command to query the motion switch?
Also, try the multimeter thing while it's plugged in
When everything is connected properly, the voltage between GND and SIGNAL oscillates between 2.68V and 3.18V as the filament moves. I guess still not enough to switch the state of signal pin on the Octopus board
Is that what the SFS is supposed to do?
I have it wired as shown and I have this in my printer.cfg file. I upped the detection length from 2.88 to 6.0 as was getting some false triggers
[filament_switch_sensor switch_sensor]
switch_pin: PG14
pause_on_runout: False
runout_gcode:
_ON_BOWDEN_FILAMENT_SENSOR_RUNOUT TOOLHEAD=0
M118 Filament runout
insert_gcode:
[filament_motion_sensor encoder_sensor]
switch_pin: PG15
detection_length: 6.0
extruder: extruder
pause_on_runout: False
runout_gcode:
_ON_BOWDEN_FILAMENT_SENSOR_CLOG TOOLHEAD=0
M118 Filament clog
insert_gcode:
Yes, it an encoder wheel with holes and IR tx/rx around it, which changes the signal every 2.88mm of filament. If you set detection length to 6(mm), then RatOS expects to see at least one signal flip/pulse every 6mm of filament it thinks it's feeding which accommodates some slack in the bowden tubes, etc (but either way will see zero pulses if it's jammed because the wheel isn't spinning). It's surprisingly simple at the end of the day.
I wonder if mine defective, because that's basically what I have. I have tried
If you move the filament when just looking at the dashboard, do you see the value of
PG10 ^PG10 !PG10 and ^!PG10.If you move the filament when just looking at the dashboard, do you see the value of
encoder_sensor flipping on and off? I don't, it just stays "detected" the whole timeThere are two status words on the dashboard. One that say "detected" when everything is normal; and then "empty" when there is a problem. I can trigger this by extruding filament while I hold the filament and do no allow it to get pulled by the extruder. The console will say "Filament clog" because of my M118 command. While watching the BTT sensor the blue light will also stop flashing when it should be pulsing.
try a pull down
~PG10Solution
I ended up ordering a new BTT SFS v2 and it works. I double checked the voltages on the new one and it was as I expected: as I move the filament, it switches between 0V and 4.4V every few mm. There must've been something wrong with the electronics of the old one. I have processed an Amazon return for it.
I tested both filament runout and filament jam capability of the new one, and it works fine with the following in my printer.cfg:
That's great news! Grats on solving it 🎉