Marlin: [BUG][bugfix-2.0.x] G29 eats previous G1

[mrvanes]

Description

After upgrading from 1.1.5 to 2.0-bugfix (Lulzbot fork) I need to insert an M400 between by G1 E-10 and G29 so that I truely retract 1cm of filament before probing the washers for bed leveling.

Steps to Reproduce

1. Part of my startup g-code

M109 R170
G1 Z150 E-10
G29

On 1.1.5 this would result in lowering the extruder and retracting 10mm of filament before leveling the bed. On 2.0-bugfix, the G29 immediately starts after reaching 170C without retraction.

If I change the startup g-code to

M109 R170
G1 Z150 E-10
M400
G29

everything works as expected.

Expected behavior:
I would expect the previoius g-code to do the same on 1.1.5 and 2.0-bugfix, i.e. not having to insert an M400 between the G1 and G29.

Actual behavior:
The printer immediately begins G29 after reaching target temp.

[mrvanes]

The bedleveling method used by Lulzbot is 4-point ABL.

[reloxx13]

this is on purpose, the planner logic changed in 2.0.x. thats why m400 exists.

edit: at least this is what i read from previous issues with the same "problem"
search for m400 in the issue list an read up urself.

[mrvanes]

Thx for clarifying. I can live with the extra M400, just was a bit surprised by the new logic.

[thinkyhead]

The M400 is needed for certain commands because G1 doesn't start a move. It just queues a move to be carried out at some point in the future.

While the G29 command does start right away, it is _supposed_ to wait for any moves in the planner to finish before it starts doing its thing. That G1 move will be in the planner by the time G29 starts. So, you shouldn't need the M400.

I just looked over the code, and it looks like UBL might have forgotten to include a synchronize at the start of G29. You wouldn't happen to be using UBL, would you?

[thinkyhead]

Try this change in ubl_G29.cpp…

  // Check for commands that require the printer to be homed
  if (may_move) {
+   planner.synchronize();
    if (axis_unhomed_error()) gcode.home_all_axes();
    #if ENABLED(DUAL_X_CARRIAGE)
      if (active_extruder != 0) tool_change(0);
    #endif
  }

[thinkyhead]

Oh, I see you're using the Lulzbot fork. Well, make sure they have planner.synchronize at the start of all the G29 commands too.

[thinkyhead]

Please test with the bugfix-2.0.x branch so we're all on the same page here. That branch contains all the latest patches.

[mrvanes]

Thx! Vanilla Marlin bugfix-2.0 on my Mini is not something I think is wise for me to do, so I'll stick to Lulzbot's fork, which has been merged from bugfix-2.0.x on May 28 for the last time. There is a planner.synchronize() in the ABL codepath, but I have to check with a debug statement whether it is hit in the normal Lulzbot Mini G29 flow: https://code.alephobjects.com/diffusion/MARLIN/browse/devel/Marlin/src/gcode/bedlevel/abl/G29.cpp$441

[boelle]

@thinkyhead would it be unfair to close this one if not using the bugfix 2.0.x branch? i mean would be hard to do much meaningfull if not on the same page

[BigIronGuru]

I have tested the above sequence with the current bugfix-2.0.x and all is well. No eating disorder.

[mrvanes]

Ok, then I think it's fair to close this bug. I will investigate further if and why the synchronize is executed or not. Thx for pointing me in the right direction!

[mrvanes]

Ok, last effort to get to the bottom of this (my apologies for reopening and not conforming to vanilla 2.0.x-bugfix).
I'm 100% positive the planner.synchronize() is hit while performing the G29 in my firmware (added a debug line). There is however strange behaviour: when I send the G1 E-10 and G29 while blocked waiting for the extruder to heat up (S109 R170) the G1 is skipped, but if I enter them one by one after the extruder is done (recv: ok) the filament is correctly retracted as soon as I enter the G1 E-10.
Does the planner behave differently when sending commands one by one and when sending them while being blocked?

[mrvanes]

Using the testing gcode below (sent from octoprint as one single print job), I clearly see G29 only eating the E move, XYZ are executed.
Inserting a G10 between the G1 and G29 retracts both the E-11 and the fwretract.

M207 S10 F150
M209 S0
M111 S38
G90
G28
M109 R170
G92 E0
G1 X10 Y175 Z150 E-11 F150
;G10
G92
G29 V4
G92
G1 X150 Y150 Z10
M104 S0
M84

The G92 after the G1 simply lies about E: it is not at -11 at that moment, but the rest is true.

