Prusa-firmware: [ENHANCEMENT]Stealth-mode/Normal-mode M-code

[vintagepc]

Printer type - Mk3S
MMU Upgrade - MMU2S

As noted in #1676 , stealth/power mode is more than just motor currents now. MBL is painfully slow when in stealth mode (esp. 7x7), and very quick in high power mode. This is partly because of all the time spent switching modes before Z-probing.

Describe the solution you'd like

I can live with the added noise for a few minutes, so I'd be thrilled if it was possible to use an M-code to toggle between normal and silent modes. That way, one could change to high power before MBL, and back to stealth for the print.

If you already have an M-code number in mind or a suggestion for a good one, I'd be happy to implement this myself.

[leptun]

There are already Mcodes implemented for this function, but not enabled by default. Take a look at TMC2130_SERVICE_CODES_M910_M918 define.

[leptun]

Please note that these commands don't save the chosen value to eeprom, so the menu might be out of sync and the values will reset for sure when the firmware is reset.

[vintagepc]

Noted, I hadn't really dived in too much when I drafted this up, I just skimmed the Marlin wiki for existing ones and didn't think to check here and look at the service codes.

Are those commands only disabled to conserve space, or are there other reasons we leave them off by default? Any objections to permanently enabling 914/915 (with possible improved handling elsewhere to indicate EEPROM override)?

Alternately, perhaps a less intrusive option is to add a flag to the MBL gcodes to turn high power mode on/off before and after.

[vintagepc]

@leptun so this is interesting. I think there may be an ugly bug somewhere surrounding the TMC2130 mode. There are situations where the variable tmc2130_mode refuses to change when commanded to by M915 or 914.
I encountered this while trying to debug why my menu tweak was thinking an M-override was present when it should not have been.

Current code is here:
https://github.com/prusa3d/Prusa-Firmware/compare/MK3...vintagepc:%232477-stealth-mode-M-code?expand=1
Summary of changes:

• re-enabled M914/5
• Updated M914 to just use FORCE_HIGH_POWER_MODE_START since that's exactly what it does
• Updated M915 to be the equivalent of force_low_power_mode.
• added some serial debugging output.

Monitoring pronterface, I get the following (commentated by me) output:

M915
SENDING:M915
tmc2130mode/smm/eep: 1 1 1
ok As expected, was already in stealth so no change
M914
SENDING:M914
tmc2130mode/smm/eep: 1 1 1
tmc2130mode/smm/eep: 0 1 1
ok As expected, change to high power mode
M914
SENDING:M914
tmc2130mode/smm/eep: 0 1 1
ok As expected, no change since we are already in HP
M915
SENDING:M915
tmc2130mode/smm/eep: 0 1 1
tmc2130mode/smm/eep: 1 1 1
ok Good- changing back to LP

[[ At this point I changed the printer to Normal mode to verify the other half of the menu ]]

M914
SENDING:M914
tmc2130mode/smm/eep: 0 0 0
ok Good, no change, already in normal
M915
SENDING:M915
tmc2130mode/smm/eep: 0 0 0
tmc2130mode/smm/eep: 1 0 0
ok Good, changed to stealth
M914
SENDING:M914
tmc2130mode/smm/eep: 0 0 0
ok Good, back to normal
M915
SENDING:M915
tmc2130mode/smm/eep: 0 0 0
tmc2130mode/smm/eep: 1 0 0
ok Good, back to stealth
M914
SENDING:M914
tmc2130mode/smm/eep: 1 0 0
tmc2130mode/smm/eep: 1 0 0
ok What? -- didn't change
M914
SENDING:M914
tmc2130mode/smm/eep: 1 0 0
tmc2130mode/smm/eep: 1 0 0
ok
M914
SENDING:M914
tmc2130mode/smm/eep: 1 0 0
tmc2130mode/smm/eep: 1 0 0
ok
[[ etc. -- printer is now stuck in "normal w/stealth override", and cannot be changed, even via LCD, until reset. ]]

I've skimmed the code and the only place I see an "unaccounted for" mode change (e.g. not directly in a power control function) is in disable_force_z() - but that shouldn't be locking out the value from future changes.

Any thoughts? I'll keep digging if not, but this seems like the sort of thing you might be able to point me in the right direction and save me a few hours of head scratching and printf-recompile-flash cycles.

Thank you again for your insight.

[leptun]

You are on the tight track with the PSU delta theory. It does lock the tmc2130 mode to silent when the Z motors are “disabled”. The real issue I see with it is that all other axes are also set to silent as a side effect.
If you disable PSU delta, the issue should be gone.

[vintagepc]

Thank you! That would explain why it works briefly and then stops working.

For the purposes of this it's probably not a huge concern if a temporary M override doesn't persist beyond a motor timeout, so I'll just update the menu indicator accordingly since it's not a bug, just exposing some internal behaviour.

Typical use case would be mid-gcode stream, e.g. before/after MBL, and possibly some utility mid print to enable crash detect/high power in "risky" print areas prone to curling.

[vintagepc]

Success! I got it sorted and it behaves now - M914 will re-wake Z for PSU_Delta, and if the timeout occurs the menu just shows "normal" again since the override has expired/will clear next wake.

[rdpeake]

What is the status of this, as being able to use silent mode to disable crash detection mid print may be useful for me, and would rather not recompile to add the define to enable these (assuming adding mcode to toggle crash detection is not worth considering?)

[vintagepc]

If it is of any value, I have been running my own M914/5 PR branch code for quite a while now; I use it all the time to do MBL in normal mode and then the rest of the print in stealth mode.

[rdpeake]

I just spotted it is your script for the retractable purge mechanism that i was looking at the 'stealth mode' option, as it otherwise requires crash detection off for the whole print to do. figured toggling stealth mode, as disabling crash via gcode isn't an option, would be better than just having crash detection off all together.

[vintagepc]

Good idea; hadn't thought of that because I am not really using the RPM at the moment. Perhaps one day I'll get back to it. In any case, I would happily entertain a request to support M914/M915 in that script. :smile:

[rdpeake]

Let me get the mechanism first (first one was lost in the mail) and set up. i'll get back to you on adding to that script once i actually have it working without it.