Kommunikationsfehler

Was ist darunter zu verstehen?

In dieser Anleitung gehen wir davon aus, dass du den Drucker bereits erfolgreich angeschlossen hast, aber Probleme wie unerwartete Pausen oder Druckabbrüche hast oder einfach nur einige Fehlermeldungen gesehen hast, die du verstehen möchtest.

Zunächst werden wir erklären, wie Kommunikation im Allgemeinen und einige Kommunikationseinstellungen funktionieren. Nur wenn du verstehst, wie sie funktioniert, wirst du verstehen, was schief läuft.

Nach der allgemeinen Erklärung erfährst du alles über die möglichen Fehlerquellen, die Gründe dafür und einige Verbesserungsvorschläge.

Kommunikationsprotokoll

Du hast zwei voneinander getrennte Geräte – einen 3D-Drucker und einen Repetier-Server, der auf einem Computer läuft. Diese sind über ein USB-Kabel, ein serielles Kabel, ein Netzwerk oder eine Drittanbieter-Zwischensoftware (Klipper Pi App, Duet Control Server) mit einem Repetier-Server verbunden. Dazwischen befindet sich noch das Betriebssystem oder eventuell ein USB zu Seriell Treiberchip. Nur wenn die Daten genau wie gewünscht zwischen Drucker-CPU über alle Beteiligten zum Server fließen können, erhältst du das gewünschte Druckergebnis.

Die grundlegende Kommunikation wird von der Server-Seite gesteuert. Ein Befehl wird gesendet, und wenn der Drucker ihn empfangen hat und bereit ist, den nächsten Befehl zu empfangen, sendet er eine Zeile zurück, die mit „ok“ beginnt oder nur „ok“. Wenn der Server diese „ok“-Meldung erhält, weiß er, dass er den nächsten Befehl senden kann und so weiter. Von Zeit zu Zeit sendet der Drucker auch zusätzliche Daten wie Temperaturen, Statusänderungen und mehr.

Der Drucker weiß, dass die Befehle beschädigt werden könnten. Wir stellen also jedem Befehl, den du mit dem N-Parameter sendest, eine Zeilennummer voran und beenden eine Zeile mit *Prüfsumme. Wenn der Drucker dies sieht, berechnet er auch die Prüfsumme, und wenn sie abweicht, beschwert er sich und fordert eine erneute Übermittlung des richtigen Befehls an.

Wir nennen diese Kommunikationslösung Ping-Pong-Modus, einfach weil sie immer in eine Richtung geht und dann auf eine Antwort wartet und so weiter.

Wenn du mit unserer Konfiguration vertraut bist, hast du gesehen, dass es die Möglichkeit gibt, Ping-Pong zu deaktivieren. Warum solltest du das in Betracht ziehen und was bewirkt es? Damit werden zwei Probleme gelöst. Das erste ist die Erhöhung der Kommunikationsgeschwindigkeit. Aufgrund der vielen beteiligten Teile, die eine Nachricht durchlaufen muss, gibt es nicht nur die physikalisch mögliche Geschwindigkeit, sondern auch eine Latenzzeit vom Beginn des Sendens einer Nachricht bis zum Empfang des ersten Bytes. Nehmen wir also eine Latenzzeit von 2 ms und ansonsten unbegrenzte Geschwindigkeit an. Ein Befehl braucht 2 ms, um gesendet zu werden, und dann warten wir 2 ms auf das OK, um zu sehen, ob wir weitere Daten senden können. Das macht 4 ms pro Befehl oder 1000 ms/4 ms = 250 Zeilen pro Sekunde. 250 Zeilen pro Sekunde sind eine gute Geschwindigkeit und die meisten Drucke können auch mit 100 Zeilen pro Sekunde gut gedruckt werden. In manchen Fällen reicht dies jedoch nicht aus und der Drucker stottert oder bewegt sich ungleichmäßig. Dies ist der Fall, wenn du sehr kleine Bewegungen hast. Wie klein die Bewegungen sind, hängt von der Druckgeschwindigkeit ab. Nehmen wir an, du druckst mit 100 mm/s. Das bedeutet, dass bei 250 Zeilen/s deine durchschnittliche Bewegungslänge unter 100 mm/250 = 0,4 mm liegen sollte. Bei sehr kurvigen Modellen und sehr kleinen Dreiecken im STL-Modell kann die Länge höher sein. Das zweite Problem, das damit gelöst wird, ist das fehlende „ok“ des Druckers. Es gibt keine Prüfsummenlösung für den Rückkanal, wenn also „ok“ zu „k“ wird, wissen wir nicht, ob wir den nächsten Befehl senden können. Aber solange wir mehr parallele Befehle senden können, kann der nächste Befehl immer noch gesendet werden und verursacht keine Zeitüberschreitung. Idealerweise fügt die Drucker-Firmware die Zeilennummer zur „ok“-Meldung hinzu, damit wir sehen, dass wir ein „ok“ verpasst haben und es sofort korrigieren können. Ohne Zeilennummer wird die Anzahl der Timeouts nur halbiert.

