[BUG] No homing of y-axis against ymin

[G4Cab]

Bug Description

With actual bugfix version i have no homing capability of the y-axis. (Tried older firmware without changing/modifying cable connections and it works)

My Configurations

Nextcloud link to my files: https://yoruichi.golf-4-cab.de/nextcloud/index.php/s/Fs2CSNNEzaczZdY

Steps to Reproduce

Just press "Home Y" or "Auto Home"

Additional Information

With the bugfix Version of one of the last weeks i didn't had this problem. have a diy core xy machine with 0,9° steppers on x, y, z1, z2 Board is a BTT GTR v1.0 Drivers on xyz TMC5160 Drivers on e1-3 TMC2130

[ellensp]

What does M119 say about Y endstop?
Does M119 change endstop status if you manually trigger the Y endstop?
Does Y axis move if you request a move away from the endstop? What does M43 says regarding what pin its using for Y endstop and Y stepper pins? Its probably not that simple, but its a starting point...

[G4Cab]

Maybe i found the error. M119 says y_min open but M43 E1 says y_min:1 If i press the switch: M119 y_min:triggered and M43 y_min:0 The logic seems inverted. And yes, i can move the Y-axis in both directions (negative and positive values, soft endstops disabled)

[G4Cab]

Hmm, the same logic with other marlin build where homing works

[ellensp]

a normal two wire endstop is normally closed and logic level 0 when not triggered and is pulled to logic level 1 when opened, ie triggered.

The comment in the config is "Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup)." which is correct.

Your homing to Y min, but you have #define Y_MIN_ENDSTOP_INVERTING true

This just looks like config error to me... as Y_MIN_ENDSTOP_INVERTING should be false. Can't explain why it used to work, other than it was a bug, it shouldn't have.

[G4Cab]

Have the same microswitch with the same wiring on x-axis without any problems.

[G4Cab]

Changed the wiring of the switches, now they are com = gnd and nc = sig (before no = sig) Also changed the inverting in the configuration.h back to false. Same problem, z raises but y axis don't move for homing.

[G4Cab]

have enabled debugging for leveling ....

M111 S247 output from G28 X and G28 Y

debug log X homing.txt debug log Y homing.txt

[G4Cab]

Okeeeh, switched my homing direction to y_max instead of y_min, now it's homing ?!?!?

[ellensp]

Some one just posed https://github.com/MarlinFirmware/Marlin/issues/18235
you both have corexy

[ruggb]

that would indicate the endstop was plugged into the wrong socket, wouldn't it? The Y_MIN would be open and high all the time so it would seem like it was already home.

[G4Cab]

Some one just posed #18235 you both have corexy

Yeah, seems i'm not the only one.

[G4Cab]

that would indicate the endstop was plugged into the wrong socket, wouldn't it? The Y_MIN would be open and high all the time so it would seem like it was already home.

And the older firmware changes my wiring? Not really. I tried changing the way my endstops triggers (from NO to NC), without no help. Only my change from homing to ymax instead to ymin helped me.

[ruggb]

I have a coreXY with a Ramps board and have not had this issue with any build including a late bugfix 2.0. So what is different? It does not home because the Ymin pin is "triggered" since it is open and pulled high. Mine would not do that because they are NO, negative logic. Changing it to home on Ymax would indicate that the Y endstop is plugged into the Ymax pins, right? I don't think it is a f/w issue unless the pins file for your board is wrong.

[G4Cab]

ruggb, you should read the whole thing. Same wiring, same pins definition, with older marlin it works and homing to y-min is working with newer marlin not. changed the microswitch behavior for testing and it's the same problem. the leds on my BTT GTR board view the trigger state of the switches, which always worked fine and the correct behavior. after all the troubles i switched to y-max and there it works fine.

[ruggb]

