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
Comments
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.
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.
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.
Schon den Test mit M111 S24 gemacht viele Zeile pro sekunde der Rechner schafft und ob man die Latenz in Geratemanager anpassen kann.
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.
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.
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.
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.
"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.
Ist eigentlich das, was mir die meisten Sorgen bereitet. Wo kommt das her. Hab mal M112 probiert dann kommt
Mit M281 (trigger watchdog) bekomme ich
Also wie erwartet. Schalte ich Strom aus und wieder an bekomme ich genau das:
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.
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:
Wie sieht das in deinem Fall aus. Gibt es passend dazu ein Port closed/connection closed/started? Immer parallel zur "start" Meldung betrachten.
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.