Wenn du also Ping-Pong deaktivierst, senden wir mehrere Befehle und zählen die gesendeten Bytes, ohne ein „ok“ erhalten zu haben. Dies hat 2 Grenzen. Die erste Grenze ist die Größe des Eingangspuffers. Dieser Puffer befindet sich auf der Druckerseite und speichert empfangene Daten zur späteren Verarbeitung. Solange wir nicht mehr senden, als in den Puffer passen würde, sind wir sicher. Ein typischer Eingangspuffers ist 127 Byte groß, und wenn wir 2 Befehle darin haben können, ist die mögliche Kommunikationsgeschwindigkeit mehr oder weniger doppelt so hoch. Und die Firmware kann vielleicht 2 OK-Nachrichten in einem einzigen Datenpaket senden. Die zweite Grenze ist, dass man die Anzahl der parallelen Befehle begrenzen kann. Dies ist normalerweise deaktiviert und macht nur Sinn, wenn der Eingangspuffers sehr groß ist. Wenn man zu viele Befehle parallel schaltet, werden Pausen oder Druckstopps zu sehr verzögert, einfach weil man bereits gesendete Befehle nicht mehr abbrechen kann.

Fehlersuche

Um Kommunikationsprobleme zu lösen, musst du die Kommunikation beobachten. Der erste Schritt besteht also darin, die Protokollierung zu aktivieren. Nur im Protokoll kannst du die gesamte Kommunikation sehen und das später beschriebene Muster erkennen.

Es kann auch hilfreich sein, die Konsole während des Druckvorgangs zu öffnen. Abhängig von den Filtern können sogar dieselben Meldungen wie im Log angezeigt werden, aber man sieht nur die letzten 1000 Zeilen, so dass, wenn der Druck weiterläuft und alle Meldungen aktiviert sind, du möglicherweise schon außerhalb der sichtbaren Zeilen liegst, wenn man sie entdeckt. Normalerweise hast du es also mit aktivierten Filtern geöffnet. Die wichtigen Meldungen sind dann sichtbar und du kannst die Zeiten notieren, zu denen sie aufgetreten sind, und später im Protokoll nachsehen.

Typische Fehler

Prüfsumme stimmt nicht überein

Wie oben erläutert, werden normalerweise Zeilennummern und Prüfsummen mit jedem Befehl gesendet. Wenn du eine solche Fehlermeldung siehst, bedeutet dies, dass der Drucker einen Fehler entdeckt hat und den Server auffordert, die Zeile erneut zu senden. In der Konsole oder im Protokoll siehst du die Meldungen zum erneuten Senden.

Solange es nur ab und zu passiert, ist das kein Grund zur Sorge. Es kommt vor. Nicht unbedingt, weil die Daten nicht korrekt übertragen wurden, sondern vielleicht auch, weil der Drucker sie nicht verarbeitet hat, bis das nächste Byte empfangen wurde. Das passiert, wenn die Interrupts in der Drucker-Firmware zu lange blockiert wurden.

Wenn du diesen Fehler ständig siehst, gibt es zwei typische Gründe. Einer ist, dass du den Eingangspuffer zu hoch eingestellt hast. Versuche zunächst, den Ping-Pong-Modus zu aktivieren, und wenn der Fehler verschwindet, war das der Grund. Bleibe im Ping-Pong-Modus oder deaktiviere ihn und reduziere den Eingangspuffer, bis der Fehler verschwindet. Gehe nicht unter 63 Byte. Niedrigere Werte machen keinen Sinn und du solltest dann den Ping-Pong-Modus verwenden.

Bleibt das Problem auch im Ping-Pong-Modus bestehen, ist die Fehlerrate sehr hoch. Gründe dafür sind eine leicht falsche Baudrate, z.B. 230400 statt 250000 oder elektrisches Rauschen auf den Kabeln.

Timeout-Meldungen

Ein Timeout bedeutet, dass wir einen Befehl an den Drucker gesendet haben und in der erwarteten Zeit keine OK-Meldung dafür erhalten haben. Einige Befehle sind bekanntermaßen langsam, wie das Warten auf das Erreichen der Temperatur oder Homing. Für diese Befehle verlängert der Server die Timeout-Zeit automatisch. Für alle anderen Befehle gilt die Zeitüberschreitung, die du in den Verbingungseinstellungen bei Kommunikationstimeout festgelegt hast.

Befehle, die schwer zu messen sind, sind Bewegungsbefehle. Diese werden gepuffert, aber wenn der Bewegungspuffer (nicht zu verwechseln mit dem Eingangspuffer) voll ist und eine neue Bewegung hinzugefügt wird, muss gewartet werden, bis die aktuelle Bewegung beendet ist, um ihn dem Bewegungspuffer hinzuzufügen. Der Timeout muss also länger sein als die langsamste Bewegungszeit, die die erwartest. 30 s sind für die meisten ein guter Wert.

Lange Timeouts haben den Nachteil, dass sie zu Blobs führen, bei denen der Extruder stillsteht, daher sind kürzere besser. Zu diesem Zweck gibt es in verschiedenen Drucker-Firmwares das zusätzliche Busy-Protokoll. Wenn wir keine Rückmeldung vom Drucker erhalten, kann der Server nicht wissen, ob er einen Befehl verpasst hat oder die Ausführung nur langsamer ist als erwartet. Mit diesem Busy-Protokoll sendet der Drucker also „Busy“, um anzuzeigen, dass die Ausführung etwas länger dauern wird. Normalerweise beträgt das Intervall 2 Sekunden, so dass du in diesem Fall den Timeout auf 3 Sekunden setzen kannst.

Zeitüberschreitung aufgrund eines verpassten Ok

Dies ist der Hauptgrund, warum die Timeout-Behandlung als letzte Verteidigung gegen einen fehlerhaften Druck existiert. Aufgrund eines Kommunikationsfehlers hat der Server ein Ok verpasst und kann keine neuen Befehle senden.

Die einzige Verbesserung ist die Verringerung der elektronischen Probleme, siehe nächstes Kapitel.

Timeout durch langsame Bewegungen oder langsamen Befehlen

Man könnte dies als falsches Positiv bezeichnen. Wenn dies geschieht, geht der Server davon aus, dass ein fehlendes Ok vorliegt, was aber nicht der Fall ist. Er sendet die nächsten Befehle, was wahrscheinlich zu einem Überlauf des Eingabepuffers und anschließend zu einem Prüfsummenfehler führt.

Die Lösung ist, die Zeitüberschreitung so zu erhöhen, dass sie die Zeit dieses Befehls abdeckt. Oder ignoriere es, wenn du weißt, dass es sich nur um eine spezielle langsame Bewegung handelt und du die Zeitüberschreitung nicht nur für diese eine Ausnahme reduzieren willst.

Timeout bei fehlendem Buys-Signal

Wenn die Firmware Busy unterstützt, sollte sie immer Busy senden, auch wenn es länger dauert, aber einige sind nicht korrekt implementiert. Wir haben Versionen gesehen, bei denen dies z.B. für Bewegungen in einigen Versionen nicht funktionierte, bis der Fehler behoben wurde.

Prüfe zunächst, ob Busy aktiviert ist. Gehe zur Konsolenansicht, aktiviere Bestätigungen und sende

G4 S20

was 20 Sekunden dauert, so dass du jetzt in der Konsole Meldungen zur Auslastung sehen solltest. Zur Analyse der Druckausgabe aktiviere die Protokollierung und schaue, wann der letzte Befehl gesendet wurde und wann das Timeout auftrat. Wenn es keine Besetztmeldungen gibt, aber der Druck später fortgesetzt wird, ist die Busy-Implementierung fehlerhaft und du musst Timeout so einstellen, als ob du keine Busy-Unterstützung hättest.

Zeitüberschreitung, wenn keine Daten empfangen werden

Das ist das wirklich das, das du nicht willst. Die Firmware läuft, der Repetier-Server läuft und die Verbindung ist als offen markiert, aber der Server bekommt keine Antworten mehr vom Betriebssystem. Es ist unmöglich zu sagen, wo genau der Fehler auftritt – Betriebssystemtreiber oder Drucker-USB-Treiber. Du denkst, die Verbindung sei offen, aber aus irgendeinem Grund kommen keine Daten durch.

