TMC2130 QUICK_HOME doesn't work

[Saur0o0n]

Description

When enabled QUICK_HOME (move both X/Y axis at once) SENSORLESS_HOMING doesn't work (it doesn't trigger ENDSTOP) - when moving only one axis at a time, it does work. Also probably ENDSTOPS_ALWAYS_ON_DEFAULT doesn't work with TMC2130 (I was also unable to trigger ENDSTOP during normal operation - but I haven't used it before, so I'm not sure).

Steps to Reproduce

1. Enable QUICK_HOME in Configuration_adv.h (of course all TMC2130 settings also need to be on)
2. Call X/Y axis home

Expected behavior: Do home of X/Y axis (moving diagonally) and stop when hitting end of every axis.

Actual behavior: [What actually happens] Carriage moves over X/Y axis diagonally, hits physical end of printer and does not triggers endstop, motors are still running loosing steps.

[dw-0]

Didn't work for me as well, but instead of actually homing and then hitting the endstops without triggering it triggered instantly and my carriages didn't even move at all.

I already tried and set the sensitivity higher... actually a LOT higher. (even tried a safety of around 60 or so). But still, instant triggering of the endstops.

Since then i disabled the feature and home only one axis at a time which works like a charm.

[thinkyhead]

What version of Marlin are you using?

[Saur0o0n]

1.1.8 from https://github.com/MarlinFirmware/Marlin/archive/1.1.x.zip

[thinkyhead]

Please test with the latest bugfix-1.1.x (and/or bugfix-2.0.x) branch to see where it stands. If the problem has been resolved then we can close this issue. If you still see the bad behavior we should investigate further.

[dw-0]

I just gave it a try again, flashed the current bugfix-1.1.x (commit 9ec8762 - 12.03.18) and enabled the Quick Home feature. It is working...but not smooth.

I observed two diffrent behaviors now:

1. case: Both carriages start homing at the same time , x-carriage hits endstop as first then stops , y-carriage stops as well without being at its endstop yet, few seconds later y-carriage moves again until hitting endstop, at the same time the x-carriage hits its endstop a second time. Homing end.

2. case: Both carriages start homing at the same time, but only jiggle one or two millimeters into homing direction. Then they stand still for a second. After that the x-carriage homes, y-carriage standing still. x-carriage hitting endstop. Then y-carriage moving until hitting endstop, motor disables. (so this behaviour could actually be compared with the quick home function disabled. its more like homing one axis at a time, just with an initial jiggle of both axes)

Which case happens when seems to be totally random to me. My sensitivity for both motors are set to 26

[thinkyhead]

If the homing speed or the travel acceleration are reduced, it might prevent stallguard getting false triggered.

[dw-0]

Actually i drive my axis pretty slow compared to others i think. My travel acceleration is set to 200mm/s² and the homing speed is set to 600mm/min. I will half the homing speed and report back again.

Will aprox take an hour or two because i do some testing right now because of another issue which occured suddenly again.

[dw-0]

Okay i just made the second try. Same bugfix commit, just changed the homing speed to 300mm/min.

Results are the same, no change in behaviour at all. Both cases still occur.

[thinkyhead]

Do you have any floating endstops or anything that could be contributing to false signals? Marlin simply responds to the endstop signals it receives, so if false endstop triggers appear to be the issue, look into the wiring. If the issue is that the steppers are being weird, you might try setting MINIMUM_STEP_PULSE to 1 or 2 to try and get more definitive STEP transitions.

[dw-0]

No floating endstops and i assume my wiring is correct. The sensorless homing without the quick_home feature works flawless. Therefore i am pretty sure my wiring is fine. If there were some problems with getting false positives in general, i should get them even with the "non_quick_home", shouldn't i?

I will try your suggestion with the MINIMUM_STEP_PULSE. Initially i set it to 0 since i wasn't quite sure which value to pick. Since the comments in the config file only say something about the A4988 and DRV8825 drivers.

EDIT: I tried MINIMUM_STEP_PULSE set to 1 and to 2. The problem still exists. But it seems like my earlier mentioned case 1 doesn't occur anymore. Out of 15 homings, it was 15 times case 2. Short jiggle into homing direction of both axes, then stop, then x homes, after that y homes. No simultanious actions, only the short jiggle at the beginning of the homing.

[Saur0o0n]

With 1.1.x bugfix it looks like my machine homes correctly with QUICK_HOME enabled. So this is fixed, unless in my case. But still ENDSTOPS_ALWAYS_ON_DEFAULT does not work - I assume this should halt the printer if it hits an endstop during normal operation, not only homing. With TMC this should be triggered, whenever any obstacle is hit - but it's not.

[thinkyhead]

@th33xitus I just noticed that you're using an old version "(commit 9ec8762 - 12.03.18)".

When I posted that you should try the latest bugfix, I was being very specific. We patched sensorless homing for quick homing after that date.

[dw-0]

@thinkyhead Two days ago as i wrote my post, that commit was the most recent one i was able to download :D but as there are new commits every few hours or at least once a day i am now "outdated" you are right.

