Open rondlh opened 11 months ago
That PR also broke sensorless probing on deltas, so I'll mark this as confirmed. https://github.com/MarlinFirmware/Marlin/pull/25758#issuecomment-1661456614
I'm curious, why do you use SPI_ENDSTOPS
instead of SENSORLESS_HOMING
on the Monster8?
DEBUG_LEVELING_FEATURE
:Marlin/src/gcode/calibrate/G28.cpp: In lambda function:
Marlin/src/gcode/calibrate/G28.cpp:266:38: error: 'DEBUG_ECHOF' was not declared in this scope; did you mean 'DEBUG_ECHO'?
266 | if (DEBUGGING(LEVELING)) { DEBUG_ECHOF(s); DEBUG_ECHOLNPGM(" current: ", a, " -> ", b); }
| ^~~~~~~~~~~
| DEBUG_ECHO
I'm curious, why do you use
SPI_ENDSTOPS
instead ofSENSORLESS_HOMING
on the Monster8?
I use both basically (SPI_ENDSTOPS and SENSORLESS_HOMING), the TMC driver detects the endstop (SENSORLESS_HOMING), but instead of reading the signal from the driver via an endstop connecotr, I use SPI_ENDSTOPS to read the endstop status via SPI. So now I have 2 endstop connectors available (X- and Y-) for other purposes, and I don't depend on the correct setting of the jumpers.
Using the endstop connectors (instead of SPI_ENDSTOPS) with ENDSTOP_INTERRUPTS_FEATURE would probably be more accurate. Any other concerns/recommendations?
I use both basically (SPI_ENDSTOPS and SENSORLESS_HOMING)
Oh, I missed the "n" in #ifndef
:
#ifndef IRON_IDEX // IDEX doesn't use sensorless homing, too inaccurate!
#define SENSORLESS_HOMING // StallGuard capable drivers only // IRON, enabled for X and Y axis
#endif
What is the source of your fork/config files? They are not stock Marlin. For example:
#define EXTUI_IRON_BTT_TFT // IRON, for TFT, used in UI_IRON.cpp
We don't have an "IRON UI"/UI_IRON.cpp
I get a bunch of errors trying to compile with your configs.
IRON is the code word I use for my custom changes. IRON UI is my custom UI for the BTT TFT35 V3.0 touch screen. The config supports 4 printers, so it's a bit complex, and there are some customizations.
I attached Marlin bugfix of August 2nd with my config. This build shows the homing problems. Marlin_230802-IRON.zip
UPDATE: "G28 X" works fine! "G28 Y" doesn't work, the Y-motors never move and "Homing failed" is reported after a few seconds. Note, there are 2 Y-motors. What's quite odd about this is that not even the homing bump move is executed. I confirmed that the Y-axis is activated, but no Y-movement at all. If I disable SPI_ENDSTOPS (and set some jumpers) then "G28 Y" also works fine.
UPDATE 2 I tested if homing works when I disable Y2 (// #define Y2_DRIVER_TYPE TMC5160). THAT WORKS FINE!
So the issue seems to be related to SPI_ENDSTOPS in combination with 2 drivers on an axis.
MY CONFIGURATION: Cartesian XY layout Sensorless homing for X, Y1 and Y2 SPI_ENDSTOPS Z-homing with BLTouch
I found the cause of the problem I am having (no movement when homing Y with Y_DUAL_ENDSTOPS in combination with SPI_ENDSTOPS). In Conditionals_post.h
Old line:
#define _USE_STOP(A,N,M,C) ((A##_HOME_TO_##M || (C+0)) && PIN_EXISTS(A##N##_##M))
New line:
#define _USE_STOP(A,N,M,C) ((ANY(A##_HOME_TO_##M, A##N##_SAFETY_STOP) || (C+0)) && PIN_EXISTS(A##N##_##M) && !A##_SPI_SENSORLESS)
Note the addition of "&& !A##_SPI_SENSORLESS" at the end. If you delete that addition, then things work for me.
#define _USE_STOP(A,N,M,C) ((ANY(A##_HOME_TO_##M, A##N##_SAFETY_STOP) || (C+0)) && PIN_EXISTS(A##N##_##M))
would this have to do with the entire ENDSTOP section missing? on my Hornet I normally define the below, however that section is no longer in the latest bugfix //#define USE_XMIN_PLUG
//#define USE_YMAX_PLUG //#define USE_ZMAX_PLUG ahh, looks like that was replaced with Inverting Stepper Pins section?
ahh, looks like that was replaced with Inverting Stepper Pins section?
No, they’re automatically defined based on homing direction now.
hmm, ok let me keep testing then, I am using the same directions as always and steppers are going opposite. Don't want to hijack thread if it doesn't pertain.
Another unintended consequence of the refactoring is that using USE_PROBE_FOR_Z_HOMING
without Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
(ie. a probe plugged into a dedicated probe port that is used for homing) causes USE_Z_MIN
to still be defined.
This causes Z_MIN endstop to be enabled in addition to the probe. It's not used for anything, in my tests I don't even have anything connected to the z-min port and homing still uses the probe and works properly.
Disabling the Z_MIN endstop now requires hacking conditionals_post.h. USE_Z_MIN
should not be set when using USE_PROBE_FOR_Z_HOMING
and not Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN
, but HAS_Z_MIN_STATE
does still need to be set.
I did finally figure it out, ended up being a mix of the "new to me" wording of Endstop Hit state High Low, vs True False as well as what The-EG mentioned where I had to also disable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and ensure both USE_PROBE_FOR_Z_HOMING as well as Z_MIN_PROBE_PIN PC2 are enabled with a pin defined. only then did everything function as intended. I see where this could function if I decided to user the now open Z_MIN_ENDSTOP for a filament runout sensor I could.
How am I supposed to home X and Y now that USE_XMIN_PLUG doesn't work, they both crash into the gantry when homing.
Did you test the latest
bugfix-2.1.x
code?Yes, and the problem still exists.
Bug Description
After #25758 (More endstops refactoring) homing doesn't work anymore. When sending G28 no axis move and the printer reports "Homing failed". I use SPI_ENDSTOPS for X, Y and Y2 based on TMC5160, and Z-homing based on a BLtouch. Disabling SPI_ENDSTOPS.solves this issue. Also disabling the Y2 driver (// #define Y2_DRIVER_TYPE TMC5160). solves the issue. So there seems to be a conflict between SPI_ENDSTOPS and using 2 motors on an axis.
Bug Timeline
25758 August 2nd 2023
Expected behavior
Homing works as before
Actual behavior
No movement at all after an G28, just reports homing failed after a few seconds. "G28 X" works fine. But no movement for "G28 Y", just a "Homing failed" message after a few seconds. I believe this is related to SPI_ENDSTOPS, because when I disable it (and add some jumpers) then G28 works fine. I have 2 Y-motors, perhaps that is the cause of the problem.
Steps to Reproduce
Version of Marlin Firmware
bugfix August 4th 2023
Printer model
Custom
Electronics
MKS Monster8 V1.0
Add-ons
BTT TFT35 V3.0
Bed Leveling
ABL Bilinear mesh
Your Slicer
Cura
Host Software
None
Don't forget to include
Configuration.h
andConfiguration_adv.h
.Additional information & file uploads
To confirm the issue I downloaded Marlin August 2nd 2023, added my Configuration, PlatformIO, pins files, ExtUI files. Configuration.zip