-
-
Notifications
You must be signed in to change notification settings - Fork 937
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
Fix a bug that wipe tower has missing extrusions when ramming is disabled #6894
Conversation
Works beautifully (at least with SEMM and ramming disabled :)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome thank you! |
One more thing - what I didn't notice is that it is "purging" in the wipe tower before the filament swap I dont think this was the case in the old version. While this is not an issue per se, its unnecessary material purge - ideally the actual purge area should be expanded to cover those areas or these omitted? Sorry I haven't deep dived in that code segment so dont know exactly why this is happening :( Appreciate this is a) not a big deal and b) the wipe tower logic is pretty harsh to read code wise :) |
Also there because it stops that pre-purge routine half way through the tower, when resuming after the tool change we get a tiny blob (depending on how well Happy Hare is configured) on the purge tower itself. I've noticed this leads to slight blobs on the surface of the tower, vs. in the past where the print resume would always happen at the edge of the tower. |
Ok there definitely is something wonky with the prime tower and ramming when ramming is disabled: It looks like it's extruding on the last layer over the prime tower but not on it if that makes sense, even though ramming is disabled in the printer settings. @SoftFever |
I've got my hands tied right now to help code a fix - upgraded to sequoia and while the project compiles I get a ton of runtime crashes when debugging - seems like the compiler in the latest Xcode toolset is more restrictive in allowing slight "errors" during runtime :( |
yeah, that's nasty. Probably need to rebuild deps. |
Already done so - deleted repo and re-cloned and rebuilt. The odd thing is running the build script (.sh) works just fine and the executable in the end is OK. But when running the debugger on Xcode it just errors out on (legitimate) issues that were not causing a complaint before. Mostly around out of bound vectors (eg in my IOI code of all places) and threading copy operations (in the expand bridges section). Prob the new build chain is more restrictive with assertions in the base libraries (vector for example). Fixed this using "resize" instead of "reserve", then I get this: Looks like some code changes are needed, which slipped through the radar before as the build chain was more "chill" with memory access |
I don't get what's the issue from the screen shot. |
I'm using latest xcode as well. I use relwithdebinfo to debug though. |
I do find an issue about this part: There is a issue, we still need to set "Filament Parking Position" to 0 if you want to turn off ramming. |
Same here - I use relwithdebinfo and this started happening when I deleted the orca git folder and cloned again for a "fresh" base. Really not sure why they are happening but the errors do seem to make some sense. The debugger just didn't seem to mind before. I've raised a PR for these three instances here: #6932 For the wipe tower - yeap sure thing - Notice the line above the prime tower. Filament ramming is disabled, cooling tube position, length, parking position and extra loading distance are all 0 Project file: Notice the below issues:
Number (2) and (3) are an issue because when invoking Tx mid way through an extrusion you get a bit of ooze from the nozzle. When you then go to resume mid way through the extrusion you get a small "bulge" that is printed on the tower. In 2.1.1 these little bulges were at the perimeter of the tower and did not matter as the nozzle de-retracted right outside the tower and started printing the purge lines with a clean nozzle. Basically we should be printing complete layers like 2.1.1 and not purge the previous material on the tower at all when ramming is disabled. Project file above should showcase these differences between 2.2 and 2.1.1 |
Yes, there is a slight behavior change. |
I'm pretty sure it always went to the edge to tool change - haven't noticed before even with multiple color changes the "in the middle of the tower" tool change. I'll make the changes on ramming and will do some deeper inspection next :) |
OK, found why the nozzle crash issue - This is forcing a Z move to the wrong layer height. @SoftFever any hint why this was added? |
OK amended the PR above to include fixes for both. But for the nozzle crash I am really not sure whether that is the right fix.... :) |
@igiannakas Feedback re change of visibility for "Prime all printing extruders" for SEMM printers. Shouldnt it also be explicitly set to false/disabled in addition to making the UI setting invisible? I've recently upgraded to 2.2.0 GA and it now always primes all extruders regardless and don't have the option to disable it since its hidden. You can also still search for the setting but not locate it in the UI. Perhaps disabling the UI control rather than hiding it is a better option? |
You’ve probably inherited this by having it enabled when it was visible. Best way around it is to edit the printer config file in your local - roaming directory |
@igiannakas Ive never set it although one of the prerelease versions may have enabled it. Update: looks like it defaults to on as single_extruder_multi_material_priming = 1 was set on all my process profiles including profiles for non mmu printers. Based on this, I can only assume that it defaults to on. Hiding and disabling it without setting it to false is likely going to cause issues. |
Description
Fix a bug where the wipe tower has missing extrusions when ramming is disabled.
Additionally, this update improves the logic for the 'Enable Filament Ramming' feature. We no longer need to set the cooling parameters to 0 to completely disable ramming.Update: there is a issue, you still need to set "Filament Parking Position" to 0 if you want to turn off ramming.
Screenshots/Recordings/Graphs
Before:
After fix:
Tests