[BUG] Ender 3V2 - Moving Z after called print also moves extruder

[pixelicous]

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

1. Start a print
2. Cancel (I cancelled using octoprint's interface)
3. Using printer interface I tried to move Z axis (I usually do it to clean the bed surface)

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

[rhapsodyv]

Sorry, as I posted earlier, doesn't this G92 E0 run on all LCD movement requests?

https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/dwin/e3v2/dwin.cpp#L2326

I don’t know how the code paths are executed in this code. I don’t have this screen.

The purpose of the test is just to be sure that the G92 E0 is executed.

[andersp5]

As promised, downloaded and updated the printer firmware with the latest bugfix 2.0 and so far it appears to have fixed my problem with the extruder. I hope this helps.

[Bluelinegecko]

Just checked with the latest bugfix on 1/5/2021 on an Ender3 V2. Ran a short test print from the SD card. Cancelled using the DWIN controller to stop the print. When I moved the Z axis up afterwards it still retracted the filament approximately the same distance.

[thinkyhead]

When I moved the Z axis up afterwards

Did you use the move menu or did you send a G1 command? These follow different code paths.

[Bluelinegecko]

When I moved the Z axis up afterwards

Did you use the move menu or did you send a G1 command? These follow different code paths.

I used the move menu on the DWIN display. Thanks for looking into this thinkyhead

[Syntax-Er]

thinkyhead 50% of the time the issue occurs Im using the LCD to move the hotend.. the other 50% its retracting during the homing procedure at the beginning of a print.

UPDATE I reflashed my firmware a few nights ago, and before even printing once, and having completely powered the printer off after the flash.. I turned the printer on, and moved the hotend X and then Z, and the extruder retracted all the filament out at a high speed.. So that kinda blew my theory it was cancelled print related.. so now I have no idea..

[CRCinAU]

Can we get an exact step list?

I just updated to 20210107 bugfix, then went: 1) Control -> Temperature -> Hotend temp and set to 190 2) Prepare -> Auto home 3) Control -> Move -> X set to 20 4) Z to 50 (no E movement) 5) X set to 200 6) Z to 100 (no E movement)

As such, the above didn't reproduce the fault. Can you document a reproducible scenario?

EDIT: But screwing around - I just managed to make the E motor rewind by moving the X from 130 -> 100...... Interesting....

[CRCinAU]

I notice there's certainly an issue with E positioning - as if you set an E value, go back a menu, then set a different E value - it acts like they are absolute requests - not relative - so setting E10, back, set E-10 will move backwards 20mm...

I can only assume something like this is happening - but at a faster move rate when something else triggers off....

[CRCinAU]

@thinkyhead / @sjasonsmith (or whoever) - when a combined X / E movement happens - say it has to move 30mm on X, but 100 on E, that'll speed up the E movement, right?

I wonder if the root cause here is that the extruder is being treated as relative movement by the menu - but is in absolute mode when trying to do the moves - hence a 50mm movement of X / Y / Z could cause whatever E value is to go to zero if prompted by that screen...

Is this consistent with expected behaviours?

ie: 1) Print starts 2) Print continues and causes E counter to increase 3) Menu based Move sets E0 - which causes the E motor to unwind everything that's been already printed.

[ct16k]

I have an Ender 3 V2 with Creality 4.2.2 board, and it's very easy to reproduce for me with the display (not using octoprint at all, only printing from SD card):

1. Cancel a print
2. Auto-home from Prepare menu

The extruder will move backwards for the same amount of time as the Z takes to go from its current position to 0.

I am currently at ba2cadb47934fa83f576aece2c45f1b6cb5829cf on the bugfix-2.0.x branch.

[Bluelinegecko]

Is this consistent with expected behaviours?

ie:

1. Print starts
2. Print continues and causes E counter to increase
3. Menu based Move sets E0 - which causes the E motor to unwind everything that's been already printed.

That could be. I only tested it a few times but everyone seems to report that the extruder move is always a retraction as far as I have read.

The DWIN menus are definitely a source of frustration and I know thinkyhead and others have some alpha/beta versions out the including an attempt to replicate the standard MarlinUI on the display. Some of the macros programmed into the Creality DWIN like turning off the heaters when one pauses a print from the menu, are annoying. A lack of flow tuning and other "standard" menu items are equally disappointing. I have no doubt an eventual Marlin Team UI for this display will be thousands of times better than Creality's effort.

[Bluelinegecko]

I notice there's certainly an issue with E positioning - as if you set an E value, go back a menu, then set a different E value - it acts like they are absolute requests - not relative - so setting E10, back, set E-10 will move backwards 20mm...

I can only assume something like this is happening - but at a faster move rate when something else triggers off....

I can confirm this as well. I just tested without even running a print. Happens for me when moving any axis not just the Z.

Steps to reproduce:

