Closed Adesin-fr closed 5 years ago
If I read correctly, the #1301 issue is not dealing with pulses. It deals with a sensor sending an ON state unless the sensors runsout, but it doesn't take in account the "speed" of the filament running ? IE : if the filament is clogged in the head, the classical sensors will still return an "everything is OKAY", but a pulse-software-klipper-based sensor would say "hey, I've asked the extruder to push 0.2mm, but nothing got pushed !" or even "I've asked 2mm backward feed, and got nothing"... and then the software would react according.... The real deal, IMHO, is to compare how much did the filament got pushed/retracted to how much did klipper asked ?
Here is a doc from SmoothieWare , we can see which settings are used : http://smoothieware.org/filament-detector
And some hardware that could be used (quoted in smoothieware doc) : https://www.thingiverse.com/thing:2515750
So practically you will have close loop for extruder
Yes, that's the goal. To summarize, it seems to me the best way to recover a print if the head goes clogged/jammed !
In that #1301 module there is support for the prusa filament sensor that reads motion. I don't know how it works.... But it's there...
This operates on a similar principle as the PAT9125 laser sensor implementation I'm working on. In theory it will be able to detect jams, in practice Prusa wasn't able to make it reliably work for jam detection. The encoder based design may be more reliable in that department, it is hard to say. Regardless, the BaseSensor implementation is there in #1301 for someone to implement the underlying encoder sensor if they wish.
@Hywelmartin The PAT9125 support isn't actually part of that pull request as it isn't ready for merging yet. It does work, however its reliability is largely dependent on the mount design.
I've read here and there that this PAT9125 is hard to source, and some user reviews said, like @Arksine, that it was not reliable, perhaps even worse with translucent filament. I think that a slotted wheel + encoder is easy to make for those who want to.
You can buy them on aliexpress without an issue. It works fine with any filament with as long as the housing well designed. Its made to track stainless steel, I'm currently using design that runs the filament between two 673 bearings. This allows the sensor to track both the filament and bearing, eliminating the issues with translucent and black filaments. The significant advantage it has over the encoder style is size, its much smaller and can be mounted directly on the extruder.
A quick thought about this PAT9125 module : it provides an output signal that is toggling when no motion is detected. That means everytime the filament stop, it will trigger an "out of filament error" ?
@LemarinelNet Communication with the pat9125 is done over i2c (at least with the Prusa based variant). You read out its registers to determine if the object you are tracking has moved, and if so the amount of movement. That data is compared to the extruder stepper's movement to determine if a runout needs to be triggered.
FWIW, you would need to do something similar for the device you linked above. You would compare the encoder pulses to stepper movement. The tricky part is getting the thresholds correct. How much "blind" stepper movement should be allowed before a runout is triggered? At .86 pulses per mm, you would probably want a few mm of forward travel without a pulse before triggering a runout.
I'm going to mark this as inactive as it doesn't appear it is being currently developed. Feel free to submit a Pull Request should it be implemented.
-Kevin
@Arksine I found this topic, now I'm also investigating how to use PAT9125 with my miniature board implementation (target STM32F0). Can you please share your results? Maybe you need any help in this task?
@Delsian I have an implementation in testing on the PrusaOwners fork I maintain. Eventually I will PR it back to Kevin's repo, however there are some things I would like to clean up before I do so.
I created a fresh branch with the latest version and pushed them here. I don't think I left anything out, but if you have any problems with it let me know.
One thing I would mention, the most important aspect to reliable filament monitoring with the pat9125 is the design of your mount/cartridge. Mine uses a cartridge that passes the filament between two bearings. Doing this allows the sensor to track both the filament and bearing simultaneously. It has a hard time tracking some filaments, but tracks the bearing reliably.
@Arksine , Does your implementation mirror or is like the Marlin Filament_Motion_Sensor logic?
Would it work with the new BTT Smart Filament Sensor? https://github.com/bigtreetech/smart-filament-detection-module/blob/master/manual/smart%20filament%20detection%20module%20manual%20191022.pdf
I'm not familiar with how Marlin handles motion based sensors, my implementation is based on Prusa Firmware's support for the PAT9125. Right now its on the back burner, however I expect that at some point I will finish it.
Looking at the manual/repo linked its not clear exactly how this BTT sensor works, so I'm hesitant to say that my PAT9125 code would support it. I'm sure some of its motion tracking logic would be useful.
One thing that stood out to me about that manual is that they instruct the user to install the sensor AFTER the extruder. Hopefully they will correct that, because it isn't much use as a runout sensor if you can't retract filament after a runout is detected.
@Arksine Thanks for taking the time to respond. I completely agree with you on the sensor position. Looking at the photo's and YouTube video, they are using an "Ender" style printer. There is no PTFE fitting on the entry side of the extruder. I suspect that is why they are installing it after the extruder?
Here is Marlin's description of motion sensor detection:
/**
I haven't done much in Python. I'm sure the current runout program in Klipper can be enhanced similarly.
Would love to see support for the BTT smart sensor in Klipper. Perhaps the only reason I am holding back from rolling it out to my printers. Following this thread for updates.
Would like to push this a bit..have the sensor lying around and would love to install it on my printer :) have the smart btt runout sensor too
Any news? I have BTT Smart Sensor too.....
I got No news, but as you need a host to handle Klipper, you most likely have octoprint too. If you have octoprint, then there is a plugin that you can use. Downside is that you need a raspberry.
Hi, I have the same BTT Smart Sensor and have been using it successfully with Marlin 2. I have just switched to Klipper and am keen to configure it to use this sensor also. Thanks.
any news or updates in regards to btt smart filament sensor?
I know that there has already been some issues about this (specialy #886), but I don't think the issues did address this one : It would be great to track if the filament is running correctly, not only the runout sensor : Ex : when I use too much retraction , sometimes the head jams, and the filament doesn't feed anymore. In this case, the runout sensor will still say "ok", but in facts the printer is printing nothing.
The main idea is to have an encoder wheel, which is turned by the filament , and send pulses every fraction of mm extruded. If the head is jammed ( or the filament runs out), no more pulses are sent. This way, we can track if the extruder behaviour is correct, and pause the print if needed to let the user correct the problem. A such sensor is easy to make (I can provide instructions and stl), and would have saved some of my prints !
PS : such a feature exists in smoothieware, we can check the docs (and code ?) to see how it is implemented.