#Toolhead sensor not reliably working

1 messages · Page 1 of 1 (latest)

urban nimbus
#

I'm currently setting up the final steps of my LDO box turtle. My current toolhead setup is Stealthburner + Dragon SF + SB2209 (CAN).

The problem i'm having is that the toolhead sensor is not reliably working. I've manually tested the switches with a multimeter under continuity mode. Eventhough a filament is inserted in the toolhead, the switches are still closed (Supposed to flip from Closed to Open). When i took the switch out and manually trigger it, it works as expected.

My current hypothesis is that it's a problem with the bearing not fully pressing the switch when a filament is in the path. I'm currently using this STL https://www.printables.com/model/826480-filametrix-body-cw2-for-sb2209sb2240-with-dual-fil/files.

Any recommendation on which STL might have better support for my config?

Let me know if further information is required. Thanks!

fresh marsh
#

There currently is an issue with the tool head runout sensor yea. It looks like there is no debounce and it’s too sensitive and stops the print at the slightest contact error with no check.

urban nimbus
#

I think i managed to fix things. Some notes for future people who needs this info:

  • When building the LDO kit be careful there's a 5mm bearing as well. I didn't pay attention and used the smaller bearing. Switching to the proper 5.5mm bearing made things way more stable

  • GPIO21 in the SB2209 board is unstable. Only GPIO22 can be used

tough nexus
# urban nimbus I think i managed to fix things. Some notes for future people who needs this inf...

"GPIO21 in the SB2209 board is unstable. Only GPIO22 can be used" I have experienced the exact same thing. SB2209/RP2040 and GPIO21 seems to act like a momentary switch. It will trigger, but then it reverses. I tried 3 different boards, created/tested 3 different cables, and all had the same result. I wonder if it is something to do with what the "port" was intentionally programmed/designed for... there is some logic somewhere that is causing the "momentary" behavior.

#

It is kina funny, cause Formbot is supplying a cable that has the TAP and Runout sensor in one cable with the runout using GPIO21. I guess for a Runout sensor, the momentary behavior is not such a problem?

stone ginkgo
#

So really the reason why you guys are considering GPIO21 as "unstable" is because PROBE does not have a pull-up resistor before the input buffer. So even though you have a pullup on the rp2040 the input buffer will always drive a 1 or 0 depending on the input. So when the switch is not connected to GND this pin will float which can cause the input buffer to change between 0 and 1 when its not being driver to GND

tough nexus
#

So… is this an instance where a “^” or a “~” is needed before the pin in config? 🙃

#

Guess that really depends on if pull up or pull down…

stone ginkgo
tough nexus
#

Thank you.

#

When I get home I am going to check the Formbot runout sensor to see if they added one to the switch going to GPIO21. They had to do something like that…

tough nexus
#

OK, so no resistor on the FB runout sensor. It is just a switch. I guess the "Pause/Resume" nature of filament runout is such that it does not care if the signal resets. It will not "resume" until there is manual input in the console or screen to commit to the resume.

Runout.jpg
stone ginkgo
#

where as in AFC, as soon a the event happens we react to it... which we can see is probably not the best

fresh marsh