Druckerseitiger Verbindungsabbruch nach Druckende

[Darrol]

Tag allerseits,

seitdem ich mein Gerät vor 3 Wochen aus der Sommerpause wiedererweckt habe, unterbricht der Drucker offenbar nach Beendigung eines Drucks die serielle Verbindung.
Wenn das Gerät an meinem Laptop bzw. Repetier-Host hängt äußert sich das so, dass Repetier-Host aus disconnect springt und der Drucker sich resetted wie wenn man das USB-Kabel umsteckt. Das führt dann auch dazu, dass das Gerät mitten in der Outputbewegung hängen bleibt.
Allerdings kann ich mich hier direkt wieder mit dem Gerät verbinden und dann wie gewohnt den nächsten Druck starten.

Beim Repetier-Server fällt die Sache noch weniger komfortabel aus: Der Server scheint den disconnect gar nicht zu registrieren und kommuniziert munter weiter mit dem Drucker. D.h. ich kann die aktuellen Temperaturen sehen und auch regeln solange ich keinen weiteren Druck starte.
Dann heizt die Kiste zwar auf, bleibt aber an diesem Punkt hängen. Im Display erscheint dann nach ein paar Minuten "Finished" und das wars.
Es kommen dann zwar immernoch Statusmeldungen zum Server aber in die adre Richtung läuft nichts mehr.
In der Konsole erhalte ich dann sowas hier:

> 13:56:19.502: Warning: Seems like we missed a ok - continue sending

Wenn ein Druck mal läuft, bleibt die Verbindung aber immerhin auch stabil bestehen. D.h. es lässt sich also noch arbeiten.

Ich denke nicht das hier ein Firmware-Problem vorliegt, da das Fehlerbild unabhängig davon das selbe ist: Habs mit der RF01.37 als auch mit der Community-Firmware v7 & v9 reproduzieren können. Zumal die Kiste in ihrer Konfiguration ja schon ein 3/4 Jahr mit der Condrad-Firmware gelaufen ist.

Jetzt bin ich ewtas ratlos was hier noch an Optionen bleibt. Ich hoffe ja, dass das Mainboard keinen Schaden hat.

[Nibbels]

Hi

Hmm ...
Kannst du dein EEPROM posten?
Und hast du im Repetier-Server die Log angesehen?
Ist es wirklich die 1.37v7 bis v9.Mod die den Fehler auch hat?

Ein paar Infos vorneweg, die vielleicht manche Mythen aus der Fehlersuppe entfernen könnten :

Was bei mir super läuft, ist eine serielle Datenrate von 115200. Der Eingangspuffer der Steuersoftware sollte auf 127 Bytes eingestellt sein (nicht 63).

Das USB-Kabel kann einen Schuss haben. Eigentlich ist das eine USB-Verbindung bis zum Board und keine serielle Verbindung. Die serielle Verbindung ist nur ein paar cm lang, vom Chip auf dem Board zum Arduino. RF2000:

Screenshot_4.jpg

Ich habe hier einen USB-Hub, der manchmal was ähnliches produziert hat, aber nicht reproduzierbar. Der Chip von dem wurde heiß..

Bei einem anderen Projekt hatte ich mal Ärger mit dem USB-Seriell-Chip-Treiber: Da ich den Fall aber beim Drucker bisher nie mitbekommen habe, glaube ichs nicht.

Wenn der Repetier-Server "start" empfängt, als Extra Zeile, dann heißt das für den Repetier-Server, dass sich der Drucker resettet hat und er aufhören soll zu senden. Der Druckauftrag müsste ganz einfach verschwinden.
Ich habe vor diesem "start" ein Enter eingefügt. Denn manchmal ist es früher passiert, dass der Repetierserver den "Start" nicht verstanden hat, weil der Drucker inmitten einer Zeile abgeschmiert ist und somit sowas wie "N1234 Gblablalbastart" ankam.
-> Im Repetier-Server gibts diese Connected.log. Dort drin oder in der Druck-Teil.log müsste das sichtbar sein.

