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

[rado79]

My setup: CoreXY, SKR1.3, TMC2209, sensorless yes, quick_home no, homing to X-min and Y-min, i am not able to reproduce this issue.

[Minims]

@rado79 can you share your configuration.h and configuration_adv.h so I can update the board and give it a try on my SKR Pro ? Thanks :-)

[rado79]

@Minims for sure.
Marlin.zip

[Minims]

thx @rado79 , so it works with your config. I now have to add my configuration step by step to check what is causing this issue. a lot of compilation to do :-)

[CorvoDewittV2]

I have the same issue. I am running a BTT GTR V1.0, TMC2209s and a coreXY, using sersorless homing. I have been getting some pretty bad surface finish on my prints, worse than my ender 3. so I tried updating the TMCdriver library. I went from 0.5.2 to 0.7.0, and it broke sensorless homing as you guys are describing. It would home X, then not move the Y. I can home X or Y, but once one is homed, the other can not be homed. I just found this out last night, and I'm starting to think its a board issue. If you can run then 0.5.2 library, and sensorless homing works, its a bug in the new library related to how the GTR is designed.

While I have everyone's attention, how is the surface finish on flat walls of your prints? Mine looks rough, almost like there are small layer shifts back and forth. Just wondering if I need to ditch the GTR or not.

[Minims]

I'm still trying to debug, but it seems that if I set micro step from 128 to 16 for X and Y it's better. but I continue to have random failure on homing. I try downgrade to 0.5.2, but the behavior is quite the same for me

[CorvoDewittV2]

You are on a SKR pro?

[Minims]

Yes SKR PRO 1.1

[CorvoDewittV2]

Hm okay so yours is more inconsistent than not working at all?

[Minims]

Yes, my start code having G28 XY , G34, G29 will fails most of the time. I may look for mechanical switch. but it has work without issue since 6 months :/ I will look at all my bearing that may alter sensorless homing.

[CorvoDewittV2]

Did you update something and it got less reliable?

[ikn369330]

Only changes I made to the bugfix version was steps per mm, speed, bltouch offset, the basics, nothing else at time of configuration, no sensorles homing used tmc5160 setup, single nozzle.

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: CorvoDewittV2 [e-mail]
Sent: Tuesday, June 30, 2020 2:49:28 PM
To: MarlinFirmware/Marlin [e-mail]
Cc: Ian K Nicholas [e-mail]; Comment [e-mail]
Subject: Re: [MarlinFirmware/Marlin] [BUG] No homing of y-axis against ymin (#18212)

Did you update something and it got less reliable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/18212#issuecomment-651802947, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEAZK2BYFYJAFSN7IREZEXLRZHUORANCNFSM4NVYMRDA.

[CorvoDewittV2]

My issue was with sensorless homing, I'm kinda surprised that hardware endstops are not working right. Do the red LEDs next to the stepper motor plug come on when it homes?

[Minims]

Did you update something and it got less reliable?

I just update Marlin to latest bug fix with same config. Add G35, and then remove it. Ma last version was from the end of April.

Today I restart Marlin config from scratch to have a minimal working config. I found something strange :

M502
M500
M119
> all is open
G28 X (Working)
M119
> y_min is TRIGGERED
> x_min is open

[G4Cab]

My issue was with sensorless homing, I'm kinda surprised that hardware endstops are not working right. Do the red LEDs next to the stepper motor plug come on when it homes?

With my setup i could preclude any miswiring, cause previous firmwares hadn't the issue.
And the correct check light switches off/on if triggered

[sjasonsmith]

@G4Cab, have you tested with bugfix-2.0.x, after the change was merged? We suspect that fixed your issue, but you have never said whether you have re-tested with the change.

[G4Cab]

i pressfitted my sensor in the ymax position, can't change it back that simple.
Maybe i'll try at weekend.

Have now other troubles with this shitty GTR board. (dual-z sometimes only one motor will continue to drive, switched motors, switched drivers, switched driver socket and reassigned the pins in the pinfile, but it is not reproduceable why one z will fail, sometimes both running like a charme, sometimes one makes troubles.)

[ikn369330]

Tried very latest bugfix version today, y axis now moves forward and grinds yet if I use the controller it moves in the correct direction, when all endstops are closed they are triggered as they should be, im possibly missing something simple this time around.

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: Martin [e-mail]
Sent: Wednesday, July 1, 2020 11:47:08 AM
To: MarlinFirmware/Marlin [e-mail]
Cc: Ian K Nicholas [e-mail]; Comment [e-mail]
Subject: Re: [MarlinFirmware/Marlin] [BUG] No homing of y-axis against ymin (#18212)

i pressfitted my sensor in the ymax position, can't change it back that simple.
Maybe i'll try at weekend.

Have now other troubles with this shitty GTR board. (dual-z sometimes only one motor will continue to drive, switched motors, switched drivers, switched driver socket and reassigned the pins in the pinfile, but it is not reproduceable why one z will fail, sometimes both running like a charme, sometimes one makes troubles.)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/MarlinFirmware/Marlin/issues/18212#issuecomment-652344726, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEAZK2C6GIF6GJQKRIFZVZTRZMH2ZANCNFSM4NVYMRDA.

[G4Cab]

Today i switched from dual z driver to single z driver with splitter cable.
My second problem is gone, z moves now flawlessly. Same driver, same driver port, same motors.
Seems to be an software issue too.
I'll test more at the weekend. And will open a new issue for this z axis problem. And i'll test the y problem too.

[G4Cab]

Compiled actual bugfix version and changed homing direction to ymin.
Working again ;)

So, i'll close this issue

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