Print barcode labels from an HMI panel over Ethernet

An operator panel already holds everything a label needs — part number, batch, quantity — so it should be the device that prints the label. It can be: an industrial HMI with Ethernet scripting opens a TCP socket to a network label printer and writes the label format as ASCII lines. No PLC print instruction, no Windows driver, no print server in between. Here is the port number, the structure of the format, the panel-side script pattern with types and a test, the label-rate arithmetic, and a read-back check with a fixed code reader. If your panel software can open a socket and write a string, you can have this running in an afternoon.

Can an HMI panel drive a network label printer by itself?

Yes. A panel with Ethernet socket scripting opens a TCP connection to the printer on port 9100, writes the label format as ASCII text, and closes it — the printer needs nothing but a fixed IP address.

The two paths this replaces both put the print logic somewhere else. A PLC can push label data out of its own serial port, as in printing a barcode label from a PLC without a PC and sending ASCII label data from a PLC serial port to a barcode printer. Panel-direct printing keeps the job where the data already lives, and it is an established pattern — printing QR sample labels from a panel in the field is the same technique on another platform.

Direction matters, and it is fixed: the panel is the TCP client, the printer is the listener. That is the same client-or-listener decision you make when you match a network barcode reader to your host, with bytes flowing out instead of in.

What the panel must have: a script language with socket open, write and close; string tags; a button or bit trigger; an alarm object for failures. Nothing else.

Which TCP port does a network label printer listen on?

Use TCP port 9100 — raw printing, the socket interface printers expose for direct jobs; the older alternative is LPR on port 515, which wraps the job in queue syntax you do not need.

Raw printing on 9100 takes the job bytes exactly as your panel writes them, and the printer's formatter interprets the stream directly. LPR on 515 expects a control file and a data file for every job, protocol overhead that buys you nothing when one panel talks to one printer.

Test the port before you write a line of script. From a PC on the printer's subnet, open a telnet session to the printer's address on port 9100; if the connection is accepted, raw printing is on. If it is refused, the service is switched off in the printer's network menu — switch it on and set a static address, or a DHCP reservation outside the pool, so the panel's socket never chases a moving target.

Raw sockets between controls equipment are ordinary work — reading a barcode reader over raw TCP sockets uses the same discipline in the opposite direction.

What does the panel write down the socket?

The whole job: a start-of-format line, one line per printed field, a label count line, and an end-of-format line — every line terminated with carriage return and line feed (0x0D 0x0A) so the printer's parser sees each command.

Industrial label printers are programmed in line-oriented ASCII command languages. The command names belong to the maker, so copy the exact lines from the printer's programming manual; the shape is always this:

FORMAT-START
TEXT 30 20 "BATCH 2214"
BARCODE 30 60 CODE128 80 "{payload}"
COUNT {qty}
FORMAT-END

Those are example commands showing the structure, not real ones — {payload} and {qty} are the two values the panel substitutes at print time. The barcode line deserves attention even as plain text: keep the narrow module at 0.25 mm (10 mil) or wider on thermal print, and keep the quiet zone clear, or the read-back reader in a later section will fight every label. Printing a readable Code 39 barcode from your own program covers the print-quality side in depth.

Assemble the whole format and send it in one write, or in back-to-back writes on the same open connection. The printer starts when its parser sees the end-of-format line; a stream that stops early leaves the formatter with nothing printable.

How do you build the print job in the panel script?

In eight steps: reserve the printer's address, declare one string tag for the job and one for the payload, open a client socket to port 9100, write the format, close it, and alarm on any nonzero status.

1. Set the printer to a static address and confirm port 9100 answers from a PC, as above.
2. Create the tags, with types and initial values:

printer_ip   STRING[15]  = "192.168.1.50"    example address
printer_port INT         = 9100
payload      STRING[20]  = ""                barcode data
qty          INT         = 1                labels per job
job          STRING[512] = ""                assembled format
status       INT         = 0                0 = success

3. Concatenate job from the format template, substituting payload and qty, with CR and LF at the end of every line. These tag names are examples; your panel software names its own socket functions — look for the script calls that open a client connection, write a string, and close.
4. On the Print button, open the socket with a 2 s connect timeout. On failure, set status and stop.
5. Write job with a 3 s write timeout, then close the socket after the end-of-format line. Do not hold the connection open between jobs.
6. Map every nonzero status to an alarm banner that names the printer address, so the operator sees a link fault and not a missing label.
7. Prove it: press Print with the cable in — expect status 0 and one label. Unplug the cable — expect the alarm within 2 s. Replug and press again — expect the label.
8. Prove the count: set qty to 5 and press once — expect five labels from the single format, not five socket sessions.

