[BUG] SKR 1.3 TMC2209 Endstops Mapping Incorrectly

[KCGreg]

I have an SKR 1.3 that I am using for a CNC with the below options defined. I am wanting to use all 5 stepper drivers. X, Y, Z, Y2, Z2 with 2 motors on both the Y and Z axis, and sensor-less homing. I believe this may be related to issue #16619 .

TMC2209 UART Mode / All Diag jumpers in place

#define EXTRUDERS 0
#define Y_DUAL_STEPPER_DRIVERS | #define Y_DUAL_ENDSTOPS
#define Z_DUAL_STEPPER_DRIVERS | #define Z_DUAL_ENDSTOPS

I am getting the following behaviors when I test this board using only one 2209 stepper plugged in at a time.The following combinations are occurring, the stepper is across the top, end-stops are on the left.

In the below tables (or the easier to read attached diagram), the end-stop shown is being tested and is reporting as (O)pen, all others are reporting as (T)riggered. Notice Z2 and Y2 are triggering incorrect end-stops.

#define Z_HOME_DIR -1 , //#define USE_ZMAX_PLUG
  | X | Y | Z | Y2 | Z2
xmin | O |   | |   |  
ymin |   | O |   |   |  
y2min |   |   |   |   | O
zmin |   |   | O |   |  
z2min |   |   |   | O |  

In the below example, the same behavior with incorrect endstops triggering is noted. In the case of the Z motor driver, all 5 endstops are (T)riggered and none are (O)pen.
#define Z_HOME_DIR 1 , //#define USE_ZMIN_PLUG
  | X | Y | Z | Y2 | Z2
xmin | O |   |   |   |  
ymin |   | O |   |   |  
y2min |   |   |   |   | O
zmax |   |   | T |   |  
z2max |   |   |   | O |  

Both Y and Z axis crash into frame with end-stops triggering in this manner.

[ellensp]

This is issue #16619. SKR 1.3 pins files assumes your using sensorless homing and doesn't work correctly with real endstops on Max pins.

[KCGreg]

This is issue #16619. SKR 1.3 pins files assumes your using sensorless homing and doesn't work correctly with real endstops on Max pins.

Thanks @ellensp ! Did you notice in my table that Y2 steppers were triggering Z2 endstops, and and Z2 steppers were triggering Y2 endstops? From the text of #16619 I didn't quite understand if the pin definitions would fix this.

[ellensp]

I found your description a little confusing.. The issue 16619 has been fixed and added to bugfix. So grab the latest bugfix and try that.. if its still an issue we can look deeper.

[KCGreg]

Hi @ellensp thanks for the quick response. I compiled using the lastest bugfix, as requested. The problem I am seeing still persists with the exception of z stepper triggering z_max, which has been fixed - Thanks!

When the firmware is setup to use dual_y and dual_z steppers and endstops, the y2 stepper seems to be triggering the z2-min endstop. The z2 stepper is triggering the y2-min endstop. I had to troubleshoot this by 1) removing all stepper motor drivers and 2) issuing an m119 with only a single driver installed first in the x socket, then repeating for y, z, y2, then z2. The chart I posted had 2 separate tests cycles, 1) where homing was to z_min, and 2) where homing was to z_max.

In the below example (homing to z_max), only the Z2 driver is installed, when I issue an M119, y2_min is showing open when it should be z2_max. If I switch homing to z_min and retest, y2_min also shows open.

[boelle]

Configurations, please
Please ZIP up your Configuration.h and Configuration_adv.h files (as
requested in the Issue template) and drop them into your next reply.
We'll check them over and see if anything is amiss.

[KCGreg]

@boelle Thanks for looking into this. Attached are the requested files.
SKR1_3.zip

[ellensp]

want   have   hardwired (for sensorless you must use these settings on skr1.3)  
x        X         x-min   
y        Y         y-min   
z        Z         z-min   
y2      E0        x-max   
z2      E1        y-max  

but in Configuration_adv.h you have the following

#define Y2_USE_ENDSTOP _YMAX_   
#define Z2_USE_ENDSTOP _XMAX_ 

Both of these are incorrect

Change them to

#define Y2_USE_ENDSTOP _XMAX_   
#define Z2_USE_ENDSTOP _YMAX_ 

And it works as expected

[KCGreg]

That did it! @ellensp and @boelle - I really appreciate the assist!

[KCGreg]

I thought this was fixed as Z2 was no longer having an issue. However, z_max is immediately showing as triggered after reconnecting the board. If I change my homing to min instead of max, everything seems to work fine, however, due to the configuration of my CNC max homing is needed.

SKR 1.3.zip

[ellensp]

You set USE_ZMAX_PLUG and are using sensorless homing. This is in conflict, when you use sensorless homing you must use ZMIN_PLUG
But if you set USE_ZMIN_PLUG and home z toward 1, you get errors in the sanity checker as marlin doesn't think that is a real possibility. (further even bypassing this check does not work)

I think the best answer for you is a custom change to the pins_BTT_SKR_V1_3.h file.
Line 47 of pins_BTT_SKR_V1_3.h is "#if Z_HOME_DIR > 0 && Z_STALL_SENSITIVITY && !defined(USE_ZMAX_PLUG)"
change this to "#if Z_HOME_DIR > 0 && Z_STALL_SENSITIVITY"

This will get you going...

[KCGreg]

Thanks again. That makes perfect sense to me. Looking at the pins definition on the Bigtreetech Github, the diag jumpers on the SKR 1.3 would connect the X,Y,Z,E0, and E1 drivers to X-, Y-, Z-, X+, Y+ endstops in that order. I assume that would leave the Z+ pin 1_24 (now defined as z_min) open for a probe or other connection? I will make the change and test later today.

[KCGreg]

@ellensp I tested and that did the trick. I'll watch for the finalized fix to be merged and will update again at that time. I appreciate you working through this!

[thinkyhead]

For one of the boards that has the stepper driver DIAG (stallGuard / sensorless homing) pins hard-wired to the MIN pins, we opted to swap the definitions of the MIN/MAX endstop pins whenever sensorless homing is enabled and homing is to the MAX end for that axis. This causes some pins labeled on the board as "MAX" to be named as MIN endstops pins in Marlin, and this is what is shown in the output of M43. It's an imperfect solution, but not a bad one, so we will soon do the same for other boards with hard-wired DIAG pins.

[KCGreg]

@thinkyhead @ellensp @boelle - it's unbelievable to me the amount of time and effort you place on this firmware and the issues sometimes encountered with new technology. It is greatly appreciated! Thanks again for the changes to get this working.

[thinkyhead]

I see that the E0 and E1 drivers also map some DIAG pins to endstops. That's interesting! I'll try to also get those remapped properly as part of the X2/Y2/Z2/Z3/Z4 auto-assignment section in pins.h.

[KCGreg]

@thinkyhead This following diagram shows how the DIAG pins connect the drivers to the endstops. It is on the right side of the page just to the right of the TMC2208-UART label.

https://github.com/bigtreetech/BIGTREETECH-SKR-V1.3/blob/master/BTT%20SKR%20V1.3/hardware/SKR-V1.3-PIN.pdf

[github-actions]

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.