Statusabfragen dauern ewig — oder kommen nie zurück

Veröffentlicht: 2026-09-15

Das Etikett druckt sauber, aber die Statusabfrage, die Ihre Anwendung danach schickt, braucht Sekunden, manchmal Minuten — und ab und zu kommt sie gar nicht zurück. Bevor man dem Drucker die Schuld gibt, lohnt der Blick darauf, was die Abfrage ist und wann der Drucker sie absichtlich nicht beantwortet.

Was `~HS` zurückgibt

~HS (Host Status Return) ist ein Sofortbefehl: Der Drucker antwortet mit drei kurzen Zeichenketten, jede beginnt mit STX und endet mit ETX CR LF — Papierende- und Pause-Flags, Etikettenlänge, Zahl der wartenden Formate, Druckmodus und einige Felder mehr. Ein Feld "der letzte Job ist fertig" gibt es nicht; die nächsten Signale sind die im Stapel verbleibenden Etiketten und das Etikett-wartet-Flag, und daraus "abgeschlossen" zu lesen ist eine Schlussfolgerung, kein Status.

Stille ist ein Zustand, kein Timeout

Das Programmierhandbuch ist eindeutig: In fünf Zuständen antwortet der Drucker auf ~HS überhaupt nicht — Medium leer, Farbband leer, Kopf offen, Aufwickler voll, Kopf überhitzt. Eine Anwendung, die hier den vollen Socket-Timeout abwartet, sieht "der Drucker ist langsam"; tatsächlich sieht sie eine Störung, die der Drucker über diesen Kanal nicht melden kann. Keine Antwort heißt unbekannt, wahrscheinlich Störung — nicht "offline" und nicht "druckt noch".

Eine Abfrage hinter einer offenen Verbindung

Die andere häufige Ursache liegt beim Host. Öffnet der Druckschritt eine Verbindung zu Port 9100 und schließt sie nicht, und öffnet der Statusschritt für ~HS eine zweite, wartet die zweite womöglich, bis die erste freigegeben wird. Das Symptom ist genau das "ewig": Die Antwort kommt, wenn die frühere Verbindung in den Timeout läuft oder geschlossen wird. Prüfen Sie, ob die Job-Verbindung vor der Abfrage geschlossen ist, oder senden Sie die Abfrage direkt nach dem Format über dieselbe Verbindung. Mit einem Raw-Client ist das schnell getestet: eine Verbindung öffnen, Etikett senden, ~HS senden, drei Zeichenketten lesen.

Über den Treiber ist es keine Druckerabfrage

Eine Windows-Warteschlange nach dem Status zu fragen liefert die Sicht des Spoolers auf den Job, nicht die des Druckers. Braucht die Anwendung die Antwort des Druckers, muss sie direkt mit ihm sprechen — der Leitfaden zum Netzwerkdruck zeigt den Raw-Weg, der Leitfaden zur Druckeridentität erklärt, warum Port 9100 keinen Handshake bietet.

Was in der Anwendung zu ändern ist

Kurzer Timeout, Stille als Störungszustand; nicht nach jedem Etikett abfragen, wenn eine Abfrage pro Stapel die Frage beantwortet; und "Job abgeschlossen" nicht auf ~HS aufbauen — das Handbuch definiert es nicht, und die Ableitung stimmt auf einem Modell und auf dem nächsten nicht.