Verminderte Geschwindigkeit nach Einbau eines neuen PCs

Legion23

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

Repetier

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.

Legion23

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.

Repetier

> 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.

Legion23

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.

Repetier

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.

Legion23

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 regionram'

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 regionram'

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 regionram'

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.

Repetier

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.

Legion23

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?

Repetier

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.

Legion23

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.

Repetier

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.

Legion23

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 :(

Repetier

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.

Legion23

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?

Repetier

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.

Legion23

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 (₄₂₅ 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?

Repetier

Oops, du solltest im link die version durch 0.92.0 ersetzen. Hab wohl vergessen den link anzupassen.

Legion23

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?

Repetier

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.