Ender3V2S1 icon indicating copy to clipboard operation
Ender3V2S1 copied to clipboard

Head doesn't park after Filament change is triggered

Open akavoukis opened this issue 2 years ago • 6 comments

Describe the bug When issuing command M600 (filament change) the head doesn't move out of the current position to change filament.

To Reproduce Steps to reproduce the behavior:

  1. Send code M600, will also work when specifying values e.g. M600 E30.00 U300.00 X0.00 Y0.00 Z100.00
  2. The filament change procedure is starting but without first moving the nozzle away from the current position.
  3. The Display is showing "Head cannot be parked"

Expected behavior The nozzle should move away from current position.

Version (please complete the following information): 2.1.3 20221222 Ender3S1-F4-UBL

Additional context I had a quick look at the the code and I can see that this is happening because that bool is probably false const bool do_park = !axes_should_home(); But not not sure if it is expected behaviour. file "src/feature/pause.cpp"

akavoukis avatar Jan 08 '23 21:01 akavoukis

The printer MUST know the current axes position before to go to the park position. Therefore, it is important that the printer axes have been homed before, you can check that by looking at the screen showing axes values in the dashboard without blink.

mriscoc avatar Jan 10 '23 14:01 mriscoc

Yes it makes sense it should know where to return. But is this expected behaviour ?

And if so how can we force the parking on M600. Currently after M600 the nozzle stays on top of the print and purges the filament on top of the last position.

akavoukis avatar Jan 10 '23 14:01 akavoukis

The important question is why the printer doesn't know the current position, maybe the axes stepper drivers were disabled.

mriscoc avatar Jan 11 '23 08:01 mriscoc

I don't think this could have happened in my case because the M600 command injected as part of my gcode file. I have also tried later (after I discovered the issue) to send M600 while on standby and I could see the same behaviour.

Below there is a snippet from my gcode file that didn't park the head.

G0 F300 X167.696 Y121.058 Z2
G0 F9000 X35.87 Y121.389
G1 F2400 E1512.72025
G0 F9000 X35.6 Y121.775
;TIME_ELAPSED:1894.404147
M600 E30.00 U300.00 X0.00 Y0.00 Z100.00 ; Generated by FilamentChange plugin

akavoukis avatar Jan 15 '23 11:01 akavoukis

Additional context I had a quick look at the the code and I can see that this is happening because that bool is probably false const bool do_park = !axes_should_home(); But not not sure if it is expected behaviour.

Here Marlin asks if the axes are in trusted state or if any axis should be hommed. The normal behavior is that if you are printing, all axes are trusted, so the printer can park the head.

mriscoc avatar Jan 16 '23 00:01 mriscoc

Below there is a snippet from my gcode file that didn't park the head.

But before of the movements, were the axes in trusted state or not?

When the axes are not trusted you can see their current position in the dashboard without blink to --?--

mriscoc avatar Jan 16 '23 00:01 mriscoc

No more feedback

mriscoc avatar Mar 13 '23 05:03 mriscoc

I'm not sure what it means for this to be a "known issue" but the github issue is closed. Does it mean you have made a fix in the code but it's not yet released? Or that it's a known issue in Marlin? Or something else?

Anyhow, FWIW, I see this behavior, too. My filament change is inserted by PrusaSlicer, and AFAICT that hasn't changed. The behavior described in this issue started when I upgraded to the Spring 2023 firmware release (I had skipped a couple of upgrades before that).

wjcarpenter avatar Apr 09 '23 23:04 wjcarpenter

I observed a little more carefully today.

I explicitly homed before printing (Prepare > Homing > Autohome). As expected, all 3 axes values on the display stopped blinking the "-?-". Then I queued a print. The print head travelled to the front left corner, as usual, to wait for the heat to come up. Because I was printing PETG, my targets were 85 for the bed and 240 for the hot end. My GCODE waits for the bed to reach the target temp before changing the hot end target.

The bed reached the target of 85, and the hot end target changed from 150 to 240. After several seconds, with the hot end not yet at the 240 target, all 3 axes resumed blinking "-?-".

That seems extremely odd. I hope this observation helps someone figure out how to resolve this issue.

wjcarpenter avatar Apr 10 '23 15:04 wjcarpenter

The bed reached the target of 85, and the hot end target changed from 150 to 240. After several seconds, with the hot end not yet at the 240 target, all 3 axes resumed blinking "-?-".

Try adding an M18 S600 command to set the stepper timeout to a much longer interval. When the steppers are powered off axes are considered "untrusted."

thinkyhead avatar Apr 10 '23 20:04 thinkyhead

Good idea @thinkyhead. From the source code, it looks like the default is only 2 minutes. I'll try your suggestion later today.

wjcarpenter avatar Apr 10 '23 21:04 wjcarpenter

After several seconds, with the hot end not yet at the 240 target, all 3 axes resumed blinking "-?-".

Great point, I was looking for why some people have their axes in the untrusted state when try to execute the filament change.

mriscoc avatar Apr 10 '23 22:04 mriscoc

So the general advice is to move the G28 after all temperature settings in the start G-code script. Please check the suggested start G-code script here: https://github.com/mriscoc/Ender3V2S1/wiki/Slicer-G-code-Scripts

mriscoc avatar Apr 10 '23 22:04 mriscoc

I think that's the answer. I just did a print with that timeout set manually, and parking happened perfectly. I also kept a watch on the display and didn't see any "-?-" blinking.

(I print exclusively via OctoPrint, so it was simple to add the setting to one of OctoPrint GCODE scripts.)

wjcarpenter avatar Apr 10 '23 23:04 wjcarpenter

move the G28 after all temperature settings

Well, I'm not so sure about that. As I mentioned, I heat my bed and then heat the hot-end. The reason I do it that way is to minimize oozing. Once the hot-end gets up to temperature, the oozing definitely starts to one degree or another with all of the filaments I use. Doing a G28 home after that would droop the oozed filament onto the center of the bed.

So, instead, I'm just using a liberal timeout for the stepper disable.

wjcarpenter avatar Apr 10 '23 23:04 wjcarpenter

Once the hot-end gets up to temperature, the oozing definitely starts to one degree or another with all of the filaments I use.

You can change a little your procedure:

  • Set your head parking position to a position where you can clean the nozzle or remove the oozing
  • Before of start select Prepare/Filament management/Park heat, that will do an autohome if it is necessary.
  • Put the G28 just before of the purge line in your star G-code script.

The next version will have a parkhead option for set in the toolbar.

mriscoc avatar Apr 10 '23 23:04 mriscoc

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.

github-actions[bot] avatar Jun 10 '23 02:06 github-actions[bot]