Statusabfragen dauern ewig — oder kommen nie zurück
Veröffentlicht:
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.
