Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

with tension sensor setup MMJ_EJECT fails to eject filament #412

Closed
ntchris opened this issue Aug 30, 2024 · 9 comments
Closed

with tension sensor setup MMJ_EJECT fails to eject filament #412

ntchris opened this issue Aug 30, 2024 · 9 comments

Comments

@ntchris
Copy link
Contributor

ntchris commented Aug 30, 2024

with tension sensor setup MMU_EJECT fails to eject filament

Problem:

has been investigating this problem for a few days.
I have a very high chance of failing to run MMU_EJECT command,
after it runs , most likely it fails and ask for pliers
00:04:38 MMU issue: Unload sequence failed: It may be time to get the pliers out! Filament appears to stuck somewhere 7.014616>1.5031320000000001

or sometimes doesn't say that but claim unloaded but the whole filament is still inside extruder.

18:30:45 [T7] < En ......... [Ex ... Nz] UNLOADED -88.0mm (e:80.2mm)
18:30:45 we are here 3 about to if runout 
18:30:45 Unload of -88.0mm filament successful (encoder measured 80.2mm)
18:30:45 Modifying MMU gear stepper run current to 85% for extruder syncing
18:30:45 Synced MMU to extruder (sync feedback activated)

so I tried quite a few times and compare different logs fails and success,
finally narrow it down
it seems this function may not work when system has tension sensor setup

    def _test_filament_in_extruder_by_retracting(self, length=None):
                   _,_,measured,_ = self._trace_filament_move("Moving extruder to test for filament exit", -length, speed=self.extruder_unload_speed, motor="extruder")

system sensor setup
print head has no sensor at all, no extruder sensor, no entry sensor
( I don't want to mess with print head since ERCF1 and the previous version ERCF-Software-V3 works really well without those print head sensors)
system has two tension sensors, expanded and compressed.

Root cause:
when system has tension sensor device, one end (belay) or two ends (compressed and expanded both ends), a tension sensor device/module should always have a slider block that can freely move for about 5mm to 20mm , it depends.
while the filament is still in extruder, the above function tries to move filament out, it can move freely for XXmm, even though the filament is still locked in extruder.

work around
maybe user can add a pre eject macro to move the filament back for certain distance, so to create a expanded state first.
then above function should work.
MMU_TEST_MOVE MOVE=-20
not ideal because it maybe already in expanded, so grinding. and sometimes it doesn't work.

Real fix
the above function should check tension sensor if defined, for expanded state, if not expanded (moving toward ERCF), move it until it's expanded.
if not defined, maybe must do a blind move for certain mm....reduce current maybe needed, to avoid grinding.

also , it's necessary to check the unloaded filament length, if it's unloaded from extruder, and if the length is too far away from the system bowden length, then should not claim it's unloaded successful and even try to cut it with EREC servo/blade.

Thanks

fail_eject.log

@moggieuk
Copy link
Owner

You are correct that with the "spring" that a sync_feedback sensor provides the _test_filament_in_extruder_by_retracting() will likely not work because it relies of the encoder seeing movement.

All these encoder based validations are essentially just looking for movement of the encoder. I allow for a single accidental pulse, so movement is defined as > 1.5 pulses (also around 1.5mm for binky).

So to get to the bottom of this:

  1. The 00:04:38 MMU issue: Unload sequence failed: It may be time to get the pliers out! Filament appears to stuck somewhere 7.014616>1.5031320000000001 seems appropriately to have caught the problem because the encoder moved when the servo was release -- i.e. filament was still present.
  2. If think the bowden unload may be the issue. This SHOULD have turned off any rotation distance adjustment so the gear motor should retract the correct filament amount? If not you should look at calibration of that gate (specifically the resultant rotation distance of gate0 * ratio).
  3. The _test_filament_in_extruder_by_retracting() function should not be called when sync-feedback device is present, at least not in current state. Agree that it could also use state change of sync_feedback sensors. I don't think it can't blindly push until expanded because that would be an unknown distance and subsequent moves may fail. Perhaps the best solution is to disable this check and optimistically return (True, 0) if sync_feedback device available. This simply nullifies a check that frankly is better and more reliably performed with a toolhead sensor..

I don't understand your last paragraph. Can you elaborate.

@ntchris
Copy link
Contributor Author

ntchris commented Aug 31, 2024

  1. yes that log shows it's caught unsuccessful, but sometimes it just claimed success. so it seems it has some different code path. I will keep digging.

thanks , last part means if the system config has bowden length of 1000mm, and we attempt to eject filament from extruder (mmu detected and confirm it was in extruder), after the MMU_EJECT operation, we can see in the log it reported unload only about 80mm, sometimes 40mm.
ie
.....
19:18:23 [T7] < En ......... [Ex ... Nz] UNLOADED -88.0mm (e:83.2mm)
19:18:23 Unload of -88.0mm filament successful (encoder measured 83.2mm)

so if compare the actual unloaded length reported VS the bowden length in config, mmu can easily tell it's not fully unloaded.
because 80mm is much much smaller than 1000mm.
so it could be another checking to add to ensure it's indeed fully unloaded and not attempt to cut it in the middle.
thanks.
(maybe at least within 50% range of the bowden length ?)

I made a fix and tested it a few times, seems working.

thanks

@ntchris
Copy link
Contributor Author

ntchris commented Aug 31, 2024

correction , all above sensor state should be compressed,
the potential fix is output more filament toward extruder, not move back, so to make more filament inside bowden, full full.
so that later extruder retract filament back, there is not free moving space, so encoder should detect it.

thanks.

@ntchris
Copy link
Contributor Author

ntchris commented Aug 31, 2024

fail_eject_but_say_success.log
here is an example log when it failed to eject but claimed it's success.
below should be lines of interst
10:03:22   DEBUG: Unloading last 28.0mm to exit the extruder
10:03:25   DEBUG: Total measured movement: 0.0mm, total delta: 28.0mm <-- must be caused by tension free move block
10:03:25 Encoder not sensing any movement:
10:03:36 Unload of -1087.0mm filament successful (encoder measured 107.2mm) only unload 107mm of 1087mm

thanks

@ntchris
Copy link
Contributor Author

ntchris commented Aug 31, 2024

some more tests done , seems the MMU_RECOVER macro and inner function _check_filament_still_in_extruder()
has the same problem, with the tension device free move dist it cannot correctly detect if the filament is still in extruder.

I think the solution would be the same, just let MMU output some filament ie 40mm to make it in compressed state.
then it should work

thanks

@ntchris
Copy link
Contributor Author

ntchris commented Sep 1, 2024

fixed by this
#414

@moggieuk
Copy link
Owner

moggieuk commented Sep 4, 2024

As commented in the PR I need some time to digest this and think about all the possible configs and how this might effect them. I also have a concern on the new auto-calibration work in "auto-calibrate" branch. Oh, the other limitation I have to adhere to is Python2 support. 10% of users are still on it and Klipper still supports it.

Copy link

This issue is stale because it has been open for over 30 days with no activity. It will be closed in 14 days automatically unless there is activity.

@github-actions github-actions bot added the stale label Oct 29, 2024
Copy link

This issue was closed because it has been inactive for 14 days since being marked as stale.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants