Endstops und Homing

Guten Morgen zusammen,

ich bin neu im Thema 3D-Drucker und versuche mich am FranzisMendel.
Bisher ist es super gelaufen, allerdings habe ich Probleme im Bezug auf die Funktion der Endstops und dem damit verbundenen Homing.

Daten:
- FranzisMendel
- Arduino Mega 2560
- mechanische Endstops --> alle als min Endstops definiert
- Software: Marlin 1.1.9
- Repetier-Host V2.1.6

---

Funktion:
Bisher funktionieren alle Motoren. Deren Drehrichtung ist so eingestellt, dass wenn ich in der Repetier-Host Software einen positiven Wert verfahren will, diese in Richtung der Enstops fahren. Bei der X-Achse nach rechts, bei der Y-Achse nach hinten und bei der Z-Achse nach unten.
Extruder-Heizung und Heizbett inkl. Temperaturfühler funktionieren und erreichen die eingestellten Temperaturen.

Die Endstops haben bisher keine merkbare Funktion. Laut "Anleitung" und sonstigem was man im Netz findet, sollten beim Homing die fahrt unterbrochen werden, sobald die Endstops betätigt werden (was ja auch Sinn macht).
Diese leuchten bei Betätigung rot und wenn man den "plus" gegen den Neutralleiter misst, habe ich 0V bei betätigtem Schalter. Unbetätigt sind es knapp unter 5V.
Hier der Link zum Endstop
Ich habe dann in der Datei versucht die Logik zu invertieren, was aber weder beim Messen, noch bei dem Versuch mit den Achsen erneut die Endposition zu erreichen einen Erfolg oder eine Änderung gebracht hat.

---

Keine Funktion beim Homing:
Ich weiß natürlich nicht, ob das mit der Fehlfunktion der Endstops zusammenhängt, aber das Homing zeigt kein sinnvolles Verhalten. Dass dies ohne die Endstops nicht funktionieren kann, ist klar, das Verhalten ist dennoch komisch.
Wenn ich in der Repetier-Software bspw. den X-Achsen Homebutton betätige, verfährt die Achse um einen kleinen Weg in Richtung des Endstops, bleibt aber dann sofort wieder stehen (Weg <10mm). Nach meinem Verständnis müsste
nach Betätigung der Homeposition die Achse bis zum Flankenwechsel des Endstops in diese Richtung fahren. Könnte mir vorstellen, dass dies nicht geht aufgrund eines fehlenden Signals an der Steuerung vom Endstop, weiß das aber nicht.

Ich hatte die Endstops anfangs falsch rum eingesteckt, was bei Betätigung des Endstops vermutlich immer einen Kurzschluss ausgelöst hat und somit die Verbindung jedes Mal unterbrochen wurden.


Hier noch meine Configuration.h Datei mit der Hoffnung, dass jemand damit besser klar kommt als ich
Marlin3DPrinterFirmware.pdf

Bin ehrlich gesagt mit meinem Anfänger-Latein ziemlich am Ende und würde mich über jeden Tipp freuen

Vielen Dank


Liebe Grüße Tom

... zuerst müssen die Taster entsprechend als X-MIN/MAX, Y-MIN/MAX oder Z-MIN/MAX erkannt werden - dafür müssen die zugeordmeten Pins und die Polarität auch stimmen.

Überprüfen kannst du das mit dem Befehl "M119", welcher dir den aktuellen Status aller Endschalter ausgibt -- mach das dann für jeden Schalter mit "Offen" und "Ausgelöst", ob der Status bei der Abfrage mit M119 sich verändert ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Hallo,

vielen Dank für deine Antwort.

Ich habe das im Moment getestet. Mit folgendem Code (wie er auch in der hochgeladenen Datei ist) habe ich im nicht betätigten Zustand bei allen drei Sensoren den Status "TRIGGERED". Wenn ich die Sensoren betätige steht "open" da. Also irgendeinen Signalwechsel scheint es zumindest mal zu geben. Ist das richtig oder ist das falsch?

// Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup).
#define X_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.   
#define Y_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop. 
#define Z_MIN_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop. 
#define X_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Y_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MAX_ENDSTOP_INVERTING false // set to true to invert the logic of the endstop.
#define Z_MIN_PROBE_ENDSTOP_INVERTING false // set to true to invert the logic of the probe.

Wenn ich die werte von "false" auf "true" ändere, ist es genau andersrum. Im nicht betätigen Zustand "open" und im betätigten "TRIGGERED".


Wie kann ich an dieser Stelle weiter machen?


Liebe Grüße Tom

... mit "true" (also "Triggered" wenn betätigt) bist du schonmal auf der richtigen Spur.

Jetzt mußt du noch die Homin-Richtung bezüglich MIN/MAX richtig einstellen (oder die den Tastern zugeordneten I/O-Pins tauschen), dann sollte das passen ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Wunderbar, ich habe alles soweit hinbekommen.

Eben den ersten Probedruck gemacht. Hat angefangen, man hat gesehen wo noch nachgebessert werden muss, usw.

Dummerweise ist er dann ausgestiegen mit folgender Meldung (welche ich schon einmal hatte, dann allerdings einen Wert angepasst habe):

Rotes Fenster:

Fataler Fehler
Ein fataler Fehler im Drucker veranlasste den Drucker alles zu stoppen bis der Fehler behoben ist. Nachricht des Drucker:

Error: Heating failed, system stopped! Heater_ID:bed

Als ich während der manuellen Kontrolle den Fehler das erste Mal hatte, habe ich etwas recherchiert. Im Internet stand, dass man den Wert
"Watch_Bed_Temp_Period" in der Datei "Configuration_adv.h" erhöhen soll. Das habe ich gemacht, er steigt aber dennoch aus.

Hier der Code-Ausschnitt:

/**
 * Thermal Protection provides additional protection to your printer from damage
 * and fire. Marlin always includes safe min and max temperature ranges which
 * protect against a broken or disconnected thermistor wire.
 *
 * The issue: If a thermistor falls out, it will report the much lower
 * temperature of the air in the room, and the the firmware will keep
 * the heater on.
 *
 * The solution: Once the temperature reaches the target, start observing.
 * If the temperature stays too far below the target (hysteresis) for too
 * long (period), the firmware will halt the machine as a safety precaution.
 *
 * If you get false positives for "Thermal Runaway", increase
 * THERMAL_PROTECTION_HYSTERESIS and/or THERMAL_PROTECTION_PERIOD
 */
#if ENABLED(THERMAL_PROTECTION_HOTENDS)
  #define THERMAL_PROTECTION_PERIOD 40        // Seconds
  #define THERMAL_PROTECTION_HYSTERESIS 4     // Degrees Celsius

  /**
   * Whenever an M104, M109, or M303 increases the target temperature, the
   * firmware will wait for the WATCH_TEMP_PERIOD to expire. If the temperature
   * hasn't increased by WATCH_TEMP_INCREASE degrees, the machine is halted and
   * requires a hard reset. This test restarts with any M104/M109/M303, but only
   * if the current temperature is far enough below the target for a reliable
   * test.
   *
   * If you get false positives for "Heating failed", increase WATCH_TEMP_PERIOD
   * and/or decrease WATCH_TEMP_INCREASE. WATCH_TEMP_INCREASE should not be set
   * below 2.
   */
  #define WATCH_TEMP_PERIOD 180                // Seconds          (war 20)
  #define WATCH_TEMP_INCREASE 2               // Degrees Celsius
#endif

/**
 * Thermal Protection parameters for the bed are just as above for hotends.
 */
#if ENABLED(THERMAL_PROTECTION_BED)
  #define THERMAL_PROTECTION_BED_PERIOD 20    // Seconds              
  #define THERMAL_PROTECTION_BED_HYSTERESIS 2 // Degrees Celsius

  /**
   * As described above, except for the bed (M140/M190/M303).
   */
  #define WATCH_BED_TEMP_PERIOD 240               // Seconds        (war 60)
  #define WATCH_BED_TEMP_INCREASE 2               // Degrees Celsius
#endif

#if ENABLED(PIDTEMP)
  // this adds an experimental additional term to the heating power, proportional to the extrusion speed.
  // if Kc is chosen well, the additional required power due to increased melting should be compensated.
  //#define PID_EXTRUSION_SCALING
  #if ENABLED(PID_EXTRUSION_SCALING)
    #define DEFAULT_Kc (100) //heating power=Kc*(e_speed)
    #define LPQ_MAX_LEN 50
  #endif
#endif

Hast du, oder jemand anders eine Idee, woran das liegen könnte? Scheinbar ist dieses Heizbett sehr träge aber ich weiß auch nicht, was ich jetzt genau anpassen soll.


Vielen Dank

... ich habe bei meinen FDM-Druckern meist die Temperaturregelung komplett deaktiviert und regele die Hotend und Bett-Temperaur über Industrie-Temperaturcontroller ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Gerade wegen solchen Gründen? Was für welche verwendest du da? Kennst du eine Lösung wie ich das vorerst auch so in Griff bekommen kann?

... nein, eher aus "Gewohnheit" aus den Anfangstagen des RepRap-Projekts (um 2007 und danach), als ich mit der Gen3 auf einem der alten Arduinos noch am "tüfteln" war und die Temperaturregelung extern einfach weniger Probleme machte ... und später auch noch, weil ich für eine der damaligen Firma hochgenaue Temeperaturcontroller mit bis zu 0.01°C Regel-Genauigkeit mit entwickelt habe, die einfach besser liefen, als alle damals auf dem Markt oder in den diversen Projekten verfügbaren

