[BUG] Z-axis moves once down after G28 when doing G1 X/Y

[richardklingler]

Bug Description

After doing a G28 for homing all axes all end switches are triggered and position is reported as 0, 0, 0. When travelling in either X or Y direction the z-axis moves down 5mm as well and M114 reports that Z is still at position 0mm.

When doing a G28 Z after G28 this won't happen and the z-axis stays at position 0mm

My Configurations

configuration.zip

Steps to Reproduce

Configure z-axis for travelling in negative direction:

z-max = 0 z-min = -70

1. G28
2. G1 X20 -> Z-axis moves down but reports 0 position
3. G28
4. G28 Z
5. G1 X20 -> Z-axis stays at 0 position

Additional Information

• Version 2.0.5.4
• Compiled with VSC 1.47.2 on Debian 10

[GMagician]

You may try: 1) Enable DEBUG_LEVELING_FEATURE 2) M111 S255 3) your commands and report log

maybe some hint will be shown

[richardklingler]

I know what the difference is...

G28 homes all axes and all end switches are triggered, therefore all axes have position of 0.

But: M114 reports Z as having position 5 although it is at position 0. That's why the first G1 movement corrects this and moves down 5mm.

Doing G28 Z homes z-axis the same way as G28, but reports Z-position as 0 where it should be.

So definitively G28 and G28Z behave totally different.

Attached the debug outputs of G28 and G28 Z.

Debug_G28.txt Debug_G28Z.txt

[GMagician]

try bugfix first and let's see what happens

[GMagician]

I see a

Raise Z (before homing) to 5.00

and it's done before moving X / Y.

You are homing to zmax. Where should move Z to move nozzle far from bed? to 5 or -5?

[richardklingler]

It has nothing to do with a bed or a 3d printer...it is for a smt pick and place machine... z-max is 0 and z-min is -70..so at home position the pick head mounted on z-axis should be up... And for picking a part the z-axis should move down to a certain position...

G28 returns:

G28 echo:busy: processing echo:busy: processing X:0.00 Y:0.00 Z:5.00 E:0.00 Count X:0 Y:0 Z:400

The limit switch status is:

M119 Reporting endstop status x_min: TRIGGERED y_min: TRIGGERED z_max: TRIGGERED

So why is Z set to 5mm when all limit switches are triggered?

Doing G28 Z gives:

G28 Z echo:busy: processing X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0

And the status of the limit switches are the same as before:

M119 Reporting endstop status x_min: TRIGGERED y_min: TRIGGERED z_max: TRIGGERED

So where does this 5mm Z position comes from with G28 but not with G28 Z ?

The Z-position after homing is exactly the same as the limit switch status shows.... but the reported position is different...

[GMagician]

Z move 5 to move away nozzle from bed. Not sure if "home to max" should home far from nozzle or no. Value comes from Z_HOMING_HEIGHT or, if not defined, from Z_CLEARANCE_BETWEEN_PROBES

[richardklingler]

Hmm... but why is G28 Z returning a different z-position which is correct?

G28 and G28 Z should behave exactly the same in respect of the z-axis...

[GMagician]

The difference is that G28 also zeroes X & Y and is when X&Y are homed that Z is raised to not collide with bed (that you don't have, but Marlin is for printers)

[GMagician]

~~and since your max is 0 and it tries to move 5 above it and since it is already at max position, maybe this may be a problem. Maybe the raise should be limited to max position, not sure code does it~~

Is not what I supposed above. Raise is limited to Z_MAX_POS so it should not try to move past max do_blocking_move_to_z(_MIN(zdest, Z_MAX_POS), MMM_TO_MMS(Z_PROBE_SPEED_FAST));

[GMagician]

Please try bugfix as I asked you, this has been fixed in that version

[richardklingler]

Just downloaded bugfix-2.0.x....but don't see any difference

G28 echo:busy: processing echo:busy: processing echo:busy: processing X:0.00 Y:0.00 Z:5.00 E:0.00 Count X:0 Y:0 Z:400 ok M119 Reporting endstop status x_min: TRIGGERED y_min: TRIGGERED z_max: TRIGGERED

G28 Z echo:busy: processing X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0 ok M119 Reporting endstop status x_min: TRIGGERED y_min: TRIGGERED z_max: TRIGGERED

[richardklingler]

Ah wait...when selecting bugfix on github page it doesn't switch the clone popup text...seems download zip is the only way...

Hmm...loads of config names have changed...can't just use the previous 020005 and rename it....

[GMagician]

Ah wait...when selecting bugfix on github page it doesn't switch the clone popup text

Once you have a clone you should be able to switch to "bugfix branch".

Attach a bugfix log if problem is sitll there

[GMagician]

Please also note that bugfix code is (with little change to it needed to shrink it here):

const float zdest =
  ENABLED(UNKNOWN_Z_NO_RAISE) && TEST(axis_known_position, Z_AXIS)
   ? 0
 : (parser.seenval('R') ? parser.value_linear_units() : Z_HOMING_HEIGHT);

float zdest = zclear + (rel ? current_position.z : 0.0f);
if (!lower_allowed) NOLESS(zdest, current_position.z);
do_blocking_move_to_z(_MIN(zdest, Z_MAX_POS), MMM_TO_MMS(Z_PROBE_SPEED_FAST));

while 2.0.5.4 is:

const float z_homing_height =
  (DISABLED(UNKNOWN_Z_NO_RAISE) || TEST(axis_known_position, Z_AXIS))
   ? (parser.seenval('R') ? parser.value_linear_units() : Z_HOMING_HEIGHT)
    : 0;
destination.z = z_homing_height + (TEST(axis_known_position, Z_AXIS) ? 0.0f : current_position.z);
  if (destination.z > current_position.z) {
    if (DEBUGGING(LEVELING)) DEBUG_ECHOLNPAIR("Raise Z (before homing) to ", destination.z);
      do_blocking_move_to_z(destination.z);
    }

as you can see no Z_MAX_POS limit to old version

[richardklingler]

Perfect :+1:

G28 echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing echo:busy: processing X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0

G28 Z echo:busy: processing X:20.00 Y:0.00 Z:0.00 E:0.00 Count X:1600 Y:0 Z:0

have a nice weekend :-)

PS: Seems the TMC5160 steppers are also running more quieter...

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