Homing, G28, and G29 probing sometimes fail to move to correct XY location

I am configuring a home-built MPCNC as a 3d printer. The issue is that, frequently but unpredictably, G28 Z fails to move to the correct XY position before probing. It usually moves at least some, and the debugging output shows that it's target is correct: (Z_SAFE_HOMING_X_POINT, Z_SAFE_HOMING_Y_POINT) - (probe offset); in my case, (116.5, 116.5). But it does not seem to make it there. The really bad thing about this is that the machine then thinks it has moved to (116.5, 116.5), but its actual position is far short of that. Thus, the X and Y axes are "unhomed" to a random position.

I also see similar behavior with the z probing when calling G29 to set up bilinear bed leveling. The probes work ok in Z, but the movement to the correct XY position falls short.

Machine details:
- MPCNC build
- Running Marlin 2.1.2.1 off an Arduino Mega 2560 with RAMPS shield
- Commands sent from Octoprint.
- Z probe is just a magnetically mounted "fixed probe" switch.
- Z safe homing enabled

Does anyone have experience with this? Happy to provide more details if it is helpful.


The debugging output from a G28 call (enabled via M111 S32):

Send: G28 Z
Recv: >>> G28 X0.00 Y0.00 Z30.00
Recv: Machine Type: Cartesian
Recv: Probe: FIX_MOUNTED_PROBE
Recv: Probe Offset X-16.50 Y-16.50 Z-8.60 (Left-Front & Below Nozzle)
Recv: Auto Bed Leveling: BILINEAR (disabled)
Recv:
Recv: >>> set_bed_leveling_enabled X0.00 Y0.00 Z30.00
Recv: <<< set_bed_leveling_enabled X0.00 Y0.00 Z30.00
Recv: Raise Z before homing:
Recv: >>> do_blocking_move_to X0.00 Y0.00 Z30.00
Recv: > X0.00 Y0.00 Z30.00
Recv: <<< do_blocking_move_to X0.00 Y0.00 Z30.00
Recv: >>> home_z_safely X0.00 Y0.00 Z30.00
Recv: current_position= X0.00 Y0.00 Z30.00 : sync_plan_position
Recv: destination= X116.50 Y116.50 Z30.00 : home_z_safely
Recv: >>> do_blocking_move_to X0.00 Y0.00 Z30.00
Recv: > X116.50 Y116.50 Z30.00
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
Recv: <<< do_blocking_move_to X116.50 Y116.50 Z30.00
Recv: >>> homeaxis(Z)
Recv: current_position= X116.50 Y116.50 Z30.00 : Probe::set_deployed
Recv: deploy: 1
Recv: Probe::do_z_raise(10.00)
Recv: >>> do_blocking_move_to X116.50 Y116.50 Z30.00
Recv: > X116.50 Y116.50 Z30.00
Recv: <<< do_blocking_move_to X116.50 Y116.50 Z30.00
Recv: >>> do_blocking_move_to X116.50 Y116.50 Z30.00
Recv: > X116.50 Y116.50 Z30.00
Recv: <<< do_blocking_move_to X116.50 Y116.50 Z30.00
Recv: Home Fast: -240.00mm
Recv: >>> do_homing_move X116.50 Y116.50 Z30.00
Recv: ...(Z, -240.00, [4.00])
[...]
Recv: echo:busy: processing
[...]
Recv: echo:busy: processing
[...]
Recv: <<< do_homing_move X116.50 Y116.50 Z30.00
Recv: Move Away: 5.00mm
Recv: >>> do_homing_move X116.50 Y116.50 Z30.00
Recv: ...(Z, 5.00, 4.00)
Recv: echo:busy: processing
Recv: <<< do_homing_move X116.50 Y116.50 Z30.00
Recv: Re-bump: -10.00mm
Recv: >>> do_homing_move X116.50 Y116.50 Z30.00
Recv: ...(Z, -10.00, 2.00)
[...]
Recv: echo:busy: processing
[...]
Recv: <<< do_homing_move X116.50 Y116.50 Z30.00
Recv: >>> set_axis_is_at_home(Z)
Recv: *** Z HOMED WITH PROBE (Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN) ***
Recv: > probe.offset.z = -8.60
Recv: Axis Z home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[Z] = 0.00
Recv: current_position= X116.50 Y116.50 Z8.60 :
Recv: <<< set_axis_is_at_home(Z)
Recv: current_position= X116.50 Y116.50 Z8.60 : sync_plan_position
Recv: current_position= X116.50 Y116.50 Z8.60 : > AFTER set_axis_is_at_home
Recv: current_position= X116.50 Y116.50 Z8.60 : Probe::set_deployed
Recv: deploy: 0
Recv: >>> do_blocking_move_to X116.50 Y116.50 Z8.60
Recv: > X116.50 Y116.50 Z8.60
Recv: <<< do_blocking_move_to X116.50 Y116.50 Z8.60
Recv: <<< homeaxis(Z)
Recv: <<< home_z_safely X116.50 Y116.50 Z8.60
Recv: >>> do_blocking_move_to X116.50 Y116.50 Z8.60
Recv: > X116.50 Y116.50 Z10.00
Recv: echo:busy: processing
Recv: <<< do_blocking_move_to X116.50 Y116.50 Z10.00
Recv: current_position= X116.50 Y116.50 Z10.00 : sync_plan_position
Recv: X:116.50 Y:116.50 Z:10.00 E:0.00 Count X:9320 Y:9320 Z:4000
Recv: <<< G28 X116.50 Y116.50 Z10.00
Recv: ok

In this case, the probing worked but the print head was parked somewhere near (60, 60) rather than the (116.5, 116.5) point the machine thought it had moved to.

