MMU-238 Fix false positive `FINDA_FLICKERS`

[gudnimg]

Summary

• Issue affects both 8-bit and 32-bit firmwares.
• Delay reporting the cut command finished until the selector has returned back to the cutting slot. This was done by adding ProgressCode::Homing to the Cut Filament state machine. ProgressCode::ReturningSelector is then used to wait for the selector to return back to the cut slot after homing becomes valid again. Only then is the cut operation reported finished and a new command can be processed e.g. Toolchange.
• Updated cut filament unit test.
• Adjust selector homing behavior in unit tests to better reflect the behavior of the firmware.
  • Waiting for the selector to return to the parked position after homing is not enforced by the firmware and should therefore not be enforced by the unit tests. There are some few exceptions to this, and for those situations I added a parameter to SimulateSelectorHoming() called waitForParkedPosition to explicitly wait for the selector to return to the parked position if set to true. This is very useful when setting up test cases in general and also allows us to control the behavior in each test. Note: I added commit cb3580a after writing the above. It makes things a bit more general and also now applies to the idler.
  • The scenario when we need to explicitly wait for the selector to return to the parked position is when a respective state machine checks for ms::selector.State() == ms::selector.Ready. Example is the Unload Filament state machine before the operation is reported finished.
• Add more debugging strings when a unit test fails.

Details

Affected users Issue affects both 8-bit and 32-bit firmwares.

---

When does the issue appear to the user?

• The issue always appears when trying to recover from a failed Toolchange, after the MMU cuts the filament (at the end of the 2nd toolchange retry attempt) and just before the start of the 3rd toolchange retry attempt. MMU will falsely issue a FINDA_FLICKERS error. The MMU and Printer recover automatically with a retry so this issue is not a blocker.

Why is this happening?

Consider the scenario when the MMU receives the cut filament command (during a failed toolchange). So we start by cutting the filament. Once we enter ProgressCode::PerformingCut the filament has been successfully cut, the homing is then invalidated and the motor settings are reset to normal. State then changes to ProgressCode::ReturningSelector and once the homing becomes valid again (the instant when the selector is at Slot 5) then the Cut filament operation is reported finished. Meanwhile the selector tries to return to the parked position in the background.

The printer sees the cut filament operation is finished and sends a Toolchange command to attempt the next retry. This triggers a call to the Toolchange Reset() method. At this point the selector is still returning the parked position (which is the slot where the filament was cut) and feed.Reset(true, false) will return false since the selector is "busy" moving. This then triggers a call to GoToErrDisengagingIdler(ErrorCode::FINDA_FLICKERS) which does not reflect reality (FINDA is working fine).

To fix this behavior, the Cut Filament state machine should be similar to Unload Filament in that it shouldn't report the operation finished until the selector has returned to the parked position.

---

Steps to reproduce:

1. Preheat the nozzle
2. Send T0 to the printer OR select Load To Nozzle from LCD.
   • Note: MMU Slot 1 is best to use to produce this issue since it will maximize the selector move distance after homing becomes valid.
3. Fail the try-load-unload sequence until the Cut command is sent.
   • Note: You don't need filament to trigger the issue, just need to make the state machine happy and trigger the filament sensors.
   • When the E-motor moves, trigger the Fsensor manually by pushing on the chimney lever.
   • Untrigger the FINDA to complete the unload
4. After the filament is cut, you will see the following behavior:
   • 1) The selector correctly cuts the filament
   • 2) the selector homes correctly. (Homing is done when the selector is at MMU Slot 5)
   • 3) Expected behavior: Selector returns to Slot 1 and retries the tool change
   • 4) Actual behavior: Selector stops abruptly while moving to Slot 1, due to the tool change state machine being reset and it triggers FINDA FLICKERS because the selector is moving. There is no error screen since there is a successful automatic retry afterwards.

The issue does not appear when using the printer's LCD because the T0 and K0 commands must be sent quickly (before Selector can park).

With MK3S+ and latest MMU FW I can reproduce this 100% of the time.

Change in memory: Flash: +16 bytes SRAM: 0 bytes

[gudnimg]

Slack thread with some screenshots https://prusa3d.slack.com/archives/GMV4A54R4/p1684684408818969

[gudnimg]

I have found a bug in the unit tests.

SimulateSelectorHoming() assumes the firmware always waits for the selector to return to the parked position. This is not true. I corrected the behavior in SimulateSelectorHoming() and now multiple tests fail, will continue investigating...

[gudnimg]

Added some more improvements to the homing behavior in unit tests. Please let me know if I should drop that commit or make changes. cb3580a

It didn't sit well with me the fact that I was making changes to the selector side but not the idler as well.