1. Turn on printer.
2. Heat hotend up beyond minimum extrusion temperature.
3. Move Extruder +40mm using Prepare-Move menu
4. Go back to previous menu
5. Return to Move Axis menu
6. Move either X,Y,or Z axis and Extruder retracts -40

The total distance appears to be to total of the last Extruder move, but as it is synchronized to the move on the X,Y,Z axis the speed of the extruder move varies. Extruder will reverse the previous movement on the next move command. If I retract the extruder 20 mm and return to the menu it will advance 20mm on the next move of any axis. If I advance the filament 20mm and return to the menu it will retract 20mm on the next move. Subsequent moves have no effect on the E axis until the E axis is moved again and one exits/returns to the return menu.

I also notice that anytime I go back a menu and return, the Extruder position is reset to 0 on the screen, where as the X,Y,Z positions remain at the value they were at last. On my other printers using the Reprap discount full graphic controller, i believe the extruder move menu always shows the current coordinates when returning to previous screens until the E is zeroed out when starting a print, homing, etc.

[abdebadie]

Le jeu. 7 jan. 2021 à 08:39, Bluelinegecko notifications@github.com a écrit :

Is this consistent with expected behaviours?

ie:

1. Print starts
2. Print continues and causes E counter to increase
3. Menu based Move sets E0 - which causes the E motor to unwind everything that's been already printed.

That could be. I only tested it a few times but everyone seems to report that the extruder move is always a retraction as far as I have read.

The DWIN menus are definitely a source of frustration and I know thinkyhead and others have some alpha/beta versions out the including an attempt to replicate the standard MarlinUI on the display. Some of the macros programmed into the Creality DWIN like turning off the heaters when one pauses a print from the menu, are annoying. A lack of flow tuning and other "standard" menu items are equally disappointing. I have no doubt an eventual Marlin Team UI for this display will be thousands of times better than Creality's effort.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/19944#issuecomment-755943481, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJK3MCY7BF4ELBYXM23Y4Q3SYVQJTANCNFSM4TDVQ7YQ .

[Syntax-Er]

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.

[Bluelinegecko]

I think @CRCinAU is onto something when he said;

I wonder if the root cause here is that the extruder is being treated as relative movement by the menu - but is in absolute mode when trying to do the moves - hence a 50mm movement of X / Y / Z could cause whatever E value is to go to zero if prompted by that screen...

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.

[omgsh]

How is it possible this has been an issue since October?

[omgsh]

@omgsh Some maths... very approximate. 500+ issues and feature requests, 1 full time programmer/administrator. 2-5 professional programmers (with real jobs and other obligations), 5-20 part time amateurs doing their best. All but one are volunteers. See the issue? Learn to code and help. Please don't waste our time on disparaging remarks.

Please don't reprimand me for something you assumed I intended to mean. That would be like me congratulating you for doing a good job, See the issue?

If you don't want to answer the question, you can allow someone who actually wants to be here to step into your role.

[CRCinAU]

Those who offer the least always make the most noise....

[omgsh]

Those who offer the least always make the most noise....

I'm not saying you are a troll, this is just very trollish. Do you live under a bridge? Do you have little to do and often find yourself spending time putting your opinion in on things where no one asked you to? Or, Are you hoping someone here will find you witty enough to let you eat their box? The reality is, you go out of your way to run your mouth on the internet because you can't deal with the fact that you would never do so in person. ='(

[sjasonsmith]

I’ve hidden several of the recent posts to avoid distracting from the actual bug discussion.

[Bluelinegecko]

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;

                  current_position.e = HMI_ValueStruct.Move_E_scale = 0;

where it is constantly resetting the extruder's current position to 0.

By eliminating the "=0" at the end so it reads;

              current_position.e = HMI_ValueStruct.Move_E_scale;

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;

      DWIN_Draw_Signed_Float(font8x16, Color_Bg_Black, 3, 1, 216, MBASE(4), current_position.e * MINUNITMULT / 10);

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.

[sjasonsmith]

I'm about to post a PR.

[chevyman142000]

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!

[Bluelinegecko]

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;

      queue.inject_P(PSTR("G92 E0"));

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;

DWIN_Draw_Signed_Float(font8x16, Color_Bg_Black, 3, 1, 216, MBASE(4), current_position.e

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.

[rhapsodyv]

Sometime ago a posted a branch to force G92 E0, right before that assignments to zero. Some has tested and said it didn't solve the issue...

[sjasonsmith]

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.

[Bluelinegecko]

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.

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.

[sjasonsmith]

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.

[sjasonsmith]

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.

[Bluelinegecko]

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.

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.

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.

[sjasonsmith]

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. That was on a printer which I just updated to the latest bugfix-2.0.x changes today.

[Bluelinegecko]

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" :)

[harbinger1080]

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.

[pixelicous]

@sjasonsmith Thx for this.. i'll try updating to this firmware in the next 2 days

[dimonoid]

I solved this by adding this G92 E0 ; Reset Extruder at the end after each print in Cura.

[github-actions[bot]]

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.

[github-actions[bot]]

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.