Cold extrusion prevention is a great idea and I'm sure it's prevented much filament grinding, but it is very confusing to users who are trying to test their extruders or print with ultra-low-temp filaments. The reason for this is that the warning doesn't appear in the jog view they are using and seems to only sometimes appear in the bottom of the screen on the status page (as it could be quickly replaced with some other message).
This is compounded by the fact that fewer and fewer people initially set up their printers using a serial connection, meaning that they might not see the error message sent out over serial.
I've personally assisted multiple users who thought their mainboards were fried because they weren't aware they were running up against cold extrusion prevention in the middle of troubleshooting some other issue or simply testing their extruder. As such, it really needs to bring up a full screen message that can't be accidentally skipped by trying to jog the printer. A simple way to do this is to kill the printer if it occurs, but the initial implementation of it didn't do this for some reason, suggesting there may be some reason not to do so?
And here's an example from today possibly caused by this: https://www.reddit.com/r/3Dprinting/comments/9yxqkk/error_with_extruder_dont_know_what_broke/
Not really a firmware issue.
This is a firmware issue. Users don't see that their extruder is being stopped from moving by a firmware feature because the error is invisible.

Its up to the host to react. Or just turn off the feature.
Perhaps it is up to the host to react-except for the inconvenient fact of
none of the hosts reacting and many, many people setting up their printers
and testing with no host attached to begin with.
Why should the user jogging an axis using the screen on the printer see an
error message on their computer 5m away but not where they're actually
using the user interface?
On Wed, Nov 21, 2018, 1:46 AM Rudolf Benner <[email protected] wrote:
[image: image]
https://user-images.githubusercontent.com/40361032/48826094-706d5e00-ed37-11e8-960b-1ba1863e2c16.png
Its up to the host to react. Or just turn off the feature.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/12499#issuecomment-440567944,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGWDqFR9HaO8bFFvyWSFWEImDgS9Q139ks5uxQS-gaJpZM4YsRkq
.
And we have confirmation from the user it was the bad user interface of this feature: https://www.reddit.com/r/3Dprinting/comments/9yxqkk/error_with_extruder_dont_know_what_broke/ea5nrzf/?context=3
In my opinion, a setting should be added, called COLD_EXTRUSION_IS_DEADLY which is on by default and kills the printer as soon as cold extrusion is prevented. The user will be forced to see the message. Then, if they have a host which wants to deal with it differently, a g code can turn it off, reconciling both of our opinions.
I'd think a simple beep, or hide the extruder jog menu when too cold would be more than sufficient. Maybe change the message based on too cold or not, so instead of Extruder, you just get Ext. Too Cold then when it heats message goes back. That's the limit of what we could really do imo.
Well, of those options, replacing the menu with a button which does nothing and says "too cold" would be good. OctoPrint still has bad UI with regards to this assuming it won't just disconnect itself upon getting the message (I'm not sure if this is the case), but fixing the menu on the printer's screen not to be there is a good start.
Why should errors when not connected to a host not be fatal actually?
Call tool change with retract / prime on, and it'll trigger. A few other areas. It's good for simulation as well. This is more of a warning than a hard error.
if you care so, add this line to planner.cpp and maybe in motion.cpp
ui.set_status (MSG_HOTEND_TOO_COLD);
under the line SERIAL_ECHOLNPGM (MSG_ERR_COLD_EXTRUDE_STOP);
@thinkyhead would be wise to insert this function?
Is there a way to display non-critical / non blocking error messages like "prevented cold extrutions" on lcds? That could be handy for cases like this.
All alert messages block general info messages. So if a "too cold" message was presented as an alert, it would then block general informational messages from then on. If it was presented as a general info message, then it would remain on-screen until the next general info message was presented. Since general info messages can be configured to expire, that may be the best option.
But that's still on the info screen, which is not right in front of the
confused user who is wondering why their extruder isn't turning, and
wouldn't think to look at the info screen.
Actually, would it be possible to show those info messages on the jog
screen as well if hiding the jog isn't possible?
On Fri, Nov 23, 2018, 4:48 PM Scott Lahteine <[email protected]
wrote:
All alert messages block general info messages. So if a "too cold" message
was presented as an alert, it would then block general informational
messages from then on. If it was presented as a general info message, then
it would remain on-screen until the next general info message was
presented. Since general info messages can be configured to expire, that
may be the best option.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MarlinFirmware/Marlin/issues/12499#issuecomment-441326644,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGWDqHqEcX4v3yxKZluRwenCiImO5vKaks5uyHtOgaJpZM4YsRkq
.
I see. If someone wants to implement that, please do. I'm quite busy with other features right now.
Note that at the moment, in Marlin 2.0 you cannot even select E movement unless the hotend is heated.
#if ENABLED(PREVENT_COLD_EXTRUSION)
if (axis == E_AXIS && thermalManager.tooColdToExtrude(eindex >= 0 ? eindex : active_extruder))
MENU_BACK(MSG_HOTEND_TOO_COLD);
else
#endif
So this is actually already fixed in a pretty good way. I'll close this, as it is just a matter of waiting for the proliferation of 2.0.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.