Edit Home Z settings? (change Y distance moved before Z homing)

Quick question. Whenever I tap the HomeZ button, the carriage moves Y+50mm before homing the Z axis. Where can I edit so as to change that distance?

This is strange behavior. Where is the button you are pressing? The TFT? Repetier-Host? If it is the TFT did you purchase it from V1? If not, did you flash the TFT with the V1 version of the TFT firmware?

Itā€™s on the TFT which has firmware from V1. Itā€™s the Home-Z button in the Homing menu group. I have not made any tweaks or done any re-compiling of the touchscreen firmware. I did tweak the V1 firmware for the main board, turning on sensorless homing, including turning on Z-safe homing. I tweaked the settings for Z-safe homing to have it happen at coordinates X+5, Y+5, instead of Z homing at the center of the ā€œbedā€œ (they speak of ā€œbedā€ because the firmware is oriented toward 3-D printers instead of CNC). I later then tried putting other numbers into the Z-safe homing parameters, only to come to the conclusion that those numbers are being ignored. I really need to find out how to get it to pay attention to those numbers. Itā€™s homing at an x-coordinate that I donā€™t want, and at a y-coordinate that I donā€™t want.

If this is a TFT firmware issue, then it is strange that no one else on the forum has complained about this issue. Before diving into this firmware, Iā€™d put your display in Marlin mode and home from the V1 custom menuā€¦or send a home command from Repetier-Hostā€¦just to make sure this is a TFT firmware issue. If it turns out to be a TFT firmware issue, Iā€™d start by reflashing your display with the latest TFT firmware from V1 before delving into changing the TFT firmware.

Edit to add: The TFT communicates to Marlin using g-code, so if you are set on modifying the TFT firmware, you can likely find the homing code by searching the files for ā€˜28ā€™ or ā€˜G28ā€™ using any grep tool.
I use GrepWin, but there are many others out on the net.

2 Likes

@robertbu
Thanks! Super helpful clarity. This gives a great plan for starting a process of elimination.

@robertbu

Well, I put the touchscreen into Marlin / LCD Simulator mode, and I get the exact same result regardless of whether I use the V1 custom menuā€™s homing options, or the main menu > ā€œMotionā€ options for ā€œAuto Homeā€ or ā€œHome Z.ā€

Based on this, I think the main board firmware tweaks (when I enabled sensorless homing and Z-safe homing, and related things) has somehow setup this behavior.

The current homing process happens as:

  1. It homes Y axis first, as I instructed in the firmware. All good so far.
  2. It homes X axis second, and it honors the "HOMING_BACKOFF_POST_MM " of 27mm. All good so far.
  3. Before homing Z, it moves some negative distance in X and moves some positive distance in Y too, before homing Z. This happens relative to the boardā€™s then-current perception of where home is for X and Y. If I disable steppers and move away from the real home, and then home Z again, the X and Y movements before homing Z, all happen relative to the new location, as the board thinks the new location is where it was before.

I am going to revisit my notes on all edits done to enable sensorless homing. More soon.

1 Like

There is some Z safe homing setting, IIRC. It always enables for me when I enable a probe. I would look through the probe settings.

The place I think it is trying to go to is the middle of the bed size. That might be another way to find the setting.

2 Likes

@jeffeb3

It had occurred to me it might be trying to find the center of a tiny bed (if the firmware does not actually correctly specify the real bed size), but I had disregarded that because I had previously already edited the Z-safe homing options to change both ā€œX_CENTERā€ and ā€œY_CENTERā€ to a set number of millimeters, which I was thinking would be interpreted in relation to X0 and Y0. Still you have provoked me to thought.

@KCGreg

Hey, when I am homing Z, Iā€™m having some issues with unwanted X and Y movement.

Iā€™m searching through various firmware options in configuration.h and confirguation_adv.h to try to sort it out.

In your notes ā€” in this post:

https://forum.v1e.com/t/lowrider-skr-1-3-dual-y-and-z-tmc2209-uart-sensorless-homing/

ā€¦ you showed the following:

#define Y2_USE_ENDSTOP _XMAX_ //This is a change from default

and

#define Z2_USE_ENDSTOP _YMAX_ //This is a change from default

Can you help me know why the Y2 endstop should be told to use XMAX (why X instead of Y), and why the Z2 endstop should be told to use YMAX (why Y instead of Z)?

I cannot rule out these edits as unrelated if I donā€™t understand what this does and why.

Thanks if you can help me understand!

When you switch the Z home dir to +1, it changes the Z1 endstop to be Zmax. If you try to change Z2 to zmin, it fails some sanity check. The easiest workaround is to set it to the unused other max pin.

I donā€™t know why Y2 is using Xmax, unless that was just the order of fixes to get it working.

@jeffeb3

OK, so since (unlike KCGreg) I am homing to Z-min, and I have INVERT_Z_DIR set to false, I could use the defaults instead of the variations he had in his notes?

UPDATE: Nope, those variations in KCGregā€™s are necessary to make sensorless dual homing work (needed in both the Y2 and Z2 endstop settings), and nope, they donā€™t seem to have anything to do with causing the unanted X and Y movement Iā€™m having on Z.

Still lookingā€¦

Iā€™m totally out of my depth in this discussion, but if sensorless homing is working for X and Y, and if you are using a touch plate for Z, could you leave what youā€™ve done so far alone and instead use G38.2 (probe target) for setting Z height?

Two things:

  1. I have reached a conclusion: Z_SAFE_HOMING gets ā€œbrokenā€ by our current implementation of sensorless dual homing.

  2. For me, a workaround is to not use Z_SAFE_HOMING, and possibly create a custom menu option to take its place.

Whenever I enable both sensorless (dual) homing and Z_SAFE_HOMING, the coordinates for where to home Zā€¦ are not honored. The coordinate values get ignored no matter what is entered.

The default variables/constants (shown below) do not work, despite that Iā€™ve carefully inputted my LowRiderā€™s actual ā€œbed areaā€ dimensions (bed size) into the Marlin firmware.

#define Z_SAFE_HOMING_X_POINT X_CENTER // X point for Z homing
#define Z_SAFE_HOMING_Y_POINT Y_CENTER // Y point for Z homing

ā€¦Also, use of specific coordinates, such as 0 or 20 etc, also get ignored.

1 Like

I forgot you are using sensor less homing. That is probably just because of the way the endstop pins are wired on the board from the E0 and E1 drivers to endstop pins.

1 Like

I needed to do this in order to overcome some incorrect mappings by Marlin, at the time. The bug post that I entered in Marlin has some tables that may help with understanding these mappings. I believe these are now fixed in current Marlin versions, however, these can still be changed if needed.

[BUG] SKR 1.3 TMC2209 Endstops Mapping Incorrectly Ā· Issue #16677 Ā· MarlinFirmware/Marlin (github.com)

@KCGreg

Thanks! I could try with a newer download of the bugfix edition.

Any ideas about Z_safe_homing target coordinates being broken by sensorless dual homing?

@KCGreg
It was rather enlightening reading the bug report / tracker you linked to. You are light years ahead of me on understanding the whole concept.

Here is a link to the pin out diagram for the SKR Pro 1.2 Iā€™m using:

1 Like