smartin015
commented
1 year ago Yeah, I suppose having a runout sensor is a pretty good reason to not want blocked files based on approximate SM counts. Sure, let's go with "on by default, but you can change the behavior".
It's going to be several weeks before I can start on this sadly - but I don't plan to release any time soon either, so if that timeline doesn't work for you I'd recommend a fork/disable for now until I can catch up :)
Terandium
Is your feature request related to a problem? Please describe. My spools in spool manager don't always add up to what is precisely on the spool, so now I have to up my spool amount so that it doesn't pause it through the software. Which is annoying because now my price calculations are off. I have a filament runout sensor, so pausing it through software makes it really frustrating (especially with the bug where it keeps repeating and thus overfilling my separate print history database. This bug is already reported, so no worries there)
Describe the solution you'd like I have brought this up before and you didn't want to clutter the settings more, which makes sense. So maybe make it an opt-out, so it's enabled by default but is able to be disabled. Otherwise, add it as a hidden option in the octoprint config file, so people who have an explicit reason to disable it. have the option too.
So instead of pausing the queue based on the virtual spool, have it as a warning (same as the spool manager itself does, I have a feeling it's why they aren't using their software as actual runout sensors, as it's simply not precise enough)
Describe alternatives you've considered Forking the repo and just stripping the functionality myself, but since my last issues were handled super well and you were very accepting. I figured I'd try it like this first.