MMU improved fsensor handling

[leptun]

• FSensorBlockRunout now properly handles nesting of the blocker.
• Events were introduced in the filament sensor code. These can be checked using polling for the three supported actions: runout, autoload and filament jam. These flags persist until they are manually cleared. These events work regardless of the FSensorBlockRunout suppression status, but can be disabled using the global eeprom setting. Example usage of these flags are checking for issues in VerifyFilamentEnteredPTFE, checking for autoload events when the user is expected to insert a filament, etc...
• These events allow VerifyFilamentEnteredPTFE to actually do it's job on non-S printers, so if the printer fails to grab the filament, the issue will be detected and a reload will be issued. On S printers, the jam event will never happen since that fsensor doesn't have the capability.

[leptun]

@gudnimg suggestion: It might be helpful if we forced a rehome of the MMU after unload when a VerifyFilamentEnteredPTFE error occurs. On the non-S printers, VerifyFilamentEnteredPTFE can fail due to filament strings where the fsensor sees "filament" too early, so the gears don't end up grabbing it. The current behaviour is to just unload the filament and immediately load back, which does nothing about the strings. If the selector were to move away from the slot and back (eg, due to rehoming), it might be enough to bend the stringy tip backwards and force it to load correctly on the next loading attempt. I'm not sure if cutting plays any role in this retry attempt since I haven't used it for now (due to 12V unit which struggles significantly more than the 24V mmu).

[gudnimg]

It might be helpful if we forced a rehome of the MMU after unload when a VerifyFilamentEnteredPTFE error occurs.

We would need some way to tell the MMU to invalidate the homing 🤔 I think a G-code is overkill, but maybe a command via the Protocol would suffice and add 'H' to enum class RequestMsgCodes to tell the MMU to home (via invalidating its current homing, state machine will take care of homing automatically)

@DRracer what are your thoughts on this?

Looking closer I see we already have Home = 'H' 🤔

[DRracer]

Yes, we can issue a homing command when the MMU is not performing anything else.

[gudnimg]

Rebased to sync with MK3 branch

[leptun]

@gudnimg The VerifyFilamentEnteredPTFE() jam detection seems to be working correctly after rebase. One note though: it's weird that there is no indication whatsoever that a jam happened during the checking. The progress bar can show all blocks as ok, but the VerifyFilamentEnteredPTFE() could still fail in the end because of the jam event. Any proposals as to what we could do about this?

[gudnimg]

@gudnimg The VerifyFilamentEnteredPTFE() jam detection seems to be working correctly after rebase. One note though: it's weird that there is no indication whatsoever that a jam happened during the checking. The progress bar can show all blocks as ok, but the VerifyFilamentEnteredPTFE() could still fail in the end because of the jam event. Any proposals as to what we could do about this?

I added a commit today PR 4080 to log the result c7f669f Maybe we can echo jam as failure reason?

Would it make sense to check the jam event more regularly so we can show the status with individual pixel?

[leptun]

We could check it more regularly instead of just the end. Would we show only one block as "jammed" or all blocks following the jam event?

[leptun]

Done. The pixels now show an "error" for each jam event that is generated

[leptun]

Testing scenario:

1. Check that the filament loads to the nozzle correctly with MMU. This is to be tested on both MK3 and MK3S. Also check that if the gears fail to grab the filament, the VerifyFilamentEnteredPTFE() fails and retries.
2. Check that autoloading works. This is to be tested both from a cold printer and a preheated printer. When the filament is inserted while cold, the filament prompt should be displayed. If the printer is already hot, the filament should just start being loaded. If there is a prompt that says "press to continue", the filament can be removed and inserted back and the prompt should be dismissed. This behavior is implemented for both the regular filament loading/autoloading and for the M600 change filament command / filament runout/jam.

[gudnimg]

I'll try running this on my MK3S+ this evening. 👍

[gudnimg]

Tested the current changes on MK3S+ with MMU. Note I added these changes on top of PR #4080 to test those together.

• ✅ Load to Nozzle from LCD
• ✅ Sending T0 and T4 gcodes after preheating
• ✅ M600
• ✅ Starting Single color MMU print

[leptun]

@gudnimg What still needs to be done is to extract these Filament_sensor.h specific code from mmu2.cpp to mmu2_fsensor.cpp so that it can be ported to the MK4 fw. Afaik, the MK4 side doesn't have this jam detection capability yet, but it could in theory be implemented with the loadcell. The ifdefs for the defined(FILAMENT_SENSOR) && (FILAMENT_SENSOR_TYPE == FSENSOR_PAT9125) can then be added to the wrappers in mmu2_fsensor.cpp

[gudnimg]

The PR seems to add about ~130B on MK3S+. The ifdefs only save ~30B. I wonder what is using more memory 🤔

[leptun]

The rest of the changes for autoloading and events in general I guess?

[leptun]

@DRracer I'd like to get the mmu2_fsensor.h interfaces unified with the Buddy fw. I see that the buddy fw uses BlockRunoutRAII, something which we don't have here. Instead, we have FSensorBlockRunout in Filament_sensor.h which is functionally identical. How should we proceed with unifying the code? I want to get rid of all Filament_sensor.h dependencies in mmu2.cpp. Only mmu2_fsensor.cpp should make MK3 fw specific calls.

[3d-gussner]

@DRracer @leptun @gudnimg What is the status of this one? Needs some attention to fix the conflicts.