Fürs Bett habe ich meist einen Watlow-Industrie-Controller, für die hotends verschiedene Typen oder auch wieder meine eigenen (bin gerade wieder in einem Projekt, wo ich Temperaturregelungen für Metalldraht-Aufschmelzen mit Temp-Regelbereichen bis 600°C aufbaue, die sind aber noch nicht "spruchreif").

Für schnell mal was günstiges kannst du bei ebay schauen - das geht da schon bei 10€ los -- [www.ebay.de]

1-mal bearbeitet. Zuletzt am 10.01.20 15:40.

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Das ganze klingt auf jeden Fall sehr interessant und ist sicher eine Option, um das ganze später mal aufzurüsten.

Ich hoffe allerdings, dass irgendjemand die Antwort auf mein Problem kennt, da ich gerne weiter machen würde am besten vorerst noch mit der
Hardware, die ich aktuell zur Verfügung habe

Also falls du noch Ideen oder Ansätze hast, was ich probieren könnte um dieses Ausfall zu verhindern, darfst das gerne noch in Raum werfen

Also eine externe Temperaturregelung ist doch absolut unnötig und macht ausser Viktor auch niemand.
Wie verhält sich denn die Temperatur bei dir? Wenn alles richtig eingestellt ist, ändert sie sich nach dem aufheizen nur noch um wenige 1/10 grad.
Wenn das nicht so ist, hast du ein Problem mit der Thermistorverkabelung, oder falsche Pid Werte. Fang doch einnal mit einem pid autotune an.

---

Gruass us dr Schwiiz
Hansjürg

... schau dir mal die Optionen bzw. M-Codes für die Temperatur-Vorgabe und -Abfrage an und welche "Minimal-Werte" in der Konfiguration stehen.

Ein andere typische Fehlerquelle ist ein zu starkes "Rauschen" des Temperatur-Meßwerts -- wenn beim "Rauschen" ein paar Außreißer unter den vorgegebenen "erlaubten" Mindest-Wert kommen, dürfte das auch abbrechen ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Ok super, das muss ich mal testen.

Habe noch einen kleinen Umbau gemacht, aber nach wie vor das Problem, dass beim drucken nicht genug Filament durch kommt. Muss ich dann die Schritte des Motors erhöhen, sodass einfach nur mehr eingezogen wird?
Mittlerweile fährt er die Bahnen des G-Codes, allerdings ohne wirklich Material auf das Heizbett zu bekommen. Düse ist 0,4mm und mein Parameterwert ist aktuell bei 877.


Hat da jemand eine Idee?

EDIT: Die 877 entsprechen dem eingestellten Wert, dass wenn 50mm Filament eingezogen werden dies auch 50mm entspricht.

1-mal bearbeitet. Zuletzt am 11.01.20 14:45.

Entweder hast du dein Temperaturproblem noch nicht gelöst, oder die Düse ist zu nah am Druckbett.

---

Gruass us dr Schwiiz
Hansjürg

Doch, soweit alles gelöst. Problem war, dass die Wärmebrücke nicht richtig funktioniert hat und den Kühlkörper mit erwärmt. Dadurch ist das Filament zu weit oben geschmolzen.
Habe einen recht guten Druck bereits bekommen, allerdings war dieser Spiegelverkehrt.

Bin noch nicht ganz sicher woran es liegt. Momentan ist meine Homeposition wenn man von oben auf das Druckbett schaut unten rechts. Wenn man von vorne auf den Drucker schaut ist der Endstop für die X-Achse rechts montiert. Der Endstop für die Y-Achse ist hinten montiert und der für die Z-Achse unten an der Grundplatte. Alle sind als MIN definiert. Ich denke da ist noch ein Fehler irgendwo...

Hallo Tom,

als quick and dirty Lösung gibt es im Slicer
die Möglichkeit, eine Achse zu invertieren.
Dann schreibt der Slicer die Weginformationen
gespiegelt raus.

Gruß Schrittverlust

Home ist bei karthesischen Druckern üblicherweise links vorne. Also müssten bei Endstopp-min-Konfigurationen die Endstopps bei "Bettschubsern" nach links und hinten (dann ist die Düse ja an der vorderen Bettkante..).
Also entweder den X-Endstopp nach links versetzen oder als X-Max benutzen. Müsstest du also auf dem Board umstöpseln und in der Firmware ändern..

Ich hoffe, ich habe nicht für komplette Verwirrung gesorgt

Georg

Ich habe meinen Nullpunkt jetzt rechts vorne eingerichtet und den endstop in der Software auf Max angepasst und umgesteckt am Board. Funktioniert wunderbar