So sieht ein richtiger Crash aus

[riu]

Habe ich.

Mit der Lösung die ich oben geschrieben habe wäre das nicht passiert.

Gruss,
Udo

[riu]

Achso das Video. Mit den Schaltern? Ich dachte du meinst die Bilder. Ja das Video habe ich gesehen. Die Schalter sind aber dafür nicht sonderlich geeignet. Die Dinger taugen einfach nichts. Das Überfahren des ersten Schalters maltretiert diese Platinenschalter einfach zu sehr. Zwei ordentliche Microschalter machen das Ganze auch Dauereinsatzfähig.

Gruss,
Udo

[Gemelon]

Ich habe jetzt mal bei Conrad nachgefragt. Ich habe den kurz das Problem geschildert und gefragt ob sie da etwas unternehmen können.

Hier die Antwort:

Wir haben Ihr Anliegen an die Entwickler des RF1000 weitergeleitet. Diese haben versucht, den Fehler nachzustellen - bisher allerdings ohne Erfolg. Wie aus dem Forum hervorgeht, tritt dieser allerdings nur zufällig auf.
Auf jeden Fall wird daran gearbeitet, den Fehler ausfindig zu machen und zu beheben.

Es wird also daran gearbeitet

Ich denke die Kollegen bei Conrad werden noch mehr Infos brauchen. Also wenn noch jemand einen Hinweis geben kann, dann bitte hier Posten. Ich werde die Infos dann an Conrad weiterleiten, wenn die nicht so wie so hier mitlesen.

Ich meine dass mein Drucker noch über USB mit dem Rechner verbunden war und ich mit Repetier Host online war. Ich habe mir den Temperaturverlauf anzeigen lassen.

Gruß
Gemelon

[Digibike]

Hi!

Husky hatte da eine Vermutung, die Plausibel zu sein scheint...
Würde erklären, warum es nur bei manchen auftritt! Wie du geschrieben hast, nutzt du Reptier Host für die
Temperaturüberwachung, während du per USB druckst, oder?
Wenn du aber per USB druckst, geht die Kontrolle an den Drucker über. Wenn du nun aber von Reptier Host
aus den Druck beendest, greift plötzlich Reptier aktiv per USB ein, aber es werden nach wie vor weiter die
Befehle der SD-Karte abgearbeitet - wahllos in einem eigentlich beendeten Prozess - bekommt also weiter
verfahrensbefehle, obwohl er auf der anderen Seite gezwungen wird, auf Druckende zu gehen...
Und da der Z- Endschalter ja bekanntlich nur ein Signal schickt, welches interpretiert werden muß und nicht ein
Abschaltsignal (sonst würde die Kalibrierung ja auch nicht funktionieren, da da ja etwas über den Abschaltpunkt
gefahren wird...) hat er in diesem Kontrollfreien Chaos keinerlei Wirkung und funktion mehr...

Das würde erklären, warum der Fehler nicht immer auftritt und auch nicht nachvollziehbar ist (werden mit Sicherheit,
wenn Sie mit Reptier beenden, auch über Reptier drucken...)
Empfiehlt sich, glaube ich, direkt über Z ein Notaus nach Udo´s Vorschlag zu realisieren - muß so plaziert sein, daß
Kalibrieren gerade noch gewährleistet ist, aber bei größerer Auslenkung sofort auf Notaus geht...
Schade, daß sich die Funktion in Reptier nicht sperren läßt, wenn man nicht darüber den Druck auch gestartet hat...

Gruß, Christian

[riu]

Ich habe ja eher eine andere Vermutung.
Der Druck wurde, so wie ich das verstanden habe, über den Drucker gestartet. Repetier war aber auch verbunden (das war zumindest bei mir so) und hat die Positionen und die Temperaturen aufgezeichnet. Dann den Druck über den Drucker abbrechen - Peng! So war es bei mir.
Wenn der Druck nun über den Drucker mit verbundenem Repetier abgebrochen wird, scheint eine Prozedur die Endschalter ausser kraft zu setzen UND den Tisch in Richtung 0 auf der Z-Achse zu fahren. Der Druck hält ja nicht nur einfach an, sondern es wird ja auch gleichzeitig die Z-Achse angesteuert. X und Y habe ich bei dem Schreck den ich hatte nicht beobachtet.

Gruß,
Udo

[Gemelon]

Ja, so wie es der Udo geschildert hat war es bei mir auch.

Gruß,
Gemelon

[Oo]

Hi,

ich hatte das auch schon 2 mal, Computer war bei mir nie verbunden hab alles über den Drucker gemacht.
Bei mir war das zum Glück nie so schlimm...
Hab es geschafft den Drucker jedes mal schnell auszumachen.
Aber hat sich auch nicht gesund angehört. Denke also nicht das es was damit zu tun hat ob ein Pc angeschlossen ist oder nicht.
Scheint ein Bug im Drucker zu sein.
Ich mach das jetzt immer so wenn ich abbrechen will, Schalter hinten aus Druck ist abgebrochen...

Gruß
Ludwig

[swdig]

Hallo,

nach den ganzen Berichten hier über das unkontrollierte Überfahren des Z-Schalters habe ich mir mal den Sourcecode angesehen und dabei eine heiße Spur endeckt. Vorweg: Ich habe (noch) keinen RF1000 und kann deshalb nicht selber testen.

Lässt man sich in der Arduino-IDE die Compiler-Warnungen anzeigen, so findet man in dem ganzen Wust eine Warnung über einen Integer-Überlauf in dieser Zeile:
Datei: RF1000.cpp Zeile 2564

if( Temp > (Z_MAX_LENGTH * ZAXIS_STEPS_PER_MM - ZAXIS_STEPS_PER_MM) )

Die Ursache dafür ist diese Definition in Configuration.h:

#define ZAXIS_STEPS_PER_MM 640
#define Z_MAX_LENGTH 202

Ändert man diese in long:

#define ZAXIS_STEPS_PER_MM 640l
#define Z_MAX_LENGTH 202l

ist die Warnung weg. Ohne die Definition als 'long' macht der Compiler aus dem Ausdruck (Z_MAX_LENGTH * ZAXIS_STEPS_PER_MM - ZAXIS_STEPS_PER_MM) eine negative Zahl, mit der long-Definition eine positive Zahl.

Das ist auch gut im List-File (Assemblercode) zu sehen:
short-Definition:
if( Temp > (Z_MAX_LENGTH * ZAXIS_STEPS_PER_MM - ZAXIS_STEPS_PER_MM) )
14e0e: 8e 0d add r24, r14
14e10: 9f 1d adc r25, r15
14e12: a0 1f adc r26, r16
14e14: b1 1f adc r27, r17
14e16: 81 58 subi r24, 0x81 ; 129
14e18: 96 4f sbci r25, 0xF6 ; 246
14e1a: af 4f sbci r26, 0xFF ; 255
14e1c: bf 4f sbci r27, 0xFF ; 255
14e1e: 4c f0 brlt .+18 ; 0x14e32

long-Definition:
if( Temp > (Z_MAX_LENGTH * ZAXIS_STEPS_PER_MM - ZAXIS_STEPS_PER_MM) )
14e0e: 8e 0d add r24, r14
14e10: 9f 1d adc r25, r15
14e12: a0 1f adc r26, r16
14e14: b1 1f adc r27, r17
14e16: 81 58 subi r24, 0x81 ; 129
14e18: 96 4f sbci r25, 0xF6 ; 246
14e1a: a1 40 sbci r26, 0x01 ; 1
14e1c: b0 40 sbci r27, 0x00 ; 0
14e1e: 4c f0 brlt .+18 ; 0x14e32

Abhänging vom Ergebnis dieses Vergleichs wird dann eine Funktion mit einem sehr verdächtigen Namen aufgerufen:
CalculateAllowedZStepsAfterEndStop( );

Diese Funktion wird an mehreren Stellen aufgerufen. Das Ergebnis der if-Abfrage wird immer falsch sein, aber die Reaktion des RF1000 hängt vielleicht davon ab, ob CalculateAllowedZStepsAfterEndStop( ); vorher schon an anderer Stelle aufgerufen wurde.

Den Überlauf gibt es auch in der Datei motion.cpp in Zeile 2183:
if( Temp <= (Z_MAX_LENGTH * ZAXIS_STEPS_PER_MM - ZAXIS_STEPS_PER_MM) )

Es könnte auch sein, dass solche Integerüberläufe auch bei X und Y auftreten, nur wirken sie sich da nicht so heftig aus.

So - nun freiwillige Tester vor.... bzw. wer schon mit dem Conrad-Support Kontakt hatte, darf das alles gerne weitergeben.

Grüße,
Stefan

[Gemelon]

Hallo Stefan,
das was du da schilderst finde ich bis jetzt wirklich am Plausibelsten. Ich habe das an Conrad weitergeleitet. Ich hoffe die können das bestätigen und damit den Fehler beheben.

Gruß
Gemelon

[riu]

Ja, finde ich auch sehr gute Arbeit! Ich denke swdig kommt von SoftwareDigger, der, der alles ausgräbt

Gruß,
Udo