Weil ich das lange nicht kapiert hatte und mir ständig der Drucker in X und Y an die Wand fuhr, wenn er abgeschmiert war, habe ich das FEATURE_UNLOCK_MOVEMENT eingeführt, welches eigentlich im Mod immernoch auf Aktiv geschaltet ist.
Der Drucker darf sich nach einem Reset nicht bewegen bis ein Homing passiert ist oder der Benutzer mindestens eine Taste am Drucker gedrückt hat.
Genau mit diesem Feature habe ich es geschafft, dass der Drucker nach einem unerwarteten Reset einfach stehen blieb, ausgekühlt ist und die G-Code-Befehle durchgespult wurden - aber alle Bewegungen inkl. Extrusion wurden ignoriert.
Ergebnis "FINISHED". (Das war wie gesagt die Notlösung bevor ich von dem Ohne-Enter-"start"-Bug wusste.)

Es gibt zusätzlich zu "start" noch andere Befehle, die man an Repetier-Host / Reptier-Server senden kann, sodass sie in einem gewissen Maß gesteuert werden können.
http://forum.repetier.com/discussion/42 ... ver#latest

Code: Alles auswählen

Com::printFLN( PSTR( "RequestStop:" ) ); //tell repetierserver to stop.
        Com::printFLN( PSTR( "// action:disconnect" ) ); //tell octoprint to disconnect

Code: Alles auswählen

Com::printFLN( PSTR("RequestPause:") ); //repetier
                    Com::printFLN( PSTR( "// action:pause" ) ); //octoprint

Code: Alles auswählen

Com::printFLN( PSTR("RequestContinue:") ); //repetier
    Com::printFLN( PSTR( "// action:resume" ) ); //octoprint

(Genau heute habe ich dieses "RequestStop:" auch dann eingefügt, wenn ein Temperatursensor defekt wird.)
Die Ausführung von "Request-Stop" funktioniert bei mir mit dem Repetier-Server hervorragend! Ich habs aber nie mit Repetier-Host und nie mit Simplify3D versucht. Auch Octoprint habe ich nie getestet - nur einprogrammiert. -> Der Drucker schickt seine Befehle einfach in "Allen bekannten Standards" ab, wenn er was von der Steuersoftware will.
-> Kurz: Das sollten wir in der Log prüfen.

[Nibbels]

Früher, mit älteren Firmwares, ist mir mal der Drucker abgeschmiert, wenn ich Output_Object angestoßen hatte.
Das ist der G-Code M3079
Ist der das Problem??

1.37v9 ist eigentlich nur als Testversion für AtlonXP gedacht gewesen, ebenso wie "zu dieser Stunde, heute" die 1.37w.
Bleibe notfalls noch für diese Tests auf 1.37v8, der aktuellen Stable-Mod stehen.

Ich schicke dir gerne auch eine vorkompilierte Hex, die ich mir 1:1 selbst dann auch draufspiele. So könnten wir zumindest die Firmware / Compilerärger / ... ausschließen.

LG

[Darrol]

Ich werde heute Abend mal die mod v8 aufspielen und dann auch mal meine bisherigen Aktionen auflisten.
Das mit dem Outputting ist aber schonmal ein guter Hinweis.
Wobei ich mein Phänomen glaube ich auch dann habe wenn ich den Druck vom Repetier-Server aus abbreche.
Baudrate und Eingangspuffer sind auch schon seit jeher auf 115200 respektive 127 Byte eingestellt.

Wie gesagt es trat plötzlich auf ohne das ich eine Änderung an meinem System gemacht habe.

[Nibbels]

Super
1.37w2 habe ich gerade im Test, die müsste in Details noch besser sein als die 1.37v8, aber an deinem Verhalten dürfte sich nichts geändert haben.
Denk mit Repetier-Server an diese Events:

Screenshot_1.jpg

LG

[Darrol]

An diesen Stellen hatte ich nichts hinterlegt.


