Verminderte Geschwindigkeit nach Einbau eines neuen PCs

Hallo Zusammen

Ich habe meinen großen Drucker bisher immer über ein Windows 10 - Tablet - PC gesteuert.
Da ich damit hin und wieder (alle paar Wochen) Probleme hatte (sporadische Systemabstürze, Verbindungsabbrüche, etc.), habe ich nun einen ausgewachsenen Industrie-PC mit 24V-Versorgung und Touchscreen installiert.

Auf dem PC läuft zurzeit Repetier Server 0.70.1, vorher hatte ich auch schon die aktuelle Version 0.91.2.
Die Hardware ist von den Leistungsdaten ähnlich, auf dem Industrie-PC werkelt ein Intel Celeron N2930 Quad-Core CPU.
Dennoch hat der neue PC Probleme bei Segmenten mit hoher G-Code-Dichte, z.B. fein aufgelösten Radien. Hier fängt der Drucker dann an zu stocken, als ob die Daten nicht schnell genug nachkommen. Der gleiche G-Code wurde mit dem alten PC (Tablet) ohne ruckeln übertragen.
An den Einstellungen habe ich nichts geändert, BAUD-Rate liegt bei 250.000, Eingangspuffer bei 127 , Ping-Pong-Modus aus.
Als Steuerung kommt ein Arduino Due mit Repetier 0.92 zum Einsatz.
Die Verbindung scheint erst mal sehr stabil, die Fehlerrate liegt bei gerade mal 0,009% (269 Fehler bei 54 MB gesendeten und 39MB empfangenen Daten). Der Anschluss erfolgt über ein geschirmtes 2m - USB - Kabel.
Das Problem tritt sowohl mit Repetier Server 0.70.1 als auch mit 0.91.2. auf.

Gibt es noch irgendwelche Einstellungen, welche die Verbindung bremsen können?
Macht es Sinn die Baud-rate zu erhöhen oder vielleicht zu senken?
Gibt es Windows-Seitig Einstellungen, welche zu Problemen führen können?
Auf dem PC läuft nichts außer einer sauberen Windows 10 Installation, Firefox und Repetier Server. Der PC ist nicht am Netzwerk angeschlossen.

Vielen Dank schon mal
«1