Wenn es sich um den Betriebssystemtreiber handelt und du Linux verwendest, haben wir die Möglichkeit, den USB-Strom abzuschalten, um den Treiber zurückzusetzen. Das ist, was die Option „USB neu verbinden bei Timeout“ steuert. Nie setzt USB niemals zurück. Früh macht es beim ersten Timeout, Konservativ beim zweiten Timeout in Folge. Wir versuchen, den Drucker in diesem Fall nicht mit dem DTR-Toggle zurückzusetzen, aber das funktioniert nicht bei allen Treibern. Hängt vom DTR-Status ab und davon, ob der Treiber von sich aus umschaltet.

Lies auch das Kapitel über elektronische Probleme.

Unerwartete Verbindungsabbrüche

Einige Benutzer gehen davon aus, dass wir den Drucker trennen. Lasse mich zunächst sagen, dass wir dies nicht tun, es sei denn, du hast „USB neu verbinden bei Timeout“ aktiviert. In diesem Fall siehst du in der Konsole und im Protokoll auch „Reconnecting USB port to fix serial driver problems …“. Wenn du einen Drucker in Repetier-Server deaktivierst, wird natürlich auch die Verbindung geschlossen. Der eigentliche Grund ist in den meisten Fällen, dass das Betriebssystem die Verbindung geschlossen und dies signalisiert hat. In neueren Serverversionen siehst du in der Konsole und im Log eine Meldung wie „Connection closed by OS“.

Warum also sollte das Betriebssystem eine Seriennummer löschen?

  • Kabel abgeklemmt oder lose.
  • USB-Chip zum Schutz abgeschaltet (EMF).
  • Betriebssystem unterversorgt USB, weil die Kernspannung zu viel und zu lange gesunken ist. Dies ist ein häufiges Problem bei Raspberry Pi-Systemen, daher haben wir das Blitz-Menü hinzugefügt, das anzeigt, ob du Unterspannung hattest oder gerade hast. Dies geschieht nicht auf allen Ebenen der Unterspannung, aber wenn du dies siehst, könnte es der Grund sein.
  • Durch Treiberprobleme im Betriebssystem wurde die Verbindung unterbrochen.
  • Bei Netzwerkverbindungen kann ein Netzwerkproblem die Ursache sein, außerdem dauert es eine Weile, bis eine Netzwerkverbindung abbricht. Aber vor allem, wenn eine der beteiligten Parteien WLAN nutzt, ist dies ein häufiger Grund, vor allem bei schlechten WLAN-Verbindungen.

Elektronische Probleme

Die Fehler, die du nicht beheben kannst, sind verpasste Bytes, wenn der Empfänger zu beschäftigt war, um die Daten rechtzeitig zu lesen.

Das häufigste Problem ist die Beschädigung der Daten oder sogar die Unterbrechung der Verbindung durch elektrische Probleme. Es gibt viele Ursachen für dieses Problem wie:

  • Ungeschirmte parallele Kabel. Wenn ein Kabel ein- oder ausgeschaltet wird, erzeugt es eine Magnetfeldänderung, die Strom auf parallele Kabel in der Nähe induziert, was dazu führen kann, dass der Auslösewert den Bitwert ändert. Besonders Heizungs- und Motorkabel mit ihren hohen Strömen können solche Signale leicht auslösen. In Druckern führt dies z.B. dazu, dass manchmal Endanschläge ohne Kontakt ausgelöst werden.
  • Die Spannung ändert sich geringfügig, wenn Heizungen/Motoren ein- oder ausgeschaltet werden, so dass das Netzteil mit größeren Stromänderungen Schritt halten muss.
  • Auch die CPU und parallele Kabel auf der Druckerplatine können Quellen sein.
  • Fehlende Abschlüsse der Kommunikationsleitungen.
  • … wir sind Softwareentwickler, also ist das nicht unser bestes Fachgebiet.

Was passieren kann:

  • Falsche Daten für den Empfänger.
  • Der Treiber bleibt hängen, weil ein spezielles Muster, das nicht vorkommen sollte, nicht erkannt wird.
  • Der USB-Chip trennt die Verbindung zum Gerät. Unter Linux siehst du eine Meldung über EMF als möglichen Grund. In neueren Serverversionen zeigen wir dies auch in der Konsole an, wenn die Verbindung unterbrochen wird.