Ich habe nun die v8mod stable aufgespielt und den Repetier-Server nochmal frisch aufgesetzt und siehe da: Der Verbindungsabbruch lässt sich nicht mehr reproduzieren.
Das verwirrt mich nun zugegebener Maßen, da ich abgeshen von der Wahl genau dieser Firmware alles schon einmal so durchexerziert habe.

Meine bisherigen Maßnahmen

---

Ausgangssituation: RF2000 mit Conrad Dev-Firmware 1.37 /RaspberryPi 2 Repetier-Server 0.85.1 auf Raspbian Jessie
Nach 3 Monaten nicht Benutzung lässt sich immer nur ein G-Code drucken, danach muss der Server rebooten bevor das nächste Teil gedruckt werden kann.
1.Verdacht: SD-Karte ist hinüber -> System wurde auf einer anderen Karte frisch aufgesetzt(Diesmal 0.86.2) -> Problem besteht weiterhin
2. Der RaspberryPi hat einen Hardwaredefekt -> SD-Karte in ein anderes RaspPi gesteckt ->Problem besteht weiterhin
3. Das USB-Kabel könnte einen Schaden -> Kabel getauscht ->Problem besteht weiterhin
4. Die RaspPi-Stromversorgung ist nach am sterben -> Netzteil getauscht -> P.b.s.
5. Der Drucker hat eine generelles Problem mit den GCodes, die ich nun mit S3D V4.0 erzeuge ->G-Codes von SD-Karte gedruckt ->Keine Probleme
5. Die Firmware verursacht Probleme -> RF1.37v7mod aufgespielt ->P.b.s.
6. Neue Repetierserverversion verursacht Probleme -> Backroll auf Repetierserver 0.75.0 und Raspbian-Lite Jessie -> P.b.s
7. Ratlosigkeit -> Direkt von Repetier-Host aus gedruckt, Cura statt S3D zum slicen verwendet ->P.b.s., hier erkenne ich zum ersten mal, dass das Problem in der USB-Verbindung zu liegen scheint
8. Im Forum mein Leiden geschildert -> Nibbels gibt Tips -> Problem durch magische Fernwirkung gelöst

Also leider kann ich nun keine interessanten Logs liefern, es sei denn jemand interessiert sich für einen reibungslosen Druckvorgang von der Heart.stl
Ich häng aber zumindest mal mein EEPROM an.

Auf meinem Server befindet sich nun lediglich der o.g. Gcode welcher also problemlos mehrfach gedruckt werden kann. Den habe ich allerdings mit einem älteren S3D Profil erzeugt.
Ich werd also mal schauen ob ich da Unterschiede in den Start- und End-Codes zu meinen aktuelleren Profilen ausmachen kann bzw. ob es einen Unterschied macht ob ich mit einem anderen Profil arbeite.

[Nibbels]

Ok

... wenn es nun geht, super!!

Ich glaube nicht, dass du wegen einer neueren Version nochmal diesen Ärger haben würdest.
Einmal habe ich einen Fall mitbekommen, derjenige hat in Linux geflashed, aber dann wurden einzelne Module gecached und beim neu compilieren hats irgendwie altes vorcompiliertes Zeugs der letzten Testversion in die neue Version mit reingebaut.
Sowas wie "clean all" als befehl hat das dann behoben.
Flashen selbst sollte, wenn man die Warnung nicht ignoriert, validiert werden.

Ich seh im EEPROM nichts verkehrtes.
- Z-Jerk mit 0.28 auf dem "Neuen mehr plausiblen minimum",
- XY-Jerk mit 11,456 voll ok.
- Acceleration ist mit 2500 etwas hoch, aber nicht völlig irre.
- Sensor als V2 konfiguriert, PID-Werte sehen plausibel aus.
- PID I drive min und max sind ok. Max wäre für meine E3D Hotends bei Extruder1 mit Wert 80 grenzwertig gegen zu niedrig, ..
- Extruder 1 Advance: 80. Das ist noch im Rahmen. Ich hab nun meistens 35-50 drin (, achte aber nicht mehr drauf. Ich sehe den Unterschied nicht, -
ausser ich drucke eckige Vasen.)
- Fan PWM auf 15Hz

Joah ^^