Therefore i downloaded the now most recent commit ( commit 5c81ce2 - 14.03.18 ) and tried again. And now i see an improvement in the function. In total i send 20 G28 command in a row to test what happens and wrote down how often "case 2" appeared and how often the function worked as intended (almost). My result was: in 9 out of 20 auto homings, the Quick-Home-Function worked. So in 45% of all homing attempts.

What i observed: My x-carriage has lesser way to travel to its endstop position than my y-carriage. In those situations where quick homing worked as intended, the y-carriage stopped for a second after the x endstop was triggered, then resumed until y is triggered as well. No big of a deal since it still homed correctly and i don't really see it as an issue since the feature is working now (at least 45% of the time :D ) But just reporting you this "misbehaviour".

[thinkyhead]

Ah, so March 12. Not Dec. 3. Best to write dates in a more universal form.

[dw-0]

@thinkyhead oh yeah, sorry its the german format for dates. Forgot to mention it...

[thinkyhead]

The way we addressed previous issues was to add a delay after the first axis homes. That's the long 1/2 second delay you're seeing. It was needed to get the stallguard to "settle." Maybe a longer delay would help…?

#if ENABLED(SENSORLESS_HOMING)
  sensorless_homing_per_axis(X_AXIS, false);
  sensorless_homing_per_axis(Y_AXIS, false);
  safe_delay(500); // Short delay needed to settle
#endif

[dw-0]

If its a simple variable i can change myself (no experience in programming c++ here) just tell me the variable and the filename and what to change and i will check it :)

EDIT: Oh okay you were faster than i with my response. In which file do i find this codeblock? I can then maybe set it to 1000ms?

[thinkyhead]

Marlin_main.cpp. Sure, try 1000.

[dw-0]

The longer delay sadly didn't help with the: My result was: in 9 out of 20 auto homings, the Quick-Home-Function worked. So in 45% of all homing attempts. The result is still the same, so i think even higher values won't change much.

[dw-0]

My approach was now to lower the value just for the lulz and i set it to "250". The result was: 16 out of 20 auto homings worked. So 80% now, with the lowered delay. I don't know if its good to lower the delay, because you guys implemented it for a specific reason... but i just gave it a try anyways.

EDIT: I just halfed the value again, so i tried "125" and what should i say... it seems like the chance of an "error" gets lower with lower values xD even though i think thats definetly not what you guys intended with the delay. With the value set to 125ms i got 18 out of 20 tries working. So a 90% quote now...

Im going to set the delay to 0 now and see what i get.

UPDATE: 0ms: 16 out of 20 -> back to 80%...

[thinkyhead]

If you're not getting 100% then you're just getting lots of false stallguard triggers. More tuning of the stepper driver current and stallguard sensitivity may help. Also make sure there's nothing sticky or binding in your movement. Everything should move smoothly and easily with steppers powered off.

[marcio-ao]

Just to chime in on this thread, I too have had issues with QUICKHOME and SENSORLESS_HOMING and have been turning off QUICKHOME on our prototypes that use sensorless homing.

I tested it again on bugfix-2.0.x yesterday and it failed, so I don't quite suspect it is fixed. Would be curious to know if anyone has actually gotten QUICKHOME and SENSORLESS_HOMING to work together.

[Saur0o0n]

Like I wrote before - yes it works for me (TMC2130 + SENSORLESS_HOMING + QUICKHOME) on 1.1.x bugfix. It's even printing right now :)

[marcio-ao]

Interesting. What happens to me is that with both enabled sometimes the X axis fails to detect the stall upon hitting the endstop and the motor skips continuously, making quite the racket. This only happens when QUICKHOME is enabled.

One thing that may or may not be relevant is that we are using an unreleased EinsyRetro board from Ultimachine. These boards are a bit different in that they tie both diag pins on the TMC driver with a pullup resistor, so that I had to call st.diag0_active_high(0) and st.diag1_active_high(0) and then set the X_MIN_ENDSTOP_INVERTING to true. Not sure whether that possibly is messing with the QUICKHOME logic.

[Saur0o0n]

I have Chinese TMC boards (https://adrian.siemieniak.net/portal/mks-gen-1-4-board-with-tmc2130-and-marlin-firmware-howto/). But since you mentioned, it happened to me twice - homing of one axis did not triggered endstop, and motor started to skip steps continuously - but since it was on early stage of my construction, I'm not sure what was the real cause.

[thinkyhead]

only happens when QUICKHOME is enabled

It's an oddity. Both X and Y are being monitored during QUICKHOME, so maybe there's some interaction going on where the signal from one is being swallowed by the non-signal from the other. Maybe some diodes would help.

[boelle]

@Saur0o0n still having issues with latest bugfix 2.0 ?

[Saur0o0n]

I'm still on 1.1.9 and I don't have a problem with QUICKHOME - it's working. I had a problem with "ENDSTOPS_ALWAYS_ON_DEFAULT" - but I haven't check it lately.

[boelle]

then maybe close this one and create a new "issue" if it's a bug as such

but you should update to 2.0

[Saur0o0n]

If we are talking about my initial report - definitely this can be closed. QUICKHOME is working since 1.1.8 for TMC - at least on my config.

[boelle]

Always nice to hear that bugs are gone, maybe one day we have them all fixed :-D

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