[Request] Warn if filament detection is not on
mrseeker opened this issue · 15 comments
Is your feature request related to a problem? Please describe.
As seen with OctoPrint/OctoPrint#3631 there is sometimes a problem with Octoprint detecting if the printer has filament detection enabled. This might cause misprints and errors with printers that have filament detection systems built-in.
Describe the solution you'd like
I propose to use the M412 command to be sent to a printer when it's firmware is known to support filament detection, and warn the user when it's not active before starting a print.
Describe alternatives you've considered
Using a plugin to do a manual runout detection won't work, since this is supposed to be built-in with the firmware. Manual detection using M412 can be tiresome and does not stop the print when the runout detection is malfunctioning.
Another option would be to add "FILAMENT_RUNOUT" to the Marlin capabilities report to detect if the firmware supports the runout sensor.
Additional context
Marlin firmware supports it: https://marlinfw.org/docs/gcode/M412.html
Thank you, @foosel
I would even be quite happy if the web UI just warned you before starting a print based on the make/model of printer selected in the connection settings, so long as the warning displayed before each print, and not just once when selecting the printer.
The issue isn't that Octoprint doesn't work with the sensor -- it's that it doesn't tell you that it doesn't work with the sensor. As an end user I'm sure that I'm not alone in being caught off guard by this.
@alandsidel You seem to believe that OctoPrint can reliably detect the make and model of your printer. It can't. Printer firmware a horrible mess. What you are asking for is anything but an "easy fix". Don't go around saying something is easy to implement when you have apparently no idea of the realities that is interfacing with the zoo of firmware that is out there in the field.
Um no.
I selected my printer in the dropdown on the left under connection. I suspect many, if not all, users do this, under "printer profile."
If you can't reliably detect the printer, and don't want to use the contents of that dropdown, then maybe you should just err on the side of caution and show the popup before every print regardless of printer until the end user permanently dismisses it.
I stand by it being an easy thing to implement, for an experienced professional developer anyway.
@mrseeker would you have the warning as permanently dismissable for printers that simply don't have filament sensors?
I think this would be only appropriate for a standalone plugin, but what if the warning was triggered when started a print longer than X hours if runout is either disabled or not present
@alandsidel No. Relying on how a user names their printer profile is a BAD idea and not how things work. The firmware needs to be identified after connect, reliably, regardless of the information in the printer profile, because the user might simply not have any bloody clue what they even have.
Filament sensors aren't as far spread that you want to pester users about them endlessly or until they dismiss some dialog (and once they have dismissed that, what to do if they suddenly update the firmware on their printer or add a sensor but misconfigure it?). There are a ton of questions to solve first before this can even remotely get looked at.
It. Is. Not. An. Easy. Fix. Stop claiming that, you have frankly no idea what you are talking about here. I am and experienced professional developer who's maintained OctoPrint for 7.5 years now, I know what I'm talking about.
Before this can even remotely get looked at implementation wise, the following points need to be solved:
- how to even identify printer models that should have a runout sensor?
- known list through firmware identification patterns requires collecting those first
- filament sensor capability report? If that's not present, that doesn't necessarily mean the printer doesn't have one
- how to check if the runout sensor is correctly configured in the firmware?
M412might be unknown but the printer could still be sending anaction:pauseon runout, we can't detect that unless an actual runout is triggered and would report false positives- Or maybe the printer just triggers an
M600internally and spamsbusy:processing, also cannot be detected without an actual runout, see above
- what to do if we detect the runout sensor as there but the firmware's handling of it being incompatible to OctoPrint?
- always warn the user? Shouldn't that be dismissible because they simply don't care?
And in the end there's also the question: why the fsck does it fall to OctoPrint once again to work about manufacturer fsck ups.
@alandsidel thankfully due to this project being open-source, as an experienced professional developer you can develop the functionality and submit a pull request, where your implementation can be further discussed.
Listen. I don't know why you're so hostile @foosel , and frankly at this point. I don't give a shit.
As an end user, I have a printer with a filament sensor. It works. I, and I'm sure every end user, expect (or rather, I expected) it to continue to work with octoprint. It doesn't. Fine. I get that. However Octoprint didn't even warn me that it possibly wouldn't. I had no *****ing clue that this was even a thing until after it failed.
If you don't see that as a problem, you have no business interacting with end users or making decisions that affect them in the UX realm.
@Mearman I intend to fork it and add the feature I want tonight after normal work is finished for the day. I'm not going to send in the PR though, I'll just run my own version. I don't think I want to contribute to a project filled with developers so openly hostile and unsympathetic to end users.
Listen. I don't know why you're so hostile @foosel ,
I'm not hostile, I'm frustrated as I've been trying to explain to you that your claims are based on wrong assumptions while you don't appear to even read my arguments and try to understand my perspective that's based on experience. And let's not forget the way how this conversation even started (hint: you are the hostile one).
It won't help anyone in the user base if I implement something in a way it won't work reliably, and it would actually decrease user friendliness.
Good luck on your future ways.
@alandsidel, the solution is not so easy or reliable as your single-use case. @foosel has spent a lot of time explaining why this is the case. I'm not sure why you think this lengthy and in-depth explanation is hostile.
But can I suggest that your terseness, in response to an open-source developer spending their time responding and helping you with their software, that is provided free of charge is not very constructive nor likely to elicit a helpful response.
I'm not hostile
Yes, you are.
I'm frustrated as I've been trying to explain to you that your claims are based on wrong assumptions
All you have to do to prevent this from happening to another user ever again is show a message saying:
`"WARNING: Octoprint does not natively support (most/many) filament sensors. Install a plugin or ensure you have enough filament to finish this print before starting!"
[ok][cancel] [ ]never show this again`
This is both easy and warranted given what I and other users have experienced. You don't agree, or don't believe me. Fine. I haven't even looked at the source to octoprint yet and have no idea what the languages or toolchain that are used are, yet I'm confident I'll be able to add such a warning in an hour or less, assuming it's not .Net or something I have to spend hours installing and configuring.
And let's not forget the way how this conversation even started (hint: you are the hostile one).
It started by octoprint not warning me that it didn't support a feature on my printer that, as an end user, I expected it to, thus wasting hours of print time and a few hundred grams of filament.
it didn't support a feature on my printer
This is exactly the issue @alandsidel. As previously mentioned, the printer has to be able to tell the host software (OctoPrint or otherwise) what features it does and does not support. If that is not done by the printer's firmware then there is no way for the host software to be able to handle these events. I would suspect you would have had the same exact thing happen to you if you had used Pronterface to send the gcode to your printer. Assuming/Expecting any software to do something based on a specific use case is never a good idea.
https://github.com/alandsidel/octoprint/compare/warn-about-filament-sensor
No PR as I can't be bothered to go through the trouble to i18n the strings and so forth, no tests were created or run, and the cookie functions should probably be put elsewhere. Heck the function being added to base.js may not even be the appropriate place. After the back and forth I really just wanted to put it in to prove that what I was asking for was not really as difficult as it was being made out to be.
It did take a little longer than an hour for me to track down where the changes needed to be made. Y'all can take it or leave it.
- filament sensor capability report? If that's not present, that doesn't necessarily mean the printer doesn't have one
I added a PR to the Marlin branch, requesting them to add this functionality:
MarlinFirmware/Marlin#18577
Optionally, you can add a "warn on large prints" alert that warns you whenever you are printing a large print >25m, with an optional override if you have a filament sensor plugin?
I'm still seeing a detection issue here. It doesn't make sense to warn the user of long prints if they don't even have a filament sensor. However, M412 reporting off or a missing capability report can mean three things: the printer not having a filament sensor, or the printer having a filament sensor but it being disabled for some reason or the printer having a sensor but the firmware nor reporting not properly on it.
Only in the case "printer has sensor but it's disabled" do we want to warn the user. Otherwise we are just needlessly alarming them of a something that either is a non issue (the sensor works just fine, e.g. by triggering an internal M600 and/or corresponding action commands, the firmware just does not report on that) or that they cannot really do anything about right now (the printer simply doesn't have a sensor to begin with) and that is bound to cause a ton of support overhead consisting of trying to reassure users that no, there's no problem, and yes, they can just safely ignore this warning, at least until they change anything about their setup, at which point you then get issues because "now my printer does have a sensor, it was misconfigured, but OctoPrint didn't warn me".
Long story short: we can reliably determine the case that a printer has a filament sensor and that it in fact is armed and ready. But we cannot distinguish between the cases of
- doesn't have a filament sensor
- has a filament sensor and it works, although it doesn't get listed in the capability report and
M412is also not implemented - has a filament sensor but it doesn't work as it doesn't send action commands or trigger internal filament swap routines with
busyprotocol
And only the latter should ever lead to a warning, not all of them. Otherwise you really just teach people to click away more message boxes.
Now... what could work is add a field to the printer profile that determines whether the printer has a sensor or not, and if that is checked, check the capability report and response to M412 (the latter only for Marlin 2.0.0+ or RepRapFirmware because other firmware flavors currently don't support that), and only if that reports disabled do display a warning. That still doesn't guarantee that the sensor actually triggers an M600 or fires action commands on runout (and other than asking the user to intentionally trigger a runout we won't be able to figure that out) but it's probably the closest we'll get to detecting case 3, hopefully with a limited amount of false positives for case 2.
I'm against this idea for a simple reason.
It's common for firmware to ship aimed at a mainboard that COULD have a filament sensor installed (but not default with the printer) and disabled so that the user only has to plug the sensor in and turn it on via G-Code.
In this scenario, every mainboard that supports a sensor but doesn't have one would falsely trigger.
As such, the suggestion that @foosel has is more likely to be correct.