2019-06-23 09:14:28,932 - Send: G92 E0
2019-06-23 09:14:28,941 - Recv: X:2.00 Y:185.00 Z:157.00 E:0.00 Count X:201 Y:18593 Z:251200
2019-06-23 09:14:28,954 - Recv: ok P15 B4
2019-06-23 09:14:28,959 - Send: G1 X10 Y175 Z150 E-11 F150
2019-06-23 09:14:28,971 - Recv: ok P14 B4
2019-06-23 09:14:28,975 - Send: G92
2019-06-23 09:14:28,982 - Recv: X:10.00 Y:175.00 Z:150.00 E:-11.00 Count X:201 Y:18593 Z:251200
2019-06-23 09:14:28,988 - Recv: ok P14 B4
2019-06-23 09:14:28,997 - Send: G29 V4
2019-06-23 09:14:29,011 - Recv:   current_position=(10.00, 175.00, 150.00) : >>> G29

I've disabled FWRETRACT_AUTORETRACT both in gcode and in the code, commenting out the #define.
Could anyone please confirm that the above gcode retracts E in bugfix-2.0.x (without the G10) while having FWRETRACT enabled so I can take this up with Lulzbot from here?

[BigIronGuru]

When I wrote

I have tested the above sequence with the current bugfix-2.0.x and all is well. No eating disorder.

I was not using UBL.
It seems there was a commit to a synch on UBL G29 last night. So perhaps that would lead to a comparison?

[mrvanes]

That's tinkyheads proposed change from https://github.com/MarlinFirmware/Marlin/issues/14355#issuecomment-504610064 and I'm not on UBL. Lulzbot uses the ABL path for the 4 point linear bed leveling.

[marcio-ao]

@mrvanes: I created a new branch of our FW which is up-to-date with Marlin upstream as of this instant. The branch is called "devel-upstream-2.0.x-jun24". It also incorporates the fix in PR#14393. This branch should be sufficient to test the problem against upstream.

Oh, I see you're using the Lulzbot fork. Well, make sure they have planner.synchronize at the start of all the G29 commands too.

For what it is worth, Lulzbot FW now a days differs very little from upstream Marlin as I've tried to push most of our changes upstream. To call it a "fork" is a bit misleading -- several of our customers use upstream Marlin without any difficulties. The only "difficult" bit is coming up with a configuration file, since ours is generated at compile time through a bunch of #ifdefs that resolves the differences between all our printer models and toolheads.

[mrvanes]

I just tried bugfix-2.0.x 07dac31 (merged in Lulzbot) and it exhibits the exact same problem. I wonder if @marcio-ao can reproduce at least on one of his Mini 1's?

[marcio-ao]

@mrvanes: Not right now. I'm in the middle of other things.

[mrvanes]

If the G1 E-10 is de last command in the print job, it works as expected. If the G1 is followed by a G29, it fails to retract but excutes the moves.

One work-around is putting an M400 between de G1 X... Y... Z... E-10 and the G29. And that is peculiar to say the least, because the M400 only executes a planner.synchronize() which is also in place in the G29 code.

I'm just baffled nobody else sees this problem?

[marcio-ao]

@mrvanes: I can't reproduce the problem on a Mini 2 running bugfix-2.0.x. If putting a M400 in your start GCODE is solving the problem, then that is the solution I would recommend for now.

This ticket can remain open. If more people start seeing the problem and we have people reproducing it consistently, then we would be in a better position to track down the problem.

I'm just baffled nobody else sees this problem?

Happens all the time :) Often software bugs interact in weird ways and it is not always obvious how to reproduce them. Sometime the best thing is simply to wait until it manifests itself in another way that makes it easier to track down.

[InsanityAutomation]

Take a look at the layer shifting issues and stepper shocks. Until just the right conditions occur itll only happen once or twice in millions of cycles. I ran a test build for 250hrs to get it to trigger 1 shift... Its possible that G1 is put in the moves queue, but G29 starts things moving immediately and directly so you could have a race condition I suppose. I havnt looked at the offending code yet.

[mrvanes]

Found the problem
https://code.alephobjects.com/diffusion/MARLIN/browse/devel/Marlin/src/Lulzbot_Extras.cpp$93

My sincere apologies for bothering Marlin with Lulzbot bug :(
Will take this up with @marcio-ao outside this issue to resolve the problem.

[marcio-ao]

@mrvanes: Ahhh. Good work. However, this is required because on some of our earlier Mini's electrical interference from the extruder motor can cause the probing to fail. If it works for you in your particular printer without that line, you can comment it out.

[marcio-ao]

@mrvanes: I guess I could also add a planner.synchronize() before calling disable_E0(), perhaps?

[mrvanes]

Yes, I sent you a mail with the fix. Issue can be closed.

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