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.
Whilst the last reply was three years ago , I'm looking to see if this moved on.
The reason for my question is that my new Prusa MK4 doesn't pass the alert on to Octorpint to say it has run out of filament. My old Mk3 does.
The Prusa Mk4 does all the right things and moves to the side of the bed and waits for me to do something, but I could be doing something else and I don't want to have to watch filament.
As Prusa can't be arsed to add the command, I'm looking at other options:
Putting an end stop in the correct positon so that the extruder hits it only and stays hit when it's waiting for a filament change, if the head is moving, then the initial trigger is ignored.
Checking the position of the head and whether it's not moving for a period of time. This appears to be the solution suggested here. I don't want tio have to write code, so was hoping that this may have been implemented (or not).
This is the best. Realistically you paid for the machine, it's you guys that should be pushing this with them to fix in their new firmware. As you mentioned, it worked before in older generations, why can't they make it work now?
Thanks for the reply. There's a lot of pressure being put on Prusa, but for some reason the MK4 firmware doesn't send out the right stuff. The argument being put back is that there is pressure elsewhere on the development team over this feature.
I have my doubts over the priority assigned to this to be honest. My suspicion is that they wish to push PrusaConnect or PrusaLink over Octoprint, but I'm a cynical git.
This isn't being fixed at the moment and I do a lot of printing, so wanted to find a decent solution. As Prusa aren't doing it, I need a solution, at the moment, I am making sure I have enough filament to do the work, but thats a hassle. All I want is what I have with my MK3.
If there is a simple API that allows me to monitor X, Y, Z and E movements, I can easily see that the head is stationary for a period of time, e.g. > 60 secs.