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.
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:
- It homes Y axis first, as I instructed in the firmware. All good so far.
- It homes X axis second, and it honors the "HOMING_BACKOFF_POST_MM " of 27mm. All good so far.
- 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
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.
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.
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:
-
I have reached a conclusion: Z_SAFE_HOMING gets ābrokenā by our current implementation of sensorless dual homing.
-
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.
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