[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. https://github.com/MarlinFirmware/Marlin/blob/a4d6908d556afd77cf66ef7a8adc7c34fee81674/Marlin/Configuration_adv.h#L1204

[rhapsodyv]

Default is a G28XY If printing from SD.

https://github.com/MarlinFirmware/Marlin/blob/a4d6908d556afd77cf66ef7a8adc7c34fee81674/Marlin/Configuration_adv.h#L1204

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?

[pixelicous]

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?

So i've set it in octo, didn't reboot the raspberry and started the print After cancelling the printer didn't home its axis at all, stayed at the same place. I've tried moving Z axis afterwards, both Z axis and extruder moved as before Tried this twice

I wasn't using your branch this time, as i've already reverted to the firmware file i've been using before (bugfix2.0 branch from around a month ago)

[rhapsodyv]

So, octoprint ignored the cancel gcode?! Can you share the serial, so we can see what it sent?

[pixelicous]

@rhapsodyv yes seems like it.. I will test it tomorrow or in 2 days and let you know

[jojolll]

So, octoprint ignored the cancel gcode?! Can you share the serial, so we can see what it sent?

Hello! I currently have a very very similar concern without using octoprint. On the other hand, I have ESP3D connected to the serial port.

In my opinion, the problem is not due to the fact that I have a XY homing after the cancellation, everything is fine until a movement is requested by the screen. In my case it's the Y axis, I set it to 230 and it ejects the filament through the extruder. I didn't try the other axes.

I even have the impression that the extruder does not even respect its steps/mm since it ejects me the totality of the filament present in the bowden tube (415mm if I take it out automatically by the extrusion motor) (Marlin 2.0.7.2)

EDIT : After a few tests, the problem also appears just after the end of a successful print, under the same conditions. The Z-axis as well as the Y-axis cause the problem. I have the impression that the extruder moves backwards by a constant amount, regardless of the demand for Z or Y movement.

[pixelicous]

@rhapsodyv

So, octoprint ignored the cancel gcode?! Can you share the serial, so we can see what it sent?

Pasted below: Changing monitoring state from "Printing" to "Cancelling" Recv: ok Send: N24 M10828 Recv: ok Send: N25 M117 0% L=0/37092 [...] Recv: ok Send: N26 M410 //quickstop_stepper69 Recv: ok Send: N27 M104 T0 S020 Recv: ok Send: //probably M81? Send: N28 M140 S095 Recv: echo:Unknown command: "//probably M81?" Recv: ok Recv: ok Send: N29 M106 S092 Send: N30 M108*25 Recv: ok Recv: ok ` @jojolll Interesting, is this on ender 3 v2? your issue is different a bit, I have no trouble moving the Y axis, only the Z axis, and i dont have it after a successful print, only after cancellation

[jojolll]

@jojolll Interesting, is this on ender 3 v2? your issue is different a bit, I have no trouble moving the Y axis, only the Z axis, and i dont have it after a successful print, only after cancellation

Yes it is also on an Ender 3 V2! And I noticed that it is not systematic on a successful print, maybe I had cancelled a print before ?

In any case the problems seem to be close ! And I tried quickly but the X axis doesn't seem to trigger any problems.

EDIT : Now that I see your answer, I too have seen some "Unknown Commands" on my serial interface.

[pixelicous]

@jojolll the unknown commands are only there as i was requested to change the octoprint cancel messages My issues are also not from moving the X axis, but the Z axis.

[pixelicous]

I never tried this before, i just confirmed, this issue also happens when moving X axis straight after cancel print. I just had all my filament thrown out on this test.. and i dont even think i've set the x axis to move that much..

[pixelicous]

@signetica you pitched in on #19644 and it just closed, maybe you can pitch in here as well

[andersp5]

Have had a similar problem but with Y axis, I moved the bed from zero by 100 to bring bed to the front and the Extruder ejected the filament at great speed. Also if you put a value of more than -100 in to extract the filament it will not work put -50 in and it does and then sometimes even with a negative value it goes forward instead of backwards, this only happens on V2.0.7.2 not V2.0.6.0.

[CRCinAU]

I've still had a report or two around this issue after October - was there any suggestions on this? Is something doing an absolute move when it should be doing a relative move?

[thinkyhead]

Unfortunately "a report or two around this" is not enough data to proceed upon. Please bring more data exhibiting the issue in a reproducible form, based on the current codebase.

[CRCinAU]

The latest report was with bugfix-2.0.x dated 2020-12-23 - report was:

After canceling a print and then using the "move z" command in the prepare menu, it ejects all the filament as well as moving the z axis.

What specifics do you want to be able to be provided to assist? I can attempt to get more info if I know what you're looking for...

EDIT: I would guess it would be this code path in the DWIN code? https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/dwin/e3v2/dwin.cpp#L1205

But also, this looks strange to me - I'm not sure why it treats E differently? I'm guessing its trying to set to relative so E moves will always start at 0 and be a +/- movement instead of absolute? https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/Marlin/src/lcd/dwin/e3v2/dwin.cpp#L2326

[andersp5]

I have not tried the latest bug fix dated 2020-12-23 are you perhaps indicating this may have fixed it?

If it hasn’t, I will try and give you exactly what happens in more detail, the sequence of operation that causes it, but this will now have to be in the New year, if that’s OK then you may be better able to help with this.

Thanks

Sent from Mail for Windows 10

From: Steven Haigh Sent: 24 December 2020 10:31 To: MarlinFirmware/Marlin Cc: andersp5; Comment Subject: Re: [MarlinFirmware/Marlin] [BUG] Ender 3V2 - Moving Z after calledprint also moves extruder (#19944)

The latest report was with bugfix-2.0.x dated 2020-12-23 - report was: After canceling a print and then using the "move z" command in the prepare menu, it ejects all the filament as well as moving the z axis. What specifics do you want to be able to be provided to assist? I can attempt to get more info if I know what you're looking for... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

-- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

[Syntax-Er]

Have experienced this problem at least 3 times in last week, was unaware why my printers bowden tube had clogged multiple times. Had to replace the tube each time which gets expensive using Capricorn tube. I finally caught the extruder moving backwards as the printer returned home at the beginning of a new print, but after a cancelled print.

I cancelled the print from the Octoprint web GUI, and then started a new print with hotend in the Z position from which the cancelled print was stopped. After reaching temp, the hotend starts to move back to the home position 0,0,0, and the extruder is retracting filament the entire time.

The first couple times it happened I was using firmware from 11-18-20, but since updating the printer to a firmware from 12-24 I am still experiencing the issue. I just caught it doing it again a few minutes ago.

Im using Marlin Firmware: 12-24-20 Printer: Ender 3 V2 Controller: Creality 4.2.2 board Slicer: Cura 4.8 Server: Octoprint 1.5.1 Mods: BLTouch 3.1 (connected to 5 pin header)

[thinkyhead]

@Syntax-Er — Does your file's Starting G-code (from Cura) do anything to reset the E position to 0, such as a G92 E0 or a G28? If you don't include this then the printer will simply continue from the last state it was in.

[Syntax-Er]

@thinkyhead yes.. it resets the E to 0 twice.. once before it purges and again before it moves to start the print.

; Ender 3 Custom Start G-code G92 E0 ; Reset Extruder G28 ; Home all axes M420 S1 Z2 ; Enable Leveling G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed G1 X0.1 Y20 Z0.3 F5000.0 ; Move to start position G1 X0.1 Y200.0 Z0.3 F1000.0 E15 ; Draw the first line G1 X0.4 Y200.0 Z0.3 F5000.0 ; Move to side a little G1 X0.4 Y20 Z0.3 F1000.0 E30 ; Draw the second line G92 E0 ; Reset Extruder G1 Z2.0 F3000 ; Move Z Axis up little to prevent scratching of Heat Bed G1 X5 Y20 Z0.3 F5000.0 ; Move over to prevent blob squish

[Syntax-Er]

I managed to catch it doing it again.. This time I cancelled a print... and then manually moved the hotend to Z-200 using the LCD controller on the printer.. as it was traveling upward the extruder was retracting.. I video'd it as well..

https://www.youtube.com/watch?v=adrWItihqE4

[rhapsodyv]

I managed to catch it doing it again.. This time I cancelled a print... and then manually moved the hotend to Z-200 using the LCD controller on the printer.. as it was traveling upward the extruder was retracting.. I video'd it as well..

https://www.youtube.com/watch?v=adrWItihqE4

What is you cancel gcode on octo? It should have G28 XY to reset marlin to a good state.

[Syntax-Er]

What is you cancel gcode on octo? It should have G28 XY to reset marlin to a good state.

@rhapsodyv I just have the default cancel code Octoprint comes preconfigured with.. ; disable motors M84

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

[Syntax-Er]

@rhapsodyv I added G28 XY ; Home X&Y G1 Y200 ; Move Bed Forward For Print Removal At the end of the cancel script, restarted Octoprint after the change, ran a print, cancelled via Octoprint, and then moved the Z to 100 and the extruder stayed still this time.. Going to try it with just the G28 X; and G1 Y200 and see if it continues to fix the issue..

Update: Problem came back this morning while trying to fix extrusion issues, I raised the nozzle to extrude some filament, and nothing came out.. looked and saw 5 inches of filament with gear marks hanging out the side the extruder..

[thinkyhead]

It's interesting. If you execute a move with G1 instead of doing a manual move from the LCD do you also see extruder movement?

[rhapsodyv]

Another interesting test is add G92 E0 to your cancel gcode on octo print, and see if the problem happens too.

[CRCinAU]

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