Unexpected result with selector touch capability

[agreen]

Test scenario:

• ERCF v2
• Selector touch configured and enabled
• Selector physical endstop configured and enabled (NOT using virtual selector endstop)
• Filament blocking gate from moving
• MMU/printer reset
• Run MMU_HOME

Expected result:

• MMU attempts to home
• MMU realizes it cannot move
• MMU attempts to clear/unblock gate
• Gate unblocked
• MMU homes to physical endstop

Actual result:

• MMU attempts to home
• MMU "grinds" selector for a second or two
• MMU reports homing error "MMU issue: Homing selector failed because of blockage or malfunction. Klipper reports: No trigger on mmu_sel_home after full movement"

I have confirmed that the "touch" capability works AFTER homing when moving from one gate to another. The documentation is not clear that the machine should be homed before this functionality starts working, and I had expected it to work prior to homing as well.

I would suggest either implementing this capability, or documenting this is only useful AFTER a successful MMU home. Personally, the attempt of clearing the blockage on homing would be a big benefit, IMO.

[moggieuk]

You are correct in your assessment - the "touch" automatic recovery only is applied to selector movement and not to homing. There is a reason for this that would need to be carefully thought thru.. specifically, is the axis is not yet homed, normal movement is not possible. It is possible to defeat this but it means bypassing all of klippers default homing logic. It is a good idea so I'll add to the "enhancement list".

[moggieuk]

EDIT: I spent a couple of hours implementing this and then realized why I didn't do it before... (if selector is not aligned which will be the case after a non-stallguard homing operation, you cannot reliability unload). Instead you can use this:

MMU_HOME FORCE_UNLOAD=1

This will ensure that filament is unloaded PRIOR to the homing operation. Can't remember why I didn't make this the default - I think because without gate sensor it will jiggle the encoder which would be confusing for normal homing.. maybe it could be the default after all calibration is complete... have to think about that.

[moggieuk]

Also, can you confirm the state of the MMU after restart? I.e. the output of MMU_STATUS. I'm going to assume that it is in an UNLOADED state (because all other states will recover position and unload if necessary) and that a piece of filament has just poked through the gate to block the selector?

I ask because I'm trying to understand the exact case that is causing you problems.

[agreen]

I'll do some further testing and get back. After I opened this bug, I have noticed sometimes it works as expected, sometimes it doesn't. FYI, I've been chasing TTC errors as well ,and I suspect there's some correlation with the TTC errors. I'm at about a 75% TTC to start print ratio. :-/

[moggieuk]

Many folks have been having success with a new (fast) sd-card..

On MMU_HOME. If the filament position is unknown or anything other than "UNLOADED", the homing logic will run a "recovery" to find filament pos and then unload if necessary before homing. The only case that wouldn't be covered if is the filament had pushed through the gate but not far enough to be detected in the gate. The "touch move" logic is able to reposition the selector, then extrudes more filament so that a reliable test can be performed and thus recover. This isn't possible/sensible on home move: a) because klipper homing using a single homing endstop - if I used more than one then I'd have to handle cases where the wrong one fired but can't be sure which is correct, b) what if the selector is not at a gate but failed .. pushing move filament could mess up a lot of things. On an ERCF the servo down could depress two gates, etc..

Basically I think the way homing works is proper and if persistence level is at 4 then there is no need to call "MMU_HOME" which is the way I have my machine setup.

I will try to remember to clarify the doc though.