@leptun (Sorry if you're the wrong person, just seems most of my interactions have been with you, and your insight would be appreciated...TIA)
I've pushed up a minimally intrusive grinding detection idea to
https://github.com/prusa3d/Prusa-Firmware/compare/MK3...vintagepc:%232478-mmu-detect-grinding?expand=1

I plan to test it myself and polish it more before filing a PR, but I wanted to get your take on this before I invest too heavily - any concerns about this particular design? I contemplated other options like a special sequence or paused state but it seems like a bog-standard M600 with custom message is going to be the least complex and bloat-y way to handle this, not to mention that code has already been proven.
The extruder will try to unload for a partial recovery, but at that point there's a user prompt indicating a jam was detected and to fix the problem. After they remove/cut/whatever the filament then it can proceed as a normal M600 reload. If it's not fixable live to recover the print there's not much we can do for them anyway, but at least they had the chance to try instead of a third of a print and two thirds air.

Something else to consider is false positives, This could get annoying if the user has a flaky sensor, so I think as part of the polish I should add an option to control this. I think maybe changing the F.sensor on/off toggle to a trinary, e.g. 'on','off','on&jam' is least intrusive, as a discrete option would need a new EEPROM var. EEPROM_FSENSOR takes up a byte, so we can easly add the new field as ==2 without impacting existing setting values. >0 is still "on" so any code that uses shorthand like (!value) or if(value) will still be valid, we only need to check ==2 in the jam detection routine.

@vintagepc The idea sounds interesting. I don't see why it wouldn't be possible to implement this also in the old fSensor. @wavexx has to confirm if this would be possible.
The only issue/concern I see/have is what happens if SpoolJoin is enabled. Is that handled gracefully?
I'll test the changes this evening and report if I find any issues with the implementation. Do you have any way of manually triggering the grinding detection? (such as a special gcode that grinds the filament)
I think that EEPROM_FSENSOR should be "Off", "On&Jam", "On" in this order since if the user had previously used FSENSOR ON, then now they will also have jam detection enabled by default.

I think we're OK on the spooljoin front, we don't mark this filament as depleted and don't pass the AUTO flag to M600 like that pathway normally does. A user should be able to fix the issue and reload the same filament again.

I agree, there's no reason this shouldn't work with an MMU2/MK3, especially with the recent sensor improvements.

I don't have any gcode yet but I suspect you could easily fake it by disabling cold extrusion and trying to extrude anyway. Since I have a skelestruder I can just lift my IR arm to make that sensor read 0.

I'll implement the EEPROM value stuff later today. If we can vet it satisfactorily it might be a nice bonus feature for 3.9, assuming that fits the schedule.

I don’t think it will be in time for 3.9.0. Maybe later revisions.

I didn't hold any reservations it would be, since I suspect we're pretty darn close to an RC by now
:)

Yeah... RC1 should be released this week, so no more changes to it.

Pushed a tentative menu update. Should have some time to flash and test later today.

@leptun just took it for a spin. Menu appears to behave correctly, value persists across restarts.

With "On&Jam", it appears to work. I did an M302 S0 to allow cold extrusion, had the FINDA triggered, and IR=0. Tried a G1 E and got the message as expected, followed by "MMU needs attention" after pushing the knob. After pushing knob, MMU attempted to recover as normal.

With only "On" selected, nothing happened and the G1 command completed as normal.

Only gotcha is option length. We'll have to come up with something that fits better, or shorten "Fil. Sensor" even more. The former is naturally preferred to minimize translation requirements. I'll noodle on this some more but am open to suggestions. Maybe "Off","+Jam" and "On", if we think that's not too confusing for users, or just ditch the "&" entirely...

Also pushed up a fix for a bug I found by inspection/review; a non-MMU Mk3(s) should only cycle 0/1, not 0/1/2 for the option. I'd already made it only say "On" if no MMU for either case, but missed making the toggle skip the second On option. Have not tested as it's a little tricky to get at the MMU to disconnect the data cable the way things are mounted in the enclosure.

Also have not tested Mk3 variant, though I did also update the relevant code in fsensor.cpp. I have the sensor somewhere but really don't fancy rebuilding my extruder wire harness...

(Side note, I modded my A3 LCD to support brightness, looks suuuper sexy in orange XD)

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

This issue has been closed due to lack of recent activity.