I think I read the whole thing a number of times. The point I was trying to make is that I have not had an issue with this on my setup, which is not the same hardware as yours but it is CoreXY. So, to figure out what is going on you need to figure out what the difference is. The fact that it works on the same hardware with previous builds, and new builds work the same as old on mine would point me to the pins file. This is assuming all adjustments to the configs are the same between your builds. Isolate the pins file that you think it is using (delete all the rest of them or move them where they won't be found outside the sketch folder) . Maybe it isn't using the right one. Everything else for the operation of endstops should be the same between mine and yours. Compare the old and new pins files. (Use Notepad++ compare feature) They should not have changed. Maybe try using the old file.

[dtpb]

I also him a bigtreetech gtr v1.0 In the end I had two friends checked up to 4 nights. why the ymin does not want to zero point. Took my time for several days. my mks sgen l works very strange. I ended up giving up. Must be a bug.

[ikn369330]

I have the same issue, Gtr v1.0 Marlin bugfix, no homing on Y-axis

[SevCr]

Hi everyone. I have previously posted similar isssue, but it seams there is more dialog on this thread, so perhaps it would be better to keep everything here (more people involved). My issue : #18235

As @G4Cab suggested I have tried homing Y on "+" direction, Thanks for the tip.

This is working although I had to relocate the limit switch. Not sure if it is proper solution and dont understand why it wouldnt home going back to "0".

My issue was posted here with all details; #18235 - , which I will close, but would be interested to find out why ony homing in one direction.

Thanks everyone.

[G4Cab]

I have the same issue, Gtr v1.0 Marlin bugfix, no homing on Y-axis

Homing to y-max helped him too (facebook group conversation)

[ruggb]

Has anyone attempted to determine the cause, or is the workaround satisfying enough? Any attention paid to the pins file for this board? Since it seems to be localized to specific hardware. IE, it works fine with my Ramps.

[dtpb]

a good solution would be nice for people with this board "bigtreetech Gtr v1.0". thanks for your effort i would like to see a solution

[ruggb]

I can't find any readable documentation for that board. But if I had one I would try reversing the port numbers in the pins file pins_BTT_GTR_V1_0.h

currently:

define Y_MIN_PIN PC13

define Y_MAX_PIN PG9

to this:

define Y_MIN_PIN PG9

define Y_MAX_PIN PC13

Of course, you need to put Y endstop back on Y-Min If you have readable docs you might check that to see if indeed they are reverse in that file and need to be changed by Marlin. Otherwise, it is another issue.

[G4Cab]

ruggb, thanks for trying to help, but you don't read my statements! The pin file didn't changed the whole time! I used the same pin file with the working release and the same pin file with the non working release!

The documentation could be found here: https://github.com/bigtreetech/BIGTREETECH-GTR-V1.0/blob/master/BTT%20GTR%20V1.0/manual/GTR%20V1.0%20PIn.PDF

[thinkyhead]

To figure out how the pins are behaving on your board (and which is which) we provide the PINS_DEBUGGING option. When this option is enabled you can use M43 to watch one or more pins, or monitor the endstop pins, and it will report their state as you touch / trigger them. This will tell you if the pins file is correct, and it will tell you whether any pins on your board are shorted or cut.

[ruggb]

ruggb, thanks for trying to help, but you don't read my statements! The pin file didn't changed the whole time! I used the same pin file with the working release and the same pin file with the non working release!

The documentation could be found here: https://github.com/bigtreetech/BIGTREETECH-GTR-V1.0/blob/master/BTT%20GTR%20V1.0/manual/GTR%20V1.0%20PIn.PDF

Sorry, there are about 3 of these going right now so I got confused - my normal state. But thanks for the link.

[thinkyhead]

@G4Cab — Could you re-post your Configuration files? (ZIP the files and drag the ZIP file into your next reply.) I need to do a build and see where the Y discrepancy is happening.

[G4Cab]

@G4Cab — Could you re-post your Configuration files? (ZIP the files and drag the ZIP file into your next reply.) I need to do a build and see where the Y discrepancy is happening.

Looked for them and this should be them. https://yoruichi.golf-4-cab.de/nextcloud/index.php/s/qZzT4GPxd4N8fj9

[G4Cab]

At the facebook groups the messages rises of homing problems:

https://www.facebook.com/groups/485785992127996/permalink/573854449987816/

https://www.facebook.com/groups/485785992127996/permalink/573111780062083/

[gouache]

I made some stupid patch before :( so I create one new pull request. correct reason was the real Y_MAX_PIN of BTT GTR V.1.0 is '0'. please review my patch.

[G4Cab]

I made some stupid patch before :( so I create one new pull request. correct reason was the real Y_MAX_PIN of BTT GTR V.1.0 is '0'. please review my patch.

Maybe this is the right direction! I can't find PC_13 declared in this variants files ! Will check it

[ellensp]

@G4Cab see https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.0.x/buildroot/share/PlatformIO/variants/BIGTREE_GTR_V1/variant.h

[G4Cab]

argh, looked the wrong path. but in my file from 6.june it's defined #if STM32F4X_PIN_NUM >= 64 //64 pins mcu, 51 gpio #define PC13 0 #define PC14 1 //OSC32_IN #define PC15 2 //OSC32_OUT #define PH0 3 //OSC_IN #define PH1 4 //OSC_OUT #define PB2 5 //BOOT1

[sjasonsmith]

I just verified that on a Cartesian printer I can home X and Y in both directions (using both -/+ endstop connectors) on a GTR V1.0. This seems to mean there is not a fundamental issue with pin definitions for this board.

@G4Cab have you tried the latest bugfix-2.0.x after the change from @gouache was merged?

[dtpb]

I tried the latest version with the patch (gouache). I can confirm that y-axis homing to 0 point now works fine on bigtreetech gtr v1.0

[Minims]

Not sure but it seems my issue https://github.com/MarlinFirmware/Marlin/issues/18391 is quite the same as the problem described here for a SKR PRO 1.1

[sjasonsmith]

@Minims do you still have the issue with the latest bugfix branch? Are you also using CoreXY?

[Minims]

@sjasonsmith Yes, still have the issue on a CoreXY with sensorless homing . No problem on a Prusa with sensorless homing.

[thinkyhead]

Have you tried a wide variety of homing speeds, backoff distances, and stallguard thresholds to see if there is any point where it can succeed? Have you tried adjusting your belt tension to see if there is any amount of tension which produces more reliable results?

[sjasonsmith]

I moved my GTR to an H-Bot machine (CoreXY, as far as software is concerned), and have no issues homing. This is using optical endstops, not sensorless as @Minims is using. I believe this issue originally involved mechanical switches.

[Minims]

I Have

• Increase current of motors for homing, no fix
• Change homing threshold : no fix
• invert X and Y wire on the board, Y is homing (on Y+) , X does not move.

[Minims]

I have remove sensorless homing and it works. I have mechanical switch, but X and Y are moving. So as it works with a PRusa with sensorless, it seems it a combinaison of Sensorless and CoreXY bug

[Minims]

If I remove this commit, I can home Y first OK , but X not working OR X first OK and Y not working : https://github.com/MarlinFirmware/Marlin/commit/bc9e5e2abc6a4c6b87d6c2f98af75cb0d5e58be3

[thinkyhead]

What did you see when you added logging?

if (!_CAN_HOME(X) && !_CAN_HOME(Y) && !_CAN_HOME(Z)) {
  SERIAL_ECHO_MSG("Can't home this axis!");
  return;
}

[Minims]

    if (!_CAN_HOME(X)) {
      SERIAL_ECHO_MSG("Can't home X axis!");
    } 
    if (!_CAN_HOME(Y)) {
      SERIAL_ECHO_MSG("Can't home Y axis!");
    } 
    if (!_CAN_HOME(Z)) {
      SERIAL_ECHO_MSG("Can't home Z axis!");
    } 
      if (!_CAN_HOME(X) && !_CAN_HOME(Y) && !_CAN_HOME(Z)) {
      SERIAL_ECHO_MSG("Can't home this axis!");
      return;
    } 

result is :

Printer is now online.
>>> M502
SENDING:M502
echo:Hardcoded Default Settings Loaded
>>> M500
SENDING:M500
echo:Settings Stored (768 bytes; crc 18613)
>>> G28
SENDING:G28
#Homing X
echo:Can't home Y axis!
echo:Can't home Z axis!
#Homing Y
echo:Can't home X axis!
echo:Can't home Z axis!
#Homing Z
echo:Can't home X axis!
echo:Can't home Y axis!

[thinkyhead]

That looks correct. So _CAN_HOME is working fine.

[Minims]

I have try to debug, but I can find where is the problem. Latest tests, I remove the belt, no move on homing Y. I remove COREXY from the config to act as a prusa. homing is working. So problem is really somewhere between COREXY and Sensorless.

[G4Cab]

I didn't use sensorless, i've used microswitches tried with NO and NC connection, only switching to ymax helped. so maybe it's corexy related

[sjasonsmith]

@G4Cab have you tested with the bugfix-2.0.x since the fix was merged? I believe this is likely solved for anyone using mechanical switches, and the remaining issues are only related to sensorless homing.

If it is working for you with mechanical switches, I think that we should try to re-open #18391 to track the sensorless issue, since the original issue reported here is fixed.

[sjasonsmith]

@Minims (and anyone else with problems with sensorless homing on CoreXY), I suggest you look at issue #16420, as it seems very much like the issues mentioned here. The title of that issue makes it seem as if it is just an SKR 1.3 / LPC1768 issue, but that doesn't seem true if it is impacting SKR Pro users in exactly the same way.

@G4Cab please close this issue if you are satisfied that your original issue (with mechanical endstops) is resolved. Based on testing by myself and others I believe it is fixed, but I'd love you see your confirmation as well.

[Minims]

@sjasonsmith i have this issue too, but a another problem where we have a code workaround. Here I have home x or home y first, I unable to home the other axis. I can make G28, G34, G29 and retry homing of individual axis, but it doesn't work. M119 seems reporting good status avec the first homing. X triggered, Y not. I can tried to debug this, but I need help to add log in the right space for example so I can report the issue.