Edited 1 time(s). Last edit at 07/06/2023 04:21PM by cmell.

You likely have bad wiring on your stepper motors

Thanks for the reply! The thing is that other movements seem to be totally fine. I can print test pieces without layer shift or any steps dropping as far as I can tell.

... too fast, so skipping steps maybe?

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

I did a repeated test of the phenomena. Procedure:

Part A, completed once:
1) Call G28 XY and manually move z to a safe position.
2) Call G1 X116.5 Y16.5, which is the Z_SAFE_HOMING_X_POINT and Z_SAFE_HOMING_Y_POINT.
3) Place a marked sticker at this location.
4) Verify the position by incrementally backing the head to 0, 0. It was correct.

Part B, repeated five times:
1) Call G28 XY.
2) Call G28 Z.
3) Place an unmarked sticker wherever the head moved to a probed.
4) Go back to step 1 for the next iteration.

I'm attaching a picture of the results . In each Part B iteration, the head moved along the correct diagonal (toward the safe homing position where the marked sticker is). However, it did not come even close to getting there. There are three stickers not even on the bed. My print bed falls completely inside the movement of the head, so there's a little space in the coordinate system off the print bed. I placed the three stickers pretty much on top of each other at this point because the head moved to that similar location on three of the iterations. But on two of them, it went a bit further. In each case, the G28 Z call gave output showing that the machine thinks it performed all the steps necessary to get to the safe homing position:

Recv: X:116.50 Y:116.50 Z:10.00 E:0.00 Count X:9320 Y:9320 Z:4000

What I observe is that on the G28 Z call, the machine moves along the diagonal to the safe homing position, and without any hesitation probes a point well short of it. That probe point is not predictably in exactly the same spot, as shown by the stickers.

Another critical fact is that a G1 X116.5 Y116.5 call always goes to the correct position (the marked sticker in the image). I performed the first two steps of Part A a few times with a M114 call after to check this. The head always moved to the marked sticker and gave the correct output:
Recv: X:116.50 Y:116.50 Z:30.00 E:0.00 Count X:9320 Y:9320 Z:12000

If my motors were dropping steps, is this behavior consistent with that? It would be dropping a LOT of steps to have this result. And would Marlin think that it had sent thousands of steps that took absolutely no time to send?

In general, how do I go about diagnosing this?

Thanks for weighing in all!

I performed one more test. I temporarily soldered a lead wire to the step pin on the A4988 driver for the X axis and connected this to an interrupt pin on an Arduino Nano. I wrote a simple program to count the number of steps that register on the driver step pin. I think this should give a fairly objective view of how many steps are actually being attempted.

Starting from the XY homed position (0,0), I called G28 Z. I did this 10 times. On all trials, the output showed that Marlin thought it had performed 9320 steps, going to the safe z home position. But my arduino counted 9320 steps on only 4 of the 10 trials. On the rest, there were variable numbers of steps counted: 3451, 7483, 9029, 3674, 7146, and 1637. So the movement did not reflect what Marlin thought it was doing.

To confirm it is not just a wiring issue, I tested this with G1 commands. In every single G1 command involving an X movement, my step counting-nano saw all steps that it was supposed to, and aligned with output from M114 calls.

How about attaching Configs so we can attempt to replicate

I can replicate this on the simulator, with broken endstops

Ie G28 XY doesn't move

Ie they are always triggered

Test your endstop

M119 while switch is open and when closed

Edited 1 time(s). Last edit at 07/08/2023 03:52AM by Dust.

Configs attached. I tested each endstop with M119. They all behave as expected.

Did you ever find a solution? I have the same exact error.

I've got a delta printer with a duet smart effector. I can watch it mess up in realtime. It will try and reach the next probe location, but before it ever physically has time to move that far it will stop and begin probing in Z well short of where it should be. I know this because I've severely restricted the probing feedrate. Typically it takes 2-3 seconds to reach the next probe point, when it faults it moves for maybe a quarter second before trying to probe within a millimeter of the last probe point.

Because it's a delta, it's now horribly out of whack and usually drives the head into the bed with the next move.

There is zero mechanical fault with the printer, this is 100% in code like you seem to have found. Just curious if you ever found a fix...

Unfortunately I have not found a solution. I can get away with this on my cartesian machine. Since G1 always works correctly, I just G1 to a desirable location for probing the bed. But it is totally prohibitive for auto-leveling or producing a mesh for z compensation.

I would still value insight from anyone who has an idea on this!

I'm trying to print with a 0.15mm E3d nozzle, and I've got a board with a STM32H743 plus a sizeable external eeprom so I went ahead and set all the calibration point values to their maximums. I that's 7 for G33 delta calibration, and then 15 for G29 UBL bed leveling, at least according to configuration files I'm using. I've now noticed that it's "short traveling" the initial middle of the bed readings for G33 too, which messes with the quality of the auto calibration.

Strangely, if I set the max points to 4 for G33 and 7 for G29 UBL it all works perfectly fine. I can get sub 0.010mm deviations for calibrations, and I can lay down 0.08mm first layers without any problems.

I seem to recall having to change some safe homing code in the past, when I was running the same printer on an old MKS sbase board, but I can't find that issue any longer...

I had this issue develop with a custom CoreXY Marlin 2.0.x Due/RADDs machine after several years. On probing, it would skip moves, lose the place, probe the same spot repeatedly. It wasn't skipping steps or losing connection with a motor, just completely ommited a move or stopped partway through a move.

Cause was loose connections, probably the ones to the x homing sensor. Fixing the loose connectors resolved the problem.