[Issue Split] homing macht evtl. mit G92 probleme?

[Nibbels]

Alter Thread: #129

Wegen dem Homing.
Kann du mir evtl. ein Video machen, wie das aussieht?

Ich verstehe auch noch nicht ganz, wie ein Homing fehlschlagen könnte, nur weil ein G92 danach kommt. Oder ich habe überlesen oder nicht verstanden, was nun genau passieren könnte.
Dagegen spricht, dass ich glaube(!) dass der Homing-Befehl die Gcodeausführung der folgenden GCodes bremst.

Wenn ich eintippe:
G28
M3117 jetzt bin ich da

Dann taucht der text erst nach dem homing auf, nicht dazwischen.

[Nibbels]

Ich hab mir G92 angesehen. Es scheint erstmal nichts verdächtig zu sein.

Es wird immer der alte Origin wieder neu reingeschrieben, wenn die Variable nicht verändert werden soll.
Oder wenn man die aktuelle Position will, wird -Printer::queuePositionLastMM[ _AXIS] übernommen. Sodass sich die aktuelle Koordinate mit der im originOffsetMM aufhebt und man "hier null hat".

Printer::queuePositionLastMM ändert sich natürlich beim Homen.
Es wird aber upgedated.

Repetier-Firmware/Repetier/Printer.cpp

Line 536 in 4b17639

void Printer::updateCurrentPosition(bool copyLastCmd)

in homeAxis:
https://github.com/Nibbels/Repetier-Firmware/blob/b1f28c5935860fb8368134bfe5ae4c2bcb122e91/Repetier/Printer.cpp#L2019

Bin also immernoch gleich verwirrt.

[Nibbels]

Das scheint falsch zu sein, interessiert uns nur leider nicht ^^.
https://github.com/Nibbels/Repetier-Firmware/blob/b1f28c5935860fb8368134bfe5ae4c2bcb122e91/Repetier/Printer.cpp#L1276

memoryE = queuePositionLastSteps[E_AXIS]*axisStepsPerMM[E_AXIS];

[mm] != [Steps]*[Steps]/[mm]

--> memoryE = queuePositionLastSteps[E_AXIS]*invAxisStepsPerMM[E_AXIS];

[Nibbels]

Da wir uns nach dem Homing auf 0 befinden, wäre es noch denkbar, dass du mal testest, ob die Fehler mit

// M3115 - set the x/y origin to the current x/y position
https://github.com/Nibbels/Repetier-Firmware/blob/b1f28c5935860fb8368134bfe5ae4c2bcb122e91/Repetier/RF.cpp#L8698

http://www.rf1000.de/wiki/index.php/GCodes#M3115_-_X-_und_Y-Koordinaten_der_aktuellen_Position_auf_Null_setzen

verschwunden sind. Position 0 gilt ja für X und Y. Z ist aussen vor. Bei Z wird beim M3115 das bisherige Offset behalten.

LG

[mhier]

Ich hatte den Fehler leider gerade auch trotz M400 zwischen dem G28 und dem G92. Das hilft also leider nicht. Filmen ist irgendwie schwierig, ich weiß ja nicht, wann das passiert und es passiert eher selten... In wie fern unterscheidet sich M3115 von G92 X0 Y0?

[Nibbels]

Eigentlich unterscheiden sich die Befehle kaum bis garnicht.
Beim M3115 wird quasi garnichts gerechnet.

Wenn das aber nur selten auftritt, glaube ich fast nicht mehr an einen Bug beim G92. Ich selbst konnte das noch nie nachstellen.

[Nibbels]

.. und dieses originOffsetMM zählt wirklich nur in dieser Funktion:
uint8_t Printer::setDestinationStepsFromGCode(GCode *com)
Nicht bei der Funktion, die das Homing übernimmt.

Wichtig wäre vermutlich einfach mal ein Ausschlussverfahren:

• Hysterese deines Schalters genau messen. (FEATURE_CHECK_HOME)
• Motorstrom checken (Menü)
• Fett checken und ausschließen dass der Drucker bei 5°C im Hobbyraum?? anders funktioniert als bei 20°C
• Mit M3200 spielen und nach einem Fail Koordinaten ausgeben lassen.
• SenseOffset auf @ und ^ anschauen.
• Prüfen, ob die erste Layerhöhe zu den gewählten Kompensationsgrenzen passt. (Letztes Vollbildmenü in Menülevel 0. Funktioniert die automatische Erkennung?)
• Compilieren mit Arduino und schauen ob sich was ändert
  (- Freien Ram nochmal prüfen)?
• Ein Rezept finden, wie man den Fehler nachstellen kann. Wann genau tritt das auf und wann nicht. Erster Druck nach Druckerstart? Zweiter+ Druck?
• Schrauben am Schalter nochmal auf wackeln prüfen
• ...

[mhier]

Ich hatte heute das Problem noch mal und zwar beim Z Offset Scan aus dem Menü - also ganz ohne G28 und G92.

Ich bin mir trotzdem 100%ig sicher, dass kein mechanisches Problem dahinter steckt. Er versucht eindeutig nicht einmal wieder in die andere Richtung zu fahren und macht auch sofort weiter mit der Ausführung des nächsten Befehls bzw. des Scans. Wenn schlechtes Fett (kalt ist es eh nicht bei mir) oder ein zu kleiner Motorstrom das Problem wären, würde man ja ein Knattern o.ä. hören, weil der Motor die Bewegung versuchen würde.

Das Einzige an der Hardware, was ich mir noch theoretisch vorstellen könnte, ist, dass mein Schalter irgendwie eine Macke hat, aber auch das ist extrem unwahrscheinlich vom Fehlerbild her. Der müsste ja exakt in dem Moment, wo die Fahrrichtung umgedreht wird, wieder schließen, und das obwohl er normalerweise erst ein paar Millimeter weiter oben schließen würde.

Es ist echt schwer, so einen Fehler zu debuggen, wenn er nicht reproduzierbar passiert... Ich werde mich demnächst aber mal genauer darum kümmern. (Erstmal will ich mein E3Dv6 wirklich ans Laufen bringen :-))

Bzgl. dem freien RAM: Es gibt die Funktionen Commands::checkFreeMemory() und Commands::writeLowestFreeRAM(), kann man sich damit irgendwie ausgeben lassen, ob der RAM mal knapp geworden ist? Vielleicht kann man das sonst als Feature einbauen und sogar bei knappem RAM automatisch eine Meldung an die Konsole oder aufs Display schreiben.

Ansonsten checke ich heute abend mal, wie viel freies RAM der Drucker beim Starten meldet, der schreibt das ja an die Konsole. Kannst du mal nachsehne, wie viel das bei dir ist?

[Nibbels]

Das DEBUG_MEMORY habe ich schon am laufen. Mein gefühl sagt mir, dass der Ram meistens strapaziert wird, wenn man diese GCODE-Scripte aus den RFx000/configuration.h ausführt (Output_Object_Script usw.). Aktuell habe ich 490byte frei und ich drucke schon das halbe Teil.
Der Ausgabebefehl ist M3200 P1.

Seit gestern abend habe ich ohne große Änderungen in der 1.41 checksum errors erhalten. Ich habe also wieder angefangen, die .elf zu meiner .hex auszuwerten und mit
"C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avr-objdump.exe" -S Repetier.ino.elf > blablabla.txt
die Zuordnung der Variablen im Ram gelistet. -> CSV -> Excel.

Weil ich nicht weiter weiß ... suche ich nun eben alle Arraygrenzen ab.

Dabei markiere die farblich, ob irgendwo mit dem index iteriert wird oder ob ein overflow absolut ausgeschlossen ist. Habe ich einen Verdacht, sortiere ich nach der Speicheradresse und sehe nach, welche Variablen dahinter stehen.
Wird vermutlich nichts bringen, aber sorgfältig ist das in jedem fall.

Anschließend werde ich wohl wieder stundenlang nacheinander alle commits lesen müssen, wenn mir nichts auffällt.

^^

[mhier]

M3200 P1 spuckt bei mir aktuell Folgendes aus (mitten im Druck):

10:18:42.842: Free RAM:1372
10:18:42.842: lowest free RAM: 1372
10:18:42.843: z-compensation matrix x: 26
10:18:42.844: z-compensation matrix y: 25

Ich bin z.Z. auf der "alten" Firmware, d.h. RF.01.37x9 - aber da hatte ich den Homing-Bug ja auch schon zweimal gesehen.

[mhier]

Was übrigens evtl. in Zukunft helfen würde, wenn du die Entwicklung in kleinschrittigen Commits (am besten hier im Repo) machen würdest und größere Errungenschaften mit Tags markierst. Dann könnte ich kleinschrittiger nach Fehlern suchen und eher konkrete Änderungen identifizieren und man behielte dennoch die Übersicht, welche Versionen als verwendbar angesehen werden können.

[Nibbels]

Das mit den kleinen Commits versuche ich schon länger :D
Ich entwickle halt immer in meinem Account, weil die "master" eigentlich immer uralt ist und die development genutzt wird.
Meine Hoffnung ist, dass ich bald nichts mehr an der Firmware machen werde. Die Liste der TODOs und Wünsche meinerseits ist inzwischen unglaublich kurz.

Der M3200 bringt dir was, wenn du
#define DEBUG_FREE_MEMORY 1
aktivierst. Ansonsten siehst du immer nur den aktuellen Stand und nicht das gesehene Minimum.

LG

[mhier]

Ah ok gut zu wissen. Dann muss ich das wohl mal heute abend aktivieren.

[Nibbels]

Ah!! Guck mal 🗡
Das 1000-Teile-Puzzle meldet....

11:37:07.764: Error:Wrong checksum
11:37:07.764: Resend:12895
11:37:07.855: Error:'
11:37:07.855: o'
11:37:07.855: $9
11:37:07.855: _
11:37:07.855: 11:37:07.856: j 11:37:07.856: * 11:37:07.856:
11:37:07.856: _
11:37:07.856: X9
11:37:07.856: (2) 11:37:07.856: V, 11:37:07.856: * 11:37:07.856:
11:37:07.857: 0-
11:37:07.857: M*
11:37:07.857: :9
11:37:07.857: _
11:37:07.857: (
11:37:07.857: 6*
11:37:07.857: 9
11:37:07.857: /9
11:37:07.857: '
11:37:07.857: n9
11:37:07.857:
11:37:07.858: H
11:37:07.858: `
11:37:07.858: c9
11:37:07.858: $
11:37:07.858: '
11:37:07.858: 'NANINITYINF =
11:37:07.858: #< 8w +2 $ O
11:37:07.858: Resend:12897

[mhier]

Ich versteh nur Bahnhof :-D

[Nibbels]

Naja da läuft was schief. Der kotzt irgendwelchen Ram oder Rom aus.
Wenn ich rausfinde was das ist oder es in der decompilerten version als ".text" finde komme ich weiter.

[Nibbels]

FSTRINGVALUE(Com::tNAN,"NAN")
FSTRINGVALUE(Com::tINF,"INF")

vs. 11:37:07.858: 'NANINITYINF =

Vermutlich hängt irgendwo ein Text ohne PSTR() aussenrum.

[mhier]

LOL

[Nibbels]

11:37:07.858: 'NANINITYINF =
11:37:07.858: #< 8w +2 $ O
11:37:07.858: Resend:12897

^^
Jetzt muss ich nur noch rausfinden, was ich überhaupt suche und etwas Glück haben.

00003954 l O .text 0000000e _ZZ25calculateZScrewCorrectionvE3__c_21
00003c91 l O .text 00000009 _ZL38ui_text_heat_bed_zoffset_search_status
00003c84 l O .text 0000000d _ZL31ui_text_heat_bed_zoffset_fix_z1
00003c77 l O .text 0000000d _ZL31ui_text_heat_bed_zoffset_fix_z2
00003c73 l O .text 00000004 _ZL17ui_text_statusmsg
00003c66 l O .text 0000000d _ZZ12searchZOScanvE3__c_45
00003c59 l O .text 0000000d _ZZ12searchZOScanvE3__c_46
00003d3e l O .text 00000011 _ZZ12searchZOScanvE3__c_37
00003d31 l O .text 0000000d _ZZ12searchZOScanvE3__c_38
00003d2a l O .text 00000007 _ZZ12searchZOScanvE3__c_39
00003cf9 l O .text 00000020 _ZZ12searchZOScanvE3__c_41
00003cc7 l O .text 00000032 _ZZ12searchZOScanvE3__c_42
00003cae l O .text 00000019 _ZZ12searchZOScanvE3__c_43
00003c9a l O .text 00000014 _ZZ12searchZOScanvE3__c_44
00003d4f l O .text 00000004 _ZZ12searchZOScanvE3__c_36
008005e4 l O .bss 00000002 _ZZ6loopRFvE23g_nSensibleLastPressure
00004103 l O .text 00000012 _ZZ6loopRFvE3__c_2
0000403a l O .text 00000009 ui_text_warning
000040f3 l O .text 00000010 ui_text_emergency_pause
00000000 l df ABS 00000000 strtod.c
0000003e l ABS 00000000 SP_H
0000003d l ABS 00000000 SP_L
0000003f l ABS 00000000 SREG
0000003b l ABS 00000000 RAMPZ
00000000 l ABS 00000000 tmp_reg
00000001 l ABS 00000000 zero_reg
000005d2 l O .text 00000003 pstr_inf
000005cd l O .text 00000005 pstr_inity
000005ca l O .text 00000003 pstr_nan
000005d5 l O .text 00000018 pwr_m10
000005ed l O .text 00000018 pwr_p10
00000000 l df ABS 00000000
0000003e l ABS 00000000 SP_H
0000003d l ABS 00000000 SP_L
0000003f l ABS 00000000 SREG

[Nibbels]

Mist, war glaube ich nur ein Symptom und nicht mein eigentliches Problem.

repetier#763

[mhier]

Nach 1x homen sagt M3200 mir 887 ram free und ein zweites mal homen ändert das nicht. Ich versuche nacher mal, den Fehler von hand gezielt zu reproduzieren.

[mhier]

Ich glaube, ich verstehe das Problem. Mein Schalter hat eine größere Hysterese als das Original, und wenn der Fehler auftritt, fährt er anscheinend nicht weit genug weg, um den Schalter wieder los zu lassen. Früher waren die Werte mal deutlich größer und im Laufe der Zeit sind die beiden Teile (jetzt 0.3mm und Z_ENDSTOP_DRIVE_OVER=0.8mm) immer kleiner geworden. Muss das so knapp sein?

[Nibbels]

Nein, die müssen nicht so klein sein.

Kannst du dir mal FEATURE_CHECK_HOME als 1 definieren und diese Firmware so draufspielen?
Das Tool misst diesen Wert genau aus.
-> M3028 X1 Y1 Z1

Dann siehst du in der Konsole die Auswertung und kannst das 3x machen. Bei mir waren die Hysterese-Werte minimal. So gegen 0.01. Bei einem RF1000 mit mechanischem Schalter wenn ich mich richtig erinnere eher 0.1.

Darum haben wir diese Einstellungen gewählt:
RF2000: 0.1 und RF1000: 0.3mm

LG

---

Wegen der Firmware. Es kommt bei mir nun immer noch ab und an ein Übertragungsfehler vor. Aber alles läuft. Die Neuanforderung der Daten funktioniert auch! Ich habe den Verdacht, dass irgendein Timing für UART falsch ist.
Das passiert jede paar Minuten .. 10/14/20 Minuten 1x.

[Nibbels]

Ok, also diese Fehler sind teilweise etwas komisch:
Error: N3668 G1 X67.586 Y151.093 E0.0000
Resend: N3668 G1 X67.586 Y151.093 E0.6884

Error: N383 G188 X0.000 Y0.000 E0.0000
Resend: N1663 G1 X90.478 Y176.258 E0.9117
Resend: N1664 M117 Layer 2/354
Resend: N1665 G1 X95.590 Y180.747 E0.9597
Resend: N1666 G1 X100.891 Y185.010 E1.0077
Resend: N1667 G1 X106.370 Y189.041 E1.0557
Resend: N1668 G1 X112.019 Y192.832 E1.1036

Error: N3861 G1 X90.478 Y176.258 E-0.0000
Resend: N3861 G1 X90.478 Y176.258 E0.9117

Error: N3956 G225 X0.000 Y-0.000 E0.0000
Resend: N3956 G1 X38.745 Y65.260 E0.1121

N3668 G1 X67.586 Y151.093 E0.0000
Resend: N3668 G1 X67.586 Y151.093 E0.6884

N3861 G1 X90.478 Y176.258 E-0.0000
Resend: N3861 G1 X90.478 Y176.258 E0.9117

N3956 G225 X0.000 Y-0.000 E0.0000
Resend: N3956 G1 X38.745 Y65.260 E0.1121

N6644 G78 X0.000 Y0.000 F0.000
Resend: N6644 G1 X168.634 Y215.115 F9600

N7052 G1 X37.609 Y-0.000 E0.0000
Resend: N7052 G1 X37.609 Y63.276 E0.0949

N8064 G119 X0.000 Y-0.000 E-0.0000
Resend: N8064 G1 X76.372 Y161.528 E0.7678

N7872 G1 X56.924 Y0.000 E-0.0000
Resend: N7872 G1 X56.924 Y133.616 E0.5438

N8159 G1 X0.000 Y-199170.406 E0.0000
Resend: N8159 G1 X37.631 Y64.301 E0.0923

N9740 G1 X182.966 Y219.781 F198.086
Resend: N9740 G1 X182.966 Y219.781 F9600

Für den Fall, dass hier immer die Params falsch sind und die restlichen Daten stimmen müssten: Dann betrifft es immer die ersten 2 Bytes des Command-Puffers. (?)

Unser Command-Puffer:
Wenn ich genau diese .hex->.elf nach Speicheradressen sortiere, ist vor "commandReceiving" in kleinerem Abstand kein Array, das irgendwie gefährlich sein könnte.

Der Command-Puffer liest aus dem Seriell-Ringpuffer:
Vor dem rx_buffer steht der tx_buffer. (Objekt von ring_buffer_rx)
Da habe ich nie was gemacht und ich nehme an, das ist solide gebaut.
davor die variable g_diffZCompensationSteps
davor das SD-Karten-Objekt.
davor das Printer::flag1
davor unser Displayobjekt uid.
das SD-Karten-Objekt ist aber zu weit weg von rx_buffer. Und 0x89 lang.

Evtl. sind es tatsächlich nur Übertragungsfehler?
Evtl. ist das tatsächlich nur ein Interrupt-Problem/Timing-Problem?
Oder das Problem ist mir nur bisher nicht aufgefallen.

Ich werds sehen. Und muss wohl etwas zurückflashen.

Was definitiv funktioniert ist die Fletcher-Errorkorrektur! :D

[Nibbels]

Ich hab glaub Halluzination.

von 22:55:29.222 bis 0:00:09.009 Uhr hatte ich 105 Fehler.
Und dann keiner mehr. Wirklich keiner. Spinnt einfach nur mein Raspberry???
Denn der Drucker kennt keine Mitternacht.

-> Es ist Schlafenszeit!

[mhier]

Gibt es nicht irgend einen Test-Modus, mit dem die Zuverlässigkeit der Übertragung getestet werden kann? Vielleicht hat einfach nur das USB-Kabel ne Macke... Ganz früher in der Anfangszeit gab es immer Probleme mit dem Drucken über USB (hauptsächlich bemerkbar als häufige Pausen beim Drucken, die später als Knubbel auf der Oberfläche sichtbar waren). Ich glaube, irgendwann wurde die Übertragungsgeschwindigkeit dann reduziert und dann ging es besser. Hast du die evtl. höher als normal eingestellt?

[Nibbels]

115200

ich hatte übrigens 0:37uhr wieder einen Fehler.
Da hilft glaub nur auf alte Software zurückgehen.

• Dann ausschließen, dass ich nur die Errormeldung "immer anzeige".
• Sonst mal Vorkommnisse zählen und statistisch auswerten ob mit 250000 mehr fehler passieren.
• Sonst Microsteps zurücknehmen ^^.

Ich patche erstmal die Debug-Funktion für COM voll durch.

[Nibbels]

als häufige Pausen beim Drucken, die später als Knubbel auf der Oberfläche sichtbar waren). Ich glaube, irgendwann wurde die Übertragungsgeschwindigkeit dann reduziert und dann ging es besser.

Das läuft aktuell so sauber ab, dass man es nicht bemerken wird.
Laut der Timelog:

• 10:44:53.198 -> Merkt er dass die Checksumme falsch ist.
• 10:44:53.210 -> Hat er den Befehl neu im Puffer.

Das ist bei allen Fällen die ich mir angeschaut habe so schnell. also grob 10-15ms deltaT pro Error.

(Die Kommunikation mit Repetier-Server erfolgt bei mir mit dem binären Protokoll Version 2, also nicht mit Ascii text)

LG

[mhier]

Offenbar hat mein Z-Schalter eine stark schwankende Hystherese und der Auslösepunkt hängt auch sehr stark von der Fahrgeschwindigkeit ab. Vielleicht ändern sich seine Parameter und deswegen funktionieren die Firmware-Einstellungen nicht mehr so wie früher. Ich habe gesehen, dass in der Original-Firmware das back move nur 0.5mm beträgt und also kleiner ist als die (0.3+0.8)mm bei uns. Daran wird es also nicht liegen. Ich habe jetzt mal meine Z-Home-Geschwindigkeit reduziert und das Problem scheint dann nicht mehr aufzutreten.

Hier der Output vom FEATURE_CHECK_HOME:

18:25:46.787: N1254 M3028 Z1
18:25:46.792: checkHome: start axis2
18:25:46.794: ishomed!
18:25:46.794: nHomeDir=-1
18:26:04.689: didsteps=-61455
18:26:04.691: wassteps=61440
18:26:04.692: recheck endstop:
18:26:05.840: aus-ein-hysterese=5
18:26:05.842: delta=232
18:26:26.355: N1281 M3028 Z1
18:26:26.361: checkHome: start axis2
18:26:26.362: ishomed!
18:26:26.362: nHomeDir=-1
18:26:44.256: didsteps=-61447
18:26:44.257: wassteps=61440
18:26:44.259: recheck endstop:
18:26:45.504: aus-ein-hysterese=26
18:26:45.505: delta=219
18:27:02.557: N1305 M3028 Z1
18:27:02.561: checkHome: start axis2
18:27:02.563: ishomed!
18:27:02.564: nHomeDir=-1
18:27:20.456: didsteps=-61444
18:27:20.458: wassteps=61440
18:27:20.459: recheck endstop:
18:27:21.841: aus-ein-hysterese=58
18:27:21.842: delta=188
18:27:38.809: N1329 M3028 Z1
18:27:38.816: checkHome: start axis2
18:27:38.817: ishomed!
18:27:38.817: nHomeDir=-1
18:27:56.710: didsteps=-61444
18:27:56.711: wassteps=61440
18:27:56.713: recheck endstop:
18:27:57.900: aus-ein-hysterese=16
18:27:57.901: delta=227

Ich denke, wir können dieses Ticket schliesen - es handelt sich nicht um ein Firmware-Problem an sich. Danke für die Hilfe!

[Nibbels]

Dass du mit normalen Geschwindigkeiten mehr Erfolg oder weniger Fehler hast, kann ich nachvollziehen.
Ich habe die Geschwindigkeiten in der Config runtergenommen, aber dein EEPROM hat bekanntlich ein eigenes Gedächtnis ( 165mm/s :D :D ). War halt früher vielleicht nicht erreicht worden, aber jetzt wo der Drucker mit Double-Quad-Octostepping läuft könnte es sein.

Schalter:
Der misst eine unterschiedliche Hysterese, Wir haben in Z auch 2560Steps/mm.
58/2560 = 0.022mm

LG

[mhier]

Ah das kann es natürlich gut erklären.

Ich denke, wir können alles so lassen wie es ist. Die Homing-Geschwindigkeit kann ich ja per Menü reduzieren (habe ich ja bereits). Vielleicht sollten wir nur sicherstellen, dass ein unmodifizierter RF1000 mit den Default-Werten auch zuverlässig funktioniert (z.B. in dem man die Homing-Geschwindigkeit deutlich über den Default erhöht und testet, dass es dann immer noch funktioniert). Das kann ich aber leider nicht machen, weil ich ja den Original-Z-Schalter gar nicht mehr habe ;-)

Beim Original ist es übrigens mit einer Messung der Hysterese nicht getan, bzw. man muss sie bei der Homing-Geschwindigkeit messen. Bei hohen Geschwindigkeiten wird der Schalter ja etwas überfahren (d.h. verbogen), und die Hysterese wird sich um diesen Wert verlängern. Dummerweise hängt das davon ab, wie stark man die Befestigungsschraube des Schalters anzieht...