How many labels per hour can this print path deliver?

About 10,400 labels per hour with a 52 mm label pitch at 150 mm/s print speed; the panel's Ethernet write is never the limit — a 1.1 KB job is about 0.1 ms of wire time at 100 Mbit/s.

Worked example. A 25-line format at an average 45 characters per line is 25 x 45 = 1,125 bytes, about 1.1 KB. Counting 10 bits per byte — the classic serial estimate, generous for Ethernet — gives 1,125 x 10 = 11,250 bits, and 11,250 / 100,000,000 = 0.00011 s, roughly a tenth of a millisecond. Even on an old 10 Mbit/s switch it is about 1 ms.

The print engine owns the pace. Thermal label printers run a typical 100-300 mm/s, and media advances in pitch units — label plus gap. At 150 mm/s with a 52 mm pitch (a 50 mm label and a 2 mm gap): 150 / 52 = 2.9 labels per second, and 2.9 x 3,600 = 10,400 labels per hour. At 300 mm/s the same pitch gives 300 / 52 = 5.8 labels per second, about 20,800 per hour. No single lane demands more than that, and if one ever does, the printer is your bottleneck — the socket has margin to spare.

How do you confirm the printed label reads back?

Add a fixed code reader at the discharge that decodes the label and sends the string to the panel, which compares it against the payload it just printed — a closed loop that catches ribbon out, media skew and a mis-edited format.

Size the reader from the module, not the label. For a 0.25 mm narrow module and 3 pixels across a module, one pixel covers 0.25 / 3 = 0.083 mm. A 72 mm field of view (a 60 mm label plus 6 mm margin a side) then needs 72 / 0.083 = 864 pixels across — comfortably inside a 1.2 MP class sensor, typically 1280 x 960: over the same 72 mm it delivers 72 / 1280 = 0.056 mm per pixel, or 0.25 / 0.056 = 4.5 pixels per module. Run your own label size through the same sum:

Close to the chute, where the label passes within a short band:

The LS-CRD-0047 mounts at the discharge inside its 60-120 mm reading distance, and the LS-HCR-0001 covers exception scans at the station. For faster lanes and wider labels, on the same network the printer sits on:

It decodes up to 60 codes/s from its 2560 x 2048 sensor over Fast Ethernet. That outruns the 2.9-labels-per-second pace computed above with room to spare.

The compare itself is a string equality check in the panel. Bottle label verification with a fixed reader does the same loop over a serial link, and building a pass/fail check station covers the match logic. Close-mount, high-speed and handheld read-back models are in the fixed code readers and handheld code readers finders, and more integration patterns sit on the code reading topic page.

When is the panel the wrong place to print from?

When the panel software has no socket scripting, when several stations must share a queue of printers, or when the label content comes from a database rather than live tags — then print from the PLC or a PC service instead.

Compact panels whose scripting only exchanges tags with a PLC cannot open sockets at all; that is a purchase-time check on the panel's communications specification, not something you code around. If labels must queue across many printers, move upstream of them: putting multiple barcode printers on one PLC with an RS485 multidrop is the proven pattern, and a compact controller can carry the whole job alone, as in a PLC printing labels straight from scanned data. When rendering lives in software — variable layouts, database fields — print from the application side, as in printing barcode labels from a vision application without an HMI add-on, and mind the dialog trap in silent label printing: fix page setup before hiding the dialog.

One printer-side dead end to avoid: a USB-only printer has no port 9100 and never will. Buy the model with Ethernet and raw printing written on its spec sheet.

What should you check before you order anything?

Four things: Ethernet with raw port 9100 on the printer's spec sheet, socket client scripting in the panel, string tags long enough for your whole format, and a switch port on the same subnet — plus a reader for read-back.

• Printer: raw 9100 listed, static address available, programming manual with the format commands, and print speed that covers your pitch using the arithmetic above.
• Panel: socket open, write and close in the script language; string tags sized for the format — 255 characters is a common ceiling on compact panels, so plan to write the job in chunks if your format runs longer; a retained tag for the last job; an alarm object for status.
• Network: reserve the printer's address outside the DHCP pool and keep panel and printer on one subnet.
• Safety: leave the printer's cutter and peel guards in place with their interlocks intact while the line runs.
• Read-back: mount the reader per the pixel math above and wire its decoded string into the panel's compare.

Start with the telnet test — it costs ten minutes and settles the port question for good. From there, the system configurator walks the whole station, and contact us for the format-command details of the printer you are pairing with the panel.