Comments

  • Windows ist erst mal langsamer als linux bei der seriellen Kommunikation. Zumindest haben das unsere tests gezeigt. Da Repetier-Firmware verwendet wird kann man leicht testen wie schnell die Kommunikation selber ist. Das ist ja normal der Knackpunkt bei vielen kleinen Segmenten. In der Konsole
    M111 S24
    schicken und dann eine 1-2MB Datei drucken. Dann Zeilen/Druckzeit in sekunden dividieren um zu sehen wie viele Zeilen pro Sekunde rüber kommen. Das geht bei mir von 3xx bei windows bis knapp 1000 unter Mac OS X. Linux liegt dazwischen. 
    Wichtige einstellungen am Server: Ping-Pong muss aus sein. Kann man leicht auch mal gegenmessen, aber mit ping-pong verliert man deutlich. Auch wichtig Repetier-Firmware als firmware einstellen. Dann passen mehr befehle in den Puffer.

    In der Kommunikation ist die Latenz zwischen den usb blöcken oft ein Faktor. Bei einigen Treibern kann man im Windows Gerätetreiber die Latenz einstellen. 2ms ist ein guter Wert um den durchsatz noch zu erhöhen.

    Ja nach erreichter Zeilenmenge muss man sich dann entscheiden:
    - Langsamer drucken
    - Nicht so kleine Segmente verwenden.
    Wenn man mit 100mm/s druckt und über 300 Zeilen/s schafft muss die segmentgröße < 0.33mm sein. Wobei das nur der Durchschnitt der vielleicht letzten 10 sein muss. Normalerweise kein Problem.
  • Vielen Dank für die schnelle Antwort.
    Aktuell läuft auf dem Drucker ein 100h-Druck, im Moment kann ich M111 also noch nicht testen. Sobald die Maschine fertig ist, versuche ich es.

    Beim Start des Druck ist mir aber aufgefallen, das es etwa 1 Sekunde gedauert hat, bis der Puffer (die "Move Cache Size") gefüllt war, zumindest wurde es in Repetier Server so grafisch dargestellt.  Ich habe den Cache auf 45 eingestellt, um den Effekt zu reduzieren. Das würde im Umkehrschluss bedeuten, dass gerade mal knapp 50 Zeilen pro Sekunde (vielleicht auch etwas mehr, so genau konnte ich die Zeit nicht abschätzen) übertragen wurden.
    Das Abrufen des EEPROMS mit seinen knapp 100 Einträgen dauert 0,4 Sekunden, was 250 Zeilen pro Sekunde entspräche. Der EEPROM wird allerdings auch in Paketen übertragen (mehrere dutzend Zeilen tragen den selben Zeitstempel), der G-Code in einzelnen Zeilen, was die Kommunikation vermutlich verlangsamt.
    Wenn sich das durch den M111-Test bestätigt, wende ich mich an den Hersteller des PCs, vielleicht ist irgendeine Einstellung im BIOS die Ursache.

    Ich bin bisher davon ausgegangen, dass die Baud-Rate die Geschwindigkeit der Kommunikation definiert, unabhängig von der Soft - oder Hardware. Sie ist bei mir auf 250.000 eingestellt, was eigentlich mehr als schnell genug sein müsste. Welchen Einfluss hat die Baud-rate auf die Geschwindigkeit?

    Falls sich die Datenrate nicht erhöhen lässt, bleibt mir nur noch die Möglichkeit, die "Move Cache Size" zu erhöhen. In den meisten Fällen gibt es bei meinen Drucken nur einen kleinen Bereich mit hoher G-Codedichte, sodass der Controller zwischen diesen Bereichen genug Zeit zum nachladen hat. Wie hoch kann dieser Wert bei einem Arduino Due maximal sein? 64? 128?
    Kann man die "Move Cache Size" auch irgendwie über den EEPROM einstellen? So könnte ich einfacher experimentieren und muss nicht immer die komplette Firmware neu hochladen.

  • > Beim Start des Druck ist mir aber aufgefallen, das es etwa 1 Sekunde gedauert hat, bis der Puffer (die "Move Cache Size") gefüllt war, zumindest wurde es in Repetier Server so grafisch dargestellt. 
    Dafür gibt es keine grafische Darstellung im server. Maximal kann man den stand in der Konsole abfragen.
    Größe Bewegungspuffer ist nur wichtig für die Zeitberechnung und sollte mit dem Wert in der Firmware übereinstimmen.
    Größe Inputbuffer ist entweder 63 oder 127 wobei meist der letzte wert korrekt ist. Bekommt man viele resends ist er gewöhnlich zu groß gewählt. Größere Werte haben da keine wirklichen Vorteile.

    Baudrate ist wichtig für den maximalen durchsatz, ja, aber da der Server nur neue Zeilen senden kann wenn er von der Firmware gesagt bekommen hat das die alten gelesen wurde und somit wieder platz ist ist auch der Roundtrip hier wichtig und damit die Latenz zwischen senden an Treiber und dem Treiber der das Paket dann als USB sendet und auf der Gegenseite wieder in serielle signale gewandelt wird. Das ist denke ich der Hauptgrund warum unterschiedliche Treiber/Betriebssysteme unterschiedlich schnell sind.
  • Ich glaube, wir reden gerade ein wenig aneinander vorbei, wahrscheinlich bin ich mit den Begrifflichkeiten ein wenig durcheinander gekommen.
    Ich meinte nicht den "Inputbuffer", sondern die "move cache size", welche bei Repetier ja quasi die Anzahl der Befehle ist, die auf dem Arduino zwischen gespeichert werden und auch für das vorausschauende Berechnen der Beschleunigungsrampen ("look ahead") genutzt wird. Mir ist klar, dass dieser Wert primär direkt in der Firmware eingestellt wird und in Rep. Server nur zur Zeitberechnung herangezogen wird.
    Dessen Größe ist glaube ich vom RAM des Arduino Due begrenzt, allerdings konnte ich noch nicht herausfinden wo hier die Grenze liegt. Mir wurde im Forum mal 32 als "move cache size" empfohlen, aktuell bin ich bei 45. Wo liegt hier das absolute maximum, was der Arduino Due vertragen kann (der Drucker ist kartesisch, kein Delta).
    Wenn ich übertrieben gesagt den "move cache size" auf 1000 einstelle, landet direkt der halbe Layer im Arduino-Zwischenspeicher, sodass die langsame Kommunikation zwischen Arduino und PC keine Rolle mehr spielt.


  • Ok, auf dem Due kann der Wert schon recht groß werden. Ist aber nicht die liste der gepufferten Befehle sonder der gepufferten Bewegungen. Kleiner unterschied da ja auch noch andere Befehle gesendet werden. Zu groß sollte man ihn nicht wählen, da sonst pausen lange brauchen bis sie reagieren. 32 ist sicher noch ein vernünftiger Wert bedenkt man das mit 16 schon normalerweise keine Pausen entstehen bei normalen Drucken. Bei vielen kleinen Segmenten kann ich das natürlich immer provozieren. Wenn der due 4kb freien RAM anzeigt bist du sicher noch auf der sicheren Seite was die Funktionsfähighkeit angeht. Ob es gut ist kommt drauf an ob du auch mal unterbrechen must und ob die Pfadplanung zu langsam wird.
  • Kann man den freien Ram beim Kompilieren oder während des Betriebs irgendwie auslesen?
    Ich habe gerade in der Config versucht, den größtmöglichen Wert einzustellen: Der "move cache size" lässt sich bis auf 635 setzten, darüber hinaus kommt es zu einem Fehler beim Kompilieren (anscheinend wird der Adressbereich des RAM überschritten).

    Folgender Fehler wird dann gemeldet:

    Arduino: 1.8.8 (Windows 10), Board: "Arduino Due (Programming Port)"

    c:/users/danie/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: address 0x20088020 of C:\Users\danie\AppData\Local\Temp\arduino_build_725774/Repetier.ino.elf section `.bss' is not within region `ram'

    c:/users/danie/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: address 0x20088020 of C:\Users\danie\AppData\Local\Temp\arduino_build_725774/Repetier.ino.elf section `.bss' is not within region `ram'

    c:/users/danie/appdata/local/arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld.exe: address 0x20088020 of C:\Users\danie\AppData\Local\Temp\arduino_build_725774/Repetier.ino.elf section `.bss' is not within region `ram'

    collect2.exe: error: ld returned 1 exit status

    exit status 1
    Fehler beim Kompilieren für das Board Arduino Due (Programming Port).

    Dieser Bericht wäre detaillierter, wenn die Option
    "Ausführliche Ausgabe während der Kompilierung"
    in Datei -> Voreinstellungen aktiviert wäre.


    Das heraufsetzen des Cache wäre aber sowieso nur meine letzte Option, da ich sonst, wie du schon gesagt hast, sehr lange auf eine Reaktion des Druckers bei einer Pause oder anderen Änderungen warten muss.
  • Ich glaube für due wird auch eine memory report beim compilieren ausgegeben. Der Fehler ist wie vermutet das ram ausgeht. Aber da muss ja noch ein puffer rein. 635 ist eh viel zu groß:-)

    Schon den Test mit M111 S24 gemacht viele Zeile pro sekunde der Rechner schafft und ob man die Latenz in Geratemanager anpassen kann.
  • Ich konnte jetzt endlich den M111 S24 - Test durchführen.
    Als Testobjekt habe ich einen G-Code mit einer Größe von 2,4 MB mit ca. 85.000 Zeilen genutzt.
    Ergebniss: Nach 10 Minuten war der Code erst zu 40% übertragen, hochgerechnet also 25 Minuten für den gesamten Code. Das entspricht gerade einmal 57 Zeilen/Sekunde (meine Schätzung war also nah dran). Mein Tablet-PC hingegen hat für den selben Test gerade mal etwa 2 Minuten gebraucht.
    Da ist es kein Wunder, dass der Cache leer läuft :/

    Ich habe auch schon einiges ausprobiert, um die Verbindung zu verbessern:
    Ich habe
    - die Baud-Rateauf 115200 reduziert
    - Im BIOS die Seriellen Ports deaktiviert (der PC hat noch echte serielle Schnittstellen)
    - Im Gerätemanager -> Com7 (Port-Nummer, an dem der Arduino erkannt wird)
    -> Anschlusseinstellungen: Bits pro Sekund erhöht,
    -> Erweiterte Einstellungen : Eingangspuffer und Übertragungspuffer auf Minimum gesetzt, FIFO-Puffer deaktiviert
    Ich konnte nirgendwo eine Einstellung für die Latenz des USB - COM - Ports finden.

    Jede Einstellung habe ich einzeln geändert und danach den Test wiederholt.
    All das hat absolut keine Änderung in der Übetragungsgeschwindigkeit hervorgerufen, sie wurde weder erhöht, noch vermindert, egal was ich eingestellt habe.

    Ehrlich gesagt weiß ich bei vielen dieser Einstellungen nicht mal, wofür sie gut sein sollen.
    Langsam bin ich hier mit meinem Latein am Ende.

    Ich hab noch ein paar Einstellungen im BIOS bezüglich USB gefunden, mit denen ich aber nichts anfangen kann und an denen ich deshalb auch noch nicht herumgespielt habe:

    USB OTG Support: Disabled
    USB VBUS: ON
    XHCI Mode: Enabled
    USB2 Link Power Management: Enabled
    USB 2.0 (EHCI) Support: Disabled
    USB Per Port Control: Enabled
    USB Port 0: Enabled
    USB Port 1: Enabled
    USB Port 2: Enabled
    USB Port 3: Enabled

    Legacy USB Support: Enabled
    XHCI Hand-off: Enabled
    EHCI Hand-off: disabled
    USB Mass Storage Driver Support: Enabled
    USB transfer time-out: 20 sec
    Device Reset time-out: 20 sec
    Device power-up delay: Auto
    Multiplecard Reader 1.00: Auto


    Mein nächster Schritt ist, dass ich den Hersteller des PCs nach einer Lösung frage.
    Hast du noch irgendeine Idee, wo die Ursache liegen könnte?
    Gibt es vielleicht noch spezielle Treiber, die ich ausprobieren könnte?
  • Die Geschwindigkeiten in den Hardwareeinstellungen werden eh nicht genutzt da host die ja selber setzt. Einzig die Latenz wäre etwas aber von den Namen her seh ich nichts was darauf passt. Sind das beides die gleichen windows Versionen, da die Treiber oft von Windows sind. Die installiereten Treiber sagen oft nur nutze den windows Treiber auch für Kennung xy. FTDI ist da eine Ausnahme.

    Du sagtest der langsame hat noch eine echte serielle Schnittstelle. Ist der so alt und vielleicht langsam? Kannst ja mal CPU last prüfen. Eigentlich braucht der server nicht viel Leistung, läuft ja sogar auf einem Raspberry Pi Zero und schafft da auch locker 300 Zeilen pro Sekunde. Das war eigentlich bisher nie ein Problem.

    Hast du beim server mal auf die console geschaut ob da viele resends drin sind. Kommunikationsfehler wären ja wenigstens eine Begründung die sinn macht.

    Übrigens wäre die echte serielle Verbindung schneller:-) Nur kommen da glaube ich 12V raus was der drucker nicht mag. Also wohl besser nicht verbinden.
  • Die Windows-Versionen sind leicht unterschiedlich. Auf dem Tablet hab ich Windows seit etwa 2 Jahren nicht aktualisiert, auf dem neuen Industrie-PC ist das aktuellste Update installiert.

    Die Hardware im Industrie-PC sollte ausreichend sein, verbaut ist eine Intel Celeron N2930 Quad Core-Cpu mit 4 gb DDR3 Ram.

    Die USB-Treiber unterscheiden sich auch: Auf dem Industrie-PC wurde wohl bei der Installation der Arduino-Software ein eigener Treiber installiert (Arduino SRL 1.1.0.0 vom 27.02.2014).
    Auf dem Tablet ist ein Windows-Treiber (Version 10.0.15063.997 vom 21.06.2006) installiert.
    Möglich, dass es daran liegt, wobei ich meine, dass das Problem schon da war, bevor ich die Arduino-Software installiert hatte.
    Ich könnte noch probieren, den Treiber am PC zu deinstallieren und die Windows-Treiber zu laden.

    Bei dem FTDI-Treiber kann man soweit ich gelesen habe auch die Latenz einstellen, aber kann ich diesen einfach für den USB-Port installieren oder funktioniert der Treiber nur mit einem USB-to-Serial-Converter?

    Wo ich gerade in die Spezifikationen des PCs schaue, fällt mir gerade auf, dass dieser einen USB 3.0 und einen USB 2.0 - Anschluss hat. Vielleicht hakt es daran.
    Gerade läuft wieder ein Druck. Sobald der fertig ist, stecke ich das Kabel um und teste, ob sich etwas ändert.

    Ich habe mir die Kommunikation in der Konsole in Rep-Server angeschaut, da sind kaum Resends zu finden. Mir ist aber aufgefallen, dass häufig genau 2 Zeilen zusammen (mit gleichem Zeitstempel) versendet werden. Ist es möglich, durch Anpassung der Firmware mehr Zeilen (z.B. 5 oder 10) auf einmal zu versenden? Damit würde die Auswirkung der vermutlich hohen Latenz reduziert.
  • FTDI Treiber hilft nicht wenn das board den nicht hat.

    Hab aber schon mal gehört das USB 3 Probleme macht und USB 2 nicht. Das board kann sicher nur USB 2 und wird USB 3 ausbremsen. Vielleicht führt das zur Verlangsamung.

    Den puffer groß auszuweiten bringt nicht wirklich etwas. Das habe ich schon probiert. Die Firmware hat ja auch etwas Verarbeitungszeit und irgenwann ziemlich schnell kommen dann trotzdem nur 2-3 Zeilen pro paket zurück weil die anderen dann noch nicht fertig sind. Der Drucker muss ja auch warten bis eine Bewegung fertig ist um neue Befehle entgegen nehmen zu können.
  • Scheinbar hat der PC entgegen der Angaben auf der AB doch 2x USB 3.0, ein Umstecken des Kabels brachte keine Änderung. Auch der Standard-Windows-Treiber ändert nichts, der FTDI-Treiber erkennt das Board nicht (wie du schon geschrieben hast).
    Der Hersteller des PCs (Firma Hematec) hat bisher auch keine Idee.
    Ich werde als nächstes die allgemeine Datentransferrate für große Dateien an den USB-Ports prüfen, um zu testen, ob vielleicht die USB-Controller nicht die volle Leistung bringen.
    Die letzte Alternative wäre nur noch, von den Tablet eine Sicherungskopie des kompletten Systems zu erstellen und zu versuchen, dieses auf dem Industrie-PC zu überspielen. Damit könnte ich alle softwareseitigen Störquellen ausschließen.

    Wenn das auch nicht hilft, bleibt mir nur noch, es mit einem anderen Hersteller zu probieren :(
  • Kannst auch einen günstigen Raspberry Pi nehmen, nur bitte mit guter Stromversorgung weil der sonst zickig wird. Dann unser image drauf und gut ist.
  • edited June 2019
    Ich habe den PC einmal neu aufgesetzt mit einer frischen Windows 10 - Installation. Als Browser habe ich Microsoft Edge drauf gelassen und Repetier Server 0.91.2 installiert, gleiches Ergebnis wie vorher.

    Dann habe ich ein anderes Tablet, was ich noch herumliegen hatte (anderer Hersteller, selbe CPU wie ursprüngliches Tablet) angeschlossen mit Repetier Server 0.86, was zu meinem Erstaunen aber auch langsam war.
    Im Anschluss habe ich auf dem Industrie-PC nochmal Repetier Server 0.70.1 installiert und siehe da, es läuft doch wieder mit richtiger Geschwindigkeit (selber G-Code, der vorher 25 Minuten brauchte, in ca. 3 Minuten übertragen).
    Der Code wird so schnell übertragen, das der Browser im Steuerungstab zeitweilig einfriert und mit der nächsten Aktualisierung des Fensters (nach einigen Sekunden) sofort 10% weiter war als vorher. Womöglich ist der Server in dieser Version bei dem Test so stark ausgelastet, dass für das Browser-GUI keine Leistung mehr zur Verfügung steht.

    Bei den Versionen 0.86 und 0.91.2 war das nicht so, da konnte während des Tests die Server-GUI im Browser immer bedient werden. Dafür war die Datenrate halt deutlich schlechter.
    Das führt mich zu der Annahme, dass zwischen den Versionen 0.70.1 und 0.86 irgendetwas an der Kommunikation geändert wurde, vielleicht um die Anzeige im Server zu verbessern, was aber die Latenz erhöht.

    Das ist schade, da ich gerne die neuen Features von 0.91.2 (insbesondere das "Rescue-System") nutzen wollte.
    Ich vermute, man kann nicht ohne Weiteres die Version 0.91.2 mit der 0.70.1er Kommunikationsschnittstelle kombinieren?
  • Ok hab mal selber gemessen mit letzter version auf einem virtuellen Windows 10 verbunden mit Drucker am Due Programming port was du scheinbar ja auch nutzt. 30798 Zeilen in 2:27 = 147s => 209,51 Zeilen/s.
    Dann hab ich gesehen das der Treiber Teensy PLC hieß und hab neu den Arduino Treiber eingerichtet. Erster druck 5:25 = 325s => 94,7s. Dabei war aber der Microsoft defender und updater im Task manager sichtbar aktiv. Neuer test ohne updater/virenscanner aktiv 3:49 =229s => 134.

    Vergleich selbe Version am mac, benchy 105373 Zeilen in 2:45 = 165s => 638,6 Zeilen/s. Eine echt ander hausnummer. Damit ist der Drucker selbst aus dem schneider.

    Gegentest Repetier-Host unter Windows: 439 Zeilen/s.
    Neue Boost bibliothek und timeouts explizit gesetzt: 233 Zeilen/s
    Gleiche im debug modus: 410 Zeilen/s.
    Es scheint so als hängt die Geschwindigkeit unter windows auch etwas vom Timing ab. Werd das noch weiter untersuchen und dann hoffentlich herausfinden wie ich stabile Werte hin bekomme.
  • Ich habe auch ein wenig weiter mit den Versionen 0.70.1 und 0.91.2 (die Version von deiner PN) getestet. Ich habe die Tests je mit dem Standard - Windows - Treiber und mit dem Arduino-Treiber durchgeführt mit dem selben Ergebnis:

    Repetier Server 0.70.1: Der Test-Code mit 85.000 Zeilen wurde innerhalb von ca. 6 Minuten übertragen, was guten 280 Zeilen/s entpricht. Die Geschwindigkeit (%/Sekunde) war von Anfang bis Ende ziemlich konstant, die Code wurde immer in 6er Paketen übertragen:

    Repetier Server 0.91.2: Der selbe Code wurde innerhalb von ca. 14 Minuten übertragen, was ca. 100 Zeilen/s entspricht.
    Jetzt wird´s aber interessant: Die Geschwindigkeit zu Anfang ist um ein Vielfaches höher als zum Ende des Tests: Die ersten 10% werden innerhalb von 20 Sekunden übertragen (~425 Zeilen/s).
    Nach etwa 20-25 % Fortschritt nimmt die Geschwindigkeit aber immer weiter ab, sodass ich zum Ende des Tests vermutlich bei ca 70-80 Zeilen/s liege.
    Wenn ich mir die Kommunikation anschaue, sehe ich auch den Grund dafür.
    Hier ein Screenshot zu Anfang des Drucks:



    Hier ein Screenshot zu Ende des Drucks bei etwa 85%:
    Wie man sieht, werden zu Beginn des Drucks die Zeilen in 5er - Paketen (ich glaube, ganz zu Anfang waren es sogar noch größere Pakete) übertragen, zum Ende nur noch in 2er - Paketen. Ich habe die Konsole eine Weile beobachtet, man kann schön erkennen, wie mit der Zeit die Pakete nach und nach kleiner werden. Dabei bleibt der zeitliche Abstand zwischen den Paketen immer ähnlich, dadurch ist der Druchsatz natürlich viel Geringer.

    Wenn ich den Test jetzt einfach neu starte, bleibt die Geschwindigkeit auf diesem Niveau.
    Erst, wenn ich den Server stoppe und neu starte, beginnt die Übertragung wieder sehr schnell, nimmt aber auch wieder schnell ab.

    Möglicherweise hilft diese Erkenntnis, das Problem einzugrenzen.
    Konntest du so ein Phänomen auch beobachten?
    Vielleicht ist dafür ein größerer Code als 30000 Zeilen notwendig.
    Übrigens: Die Version 0.91.2 von deiner PN und die normale Download-Version waren bis aufs Byte genau gleich groß. Waren die überhaupt unterschiedlich?
  • Oops, du solltest im link die version durch 0.92.0 ersetzen. Hab wohl vergessen den link anzupassen.
  • Ich habe jetzt die Version 0.92.0 getestet, das ist wirklich ein riesiger Unterschied!
    Der Code wurde in 1:58 Minuten übertragen, also 720 Zeilen/s, und zwar mit stabiler Geschwindigkeit.


    Der zeitliche Abstand zwischen den Zeilen bzw Zeilenblöcken ist auch viel geringer als bei den andern Versionen.
    Ich habe jetzt noch keinen echten Druck damit getestet, aber im DEBUG sieht das schon sehr gut aus.

    Vielen Dank für deine Mühen.
    Stellst du die Version nun auch öffentlich zur Verfügung?
  • Die Version ist noch nicht 100% fertig was geplante features angeht, wird aber bald kommen. Schön das es bei die so schnell ist. Mal sehen wenn ich es mich einem Laptop versuch auf dem Windows nativ läuft ob es dann auch bei mir so schnell ist. Zumindest in der Virtuellen Maschine ist es zu zuverlässig nicht die langsame Geschwindigkeit, was schon mal ein Fortschritt ist. Geändert hab ich nur wie Windows auf Meldungen wartet, also wie lange. Der Rest scheint nicht zu bremsen, ist also wirklich nur mit welchen Einstellungen man windows nach neuen Daten fragt.
  • Hab noch mal auf meinem Windows Laptop getestet und komme von 170 Zeilen/s auf 940 Zeilen/s mit der Modifikation. Die scheint also wirklich eine spürbare verbesserung zu bringen und das ist sogar schneller als der Host es schafft. Die Änderung wird also sicherlich so in der Form erst mal drin bleiben.
  • Ich habe die Version jetzt eine Weile getestet.

    Leider sind neue Probleme aufgetaucht, die aber vermutlich nicht mit der neuen Server-Version zu tun haben. Vielleicht kannst du mir trotzdem auch hier helfen:

    Seit etwa einer Woche habe ich immer wieder Druckabbrüche, meistens nach 5 - 15 Stunden (häufig zu ähnlichen Zeitpunkten im Druck).
    Der G-Code selber ist auf jeden Fall sauber, da ich diesen schon einige male erfolgreich gedruckt habe.
    Wenn der Druck abbricht, gehen auch sämtliche Heizelemente aus. Der Fehler wird in Repetier-Server auch erkannt als Druckabbruch, allerdings wird der "Rettungscode", den ich im Falle eines Verbindungsabbruchs definiert habe, nicht gesendet. Eigentlich soll der Drucker X- und Y-Achse homen und das Heizbett auf eine definierte Temperatur fahren, das geschieht aber nicht.
    Ich habe bereits den Rettungsmodus getestet (während eines Testdrucks das USB-Kabel gezogen und wieder eingesteckt), in diesem Fall wird der Code ausgeführt.
    Ich habe den G-code im Trockenlauf (Extruder und Druckbett abgeschaltet, Motoren aktiv) gestern durchlaufen lassen ohne Störungen, kann aber auch Zufall sein, dass der Fehler da nicht aufgetreten ist.
    Ich habe auch schon am USB-Kabel an beiden Enden gewackelt während des Drucks ohne Ausfall, daher denke ich, dass es kein Wackelkontakt ist.
    Die Verbindungsqualität scheint auch an sonsten sehr gut zu sein, bei 100 MB übertragenem Code gerade mal 5 Fehler.
    Außerdem habe ich zwischenzeitlich die Server-Version 0.72 installiert, auch hier trat der Fehler auf. Ich denke daher nicht, dass es an der neuen Server-Version liegt.

    Zur Fehlersuche habe ich einige Drucke mitgeloggt, hier der Übersichtlichkeit halber nur die letzten Worte des Druckers vor seinem Ableben:

    Abbruch 1:
    ...
    < 18:33:06.043: N1540883 G1 X170.913 Y273.704 E19.2473
    > 18:33:06.059: ok 33551
    < 18:33:06.059: N1540884 G1 X170.590 Y272.590 E19.2989
    > 18:33:06.074: ok 33552
    < 18:33:06.074: N1540885 G1 X169.970 Y270.658 E19.3891
    > 18:33:23.902: start
    > 18:33:23.902: Info:PowerUp
    > 18:33:23.902: Detected EEPROM version:20
    > 18:33:23.902: XY jerk was too low, setting to 14.08
    > 18:33:23.902: Z jerk was too low, setting to 0.34
    > 18:33:23.902: Free RAM:72252
    > 18:33:23.917: SelectExtruder:0
    > 18:33:23.917: FlowMultiply:100
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    > 18:33:23.917: Warning: Seems like we missed a ok - continue sending.
    > 18:33:23.917: wait
    < 18:33:23.917: N0 M110 N0
    < 18:33:23.917: N1 M105
    < 18:33:23.917: N2 M115
    < 18:33:23.917: N3 M220 S100
    < 18:33:23.917: N4 M221 S100
    < 18:33:23.917: N5 M355
    < 18:33:23.917: N6 G92 E0
    < 18:33:23.917: N7 G90
    < 18:33:23.917: N8 M82
    < 18:33:23.917: N9 G21
    < 18:33:23.917: N10 M114
    < 18:33:23.917: N11 G90
    > 18:33:23.917: ok
    > 18:33:23.917: ok 1
    < 18:33:23.917: N12 M111 S6
    > 18:33:23.917: T:217.87 /0 B:67.86 /0 B@:0 @:0 T0:217.87 /0 @0:0 T1:33.33 /0 @1:0 T2:46.47 /0 @2:0
    > 18:33:23.917: ok 2
    < 18:33:23.917: N13 M360
    > 18:33:23.933: FIRMWARE_NAME:Repetier_1.0.4 COMPILED:May 30 2019 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:3 REPETIER_PROTOCOL:3
    > 18:33:23.933: Cap:PROGRESS:0
    > 18:33:23.933: Cap:AUTOREPORT_TEMP:1
    > 18:33:23.933: Cap:HOST_RESCUE:1
    > 18:33:23.933: Cap:EEPROM:1
    > 18:33:23.933: Cap:AUTOLEVEL:0
    > 18:33:23.933: Cap:Z_PROBE:0
    > 18:33:23.933: Cap:SOFTWARE_POWER:0
    > 18:33:23.933: Cap:TOGGLE_LIGHTS:0
    > 18:33:23.933: Cap:PAUSESTOP:1
    > 18:33:23.933: Cap:PREHEAT:1
    > 18:33:23.933: Cap:EMERGENCY_PARSER:1
    > 18:33:23.933: Printed filament:82032.80m Printing time:367 days 17 hours 48 min
    > 18:33:23.933: PrinterMode:FFF
    > 18:33:23.933: ok 3
    > 18:33:23.933: SpeedMultiply:100
    > 18:33:23.933: ok 4
    > 18:33:23.933: FlowMultiply:100
    > 18:33:23.933: ok 5
    < 18:33:23.933: N14 M539 S1
    < 18:33:23.933: @getip
    > 18:33:25.058: Info:No case lights
    > 18:33:25.058: ok 6
    > 18:33:25.058: ok 7
    > 18:33:25.058: ok 8
    > 18:33:25.058: ok 9
    > 18:33:25.058: ok 10
    > 18:33:25.058: X:0.00 Y:0.00 Z:0.000 E:0.0000
    > 18:33:25.058: ok 11
    > 18:33:25.058: ok 12
    > 18:33:25.058: DebugLevel:6
    > 18:33:25.058: ok 13
    > 18:33:25.058: Config:Baudrate:250000
    > 18:33:25.058: Config:InputBuffer:127
    > 18:33:25.058: Config:NumExtruder:3
    > 18:33:25.058: Config:MixingExtruder:0
    > 18:33:25.058: Config:HeatedBed:1
    > 18:33:25.058: Config:SDCard:1
    > 18:33:25.058: Config:Fan:1
    > 18:33:25.058: Config:Fan2:1
    > 18:33:25.058: Config:LCD:0
    > 18:33:25.058: Config:SoftwarePowerSwitch:0
    > 18:33:25.058: Config:XHomeDir:-1
    > 18:33:25.058: Config:YHomeDir:-1
    > 18:33:25.058: Config:ZHomeDir:-1
    > 18:33:25.058: Config:XHomePos:0.00
    > 18:33:25.058: Config:YHomePos:0.00
    > 18:33:25.058: Config:ZHomePos:0.000
    > 18:33:25.058: Config:SupportG10G11:1
    > 18:33:25.058: Config:SupportLocalFilamentchange:1
    > 18:33:25.058: Config:CaseLights:0
    > 18:33:25.058: Config:ZProbe:0
    > 18:33:25.058: Config:Autolevel:0
    > 18:33:25.058: Config:EEPROM:1
    > 18:33:25.058: Config:PrintlineCache:96
    > 18:33:25.058: Config:JerkXY:14.08
    > 18:33:25.058: Config:KeepAliveInterval:2000
    > 18:33:25.058: Config:JerkZ:0.34
    > 18:33:25.058: Config:RetractionLength:3.00
    > 18:33:25.058: Config:RetractionLongLength:13.00
    > 18:33:25.058: Config:RetractionSpeed:40.00
    > 18:33:25.058: Config:RetractionZLift:0.00
    > 18:33:25.058: Config:RetractionUndoExtraLength:0.00
    > 18:33:25.058: Config:RetractionUndoExtraLongLength:0.00
    > 18:33:25.058: Config:RetractionUndoSpeed:20.00
    > 18:33:25.058: Config:XMin:0.00
    > 18:33:25.058: Config:YMin:0.00
    > 18:33:25.058: Config:ZMin:0.00
    > 18:33:25.058: Config:XMax:810.00
    > 18:33:25.058: Config:YMax:420.00
    > 18:33:25.058: Config:ZMax:805.00
    > 18:33:25.058: Config:XSize:810.00
    > 18:33:25.058: Config:YSize:420.00
    > 18:33:25.058: Config:ZSize:805.00
    > 18:33:25.058: Config:XPrintAccel:2000.00
    > 18:33:25.058: Config:YPrintAccel:2000.00
    > 18:33:25.058: Config:ZPrintAccel:300.00
    > 18:33:25.058: Config:XTravelAccel:1000.00
    > 18:33:25.058: Config:YTravelAccel:1000.00
    > 18:33:25.058: Config:ZTravelAccel:300.00
    > 18:33:25.058: Config:PrinterType:Cartesian
    > 18:33:25.058: Config:MaxBedTemp:120
    > 18:33:25.058: Config:Extr.1:Jerk:20.00
    > 18:33:25.058: Config:Extr.1:MaxSpeed:50.00
    > 18:33:25.058: Config:Extr.1:Acceleration:5000.00
    > 18:33:25.058: Config:Extr.1:Diameter:0.00
    > 18:33:25.058: Config:Extr.1:MaxTemp:275
    > 18:33:25.058: Config:Extr.2:Jerk:20.00
    > 18:33:25.058: Config:Extr.2:MaxSpeed:50.00
    > 18:33:25.058: Config:Extr.2:Acceleration:5000.00
    > 18:33:25.058: Config:Extr.2:Diameter:0.00
    > 18:33:25.058: Config:Extr.2:MaxTemp:275
    > 18:33:25.058: Config:Extr.3:Jerk:NAN
    > 18:33:25.058: Config:Extr.3:MaxSpeed:NAN
    > 18:33:25.058: Config:Extr.3:Acceleration:NAN
    > 18:33:25.058: Config:Extr.3:Diameter:0.00
    > 18:33:25.058: Config:Extr.3:MaxTemp:275
    > 18:33:25.058: ok 14
    > 18:33:25.058: wait
    < 18:33:25.058: N15 M155 S1
    < 18:33:25.058: N16 M415
    < 18:33:25.058: @stopLog

    Abbruch 2:

    ...
    < 13:56:09.985: N5653344 G1 X57.617 Y326.555 E0.1991
    > 13:56:10.016: ok 17247
    < 13:56:10.016: N5653345 G1 X57.920 Y326.188 E0.2203
    > 13:56:10.032: ok 17248
    < 13:56:10.032: N5653346 G1 X58.142 Y325.824 E0.2392
    > 13:56:41.374: start
    > 13:56:41.374: Info:PowerUp
    > 13:56:41.374: Detected EEPROM version:20
    > 13:56:41.374: XY jerk was too low, setting to 14.08
    > 13:56:41.374: Z jerk was too low, setting to 0.34
    > 13:56:41.374: Free RAM:81212
    > 13:56:41.374: SelectExtruder:0
    > 13:56:41.374: FlowMultiply:100
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    > 13:56:41.374: Warning: Communication timeout - resetting communication buffer.
    > 13:56:41.374: Connection status: Buffered:0, Manual Commands: 16, Job Commands: 1
    > 13:56:41.374: Buffer used:0 Enforced free byte:0 lines stored:0
    < 13:56:41.374: N0 M110 N0
    < 13:56:41.374: N1 M105
    < 13:56:41.374: N2 M115
    < 13:56:41.374: N3 M220 S100
    > 13:56:41.374: ok
    > 13:56:41.374: ok 1
    < 13:56:41.374: N4 M221 S100
    > 13:56:41.374: T:206.10 /0 B:67.65 /0 B@:0 @:0 T0:206.10 /0 @0:0 T1:34.53 /0 @1:0 T2:47.25 /0 @2:0
    > 13:56:41.374: ok 2
    < 13:56:41.374: N5 M355
    > 13:56:41.390: FIRMWARE_NAME:Repetier_1.0.4 COMPILED:Jul 3 2019 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:3 REPETIER_PROTOCOL:3
    > 13:56:41.390: Cap:PROGRESS:0
    > 13:56:41.390: Cap:AUTOREPORT_TEMP:1
    > 13:56:41.390: Cap:HOST_RESCUE:1
    > 13:56:41.390: Cap:EEPROM:1
    > 13:56:41.390: Cap:AUTOLEVEL:0
    > 13:56:41.390: Cap:Z_PROBE:0
    > 13:56:41.390: Cap:SOFTWARE_POWER:0
    > 13:56:41.390: Cap:TOGGLE_LIGHTS:0
    > 13:56:41.390: Cap:PAUSESTOP:1
    > 13:56:41.390: Cap:PREHEAT:1
    > 13:56:41.390: Cap:EMERGENCY_PARSER:1
    > 13:56:41.390: Printed filament:82102.40m Printing time:368 days 1 hours 54 min
    > 13:56:41.390: PrinterMode:FFF
    > 13:56:41.390: ok 3
    < 13:56:41.390: N6 G92 E0
    > 13:56:41.405: SpeedMultiply:100
    > 13:56:41.405: ok 4
    > 13:56:41.405: FlowMultiply:100
    > 13:56:41.405: ok 5
    > 13:56:41.405: Info:No case lights
    > 13:56:41.405: ok 6
    < 13:56:41.405: N7 G90
    < 13:56:41.405: N8 M82
    < 13:56:41.405: N9 G21
    < 13:56:41.405: N10 M114
    < 13:56:41.405: N11 G90
    > 13:56:41.405: ok 7
    > 13:56:41.405: ok 8
    > 13:56:41.405: ok 9
    > 13:56:41.405: ok 10
    < 13:56:41.405: N12 M111 S6
    < 13:56:41.405: N13 M360
    > 13:56:41.405: X:0.00 Y:0.00 Z:0.000 E:0.0000
    > 13:56:41.405: ok 11
    > 13:56:41.405: ok 12
    > 13:56:41.405: DebugLevel:6
    > 13:56:41.405: ok 13
    > 13:56:41.405: Config:Baudrate:250000
    < 13:56:41.405: N14 M539 S1
    < 13:56:41.405: @getip
    > 13:56:42.530: Config:InputBuffer:127
    > 13:56:42.530: Config:NumExtruder:3
    > 13:56:42.530: Config:MixingExtruder:0
    > 13:56:42.530: Config:HeatedBed:1
    > 13:56:42.530: Config:SDCard:1
    > 13:56:42.530: Config:Fan:1
    > 13:56:42.530: Config:Fan2:1
    > 13:56:42.530: Config:LCD:0
    > 13:56:42.530: Config:SoftwarePowerSwitch:0
    > 13:56:42.530: Config:XHomeDir:-1
    > 13:56:42.530: Config:YHomeDir:-1
    > 13:56:42.530: Config:ZHomeDir:-1
    > 13:56:42.530: Config:XHomePos:0.00
    > 13:56:42.530: Config:YHomePos:0.00
    > 13:56:42.530: Config:ZHomePos:0.000
    > 13:56:42.530: Config:SupportG10G11:1
    > 13:56:42.530: Config:SupportLocalFilamentchange:1
    > 13:56:42.530: Config:CaseLights:0
    > 13:56:42.530: Config:ZProbe:0
    > 13:56:42.530: Config:Autolevel:0
    > 13:56:42.530: Config:EEPROM:1
    > 13:56:42.530: Config:PrintlineCache:32
    > 13:56:42.530: Config:JerkXY:14.08
    > 13:56:42.530: Config:KeepAliveInterval:2000
    > 13:56:42.530: Config:JerkZ:0.34
    > 13:56:42.530: Config:RetractionLength:3.00
    > 13:56:42.530: Config:RetractionLongLength:13.00
    > 13:56:42.530: Config:RetractionSpeed:40.00
    > 13:56:42.530: Config:RetractionZLift:0.00
    > 13:56:42.530: Config:RetractionUndoExtraLength:0.00
    > 13:56:42.530: Config:RetractionUndoExtraLongLength:0.00
    > 13:56:42.530: Config:RetractionUndoSpeed:20.00
    > 13:56:42.530: Config:XMin:0.00
    > 13:56:42.530: Config:YMin:0.00
    > 13:56:42.530: Config:ZMin:0.00
    > 13:56:42.530: Config:XMax:810.00
    > 13:56:42.530: Config:YMax:420.00
    > 13:56:42.530: Config:ZMax:805.00
    > 13:56:42.530: Config:XSize:810.00
    > 13:56:42.530: Config:YSize:420.00
    > 13:56:42.530: Config:ZSize:805.00
    > 13:56:42.530: Config:XPrintAccel:2000.00
    > 13:56:42.530: Config:YPrintAccel:2000.00
    > 13:56:42.530: Config:ZPrintAccel:300.00
    > 13:56:42.530: Config:XTravelAccel:1000.00
    > 13:56:42.530: Config:YTravelAccel:1000.00
    > 13:56:42.530: Config:ZTravelAccel:300.00
    > 13:56:42.530: Config:PrinterType:Cartesian
    > 13:56:42.530: Config:MaxBedTemp:120
    > 13:56:42.530: Config:Extr.1:Jerk:20.00
    > 13:56:42.530: Config:Extr.1:MaxSpeed:50.00
    > 13:56:42.530: Config:Extr.1:Acceleration:5000.00
    > 13:56:42.530: Config:Extr.1:Diameter:0.00
    > 13:56:42.530: Config:Extr.1:MaxTemp:275
    > 13:56:42.530: Config:Extr.2:Jerk:20.00
    > 13:56:42.530: Config:Extr.2:MaxSpeed:50.00
    > 13:56:42.530: Config:Extr.2:Acceleration:5000.00
    > 13:56:42.530: Config:Extr.2:Diameter:0.00
    > 13:56:42.530: Config:Extr.2:MaxTemp:275
    > 13:56:42.530: Config:Extr.3:Jerk:NAN
    > 13:56:42.530: Config:Extr.3:MaxSpeed:NAN
    > 13:56:42.530: Config:Extr.3:Acceleration:NAN
    > 13:56:42.530: Config:Extr.3:Diameter:0.00
    > 13:56:42.530: Config:Extr.3:MaxTemp:275
    > 13:56:42.530: ok 14
    > 13:56:42.530: wait
    < 13:56:42.530: N15 M155 S1
    < 13:56:42.530: N16 M415
    < 13:56:42.530: @stopLog

    Was mir auffällt:
    - Die Dauer zwischen dem Stop des Drucks und dem Neustart der Kommunikation ist nicht identisch (einmal 17 Sekunden, einmal 31 Sekunden.
    - Der "Rettungscode" ist in der Kommunikation nach dem Stop nicht enthalten
    - Nach "Start" wird "Info: PowerUp" angezeigt.

    Die vielen "Warning: Seems like we missed a ok - continue sending." habe ich bei jedem Druckerstart und ist erst mal nicht problematisch, denke ich. Während des Drucks tritt diese Meldung nicht auf.

    Ich habe schon den Arduino Due ausgetausch, ohne Besserung.
    Als Firmware läuft aktuell die Version "1.04 dev".

    Was kann diesen Fehler auslösen?
    Heißt die Meldung "Info: PowerUp", dass die Spannungsversorgung wegbricht und der Arduino selber komplett neu bootet oder ist das eine Standardmeldung für eine neu hergestellte Verbindung?
    Die Meldung kommt auch, wenn ich das USB-Kabel ziehe und wieder einstecke. In diesem Fall kommt dann aber nicht "Warning: Seems like we missed a ok - continue sending." Kann es sein, das die Meldung auch beim Umschalten zwischen 5V (USB) - und 24V (RADDS) - Spannungsquelle erscheint?

    Das RADDS 1.5 - Shield, welches auf dem Arduino sitzt, ist mittlerweile schon 4 Jahre alt und wurde lange Zeit fast nonstop genutzt. Kann es sein, dass der DC-DC-Konverter des Shields, welcher den Arduino versorgt, seinen Zenit erreicht hat und Aussetzer hat?
    Gibt es noch andere Möglichkeiten, über irgendwelche Logs die Fehlerquelle zu identifizieren?

    Die 24V-Versorgung kann es eigentlich nicht sein, da daran auch der Industrie-PC hängt und dieser ist laut Windows Event-Log nicht abgestürzt.

  • Ich habe noch etwas herumprobiert:
    Zum Testen habe ich 2 Tablets, auf einem läuft Rep. Server 0.70.1, auf dem anderen 0.86.2. Außerdem habe ich 2 Drucker mit gleicher Hardware (Arduino Due und RADDS 1.5), wovon der Kleinere (gesteuert von einem Tablet mit Rep. Server 0.70.1 mit Repetier-Firmware 0.92) seit nunmehr 3 Jahren ohne jedwede Ausfälle läuft, der Größere (der Drucker mit dem neuen Industrie-PC) hatte jetzt die Absturz-Probleme.

    Ich habe festgestellt, dass immer, wenn Repetier Server neu startet, es zu den vielen "Warning: Seems like we missed a ok - continue sending." kommt. Es dauert etwa 30 Sekunden, bis der "communication buffer" zurückgesetzt wird und die Kommunikation funktioniert. Davor habe ich keine Temperaturanzeigen und kann den Drucker nicht steuern, nach dem Zurücksetzten läuft alles wieder.
    Das tritt sowohl auf, wenn ich im laufendem Betrieb den Server stoppe und wieder starte als auch wenn ich den PC komplett neu starte.

    Das passiert aber nur, wenn ich eine Rep-Server-Version nutze, die neuer als 0.70.1 ist (also 0.86.2 und 0.92).
    Wenn ich Rep-Server 0.70.1 installiere (egal auf welcher Kombination aus Tablet / PC oder oder Firmware-Version), habe ich dieses Problem nicht. Mit 0.70.1 ist die Verbindung sofort nach Einschalten des Servers da.

    Vielleicht werden die Abstürze doch durch die neuere Server-Version ausgelöst.
    Ich werde noch ein paar Trockenläufe durchführen und testen, ob der Fehler mit 0.70.1 auch wieder auftritt.
  • < 18:33:06.074: N1540885 G1 X169.970 Y270.658 E19.3891
    > 18:33:23.902: start
    > 18:33:23.902: Info:PowerUp
    Das heist erst mal das der Drucker neu gestartet wurde. Und das während des drucks. Ich nehme an dein Timeout ist 3s und weil er zwischendurch 20 sekunden nicht reagiert haben sich da die "Warning: Seems like we missed a ok - continue sending." angesammelt denke ich. Kannst im server.log (c:/ProgramData/Repetier-Server/logs) nachsehen ob der server zu der Zeit neu verbunden hat. Das loggt der ja normalerweise. Jedenfalls ein Reset des Druckers führt immer zum Abbruch des Drucks weshalb dann auch das Rescue nicht funktioniert. Wäre allerdings auch ein Kandidat zum abfangen, wobei hier die Firmware nicht wie beim usb verbindungsabbruch helfen kann. Da er auch nicht so reagiert denke ich das wirklich der Drucker neu gestartet hat ohne das die serielle Verbindung getrennt wurde. PowerUp ist eigentlich der normale start aber ohne strom hätte er die Serielle Verbindung getrennt. Es gibt aug watchdog/reset/brownout was die eigentlichen verdächtigen wären.

    Bin mal gespannt auf tests mit 0.70.1 - eiegntlich sieht es aus als ob die druckerseite hier neu startet. Ist aber vermutlich schwer zu testen wenn es so unregelmäßig passiert.

  • Ich habe jetzt den Druck (20h Druckzeit jeweils) x3 mit Repetier Server 0.70.1 durchgeführt ohne Fehler oder Abbrüche. 2x davon waren Trockenläufe, aber mit aktivem Extruder.
    Es scheint also doch an der Repetier-Version 0.92 zu liegen.

    Ich habe mir folgendes überlegt:
    Immer, wenn der Druck mit v0.92 abgebrochen ist, kam die Meldung "Warning: Seems like we missed a ok - continue sending." mehrfach.
    Diese Meldung kann ich nur reproduzieren, indem ich Repetier Server stoppe und neu starte. Wenn ich nur die USB-Verbindung trenne und wiederherstelle, kommt die Meldung nicht. Dabei ist es egal, ob das Arduino-board nur vom USB-Anschluss oder auch extern durch 24V versorgt wird.
    Daraus schließe ich, dass bei den Druckabbrüchen, die ich beschrieben habe, sich der Server von alleine neu gestartet haben muss und dadurch den Druck beendet hat, weshalb auch immer.

    Da ich jetzt alle Teile des Auftrags fertig gedruckt habe, könnte ich jetzt noch testen, ob sich der Fehler auch im Debug-Modus (M111 S24) reproduzieren lässt. Das wäre dann ein Indiz dafür, dass vielleicht z.B. irgendein Puffer oder Zähler im Server überläuft und so einen Absturz hervorruft.

    Ich habe mir die Server-Log zum Zeitpunkt des Absturzes angesehen:
    Absturz 1:
    2019-07-02 06:43:24: Job created: C:\ProgramData\Repetier-Server\printer\Perseus\jobs/00000003_V6   PART   002730785 0.u
    2019-07-02 06:43:25: finish job C:\ProgramData\Repetier-Server\printer\Perseus\jobs/00000003_V6 PART 002730785 0.u
    2019-07-02 06:43:25: start printjob V6 PART 002730785 0 on printer Perseus
    2019-07-02 07:38:59: Host not found: download.repetier-server.com
    2019-07-02 07:38:59: Host not found: licence.internetloesungen.com
    2019-07-02 08:44:36: Host not found: download.repetier-server.com
    2019-07-02 08:44:36: Host not found: licence.internetloesungen.com
    2019-07-02 09:50:14: Host not found: download.repetier-server.com
    2019-07-02 09:50:14: Host not found: licence.internetloesungen.com
    2019-07-02 10:55:51: Host not found: download.repetier-server.com
    2019-07-02 10:55:51: Host not found: licence.internetloesungen.com
    2019-07-02 12:01:28: Host not found: download.repetier-server.com
    2019-07-02 12:01:28: Host not found: licence.internetloesungen.com
    2019-07-02 13:07:06: Host not found: download.repetier-server.com
    2019-07-02 13:07:06: Host not found: licence.internetloesungen.com
    2019-07-02 14:12:43: Host not found: download.repetier-server.com
    2019-07-02 14:12:43: Host not found: licence.internetloesungen.com
    2019-07-02 15:18:20: Host not found: download.repetier-server.com
    2019-07-02 15:18:20: Host not found: licence.internetloesungen.com
    2019-07-02 16:23:58: Host not found: download.repetier-server.com
    2019-07-02 16:23:58: Host not found: licence.internetloesungen.com
    2019-07-02 17:29:35: Host not found: download.repetier-server.com
    2019-07-02 17:29:35: Host not found: licence.internetloesungen.com
    2019-07-02 18:35:12: Host not found: download.repetier-server.com
    2019-07-02 18:35:12: Host not found: licence.internetloesungen.com
    2019-07-02 18:56:02: Websocket opened
    2019-07-02 19:28:37: Job created: C:\ProgramData\Repetier-Server\printer\Perseus\models/00000008_V6 PART 002730785 0 Z 57,3.u
    2019-07-02 19:28:37: finish job C:\ProgramData\Repetier-Server\printer\Perseus\models/00000008_V6 PART 002730785 0 Z 57,3.u
    2019-07-02 19:28:37: Uploaded size:40737048
    2019-07-02 19:28:38: Updating info for C:\ProgramData\Repetier-Server\printer\Perseus\models/00000008_V6 PART 002730785 0 Z 57,3.g printer Perseus
    2019-07-02 19:31:41: Job created: C:\ProgramData\Repetier-Server\printer\Perseus\jobs/00000004_V6 PART 002730785 0 Z 57,3.u
    2019-07-02 19:31:42: finish job C:\ProgramData\Repetier-Server\printer\Perseus\jobs/00000004_V6 PART 002730785 0 Z 57,3.u
    Absturz 2:

    2019-07-04 19:37:25: start printjob V6   PART   002730785 0 on printer Perseus
    2019-07-04 20:39:25: Host not found: download.repetier-server.com
    2019-07-04 20:39:25: Host not found: licence.internetloesungen.com
    2019-07-04 21:45:02: Host not found: download.repetier-server.com
    2019-07-04 21:45:02: Host not found: licence.internetloesungen.com
    2019-07-04 22:50:40: Host not found: download.repetier-server.com
    2019-07-04 22:50:40: Host not found: licence.internetloesungen.com
    2019-07-04 23:56:17: Host not found: download.repetier-server.com
    2019-07-04 23:56:17: Host not found: licence.internetloesungen.com
    2019-07-05 01:01:54: Host not found: download.repetier-server.com
    2019-07-05 01:01:54: Host not found: licence.internetloesungen.com
    2019-07-05 02:07:32: Host not found: download.repetier-server.com
    2019-07-05 02:07:32: Host not found: licence.internetloesungen.com
    2019-07-05 03:13:09: Host not found: download.repetier-server.com
    2019-07-05 03:13:09: Host not found: licence.internetloesungen.com
    2019-07-05 04:18:46: Host not found: download.repetier-server.com
    2019-07-05 04:18:46: Host not found: licence.internetloesungen.com
    2019-07-05 05:24:24: Host not found: download.repetier-server.com
    2019-07-05 05:24:24: Host not found: licence.internetloesungen.com
    2019-07-05 06:30:01: Host not found: download.repetier-server.com
    2019-07-05 06:30:01: Host not found: licence.internetloesungen.com
    2019-07-05 07:35:38: Host not found: download.repetier-server.com
    2019-07-05 07:35:38: Host not found: licence.internetloesungen.com
    2019-07-05 08:41:16: Host not found: download.repetier-server.com
    2019-07-05 08:41:16: Host not found: licence.internetloesungen.com
    2019-07-05 09:46:53: Host not found: download.repetier-server.com
    2019-07-05 09:46:53: Host not found: licence.internetloesungen.com
    2019-07-05 10:52:30: Host not found: download.repetier-server.com
    2019-07-05 10:52:30: Host not found: licence.internetloesungen.com
    2019-07-05 11:58:08: Host not found: download.repetier-server.com
    2019-07-05 11:58:08: Host not found: licence.internetloesungen.com
    2019-07-05 13:03:45: Host not found: download.repetier-server.com
    2019-07-05 13:03:45: Host not found: licence.internetloesungen.com
    2019-07-05 14:09:22: Host not found: download.repetier-server.com
    2019-07-05 14:09:22: Host not found: licence.internetloesungen.com
    2019-07-05 15:15:00: Host not found: download.repetier-server.com
    2019-07-05 15:15:00: Host not found: licence.internetloesungen.com
    2019-07-05 16:20:37: Host not found: download.repetier-server.com
    2019-07-05 16:20:37: Host not found: licence.internetloesungen.com
    2019-07-05 17:26:14: Host not found: download.repetier-server.com
    2019-07-05 17:26:14: Host not found: licence.internetloesungen.com
    2019-07-05 17:28:52: Websocket opened
    2019-07-05 17:32:47: Websocket opened
    2019-07-05 17:50:32: Job created: C:\ProgramData\Repetier-Server\printer\Perseus\models/00000008_V6 PART 002730785 0 Z 134.7.u
    2019-07-05 17:50:32: finish job C:\ProgramData\Repetier-Server\printer\Perseus\models/00000008_V6 PART 002730785 0 Z 134.7.u
    2019-07-05 17:50:32: Uploaded size:4718220
    Den Druckstopp erkenne ich daran, dass ich den selben G-Code mit Z-Koordinaten versehen neu starte, um das Druckteil noch zu retten.
    Im Log erkenne ich folgendes: Immer, bevor es zum Druckstopp kommt, kommt die Meldung "Websocket opened".
    Was bedeuted diese Meldung?
    Bei allen Drucks, die erfolgreich abgeschlossen wurden, sehe ich die Meldung nicht.

    Was mir noch einfällt: Ich bin mir nicht sicher aber ich glaube, dass sich der Server beim Druckstopp kaum noch bedienen ließ, er reagierte kaum noch auf Eingaben. Nachdem ich den Browser (Firefox) geschlossen und wieder geöffnet habe, ließ sich die Server-Oberfläche wieder flüssig bedienen.
    Steht "Websocked opened" dafür, dass der Browser neu gestartet wurde?

    Die vielen "Host not Found" kommen vermutlich daher, dass der PC nicht mit dem Internet verbunden ist.
  • Host not found ist wegen fehlender internetverbindung. Er testet auf updates und Lizenz Gültigkeit. Sollte keinen Einfluß haben.

    "Websocket opened" ist die Meldung das sich jemand zur Kommunikation verbunden hat, was normal deine web gui ist. Passiert bei jedem reload oder wenn Verbindung unterbrochen wurde.
    So gesehen ist das server.log normal - keine restarts oder spezielle Fehlermeldungen. Nur ausgaben die zu erwarten sind.

    Wenn der Browser nicht bedienbar ist kannst du gerne mal die javascript console öffnen (rechte Taste über der Seite ->element untersuchen wählen dann Console wählen). Vielleicht gibt es ja dort Fehlermeldungen die erklären warum er amok läuft. Oder er bekommt so viele Daten das er eine hohe last hat. Schwer so zu beurteilen.

    > 13:56:41.374: start
    > 13:56:41.374: Info:PowerUp

    Ist eigentlich das, was mir die meisten Sorgen bereitet. Wo kommt das her. Hab mal M112 probiert dann kommt
    9:53:42.063: start
    9:53:42.063: Info:Software Reset
    Mit M281 (trigger watchdog) bekomme ich
    9:55:24.275: start
    9:55:24.275: Info:Watchdog Reset

    Also wie erwartet. Schalte ich Strom aus und wieder an bekomme ich genau das:
    9:56:33.496: start
    9:56:33.496: Info:PowerUp
    Das gleiche bekomme ich wenn ich den Drucker im server deaktiviere und aktiviere. Genau so wenn ich emergency reset in der gui aufrufe weil er dabei auch neu verbindet und dabei einen reset auslöst.

    > 13:56:10.032: ok 17248
    < 13:56:10.032: N5653346 G1 X58.142 Y325.824 E0.2392
    > 13:56:41.374: start
    > 13:56:41.374: Info:PowerUp
    > 13:56:41.374: Detected EEPROM version:20
    > 13:56:41.374: XY jerk was too low, setting to 14.08
    > 13:56:41.374: Z jerk was too low, setting to 0.34
    > 13:56:41.374: Free RAM:81212
    > 13:56:41.374: SelectExtruder:0
    > 13:56:41.374: FlowMultiply:100
    > 13:56:41.374: Warning: Seems like we missed a ok - continue sending.
    > 13:56:41.374: wait
    ist damit der interessante Abschnitt. Server sendet einen move, 31 Sekunden nichts dann startet Drucker neu und innerhalb einer Millisekunde werden neustart angezeigt, warnings nachgeholt und Systemabfrage gestartet.#
    Ich gehe davon aus das der Strom nicht ausgeschaltet wurde. Interessant ist das Server log zu dem Zeitpunkt was ich leider nicht habe. Von meinen tests steht so wa sim log:
    2019-07-10 09:53:25: Connection started: Felix
    2019-07-10 09:53:25: Reset printer Felix
    2019-07-10 09:56:27: error: Reading serial conection failed: Device not configured. Closing connection.
    2019-07-10 09:56:27: Port closed for Felix
    2019-07-10 09:56:27: Connection closed: Felix
    2019-07-10 09:56:33: Connection started: Felix
    2019-07-10 09:56:33: Reset printer Felix
    2019-07-10 09:57:35: Port closed for Felix
    2019-07-10 09:57:35: Connection closed: Felix
    2019-07-10 09:57:39: Connection started: Felix
    2019-07-10 09:57:39: Reset printer Felix
    2019-07-10 09:58:38: Reset printer Felix

    Wie sieht das in deinem Fall aus. Gibt es passend dazu ein Port closed/connection closed/started? Immer parallel zur "start" Meldung betrachten.
  • Bei den Server-Logs, die ich (am 9.7.) hochgeladen habe, ist der Zeitraum der Abstürze sichtbar.
    Der Absturz muss irgendwann zwischen

    2019-07-02 06:43:25: start printjob V6   PART   002730785 0 on printer Perseus
    und
    2019-07-05 17:26:14: Host not found: licence.internetloesungen.com
    2019-07-05 17:28:52: Websocket opened
    2019-07-05 17:32:47: Websocket opened
    2019-07-05 17:50:32: Job created: C:\ProgramData\Repetier-Server\printer\Perseus\models/00000008_V6 PART 002730785 0 Z 134.7.u
    stattgefunden haben.
    Dazwischen sind keine Meldungen, die ein Reset oder einen Reconnect beschreiben.
    Ich kann bei den Logs auch nur erkennen, dass überhaupt ein Absturz geschehen ist, weil ich weiß, dass ich nach dem Absturz einen gekürzten G-Code hochgeladen habe ("Job created"), welcher an der Stelle ansetzt, an der der Druck gestoppt wurde.
    Sonst wäre der Absturz im Log garnicht sichtbar.
  • Ok, wenn kein connect drin war hat Windows die Verbindung zumindest nie als unterbrochen markiert. Macht es schwer zu sagen warum er dann einen Reset gemacht hat.
  • edited September 2019
    Bis gerade eben dachte ich, ich hätte den Fehler gefunden:

    Vor ein paar Wochen kam ich in meine Wohnung, schaltete das Licht ein und stellte dann fest, dass der Drucker genau in diesem Moment wieder resettet wurde. Das konnte kein Zufall sein. 
    Dann ist mir aufgefallen, dass ich bei meinem kleineren Drucker in der Kaltgerätesteckdose einen Netzfilter habe, welcher beim großen Drucker fehlt.
    Scheinbar habe ich unter bestimmten Umständen in meinem Netz Spannungsspitzen, welche bis zum Controller durchschlagen und einen Reset der Verbindung bewirken.

    Jetzt gibt es natürlich wieder mehrere mögliche Ursachen:
    - Der Filter ist zu schwach
    - der 2. Drucker, der ebenfalls an der Steckdose hängt, erzeugt selber HF-Spitzen, die dann vom Filter nicht mehr gedämpft werden. Sollte aber eigentlich nicht passieren, da der selber einen Netzfilter eingebaut hat
    - Das Problem liegt doch irgendwo anders, zu langes Kabel, EMV im Schaltschrank, etc.

    Jetzt hab ich noch die Idee, vor dem Arduino ein Raspberry Pi zu schalten, mit ganz kurzem USB-Kabel, was dann hoffentlich nicht so störanfällig ist.
    Allerdings bin ich mir jetzt noch nicht so ganz sicher, ob das so funktioniert, wie ich es mir vorstelle:
    Das RPi ist ja quasi Host, läuft daher eigenständig. Soweit ich das verstehe, wird der G-code auf der SD-Karte im RPi abgelegt. 
    Trotzdem würde ich gerne meinen Industrie-PC als Steuerung behalten. Kann ich den RPi per USB oder Ethernet direkt mit dem Industrie-PC verbinden, ohne den Umweg über einen Router, und so über Firefox auf den RPi zugreifen, den G-Code vom Industrie-PC aus auf das RPi übertragen und steuern? Oder muss ich beide mit dem Router über LAN/WLAN verbinden?
  • Das Problem mit Spannungsspitzen beim Licht einschalten hab ich auch schon bei anderen gehört. Insbesondere Leuchtstoffröhren sind da wohl kritisch. Lösung war wohl meist eine USV insbesondere bei schwachem Netz. Solange der Drucker dadurch resetet (ohne anschluss) wird das mit dem pi nichts ändern, der ja auch recht Stromempfindlich ist.

    Nehmen wir aber mal an kurze Kabel helfen weil lange ohnehin gerne Probleme machen. Ob du den Pi am Industrie-PC oder am Router anschließt ist dem egal. Es ändert sich nur wer ihn sehen kann - also alle im Netz oder nur der Industrie-PC. Must am PC halt eine Schnittstelle mit DHCP konfigurieren oder statische IP am pi vergeben so dass die sich halt sehen. Klar ist das dass dann der Pi die gcodes braucht und alles steuert.
  • Ich habe inzwischen ein anderes Netzteil (Markenware von Meanwell) und einen hochwertigen Netzfilter an die netzseitige Zuleitung angeschlossen. Erst war ich guter Dinge, das es jetzt klappt, aber nach etwa 4 Wochen wieder das selbe Problem.

    Jetzt habe ich mir ein Raspberry Pi 4 mit 4gb Ram besorgt und gemäß eurer Dokumentation das V18-Image von Repetier Server installiert. Als Speicher nutze ich eine 32gb-SD-Karte. Das RPi ist direkt über Ethernet mit einem Cat7-Kabel mit dem PC verbunden, den Server rufe ich über den Browser auf (http://repetier-server.local/ ).
    Irgendwie bleibt der Server dann aber nicht stabil. Nach wenigen Minuten kommt die Meldung "Verbindung verloren" und der Server reagiert auf nichts mehr. Das passiert besonders dann schnell, wenn ich einen großen G-Code (>300 mb) übertrage und dieser dann im Hintergrund berechnet wird, aber auch wenn ich mir nur einen G-Code ansehen möchte.
    Ich hatte die Stromversorgung im Verdacht, aber ich glaube nicht, dass es daran liegt. Getestet habe ich mit 2 Stecker-USB-Netzteilen (1,8A und 2,5A) über USB-C und mit einem Labornetzteil, welches ich direkt mit einem recht kurzen Kabel an die Power-Pins der GPIO-Leiste angeschlossen habe. Die Stromaufnahme steigt dabei nie über 1A, das Netzteil liefert bis zu 5 A.
    Sobald ich das Ethernet-Kabel trenne und neu verbinde, reagiert der Server, aber nur für wenige Minuten. Dann verliere ich die Verbindung wieder, selbst im Idle ohne jegliche Last.
    Ist so ein Fehlverhalten bekannt?
    Ob der Server an sich weiter läuft, weiß ich nicht, da ich das RPi noch nicht mit dem Drucker verbunden habe und auch kein Mikro-HDMI-Adapter habe.

    Ich verwende das V18-Image ohne jedwede Konfiguration, ich starte es so, wie es nach dem Flashen ist.
    Muss im Server oder in Windows noch irgendetwas konfigurieren, was ich vielleicht übersehen habe?
    Kann es sein, dass der Ethernet-Controller des RPi abschmiert oder überhitzt oder kann es an der Windows - Firewall liegen?
Sign In or Register to comment.