-
Notifications
You must be signed in to change notification settings - Fork 229
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
[BUG] Filament Should Purge At Higher-Temp Filament's Temperature When Changing - MK4 #3585
Comments
I requested this previously, but got bounced, because apparently Prusa don't consider it a problem. I wonder if, like with Octoprint support, this will suddenly get attention because it's an MK4 issue as well now... |
This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment. |
Is this fixed in the meantime? It should be closed only if resolved. |
Thank you for your contribution to our project. This issue has not received any updates for 60 days and may be considered "stale." If this issue is still important to you, please add an update within the next 7 days to keep it open. Administrators can manually reopen the issue if necessary. |
@Tupson444 No more so than previously. The auto-staler is a bit disappointing, as it basically amounts to the same pattern every time:
Repeated posting will of course keep it alive, but if there is no plan or interest in fixing this issue, it should be done officially, not by default. |
Yeah, the bot is opposite of useful (unless the goal is to actually ignore problems). 60 days of inactivity, like things are happening faster than that... I mean, there are good suggestions (that are often easy to implement) waiting years to be worked on, yet if nobody responds to an issue after two months it's considered there is no interest in it. Many issues don't need any further discussion (which is the only way to keep it open) - they just need to be fixed. |
@kozross all of the thousands of requests out there are potentially "legitimate". I respect and understand your point of view, but even our company has legitimate development plans and a big responsibility towards many, which means any given request must be very carefully studied before taking aciton. In fact, this specific topic has already been tackled multiple times so it seems the case of a duplicate issue to be closed (manually). Actually, @adamz5k this topic has been lengthy debated from various perspectives on this (MINI/MK4/XL ...) and older (MK3/MK2 ...) repositories -> about that, here is a description of the current expected workflow with MK2/MK3 if interested prusa3d/Prusa-Firmware#3114 (comment). Please check for existing similar issues, and participate in the most relevant conversations. We understand your point of view and meaningful comments are always appreciated. This issue will be closed in favor of issue #1821. Michele Moramarco |
It's understandable that it's difficult to process so many requests, many of which are duplicates or not useful, so a bot can help. But I think the time for closing is too short. One can report a problem, have a few replies, confirming the bug or interest in a feature, and then only because those few people didn't notice the bot 'stale' warning, the issue gets closed, while the poster thinks they've done their part reporting it and that it will be worked on one day, unaware that it is ignored. I suggest changing the time to 365 days - a full year would be more reasonable than just two months. I'm not implying that everything should be done faster, just that if something doesn't have an actual reason to be dismissed (and especially if it has strong reasons to be implemented), it shouldn't be accidentally forgotten because of some unoptimized bot. Yes, this is unrelated to the firmware issue, but I wanted to give feedback on how the bot can be improved. Is there a specific place where I can do that? (I couldn't find it, and I don't know what to search for exactly.) |
I am not sure if we can take requests about the stale-bot as this is more strictly related to the moderation and maintenance of this repository, in other words, up to Prusa Research. However, as usual, your feedback will be collected and forwarded to the competent team. We appreciate your thoughtful comment. Michele Moramarco |
Printer type - Prusa Mk4
Printer firmware version - 5.1
Original or Custom firmware - Original
Optional upgrades - ObXidian Nextruder Nozzle / Nextruder V6 Adapter with hardened steel nozzle
USB drive or USB/Octoprint
USB
Describe the bug
I switch between PETG and PLA probably more frequently than most and have discovered that my nozzle tends to get clogs when switching between PLA and PETG. I've never had this issue on the MK3 or the Mk2 and though the nextruder is different, I'm even having this issue with the V6 adapter. I believe I've narrowed down the issue to the filament change procedure. On the Mk3 & Mk2, the filament unloads at the temperature based on user input and I've always selected PETG as the filament type when changing.
However, on the MK4, due to the fact that it "remembers" the filament type, it always asks what the newly inserted filament is, and purges at that temperature. What this means is that, when switching from PETG to PLA, the remaining PETG in the nozzle is being purged at PLA temperatures; most is purged, but occasionally not all, and what's left tends to harden in the nozzle. This can cause occasional build-ups of PETG and partial clogs. I haven't tried this with higher-temp filaments, but expect the issue would either be similar or worse.
I tested this by switching between black PETG and white PLA until I noticed curling on the filament, indicating a partial clog. Once the partial clog was identified, I executed a cold pull and found that the partial clog appeared to have been caused by black filament still left in the nozzle.
How to reproduce
Switch between PETG and PLA several times.
To test: Switch from black PETG to white PLA, purge, then do a cold pull to see the remaining PETG.
Proposed Solution
I propose that the MK4 emulates the behavior of my Mk2 & 3 by identifying the hotter of the two filaments, and then purging at that temperature. At the moment, this is possible via workaround from either selecting the incorrect filament and changing it later or manually adjusting the temperatuer, but building it in to the firmware would be significantly more conventient and make things less likely to fail for other users.
The text was updated successfully, but these errors were encountered: