Case studiesIndonesian food manufacturer

Production orders to coding printers, by line

A production order should set the right message, batch and dates on every coding printer of a line, and refuse a format a printer does not know. The flow below targets production lines, not individual printers, so adding a printer needs no flow edit. It covers 43 printers across five models.

The problem

The plant prints batch, production date, expiry date and weight on sachets, cartons and boxes. Each production order decides what a line prints, and the line has several printers, often of different makes. Setting each printer by hand for every order means many manual steps and room for error.

The production planning system should post the order once, and every printer of that line should print the right layout with the right fields.

Printers in scope
PrinterTypeUnitsLink
Markem-Imaje 9040Continuous inkjet18TCP, default port 2101 on newer boards, or RS-232
Videojet 3340CO2 laser4TCP, text communications port of the CLARiTY controller
Hitachi RX2-BContinuous inkjet, cartoning1RS-232, 4800 baud
ANSER A1Thermal inkjet, boxes8RS-232, the printer’s Scan and Print input
Mango CO2 laser, Sunine V5 controllerCO2 laser12Not driven yet: the remote protocol is not public

The flow

Nodes in the order flow, in order

  1. order ingest
  2. order to print fields
  3. by line
  4. printer: line 1
  5. printer: line 2
  6. printer: line n

Nodes in the box weight flow, in order

  1. scale ingest
  2. weight to field
  3. printer: box line
  1. The production planning system posts an order to the ingest API, one call per building: line, format id, batch, production date, expiry date and an optional counter reset.
  2. A script turns the order into a record whose metadata holds the line, the message and the fields. The message is FMT-<format id>. The fields are BATCH, PD, ED and two text lines. Dates are written in one of three styles, depending on the format: day month year, day and English month name, or a two-digit year.
  3. A branch routes by line. An order for a line the flow has no branch for is refused, and the caller gets a 422 that names the line.
  4. One printer node per line sends the job to every enabled printer whose configuration says it is on that line.
  5. The caller waits for the result and gets one answer per printer.

The box printers take a second input. The checkweigher posts each weight to the ingest API for its line, a script validates it and turns it into a WEIGHT field such as 2.18kg, and the printer prints it on the next box together with its own clock and box counter. The order flow resets that counter at each new batch.

Lines, not printer ids

Nothing in the flow names a printer. Each printer entry carries a line, and the printer node finds every printer on that line when the job runs. A new printer joins a line by getting the line in its configuration, and the flow does not change. A new line needs one branch port and one printer node, copied from an existing pair.

printers.yaml, one entry per physical printer
- id: mi9040-s6l-01
  line: S6L-01
  protocol: markem_imaje
  transport: { kind: tcp, host: 192.168.10.11, port: 2101 }
  messages: { FMT-3: "1", FMT-4: "2", FMT-5: "3" }
  fields: { LINE1: "1", LINE2: "2" }

The flow speaks logical names: FMT-3 for a message, BATCH or LINE1 for a field. Each printer maps the names it uses to its own message and field numbers. The map is a whitelist. A printer takes only the fields it maps and refuses a format it has no message for, so it never prints with the wrong layout. IT can add, move or swap a printer through the API, and the change survives a restart.

A printer that needs its own override gets a single-printer node of its own. The shipped flow includes one disabled example.

Answers and the job log

What the production system gets back
HTTPMeaning
200Every step and every printer succeeded.
422Refused: bad order data, an unknown line or format, or a printer that rejected the job. Resending the same body fails again.
503A printer was unreachable or silent. Resend later.
202Still running when the wait ended. The job log shows the outcome.

Every job lands in a job log that keeps 90 days: printer, source, logical message, fields and counter, outcome, steps and duration. Before anything is connected, a dry run shows for each printer the message, fields and counter it would send without printing.

Line assurance builds on the same log: batch and lot recall, verification of the printed code by scanner read-back or printer confirmation, a live line board and a shift report. The configuration prepared for this plant does not turn verification on.

What is open

  • The flow and the printer configuration are prepared. Printer addresses are placeholders that are set per printer at commissioning, and no results from a running line are reported here.
  • The 12 laser printers on the Sunine V5 controller are not driven yet. The supplier provides the external data communication interface definition on request. Once it arrives, a text-line entry or a new driver covers them.
  • ANSER’s network protocol is not public. The A1 is driven over its serial Scan and Print input, and its counter is reset by the printer’s own input until the vendor confirms a remote reset.
  • On the Videojet printers the text communications port is off by default and must be enabled on the controller. The Hitachi serial link is an option board that must be fitted.
  • Two format ids in the plant’s format sheet are not defined yet and are not in the flow.

Related

From download to first record in minutes.

Run one binary, connect a PLC, a CNC or a webhook, and watch the records arrive in the editor.

Builds for Linux (x86_64 and ARM64), Windows and macOS.

  • One binary
  • Raspberry Pi to rack server
  • Signed delivery with retries

Sizing questions or an air-gapped install? Email marketing@opexcg.com or read the quick start.