Overview LabelServer4j: Difference between revisions

Latest revision as of 12:26, 1 April 2026

LabelServer4j is a background label printing service that acts as a bridge between Commander4j and physical label printer devices on a production line. It monitors for incoming label requests, processes them through configurable scripts, and communicates with printers over TCP/IP.

Purpose

When an operator assigns a Process Order to a production line in Commander4j, the system exports a CSV data file containing all the fields needed to print the label — product code, description, batch number, SSCC, expiry date, and so on. LabelServer4j detects this file, reads the data, executes a printer command script, and sends the appropriate commands to the labeller over the network.

This separation means label printing is handled by a dedicated background service rather than by the Commander4j desktop application itself, allowing printers to be driven remotely without any operator interaction beyond assigning the order.

Difference from AutoLab4j

LabelServer4j and AutoLab4j serve related but distinct purposes:

Feature	LabelServer4j	AutoLab4j
Typical use	Case labellers, secondary labellers	Pallet labellers
SSCC generation	No — SSCC is supplied in the CSV	Yes — generates unique SSCCs via Modbus signals from the line
User interface	None — background service only	Graphical window with printer status displays
Label trigger	CSV file from Commander4j	Modbus signal from production line equipment

How It Works

Commander4j writes a CSV file to the configured output directory when an order is assigned to a line.
LabelServer4j polls that directory every 250 ms.
When a CSV file is detected, it is locked (renamed to .in), parsed, and its fields loaded as variables.
A command script (a plain text file) is executed line by line. The script sends ZPL or proprietary printer commands to the labeller, substituting data fields from the CSV.
The printer responds; LabelServer4j validates the response.
On success, the CSV file is deleted. On failure, it is moved to an error directory.

Supported Printer Types

LabelServer4j communicates with printers over raw TCP/IP sockets and supports two label command formats:

ZPL (Zebra Programming Language) — for Zebra and Videojet printers. Full ZPL commands with GS1 Code 128 barcode support via the built-in CODE128SWITCHER() function.
Logopak format — a proprietary command structure using lock/load/field data/end sequences, with binary file transfer using Intel Hex encoding for uploading label templates to the printer.

Any printer that accepts raw TCP/IP text commands on a configurable port can be driven by LabelServer4j, provided an appropriate command script is written.

Multi-Site and Multi-Printer

LabelServer4j supports multiple sites (each with its own labellers.xml) and runs each configured printer in an independent background thread. Multiple printers operate simultaneously without interfering with one another.

Database Integration

LabelServer4j can connect directly to the Commander4j database to perform SQL queries during script execution. This allows label content to be dynamically enriched with data that is not included in the CSV file — for example, querying the current status of an order or looking up a reference value.

@@ Line 1: / Line 1: @@
-LabelServer is a module of [[Commander4j]] which is designed to send data provided by Commander4j to external Labellers via a script which is just plain text. The script can contain specific printer commands and or data in whatever combination is needed. Therefore the application can accomodate a variety of printer types.
+LabelServer4j is a background label printing service that acts as a bridge between Commander4j and physical label printer devices on a production line. It monitors for incoming label requests, processes them through configurable scripts, and communicates with printers over TCP/IP.
-It shares a lot with the [[AutoLab4j]] module but has some important differences as well.
+== Purpose ==
-Rather than replicate wiki pages across the multiple Commander4j modules - some of the links will take to the relevant wiki page of the referenced program.
+When an operator assigns a [[Process Orders|Process Order]] to a production line in Commander4j, the system exports a CSV data file containing all the fields needed to print the label — product code, description, batch number, SSCC, expiry date, and so on. LabelServer4j detects this file, reads the data, executes a printer command script, and sends the appropriate commands to the labeller over the network.
-AutoLab4j is designed to send data when requested via a Modbus signal and is intended to generate a unique SSCC on each request. This makes the [[AutoLab4j]] program more suitable for [[Pallet Label]].
+This separation means label printing is handled by a dedicated background service rather than by the Commander4j desktop application itself, allowing printers to be driven remotely without any operator interaction beyond assigning the order.
-The LabelServer application will send data to a labeller when an operator has assigned an order to a production line within the Commander4j application. This is more suitable for [[Case Label]] where the data remains the same (no SSCC).
+== Difference from AutoLab4j ==
-You should refer to the documentation on [[Production Lines & Labellers]]
+LabelServer4j and AutoLab4j serve related but distinct purposes:
+{| class="wikitable"
+|-
+! Feature !! LabelServer4j !! AutoLab4j
+|-
+| Typical use || Case labellers, secondary labellers || Pallet labellers
+|-
+| SSCC generation || No — SSCC is supplied in the CSV || Yes — generates unique SSCCs via Modbus signals from the line
+|-
+| User interface || None — background service only || Graphical window with printer status displays
+|-
+| Label trigger || CSV file from Commander4j || Modbus signal from production line equipment
+|}
+== How It Works ==
+# Commander4j writes a CSV file to the configured output directory when an order is assigned to a line.
+# LabelServer4j polls that directory every 250 ms.
+# When a CSV file is detected, it is locked (renamed to <code>.in</code>), parsed, and its fields loaded as variables.
+# A command script (a plain text file) is executed line by line. The script sends ZPL or proprietary printer commands to the labeller, substituting data fields from the CSV.
+# The printer responds; LabelServer4j validates the response.
+# On success, the CSV file is deleted. On failure, it is moved to an error directory.
+== Supported Printer Types ==
+LabelServer4j communicates with printers over raw TCP/IP sockets and supports two label command formats:
+* '''ZPL (Zebra Programming Language)''' — for Zebra and Videojet printers. Full ZPL commands with GS1 Code 128 barcode support via the built-in <code>CODE128SWITCHER()</code> function.
+* '''Logopak format''' — a proprietary command structure using lock/load/field data/end sequences, with binary file transfer using Intel Hex encoding for uploading label templates to the printer.
+Any printer that accepts raw TCP/IP text commands on a configurable port can be driven by LabelServer4j, provided an appropriate command script is written.
+== Multi-Site and Multi-Printer ==
+LabelServer4j supports multiple sites (each with its own <code>labellers.xml</code>) and runs each configured printer in an independent background thread. Multiple printers operate simultaneously without interfering with one another.
+== Database Integration ==
+LabelServer4j can connect directly to the Commander4j database to perform SQL queries during script execution. This allows label content to be dynamically enriched with data that is not included in the CSV file — for example, querying the current status of an order or looking up a reference value.
+See also: [[LabelServer4j Configuration]], [[LabelServer4j Operation]], [[LabelServer4j Dataset CSV]], [[Production Lines & Labellers]]
+[[Category:LabelServer4j]]