[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

[sjasonsmith]

How do you observe E moving? Maybe it is just oozing while everything is hot?

[pixelicous]

@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

[liamtoran]

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)

[pixelicous]

@liamkesatoran I tested today, If you home x/y (octoprint) before moving Z then it won't take out the filament..

[boelle]

@pixelicous i think a video will be good in this case

[pixelicous]

@boelle @sjasonsmith Attached video - https://youtu.be/LNKouvYJv7E

I tried homing / moving Z from lcd menu, this resulted in the same thing..
So only homing/moving from octo worked after cancel, I didn't try homing from octoprint but moving Z from lcd menu

[pixelicous]

@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

[chevyman142000]

I am also having this same issue. More than glad to help troubleshoot if you need anything.

[sjasonsmith]

It would help if you can try an older version such as 2.0.6.1, to determine whether this problem is new.

[rhapsodyv]

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?

[rhapsodyv]

@pixelicous can you do a simple test with this branch? https://github.com/rhapsodyv/Marlin/tree/dwin-move-axis-fix It just a "try".

[FanDjango]

Could you also check what is coded in the Octoprint Setup for "GCODE Scripts" for when a print is cancelled?

[rhapsodyv]

@pixelicous can you do a simple test with this branch? https://github.com/rhapsodyv/Marlin/tree/dwin-move-axis-fix It just a "try".

No one having the issue could test this?

[liamtoran]

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?

For me it has happened even though I never used Octoprint.

[pixelicous]

sorry for not being responsive
@sjasonsmith It happened also on 2.0.6.1
@rhapsodyv it also happened without octoprint before. i dont remember the results of the two other questions but i can test tomorrow. It will be possible to test the branch in a day or two
thanks for looking at this 👍

[rhapsodyv]

Hi @pixelicous, did you tried my branch? Thanks!

[pixelicous]

@rhapsodyv Sorry, I didn't have time to check it out till today-

So i did a couple of tests

1. Start print > Stop from octoprint > Move Z axis from printer
   result: same problem, extruder moves the same amount as z axis

2. Start print > Stop from octoprint > Move Z axis from octoprint
   result: Z axis move as expected and extruder moves for a very quick duration (like 2ms) and then stops. Not sure if this is the same issue where the extruder moves again but then halted for some reason, or just normal operation where a retraction happens before the heatblock moves up on z axis

3. Start print > Stop from octoprint > Move Y axis from printer screen then try to move Z from printer screen
   result: only the z axis moves, no issues with extruder

@FanDjango This is the gcode script ran after job is cancelled (From octoprint):

; disable motors
M84

;disable all heaters
{% snippet 'disable_hotends' %}
{% snippet 'disable_bed' %}
;disable fan
M106 S0

[rhapsodyv]

@rhapsodyv Sorry, I didn't have time to check it out till today-

So i did a couple of tests

1. Start print > Stop from octoprint > Move Z axis from printer
   result: same problem, extruder moves the same amount as z axis
2. Start print > Stop from octoprint > Move Z axis from octoprint
   result: Z axis move as expected and extruder moves for a very quick duration (like 2ms) and then stops. Not sure if this is the same issue where the extruder moves again but then halted for some reason, or just normal operation where a retraction happens before the heatblock moves up on z axis
3. Start print > Stop from octoprint > Move Y axis from printer screen then try to move Z from printer screen
   result: only the z axis moves, no issues with extruder

@FanDjango This is the gcode script ran after job is cancelled (From octoprint):

; disable motors
M84

;disable all heaters
{% snippet 'disable_hotends' %}
{% snippet 'disable_bed' %}
;disable fan
M106 S0

Thanks for the tests! We are almost there. Two things:

1. Did you test using bugfix, or my branch? ( https://github.com/rhapsodyv/Marlin/tree/dwin-move-axis-fix)

2. Can you add G28 at the end of gcode for canceled scripts and test again?

Thanks!

[pixelicous]

@rhapsodyv

1. your branch
2. yes, will do it tomorrow morning hopefully :) but if i am not mistaken i already tested homing from octoprint and then moving the y axis from the screen and it was OK, no issues with extruder starting as well

[rhapsodyv]

2. yes, will do it tomorrow morning hopefully :) but if i am not mistaken i already tested homing from octoprint and then moving the y axis from the screen and it was OK, no issues with extruder starting as well

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.

[pixelicous]

1. yes, will do it tomorrow morning hopefully :) but if i am not mistaken i already tested homing from octoprint and then moving the y axis from the screen and it was OK, no issues with extruder starting as well

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..

[rhapsodyv]

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)

[thisiskeithb]

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.

Isn't that a bad idea if you have a half-completed print on the bed and you cancel?

[rhapsodyv]

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.

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.

[thisiskeithb]

Default is a G28XY If printing from SD.

Marlin/Marlin/Configuration_adv.h

Line 1204 in a4d6908

#define EVENT_GCODE_SD_ABORT "G28XY" // G-code to run on SD Abort Print (e.g., "G28XY" or "G27")

[rhapsodyv]

Default is a G28XY If printing from SD.

Marlin/Marlin/Configuration_adv.h

Line 1204 in a4d6908

#define EVENT_GCODE_SD_ABORT "G28XY" // G-code to run on SD Abort Print (e.g., "G28XY" or "G27")

Exactly!

Plus M410 (quickstop_stepper()) and M108.

Marlin does something like this on a SD print abort:

M410  //quickstop_stepper
{% snippet 'disable_hotends' %}  //probably M81?
{% snippet 'disable_bed' %}
;disable fan
M106 S0
M108
G28XY  //home xy -> EVENT_GCODE_SD_ABORT

@pixelicous can you try this?

[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.

[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]

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]

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.