Z_MIN & Z Probe auf dem gleichen Pin, derzeit eine sehr dumme Idee. Getestet bis 1.0.4 dev
Ich wollte einen billigen ANet A8 um AutoBed Leveling erweitern. Ich schloss einen kapazitiven Sensor parallel zum Z_MIN an und brachte mit Mühe den notwendigen Code unter - auf Kurven G2/G3 musste ich verzichten.
Nur, der Drucker lief nicht mehr richtig. Z Homing klappt manchmal, meistens nur beim ersten Auslösen von Z_MIN und beim erneuten Runterfahren bei dem Homing wurde der EndStop ignoriert. Das ABL funktionierte im Prinzip. Ich hatte über Wochen einen Hardwarefehler im Verdacht, doch eine alte eingespielte Firmware funktionierte einwandfrei. Damit beließ ich es frustriert.
Heute passte ich diese Repetier Config an einen P3Steel an. Ich hatte fast 2h versucht zu verstehen, warum Z_MIN seitens der Firmware nicht erkannt wurde. Nach einem M119 sah ich, das ein Z-Probe Sensor erwartet wurde, der löste brav aus, aber nicht Z_MIN. FEATURE_Z_PROBE = 0 sorgte dann für ein problemloses Arbeiten.
Ich bin nun etwas zu müde, um genauer in den Code zu schauen. Ich vermute mal im Schnellschuss, das der Status des Port ausgelesen wird und in einer Variablen gespeichert wird. Die einfachste Lösung wäre dann hier, beide Variablen als volatile zu definieren und auf die gleiche Adresse zu legen. Ich werde mich die Tage mal ransetzen.
Es mag eine Frage sein, ob es ein Bug oder nur ein seltener Seiteneffekt einer undokumentierten Möglichkeit ist, doch ich halte es eher für einen Bug. Manche Boards haben nicht genug Ports und diese Konfiguration, Z-Probe und Z-Min auf dem selben Port logische Lösung.
Nur, der Drucker lief nicht mehr richtig. Z Homing klappt manchmal, meistens nur beim ersten Auslösen von Z_MIN und beim erneuten Runterfahren bei dem Homing wurde der EndStop ignoriert. Das ABL funktionierte im Prinzip. Ich hatte über Wochen einen Hardwarefehler im Verdacht, doch eine alte eingespielte Firmware funktionierte einwandfrei. Damit beließ ich es frustriert.
Heute passte ich diese Repetier Config an einen P3Steel an. Ich hatte fast 2h versucht zu verstehen, warum Z_MIN seitens der Firmware nicht erkannt wurde. Nach einem M119 sah ich, das ein Z-Probe Sensor erwartet wurde, der löste brav aus, aber nicht Z_MIN. FEATURE_Z_PROBE = 0 sorgte dann für ein problemloses Arbeiten.
Ich bin nun etwas zu müde, um genauer in den Code zu schauen. Ich vermute mal im Schnellschuss, das der Status des Port ausgelesen wird und in einer Variablen gespeichert wird. Die einfachste Lösung wäre dann hier, beide Variablen als volatile zu definieren und auf die gleiche Adresse zu legen. Ich werde mich die Tage mal ransetzen.
Es mag eine Frage sein, ob es ein Bug oder nur ein seltener Seiteneffekt einer undokumentierten Möglichkeit ist, doch ich halte es eher für einen Bug. Manche Boards haben nicht genug Ports und diese Konfiguration, Z-Probe und Z-Min auf dem selben Port logische Lösung.
Comments
Wenn er bei Z=0 nicht mehr z-probe H anzeigt must du z-raise before homing aktivieren. Passiert bei manchen Sensoren und dann kann man nicht 2 mal homen weil er beim zweiten mal wegen Z=0 nicht auslöst. Ist aber wie gesagt Sensorabhängig.
Ich werde es heute Abend testen.
Im besten Fall sollte dann ein Macro die gleichzeitige Verwendung von z-min und z-probe beim Compilieren abfangen, oder die Firmware auch sicher statt Z Homing die ABL Routinen nutzen.
Wie auch immer, ich war durch reines Home all in der Lage, ein gedrucktes Teil am Drucker zu zerbrechen, weil die Z Achse in den physikalischen Anschlag fuhr. Insofern halte ich diese jetzige Situation für einen Bug.
Ursprünglich wollte ich z-min als zusätzlichen Fallsave, wenn der ABL Sensor ausfällt, hier ist notfalls Stop. Nicht ganz sinnlos, der Schlitten fürs Hotend hat etwas Spiel, wenn er mit Gewalt auf das Bett gedrückt wird. Genug, damit ein Schalter dann doch auslöst, wenn der eigentliche Sensor ausgefallen wäre.
Das sollte gehen, aber er darf wohl dann in der Firmware nicht als z-min definiert sein.
Du kannst zmin parallel haben, aber er muss so tief sein das er erst unterhalb des Betts triggert. Dabei ist wegen der Rotation der tiefste Punkt des Betts gemeint. Macht natürlich nur sinn wenn das Bett über federn gelagert ist und nachgeben kann. Triggert er vorher kann homing falsch sein. Hängt wie gesagt alles von der Bettrotation und dem Triggerpunkt der echten Probe ab.
Physisch triggert der Z-Min Schalter ca. 2 mm nach Z-Probe, Bett ist federnd gelagert. Es geht normalerweise nur im negativen XY Bereich, da der Sensor dann durch den Offset zur Düse quasi in der Luft hängt.
Mal konkret, warum geht es hier schief?:
Home Order XYZ, Anet A8, also Cartesian Printer. X-min-pos ist mit -21 angegeben, y-min-Pos mit -12, X-max-length und y-max-length mit je 200, Druckbereich ist 0-200. z-min-Pos ist 0, z-max-length 190. (Vielleicht sollte ich z-min-pos auch mit -2 angeben). Z-Probe war default, nur der Offset zur Düse angepasst. Schalter und Sensor arbeiten, Signal kommt auf dem Board am Testpunkt an. ( In der Home Order kommt das Heizbrett erst hinzu, wenn es prinzipiell funktioniert )
Der nun beschriebene Ablauf ist bei 1.0.3 und 1.0.4-dev identisch:
Mit Feature-Z-PROBE 1
Home All zur Eröffnung-> X macht Home, Y macht Home, ist nun X ist -21, Y -12. Soweit noch gut.
Nun macht Z Home, wieso auch immer:
Beim ersten Kontakt wird z-min auf H gesetzt gesetzt, Z Achse geht wieder ein Stück nach oben. Nun fährt sie langsam runter. Beim nächsten Kontakt bleibt z-min auf L und z-probe geht auf H.
Repetier ignoriert es und fährt weiter runter.
Wieso ?
Es wurde auch nicht die XY Position für das Bedleveling angefahren, XY war wegen der Homeorder da schon mit X -21 und Y mit -12 bekannt. Also war es die normale Homeing Routine, welche sich nicht für das z-probe H interessiert.
Egal wie man es dreht, er hätte nicht weiter runterfahren dürfen. Das ist bei einer Firmware immer noch ein Fehler, auch Bug genannt, selbst wenn er nur unter seltenen Nebenbedingungen auftritt.
Oder wieso versucht mit Feature-Z-PROBE 1 Repetier ein normales Z-Homing, wenn es von der Programlogik laut Ihrer Aussage nicht geht ? Eventuell, weil nur einmal eine Auslösung des Schalters erwartet wird, er sich aber zweimal rantastet? Beim ersten Mal wird ja z-min auf H gesetzt. Dann wäre das zweimalig Antasten ein Fehler, nur das war so bei mir schon bei allen Repetier-Firmware Versionen, ich halte/hielt es daher für normal.
Mit Feature-Z-PROBE 0 geht es so:
Home All zur Eröffnung-> X-Home normal, Y-Home normal, Z-Home geht auf Kontakt, fährt wieder ein Stück hoch und nähert sich nochmal langsam dem Kontakt. z-min geht wieder auf H und Z-Achse bleibt stehen.
Ich baue den A8 gerade auf Alurahmen um, dabei wird auch das Anet Board wegen der begrenzten Flash Kapazität durch ein GenL mit ATmega 2560 ersetzt. Das sollte am Wochenende fertig sein und ich werde dann gerne andere Config's nach Ihren Vorgaben versuchen und auf Wunsch incl. Video posten, falls Ihr diesen Ablauf nicht glaubt.
Und ja, die Configuration.h wurde extra mit dem Tool erzeugt, ich hatte schon die Erfahrung gemacht, das eine rein manuelle Anpassung nicht immer sinnvoll ist
Wie du siehst wird wenn homing flag nicht gesetzt ist z min signal auf low gesetzt. Muss also homing aktiv sein.
Jetzt mal z homing betrachtet:
Er sollte da also zumindest kurz anhalten, ist ja die gleiche Funktion wie beim ersten test wo es auch geklappt hat.
Danach kommt allerdings eine z korrektur bei der end stops keine Rolle mehr spielen. Insbesondere
Solange der wert positiv ist kommt er danach also dem Bett näher. Es ist also wichtig das er nicht größer ist als er wirklich ist sonst geht es in der tat ins Bett rein. Hier unbedingt auch nachsehen was im eeprom steht.
Ist z probing an xhome/yhome ok? Wenn nicht must do homing order HOME_ORDER_XYTZ verwenden, dabei kannst du bestimmen wo z homing geschehen soll. Extruder temperatur kannst du auf 0 lassen für ist egal.
Ist kein Vorwurf, der angedachte Umbau auf Alurahmen hat sich durch das Problem etwas beschleunigt. Wie gesagt, hatte Knack gemacht beim billigst A8. Ich brauchte einfach zu lange, vom Überwachen der Endstops am PC bis zur Auslösung des Notstop. Bin halt auch etwas älter und nicht mehr so flink
Noch ist der P3Steel mit dem Druck der benötigten Teile für den Umbau beschäftigt, der umgebaute A8 bzw. neue AM8 sollte Sonntag wieder verfügbar sein. Ich riskiere es nicht, 2 Drucker gleichzeitig zu verlieren.
Ich mag mich irren und bin schon lange aus der Materie raus, aber ich werde nach deinen Vorschlägen hinterher auch einen Patch versuchen, der die ersten beiden Male z-min setzt ( bzw. mit setzt) und nicht nur beim allerersten Mal. Irgendwie habe ich das Bauchgefühl, da liegt in dieser Config das Problem. Homing scheint erst nach dem 2.ten Auslösen von z-min wirklich abgeschlossen zu sein. Könnte natürlich auch so schnell geschehen, das ich es nicht mitbekommen kann und daher irre.
Den P3Steel habe ich, da die TMC2209 ankamen, auf SKR1.3 und somit zwingend Merlin umgerüstet. Keine Probleme, es arbeitet wie ich es erwartet habe. Also ganz unfähig bin ich auch nicht
Den AM8 werde ich dann nochmal mit Repetier flashen, diesem Problem möchte ich doch nachgehen. Denn ich habe den A8 mehrfach frisch gezogen über fast 1 Jahr mit Repetier aufgesetzt, ohne es je in den Griff zu bekommen. Ist es ein Super DAU Fehler meinerseits oder doch ein sehr rarer Bug. Wie gesagt, beim A8 beim letzten Test war der Sperrholzrahmen gebrochen. Beim stabileren P3Steel musste ich nur ein X-Endstepper ersetzen.
Was ich von der Logik einfach nicht verstehe, wenn Homing im Programablauf abgeschlossen wäre und er jetzt beim Z-Probe ist, warum wird dann das vorhandene Signal Z-Probe ignoriert und er fährt weiter runter. Darum denke ich ja, er müsste noch im Homing festhängen, wo das Z-Probe Signal keine Rolle spielt.
Egal, der nächste Post sagt dann, alles ok, ich bin nur zu Blöd, oder ich poste die Config.h. In jedem Fall ziehe ich frische Source, nur um irrtümlichen vergessene Änderungen vorzubeugen.