Filament movement sensor and plugin

The main difference between this and @OutsourcedGuru's project is that it requires hard-wiring to the printer's control board, messing with firmware settings, etc. His solution is an attempt to provide something simpler I think that you could just install hardware, install plugin, all up and running.

I suppose... but it has to work.

Yeah... I'm thinking that all this mouse/cable/code has to move to the OctoPrint plugin to be honest. I just thought it was cooler as a separate device.

Or did you mean that the IoT device needs to send the pause command instead? But then, it would need to know if we're printing or not (or heating up or not) so I thought that might be a pain.

lol
Love it

Reminds me of this

1 Like

Do you want to create a service that writes to a unix socket which the API service can read; bypassing a lot of the http overhead?

I kind of just went through all this in another project, to be honest. The C program for the mouser client now uses sockets to POST to the REST API. It's possible that the plugin side of this isn't getting much "air" from OctoPrint so it's slow in responding, backing up the queue to the ridiculous level.

I could write a service on the OctoPrint Pi side of things but then I'd have to... actually, I could have that then just make the call to pause the job.

The problem is that something needs to know the state. It's printing or it's not. It's warming up for the print job or it's actively printing/extruding. That feels like the plugin since it's closest to that information. Trying to push the state management outside of the control of OctoPrint's umbrella means that I have to communicate state over to either the client or that service you're suggesting.

But if it runs too slow then, you got to.

you could use the BTT Filament break sensor connected to a GPIO pin on the Raspberry Pi watching for the pulses coming from the sensor. All the available plugins are for simple runout sensors which is just a micro switch sending either a high or low not a pulse. I'm sure your code could be modified to work with this.

Hi OutsourcedGuru! I'm working on a simpler solution - a magnet attached to the spool holder which triggers a reed switch at each revolution. If it stops triggering the reed switch for a certain amount of time, the print must pause or stop. What if anything is your current solution for filament movement monitoring?

I haven't pushed any of my code to github yet since it's not 100%. Half the code appears to be a plugin and the other half a C-based (or Python?) that talks to the mouse to get movement events.

Hard to know what that number might be unless you know what the printer is doing.

Obviously this is nothing new but I'm looking at a project that uses a 360 rotary encoder. Even if the printer for some reason is feeding then retracting it still won't trigger. Although you need to add electronics (a pic and perhaps a few discreats) you can create a simple trigger to mimic a filament runout detector. The obvious downside is inevitable extra load on the extruder.

Given that the accuracy of a $10 encoder isn't necessary I might just go with a 3d printed interrupter and whatever sensor is cheapest.

What I want to avoid is the printer printing nothing, either from a nozzle block or spool side filament jam, for many hours. So, if the timeout is quite long, say 5 minutes, the printer will be printing air for 5 minutes and then stop. Still a lot better than many hours.

From experience in testing my own plugin, there are times when the job will print a raft, say, and the assembly will have gone back/forth many times when tends to spool out a fair amount of filament. Next, if it's printing a small single part on a big raft it won't extrude much; the spool movement detection then won't really kick off for up to a minute in some cases. And I certainly don't wait for a full 360ΒΊ revolution of the spool. That strikes me as being a good ten minutes in some cases.

Absolutely but isn't that what filament run out detector is for?

There are times when I'm sitting next to the printer, coding software and relatively oblivious to what's going on. I can hear movement and I can hear when there are certain suspicious sounds, for example I know the sound of filament snapping.

With relatively-immediate warning, I can just fix the problem without even a pause in the print job.

Trust the force, young Starwalker.

1 Like

After having a failure last night because of broken filament, I came across this thread. After thinking about it i guess it would be the best to additionally measure the extruders electrical signal or its rotation. Alternatively have a sensor before and after the extruder. If only one of the sensors detect movement, we can almost instantly detect a failure and report it to either octoprint or the printers mainboard. To cover some special cases it could be useful to do both and use all three sensors. (lack of extruder grip or if filament breaks at the extruder and then misses the ptfe Tube)

I had thought of the exact same thing. Using the rotary encoder + USB interface from any mouse makes sense. My idea was to measure net motion over a configurable time period. I am trying to get my money's worth out of a roll of crappy filament that I KNOW will break. Another common runout scenario that switch sensors do not handle is extruder chew-through - where there may be a kink in otherwise good filament or a soft spot, and the extruder grinds into the filament.

I totally get why it's best to do this in Octoprint - I want to be informed and have the opportunity to take different actions.

I'm just getting started on plugin development but I would like to help with this. As far as the hardware, I thought of disassembling the mouse because there is usually a tiny board with the actual buttons and rotary encoder. I believe a plugin should be able to read the raw HID events from the "mouse" device and accumulate the net motion.

Using a rotary encoder would allow you to have passive turning motion from a printed set of pulleys as opposed to bump motion. In any case a good first step would be to code up a plugin that reads mouse HID events, and that could support either arrangement. I'll put something on my github account.

Worryingly, I've started to experience that super power, love the little song it sings going round curves. Obviously I'm spending way too much time 3d printing.

Any steps forward on this project? Thanks