The label prints fine, but the status query your app sends
afterwards takes seconds, sometimes minutes, and now and then never returns.
Before blaming the printer, it helps to know what the query actually is and
when the printer is designed not to answer it.
What ~HS returns
~HS (Host Status Return) is an immediate command: the printer
answers with three short strings, each starting with STX and ending with
ETX CR LF, carrying paper-out and pause flags, the label length, the number
of formats waiting, the print mode and a few more fields. There is no field
that says "the last job is finished" — the closest signals are the labels
remaining in the batch and the label-waiting flag, and reading "completed"
out of them is an inference, not a status.
Silence is a state, not a timeout
The programming guide is explicit: in five conditions the printer does not
answer ~HS at all — media out, ribbon out, head open,
rewinder full, head over-temperature. An application that waits for
its full socket timeout in these cases sees "the printer is slow"; what it is
looking at is a fault the printer cannot report through this channel. Treat
no answer as unknown, probably a fault, not as "offline" and not as
"still printing".
A query stuck behind an open connection
The other common cause is on the host. If the print step opens a
connection to port 9100 and does not close it, and the status step opens a
second connection for ~HS, the second one may simply
wait until the first is released. The symptom is exactly "an age": the reply
arrives when the earlier connection times out or is closed. Check that the
job connection is closed before the query, or send the query on the same
connection right after the format. A raw client makes this easy to test —
open one connection, send the label, send ~HS, read the three
strings.
Through the driver it is not a printer query
Asking a Windows queue for status returns the spooler's view of the job,
not the printer's. If the app needs the printer's answer, it has to talk to
the printer directly — the network
printing guide shows the raw path, and the
printer identity
guide explains why port 9100 has no handshake to lean on.
What to change in the application
Use a short timeout and map silence to a fault state; do not poll after
every label if one query per batch answers the question; and do not build
"job completed" on top of ~HS — the guide does not define it,
so whatever you derive will be right on one model and wrong on the next.
