Precise filament sensor optical width, move and runout

I find here a lot of Sensor plugins most of them do just a dumb stop or pause.

The BTT one seems to be the smartest looking forward to test it out. but,

is there any project and Plugin developing or existing, that deals with the integration of an " real intelligent realtime optical" solution that I may have missed?

Would be great to have a plugin working with a arduino togeher or TSL1402R Linear senor array to get a real smart solution for ocotprint or another example from Thingiverse:

Example Filament Width Sensor with 3 LEDs, TSL1401CL, and Arduino Pro Micro :

Thanks in advance for informations

Tom Sanladerer (YouTube) did a folow-up video of an old design he did for this type of width sensor.

Thanks for the quick answer
Yes I know the video, will take that into consideration but it is mechanical and limited because it measures only in on direction and if the filament has small bents it could be fooled

What I didnt get from Toms video is the integration with octoprint plugins, did I miss something or how did he intergrate that?

I really want would prefer an active loop that not only does controll if movment or jammed filament is a problem, Measuring and controlling dynamically the filament multiplier is the higher goal, as Marlin or Klipper !? do support already

I think this would be something that would be better integrated in firmware rather than by a plugin personally. You want the real-time adjustments, similar to babystepping, to be as quick and accurate as possible relative to when the filament is entering the extruder/hot end. With OctoPrint and it's gcode buffer in front of the printer's command buffer I think there would be too much of an unknown difference between the two and not get good results.

The critical part here for marlin is FILAMENT_WIDTH_SENSOR.

found this too as reference, using optical methods, but still seems to be one-sided.

Yes I know just have scraped all that videos as well :wink:
Thats why I started asking after.

Didnt knew/recognized that with the buffer.

so you mean a 3dprinter creator should develop their devices and connect it directly to the board to create a closed loop in the firmware
Is there any light at the end of the line you know about? didnt find any brand to do so in the consumer level.

I'm not aware of any commercial products available for this. If there is such a thing, it's probably in the industrial/non-hobbyist space.

too bad would realy love to see octoprint smart as high tech comercial products.

Is there any reference where I can learn more about the buffering between octoprint and the firmware?

Thanks for your opinion and advice

Have a nice day

This might be a good reference discussion. How does OctoPrint implement G-Code Caching

Didnt let me go

If I know (calibrate the exact length from the measuring device) to the nozzle outlet octoprint does exactly know where the filament measure point is, no matter of the buffer!
So if done a measure at lets say every 1s it does know how thick the filament is rignt now. With that all in mind and the calibrated length it should be a matter of calulation and the according adjustation of the flowrate modifier to solve that problem. Isnt the buffer irrelevant if the plugin knows what the exact extrusion length is?? It is just a pre-calculation

Or do I see that wrong?

I think you see it wrong, unless you measure the entire filament and pre-process it beforehand the printer buffer gets in the way. OctoPrint is not real-time control of the printer, it sends commands which get put into a queue by the printer and executed when it is ready to do so. There's no way for OctoPrint to know that the command it sends now will be extruding the measured piece of filament, we don't know if it is a lag of 5 secs, 10 secs or maybe the buffer has underrun (where you might see stuttering) and the response is instant.

You could make a pretty good guess, but it wouldn't be accurate. The printer & it's firmware on the other hand knows exactly what step the extruder is on now and could do this accurately.


Maybe I'm missing something here but rather than real time sensing of filament diameter and firmware adjustment of extrusion based on that sensor, wouldn't it be easier to just buy quality filament?


Why do you want to add the filament sensor to Octoprint? I am using the BTT smart Sensor on my Ender 3 v2 plugged directly to the main board of the printer. It is simple to set marlin to monitor the sensor. Marlin will generate a M600 command depending on the sensor data and settings in configuration_adv.h.
also setting
will report back to octoprint

Yes I am aware of "Good Filament" and I buy it.

But even that has tolerances and bad charges.
Why precise filament measuring :

I am starting to build my own products for sale, so this has to have the best quality I can get out of my printers

For that reason precision is one of the highest prio's.

The goal is on the other side to get the best out of the printer even if the filament isnt the best!

For example developing my prototyps I often use cheaper filament, in spite of that I want to develope printing quality during evolution of the prototype.

So realtime measure and flowrate manipulation for quality is my goal for several reasons.

I want to develope my printers into the future
and the future is not only a somehow smart filament sensor, it is the
whole technical ecosystem around it.

What I mean is a precise calculation of the used filament/documentated communication with hopefully soon the Spool-Manager external Database, to get precise data of used filament, on top of optical filament spool recognitioin, ERP filament ordersystem..... u name it.

If I can calculate precise thickness, roundness and extrude value and real density we get further.

On the other side I can analyze tolerances after print if the filament is really so good as promised!
So yes this is tracable quality management/proof of evidence also .

Right now it is guesswork or you never can find out why print quality is worse in some regions/Laxers. Is it the filament or another problem?

Hope you can understand my the vision for the future

and thank you Bill.b1 for the hint that you can plug in BTT on foreign boards, didn't recognize that.
The problem here, if I have a closed firmware like on my Chirons I can never realize (without experimenting and flashing somehow Marlin firmware). Thats why I would like independent direktly with octoprint interacting smart sensors. But that is what I learned above wishfull thinking because of the printcue problem

Looks like the creator of the pandapi board also working on something like you want to build.

Thanks a lot for the hint will take it into consideration

ah it has no width sensor.