-
Notifications
You must be signed in to change notification settings - Fork 103
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
Feature Request: Smart PTFE tube length calibration #151
Comments
So I had a poke at the code for a few minutes and I see that the load/unload are controlled here:
What interests me most is that as I dig into the As Hopefully I'll get a chance to test it, but my assumption is that code can be added to the I haven't dug far enough, but I am assuming that |
Totally with you - I applaud that the printer 'figures it out', but it's a good assumption the tube won't change length significantly from the first layer to the second, and a lot of time could be saved. I find the 1st load fails like 70% of the time, but the rest of the print is generally ok. It's in the logic, I'm sure, but I rarely get answers to genuine questions on here. :-\ |
Setup:
Given that it appears that on the 3S the MMU is now using the IR sensor to help it with loading, I swapped in a 1m PTFE tube between the MMU and extruder to see how it would handle it. I'm happy to say that it worked with no, but it could use improvements.
My test was 5 20x20x0.2mm squares with each assigned a different filament. I first ran it with the normal tube and it worked as expected. I then ran with the 1m tube and it worked as well, but with a substantially longer run time (30m vs the 13m with the normal tube).
The issue is that while loading starts normally, after it runs the "fast load" portion it starts "searching" for the IR sensor. It does this by advancing the filament a bit at a time until the IR sensor trips. How long that takes is clearly going to be dependent on the PTFE tube. After finding the IR sensor it continues on as normal. When it comes time to unload for the next tool change it does the same thing in reverse looking for the FINDA. The whole process repeats for each load and unload.
The way I would like to see it work is that it would go through this slow process on the first load, store the information, and then reuse it for all future load/unload procedures for the current print.
This would allow for great flexibility for the end user as to where the locate their MMU in relation to the extruder with a minimal impact to the printing time.
The text was updated successfully, but these errors were encountered: