Sensorless homing mit tmc2130 und Marlin Bugfix 1.1x

Hallo,

ich versuche mich gerade am sensorless homing mit den tmc2130 treibern im spi mode.
Beim Board handelt es sich um ein Ramps 1.4 Board mit der aktuellsten Bugfixversion 1.1.x
Für das sensorless homing habe ich auf der x und y Achse dbg1 vom tmc2130 Treiber mit dem x_max und und y_max Eingang für die Endstops verbunden.
Ich habe die Pullups für diese Eingänge aktiviert und auch die Eingänge der Endstops invertiert (Fallende Flanke aktiviert Endstops).

Das ganze sollte zumindest richtig konfiguriert sein. Denn beim Homing fällt auch kurz der Pegel ab (mit Oszi gemessen).
Allerdings fällt der Pegel schon nach 1-2 mm Bewegung ab.

Ich habe die Einstellungen für die Sensitivität schon so niedrig wie möglich gestellt:

#if ENABLED(SENSORLESS_HOMING)
#define X_HOMING_SENSITIVITY 63
#define Y_HOMING_SENSITIVITY 63
//#define Z_HOMING_SENSITIVITY 8
#endif

Könnte dies eventuell daran liegen, dass ich die Schrittmotoren mit 24V betreibe und Stallguard2 die ganze Zeit zuschlägt?
Habe schon bei Steppern Einstellungen an den Stromaufnahmeeinstellungen rum gespielt.
Habe alle Stromstärken zwischen 600-1200mA probiert ohne einen Erfolg zu haben.
Am saubersten laufen die Stepper allerdings mit circa 720 mA.

Danke schon mal im Voraus für die Unterstützung

Hast Du die Werte direkt so stark erhöht?

   * Lower value make the system MORE sensitive.
   * Too low values can lead to false positives, while too high values will collide the axis without triggering.

Herzl. Grüße

Ich habe erst mal mit den Standardwerten angefangen (waren glaub 8). Nach Oszi triggert es ja auch bei der maximalen Einstellungen.
Ich vermute, dass die Treiber wegen der 24V Spannungsversorgung "zu früh" den Stallguard2 aktivieren.

Ich würde die grundsätzliche Funktion mal hiermit testen:
[github.com]

Herzl. Grüße

Also ich hab die TMC2130 mit 24V und Sensorless Homing aktiv. Die X_HOMING_SENSITIVITY liegt bei mir bei 6 bis 8. Über 8 fährt er gegen die Wand und verliert Schritte ohne zu triggern. Wie es mit 68 funktionieren soll erschließt sich mir nicht.

---

P3Steel Toolson MK2 / TMC2209 + TMC2100 / Marlin 1.1.8 / Ramps 1.4 / 24V / S3D

Vielen Dank für die Unterstützung.

Bin aus gesundheitlichen Gründen erst heute zum Testen gekommen.

Mit dem Stallguardtest funktioniert es ohne Probleme mit einer Einstellungen für die SENSITIVITY von 8.
Allerdings habe ich diesen Test mit folgender Option gemacht : driver.diag1_stall(1);
Gemessen habe ich den Diag 1 Ausgang direkt mit dem Oszi. Beim aktivieren von Stallguard sprang der Pegel von 0 auf 5 V an.

In Marlin wird die Logik ja umgekehrt, sprich driver.diag1_stall(0);

Die Pullups für die Endstopeingänge sind gesetzt und die Eingänge und die Logik für die Eingänge invertiert.
So lange der der Diag1 Ausgang nicht an den Pins für die Endstops angeschlossen sind, messe ich 4,95 V an den Eingängen => Pullups tatsächlich aktiviert.
Schließe ich den Diag1 Ausgang an, dann liegen nur noch 3,48 V am Eingang an => Sollte aber für ein logisches High-Level reichen.Die Stepper sind zu diesem Zeitpunkt nicht "enabled"

Wenn ich das Homing starte ohne dass der Diag 1 Ausgang am Endstopeingang angeschlossen ist, dann laufen den Stepper bis ich den Diag 1 anschließe.
Die Spannung fällt am Eingang allerdings dabei nicht unter 3,4 V.

Ich bin ein wenig ratlos....

Die Pullups solltest Du vielleicht deaktivieren.

Herzl. Grüße

Das wird wohl nicht der richtige weg sein, da dann dies passieren würde:

#elif X_SENSORLESS && X_HOME_DIR == 1 && (DISABLED(X_MAX_ENDSTOP_INVERTING) || DISABLED(ENDSTOPPULLUP_XMAX))
#error "SENSORLESS_HOMING requires X_MAX_ENDSTOP_INVERTING and ENDSTOPPULLUP_XMAX when homing to X_MAX."

Sensorless Homing setzt aktive Pullups und umgekehrte Logik voraus...

Hm, aus der Beschreibung von Watterott:

Quote

DIAG1 Diagnostics Output 1 (100k pulldown to GND)

Herzl. Grüße

Gerade dann müssen Sie doch aktiviert sein:

Der Ausgang ist ein Open Drain Ausgang. Der Pulldown Widerstand soll den Ausgang des Diag1 auf Ground ziehen.
Dieser ist mit 100k sehr hoch gewählt.

Am Arduino wird der Pull-Up aktiviert. Diser müsste irgendwas zwischen 20k bis 50k haben.

Daraus ergibt sich eine Reihenschaltung des Pullup am Arduino un des Pulldown am Diag 1.
Dabei müsste sich in etwa so etwas ergeben:

         VCC
          +
          |
          |
         .-.
         | |
         | |  47k
         '-'
          |
  Endstop |
  Eingang o------------o Arduino Mega
          | 3,3 V
          |
          |
          |
          |
          |
  Diag1   o----------.
          |          |
         .-.          <|
         | |           |-
         | | 100k     /|
         '-'         |
          |
          |
          |
          |
         ===
         GND

Wen der Transistor vom TMC2130 geschaltet wird, dann kann der Strom über den Transistor abfließen und der Eingang am Arduino wird auf 0 V gezogen.

         VCC
          +
          |
          |
         .-.
         | |
         | |  47k
         '-'
          |
  Endstop |
  Eingang o------------o Arduino Mega
          |
          | 0 V
          |
          |
          |
          |
  Diag1   o----------.
          |          |
         .-.          <|
         | |           |-
         | | 100k     /|
         '-'         |
          |
          |
          |
          |
         ===
         GND

Eventuell schreibe ich aber auch Käse, da ich diese Open Drain Geschichte falsch verstanden habe

Du hast Recht. Die Änderung wurde wohl
deswegen [github.com] eingeführt.
Könntest Du bei Dir einfach ändern.

Herzl. Grüße

Mal ein kurzes Update.
Habe jetzt nochmals das Stallguard Testprogramm laufen lassen. Dabei ist mir aufgefallen, dass auch beim Beschleunigen des Motors der Diag1 Pin geschaltet wird.
Allerdings ist das billig USB-Oszi von Hantek extrem bescheiden was das Triggern angeht. Sehr oft triggert es einfach nicht.
Kauft euch ja nicht das Hantek 6022BE, wenn ihr damit ernsthaft solche kurzen Ereignisse Triggern wollt

Ich kauf mir jetzt erst mal nen gescheites Oszi, damit ich mal wenigsten im Stallguardtestprogramm sehe, was Sache ist.
Habe mir mal das Datenblatt zum TMC2130 genauer angeschaut. Da kann man doch noch mit einigen Einstellungen den Stallguard optimieren.

Und ja, ich könnte auch einfach wieder die Endstops dran bauen. Dann könnte ich mir aber auch einen fertigen Drucker kaufen

2-mal bearbeitet. Zuletzt am 21.03.19 15:03.

Nachdem das Ganze nun funktioniert, wollte ich hier mal meine Erkenntnisse posten:

Das eigentliche Problem waren nicht die Einstellungen für die Endstops etc.

Das Problem war, dass meine Hominggeschwindigkeit zu gering war. Bei einer zu geringen Geschwindigkeit ist zumindest mit meinen Steppern und dem TMC2130 keine funktionierende "Stalldetection" möglich bzw. dauerhaft aktiviert. Unabhängig von der Sensitivität. Das führt allerdings auch dazu, dass während der Beschleunigung ein "Blockieren" der Motoren detektiert wird und der Debug 1 Ausgang des TMC2130 auslöst.


Aus diesem Grund habe ich in der Datei "stepper_indirection.cpp" die Einstellungen des Stallguard-Sketch übernommen, welche bei mir zuverlässig funktioniert haben:

//File: stepper_indirection.cpp

   void tmc2130_init(TMC2130Stepper &st, const uint16_t mA, const uint16_t microsteps, const uint32_t thrs, const float spmm) {
     #if DISABLED(STEALTHCHOP) || DISABLED(HYBRID_THRESHOLD)
       UNUSED(thrs);
       UNUSED(spmm);
     #endif
     st.begin();
     st.setCurrent(mA, R_SENSE, HOLD_MULTIPLIER);
     st.microsteps(microsteps);
     st.blank_time(24);
     st.off_time(5); // Only enables the driver if used with stealthChop
     st.interpolate(INTERPOLATE);
+    st.power_down_delay(32); // ~2s until driver lowers to hold current
+    st.hysteresis_start(4);
+    st.hysteresis_end(-2);
+	st.semin(5);
+	st.semax(2);
+	st.sedn(0b01);
+	st.coolstep_min_speed(0x000100);

Eine der wichtigsten Einstellung wird wohl diese sein:

+	st.coolstep_min_speed(0x000100);

Damit wird indirekt festgelegt, ab welcher Geschwindigkeit überhaupt Stallguard aktiviert wird. Dieser Wert ist natürlich bei jedem Stepper/ Drucker unterschiedlich einzustellen.
Dies verhindert bei mir, dass schon beim Beschleunigen Stallguard auslöst.

Zur Sicherheit habe ich auch noch die Datei "tmc_util.cpp" angepasst:

//File: tmc_util.cpp

     void tmc_sensorless_homing(TMC2130Stepper &st, const bool enable/*=true*/) {
+    //st.coolstep_min_speed(enable ? 1024UL * 1024UL - 1UL : 0);
+	st.coolstep_min_speed(enable ? 0x000100 : 0);	//2019-03-29 theblackraven
     #if ENABLED(STEALTHCHOP)

Zudem hat die festgelegte Motorstromstärke einen wesentlichen Einfluss auf die "Stalldetection". Je geringer die Stromstärke, desto geringere Geschwindigkeiten können für das Homing verwendet werden.

Aus diesem Grund setze ich die Stromstärke vor dem Homing im G-Code auf einen niedrigeren Wert und danach wieder auf den Wert für den Druck:

M906 X500 Y500; Set max steppercurrent to 500 mA
M914 X1 Y3; Set TMC Bump Sensitivity
M906 Z1000; 
G28 ; home all axes
M906 X760; Set max steppercurrent to 720 mA
M906 Y760; Set max steppercurrent to 720 mA

Hier noch die restlichen Einstellungen:

Das Homing findet bei meinem Drucker in die positive Richtung statt:

//File: Configuration.h

// Direction of endstops when homing; 1=MAX, -1=MIN
// :[-1,1]
#define X_HOME_DIR 1
#define Y_HOME_DIR 1

Die Pullups müssen müssen aktiviert werden:

//File: Configuration.h


 #if DISABLED(ENDSTOPPULLUPS)
   // Disable ENDSTOPPULLUPS to set pullups individually
   #define ENDSTOPPULLUP_XMAX
   #define ENDSTOPPULLUP_YMAX
 #endif

Die Logik für die Enstops muss invertiert werden:

 #define X_MAX_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.
 #define Y_MAX_ENDSTOP_INVERTING true // set to true to invert the logic of the endstop.

Elektrisch verhält sich das so wie in diesemt: Post

Es muss das Sensorlesshoming aktiviert werden:

//File: Configurationh_adv.h


#define SENSORLESS_HOMING // TMC2130 only
 
 #if ENABLED(SENSORLESS_HOMING)
    #define X_HOMING_SENSITIVITY  3
    #define Y_HOMING_SENSITIVITY  3
     //#define Z_HOMING_SENSITIVITY  8
#endif

4-mal bearbeitet. Zuletzt am 05.04.19 07:13.

*gelöscht*

2-mal bearbeitet. Zuletzt am 05.04.19 07:11.