-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
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] Ender 3V2 - Moving Z after called print also moves extruder #19944
Comments
How do you observe E moving? Maybe it is just oozing while everything is hot? |
@sjasonsmith sorry for not being clear on this, the extruder actually moves back, minus of the same amout I guess, it retracts in the same amount.. I see the filament shooting out.. I can take a video of this happening if needed.. Just start a print, cancel it and it will happen |
Same exact behavior for me. For me the extruder retracts like crazy when moving Z up (There is a knob and it turns counterclockwise, its not oozing) |
@liamkesatoran I tested today, If you home x/y (octoprint) before moving Z then it won't take out the filament.. |
@pixelicous i think a video will be good in this case |
@boelle @sjasonsmith Attached video - https://youtu.be/LNKouvYJv7E I tried homing / moving Z from lcd menu, this resulted in the same thing.. |
@sjasonsmith Thanks for labelling this, hopefully somebody will pick this up.. it can be very problematic.. would have helped myself if i knew where to look, never code anything on marlin firmware |
I am also having this same issue. More than glad to help troubleshoot if you need anything. |
It would help if you can try an older version such as 2.0.6.1, to determine whether this problem is new. |
It only happen with printing started / cancelled using OctoPrint? If you start/stop the print from the LCD, do you get the same behaviour? If you start/stop the print from the Octoprint and try to move using Octoprint interface, do you get the same behaviour? |
@pixelicous can you do a simple test with this branch? https://github.com/rhapsodyv/Marlin/tree/dwin-move-axis-fix It just a "try". |
Could you also check what is coded in the Octoprint Setup for "GCODE Scripts" for when a print is cancelled? |
No one having the issue could test this? |
For me it has happened even though I never used Octoprint. |
sorry for not being responsive |
Hi @pixelicous, did you tried my branch? Thanks! |
@rhapsodyv Sorry, I didn't have time to check it out till today- So i did a couple of tests
@FanDjango This is the gcode script ran after job is cancelled (From octoprint):
|
Thanks for the tests! We are almost there. Two things:
Thanks! |
|
What is happening is that when we cancel a print from Octo (without G28), Marlin stays in a total unpredictable state. That is the reason the axis move together. In my branch, I'm trying to work around it, but the "correct" way would be: always do G28 when a print is canceled. Marlin does that, when you print from SD. I think Octo should to it too. |
I'll try to print from marlin directly and sd, then cancel and see what happens. if i remember correctly it didn't happen only with octoprint.. need to check though. also.. how can we explain the fact that moving the Y axis, just after that cancelled print, only the y axis move and not the extruder, while moving the Z axis move both.. |
I don't have any idea, yet hahaha. I'm trying to fix things that could generate this problem, but I can't reproduce it (I don't have a ender v2) |
Isn't that a bad idea if you have a half-completed print on the bed and you cancel? |
Yes, you are right. G28 is a terrible idea. Let me take a look in what marlin actually does. |
Default is a Marlin/Marlin/Configuration_adv.h Line 1204 in a4d6908
|
Exactly! Plus Marlin does something like this on a SD print abort:
@pixelicous can you try this? |
Tonight I had a first layer that didnt extrude properly.. I cancelled the print via Octoprint.. I don't remember exactly what I did next, but it caused the extruder to retract a little filament slowly.. it appeared to be about the same amount of filament it had tried to extrude before I cancelled the print.. The next thing I did was I press the extruder lever, feed the half inch or so of filament back into the hotend, and noticed the LCD was reading the E position as 0.00 at this point.. I dialed it up to 5.00 and pressed the button expecting to prime the hotend again, but instead it started moving in reverse again.. this time more than 5mm.. as if the lcd was reading 0 but the printer thought the count was still at 20 or something.. it began retracting a good amount of filament very slowly.. I waited a few seconds but eventually killed the power to the printer, at which point I had to remove the bowden tube again, and slowly pull the clog all the way thru.. got lucky this time, it was a brand new capricorn tube and I was able to get the clog thru without breaking the filament.. But this is pretty much a constant thing, after a cancelled print, using the LCD to move any of the steps including the extruder can cause it to retract. |
I think @CRCinAU is onto something when he said;
In my testing in my previous post I showed that this happens even when first powering the printer on and not just at the end of prints. The reason it only seems to be detected at the end of the prints is that the nozzle is warmed up. If the nozzle is too cold, Marlin doesn't move the extruders, but if you heat the nozzle you will see it constantly reverse the previous extruder move the first time you enter the Prepare-move menu and move any axis. I've been trying to dig through the code and find the bug, but I'm not real familiar with the code and it looks like the code for the "standard" marlin UI is a bit different so there isn't much for me to compare it to. Hopefully someone in here can locate it and offer a possible fix. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I’ve hidden several of the recent posts to avoid distracting from the actual bug discussion. |
Well, I think I found the origin of the problem with the Ender3 V2 reversing the last extruder move (only if the nozzle is above minimum temp) when the Prepare-move menu is used to move any other axis I believe it is caused by line 2325 in dwin.ccp https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/dwin/e3v2/dwin.cpp#L2325 Specifically it seems to be caused by;
where it is constantly resetting the extruder's current position to 0. By eliminating the "=0" at the end so it reads;
the printer no longer reverses the previous extruder move anytime you enter the prepare-move menu and move aother axis. And by changing the following line (2326) to read;
the menu will show the current extruder position when you first enter the prepare-move menu, but it is reset to 0 anytime you click on the move E menu. I suspect that is from line 2324, which I don't know if we really need in the code. https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/dwin/e3v2/dwin.cpp#L2324 I hope one of the main developers can look this information over and verify if it will work. I don't know if it may cause unintended consequences. I am not a programmer and only have a very basic understanding of C++ and other languages. I was trying to compare the code to the code used in the standard marlin UI used on displays like the Reprap Discount Full graphic controller, but the numerous different functions/variables used in that code to adapt it to so many different displays made it difficult for me to follow. This seems to be working on the Ender3V2 I am using but I haven't done extensive testing yet. |
I'm about to post a PR. |
I would love to help, but I'm not super comfortable compiling firmware. If there is anything I can do to help, please let me know. Thanks! |
Thanks, I'm really not familiar with the process on Github so I'd definitely prefer someone else take a look at it to verify it and also see if we still need line 2324;
in there as well. My other printers with the full graphic smart controller never bother resetting the extruder position in the move menu but I don't know if that is still needed with the issues others were having. I also think line 2326 could be simplified as;
it looks like it reports the correct value without having to multiply it by MINUNITMULT (which has a value of 10) and then redivide it by 10. |
Sometime ago a posted a branch to force |
I'm not sure why the G92 doesn't work, but replacing it with a different call to update the planner position seems to resolve the issue. I think it is best to continue to reset the extruder to 0 when doing manual moves. X/Y/Z have finite bounds, but the extruder might have very large values depending on previous printer activity. Please test the change I posted, and reply to the PR whether it works for you or not. |
I don't see the point of this honestly. That is not the normal behavior when using the "standard" Marlin UI that has been used on countless printers for years now. The "PREVENT_LENGTHY_EXTRUDE" function if enabled should prevent any major issues when manually jogging the extruder. While the MarlinUI code is really confusing to someone like me not familiar with it, I really think we should aim to replicate the same behavior across displays when using MarlinFW. |
Honestly, I don't really care either way. I don't use this display anyway. I fixed the immediate bug without changing any of the expected behavior. |
Actually, I just tested with a RepRapDiscount Full Graphics display, and it does reset E to 0.0 each time I start a new move. |
I'm getting ready to upload your fix and see if it works for me. I thank you for taking the time to look into this. I'm not a programmer by trade and while I am familiar with compiling Marlin firmware, a lot of the activity "under the hood" is still foreign to me. It doesn't matter to me either way as well, and I know Thinkyhead has started a Alpha build on porting the standard marlin UI fucntions to the DWIN display so it might eventually make no difference. I just think most people would like to expect the same behavior regardless of the displays they use.
Both my printers with RepRapDiscount Full Graphics displays show the Extruder at 0 the first time I enter the prepare-move screen, but after that maintain the relative coordinates no matter how many times I exit and return to the menu. They only resets to 0 when ending a print or rebooting the printer. |
I don't know why we are seeing different behavior. Maybe there is a config option somewhere we have different. |
Possibly. My other 2 printers have an older version of marlin on them but the Extruder position has never constantly reset to 0 every time one enters the Prepare-move menu, so if that is the expected behavior it is new to me. Just uploaded the firmware with your fix... It seems to have solved the inadvertent extruder movement when jogging other Axis on this Ender3V2 I'm testing. Hopefully others will test it and give their blessing as well. Thanks again for coding it the "right way" :) |
I was having the exact same problem-- extruder would eject a ton of filament when I moved the Z after a print. Applied your changes this afternoon and I cannot reproduce the problem any longer. |
@sjasonsmith Thx for this.. i'll try updating to this firmware in the next 2 days |
I solved this by adding this |
This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Bug Description
Working with ender 3v2, using latest bugfix branch when cancelling a print, moving Z axis will also move the filament (it moved the extruder in the same amount).
Another move of Z axis will not do it again.
This happened in 2.0.7, later i reverted to creality's firmware, but now after installing bltouch i put bugfix 2.0.x and i see this hasn't been solved.
#19644 < Posted here before
Configuration Files
Archive.zip
Steps to Reproduce
Expected behavior:
Only the Z axis should move
Actual behavior:
Z axis move and extruder moved as well
Very problematic as this can harm printers, the nozzle might not be hot enough, it can also cause jam inside the bowden tube (which it did for me) and it can make a mess of the spooler as it throws out the filament very quickly
The text was updated successfully, but these errors were encountered: