Destruction and how to prevent it
-
I built a core xy matchine and had an accident this evening. Mid print someone mistakenly activated auto bed leveling and bad things happened. Is there a way to lock this option out on my panel due or in the config.g so it cannot be activated while printing?
-
@jackatom74, currently there is no facility to lock out other input channels while printing. To implement one, we would need to start from a specification of what commands should be locked out. For example, it's useful to be able to change temperatures, firmware retraction settings and some other configuration settings while printing. Also, pause commands and emergency stop must be allowed. So it's not as simple as locking out all commands from input channels.
-
@dc42 thank you, I understand.
-
@dc42 could the button on the paneldue be hidden when a print starts at least?
-
@phaedrux said in Destruction and how to prevent it:
@dc42 could the button on the paneldue be hidden when a print starts at least?
Which button or buttons? The Pause button is needed, so are the buttons to adjust fan speeds and temperatures. Macro buttons may or may not be needed depending on what they do.
-
@dc42 no, not all the buttons, I just mean the bed level button, since it seems to have a very immediate and damaging effect mid print.
This must be possible since the baby stepping button only appears when a print is started and disappears when finished.
-
I guess I could disable the bed comp and homing buttons while a print is active and not paused, but I suspect that once I have done that, there will be complaints that other functions should be disabled too. This is the sort of change that needs to be thought out properly in advance.
-
I haven't used that bed button on the PanelDue. Does it just run a macro? If so, the user could protect themselves by adding a block M291 prompt at the beginning that asks if they are sure they wish to run it. Would that still interrupt the print?
-
I'd suggest something similar to the user access control linux has. At least during a print refuse commands that aren't encapsulated in another gcode ie:
M[unused number] "G1 X50 Y50 Z50" P[sudo like password]
Duet and web control could be adapted to use sudo gcode for a configurable time period and Duet could respond with permission denied to normal gcode mid print. E-Stop commands should probably be accepted without encapsulation.
Edit: If this feature was disabled by default when added it would be completely unintrusive for users who don't want it. Likewise the password section should probably default to no password.
-
sudo-like command is interesting, but if the use of a blocking macro with M291 does not interrupt the print, it seems to me a much simpler (and already implemented) option.
-
I've not tried to use M291, but from what I can see it doesn't help when more atomic, or single line commands are used or triggered by mistake such as G1. Likewise whilst the blocking macro may save from damage wouldn't this also potentially cause an artefact inducing pause?
-
Would it be possible to simply have a timed lockout for the panel due similar to the screen dimming? After which time a long press would need to be entered to regain control? At least that way you're guarded against inadvertent presses and probably also protect against strangers just pressing buttons.
-
I have moved this to the firmware wish list as it will probably require firmware changes to implement.
@Phaedrux having a lock screen for the paneldue is on the wishlist.
