CEN/TS 15525:2006

SLOVENSKI STANDARD
01-maj-2007
3RãWQHVWRULWYH6WDQGDUGQLYPHVQLNL9PHVQLNPHGNUPLOQLNRPLQWLVNDOQLNRP
þUWQHNRGH
Postal Services - Standard Interfaces - Interface between Machine Control and Bar Code
Printers
Postalische Dienstleistungen - Standardschnittstellen - Schnittstelle zwischen
Betriebssystem von Sortiermaschinen und Barcodedruckern
Services postaux - Interface entre machine de supervision et imprimantes de codes a
barres
Ta slovenski standard je istoveten z: CEN/TS 15525:2006
ICS:
03.240
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 15525
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
November 2006
ICS 03.240
English Version
Postal Services - Standard Interfaces - Interface between
Machine Control and Bar Code Printers
Services postaux - Interfaces standard - Interface entre Postalische Dienstleistungen - Standardschnittstellen -
machine de supervision et imprimantes de codes à barres Schnittstelle zwischen Betriebssystem von
Sortiermaschinen und Barcodedruckern
This Technical Specification (CEN/TS) was approved by CEN on 23 October 2006 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15525:2006: E
worldwide for CEN national Members.

Contents Page
Foreword.4
Introduction .5
1 Scope .7
2 Normative references .8
3 Terms and definitions .9
4 Symbols and abbreviations .10
5 Overview of the interface .10
6 Data communications interface .11
7 Signalling interfaces.12
7.1 Physical connections .12
7.2 Print clock signal .13
7.3 PrintGo signal .14
8 Messages and their usage .15
9 Detailed message definitions .18
9.1 The message header .18
9.2 0x00: PrintData.18
9.3 0x01: ClearPrintData.25
9.4 0x10: SoftwareDownload .25
9.5 0x11: InitManufacturer .27
9.6 0x12: InitCustomer.28
9.7 0x13: LoadPattern.29
9.8 0x14 LoadBarCodeFormat.33
9.9 0x16: LoadFont .36
9.10 0x20: PrinterOffLine .38
9.11 0x21: PrinterOnLine.38
9.12 0x22: RequestTechnicalData.39
9.13 0x23: RequestSoftwareVersion.40
9.14 0x24: RequestStatus .40
9.15 0x25: ResetPrinterFaults.41
9.16 0x2F: TestInkJet.41
9.17 0x90: SoftwareUpload .42
9.18 0x91: UploadManufacturer.42
9.19 0x92: UploadCustomer.42
9.20 0x93: UploadPattern .42
9.21 0x94: UploadBarCodeFormat .43
9.22 0x95: UploadFont.43
9.23 0xA2: TechnicalData.44
9.24 0xA3: SoftwareVersion.44
9.25 0xA4: PrinterStatus.46
10 Message flow.52
10.1 Printer states and state changes .52
10.2 Printer initialisation .53
10.3 Printing .55
10.4 Requests and responses .57
10.5 Ink jet testing.58
11 Use of the service socket.58
Annex A (Normative) Timing diagrams.59
A.1 Normal timings .59
A.2 Double PrintData message.60
A.3 PrintGo errors .60
A.4 Print error .61
Annex B (Informative) PrintData examples.63
B.1 Example of a mixed bar code and text message .63
B.2 Example of a mixed image and text message .68
Annex C (Informative) Load Font definition .72
C.1 General .72
C.2 Message structure.72
Bibliography.75

Foreword
This document (CEN/TS 15525:2006) has been prepared by Technical Committee CEN/TC 331 “Postal
Services”, the secretariat of which is held by NEN, in collaboration with UPU.
NOTE This document has been prepared by experts coming from CEN/TC 331 and UPU, under the frame of the
Memorandum of Understanding between UPU and CEN.
1)
The UPU’s contribution to the specification was made, by the UPU Standards Board and its subgroups, in
accordance with the rules given in Part V of the "General information on UPU standards".
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification: Austria, Belgium, Cyprus, Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden,
Switzerland and United Kingdom.

1)
The UPU's Standards Board develops and maintains a growing number of standards to improve the exchange of postal-related
information between posts, and promotes the compatibility of UPU and international postal initiatives. It works closely with posts,
customers, suppliers and other partners, including various international organizations. The Standards Board ensures that coherent
standards are developed in areas such as electronic data interchange (EDI), mail encoding, postal forms and meters. UPU standards are
published in accordance with the rules given in Part VII of the General information on UPU standards, which can be freely downloaded

from the UPU world-wide web site (www.upu.int).
Introduction
Automated postal sorting systems frequently use printers to print bar codes, cancellation and other marks and
human readable data on the items processed through them. Bar codes are used to control further processing
steps and to support item tracking and performance monitoring; cancellation marks to prevent the re-use of
postage stamps, record data and the location of processing and to convey advertising or other messages and
human readable text is used to support a provision of instructions, such as forwarding addresses to delivery
agents and manual sorting staff and providing back-up in the event of unreadability of bar codes.
In order to print bar codes, images or text on items, an interface between sorter and printer is needed for
transferring information, providing sorter speed information and to control the start of printing. This interface
has traditionally been different for each printer supplier and even for different models of printer. This has
resulted in the need for sorting equipment suppliers to develop printer- or even project-specific interface
solutions to fulfil the requirements of individual postal operators for the printer brand they want to use. This
has several disadvantages. Such specific interface solutions are typically not integrated into the sorting
system supplier’s product line and often result in:
 substantial duplication, with each participating supplier being required to undertake separate
development;
 system integration being complex and time consuming (and therefore expensive);
 long-term dependence on the original supplier(s), due to the impossibility of contracting modification of
the interface to third parties;
 high maintenance costs, at least once the initially agreed maintenance period is over;
 early obsolescence, due to lack of support for long-term maintenance;
 inability to upgrade equipment and/or to replace worn out or obsolete equipment;
 poor transferability between projects.
The above issues are not limited to the sorting systems interface with printers, but apply also to interfaces with
other system components, including bar code readers, image capture devices, OCR sub-systems, etc. Their
impact is also growing because, to optimise performance, postal operators increasingly require sorting
systems which integrate equipment from different suppliers. In the past this has led to project specific
interfaces being negotiated between one postal operator and one or multiple suppliers. These project-specific
interfaces were developed by the suppliers and maintained for an agreed period of time.
Some suppliers have sought to address these problems by defining supplier-specific “open interfaces” that
apply across a range of products, but these still have the disadvantage of being in product use by only one
supplier. This led to an initiative, on the part of a group of suppliers and postal operators, to develop a range
of “open standard interfaces” which, following their implementation by suppliers, could support the
construction of systems using components from different suppliers.
This standard, which covers the interface between the control unit of a postal sorting system and a printer
connected to that system, is the first of these open standard interfaces. Like the similar specifications that are
2)
expected to be developed in the future , it is expected – subject to its adoption as a tendering requirement by
postal operators – to lead to improved economics and performance of postal automation systems through:
 long term reductions in costs, with higher initial product development and system acquisition costs being
more than offset by reductions in project-specific developments, integration and maintenance costs;
 simpler, faster, system integration, particularly in cases in which equipment from different suppliers is
involved;
 longer term, lower cost, maintainability and increased longevity of systems;
 increased competition between suppliers, resulting in both enhanced products and lower costs;
 reduced dependence on individual supplier(s).

2) A second specification, covering the interface between the control unit of the image processing subsystem of a sorter
and an image enhancement subsystem, such as an address interpretation system, is already under development; others
are expected to follow as and when the need is identified and the resources for development become available. Each will
be developed by a separate ad-hoc project group working under the auspices of CEN/TC 331 Postal services and/or the
UPU Standards Board.
1 Scope
This document specifies the electrical, data and timing interface between the control unit of a postal sorting
system and an ink jet printer connected to that system. It further specifies an ancillary interface to the printer,
which can be used for the support of remote diagnostics and other service functions.
NOTE 1 This specification can equally be applied to the interfacing of printers to sequencing systems and combined
sorting and sequencing systems. It was primarily developed for application to ink jet printers, but could be applied to
printers with similar functionality that make use of other printing technologies.
At the physical level, the specification is based on the use of a combination of a standard 100 Mbps Ethernet
connection for the transfer of data and patch cables for signalling. At a logical level, data is transferred using
messages transmitted across the Ethernet connection using three TCP/IP sockets, with the execution of time-
critical functions being controlled through the use of signals on a TIA/EIA-422 interface.
NOTE 2 Several printers can be connected to a single sorting system. In this case, the printers can optionally share
access to a single Ethernet network, but each requires its own patch cables. This standard does not support the
connection of a single printer to multiple sorting system control units.
This document defines all messages that may be transferred via each of the TCP/IP sockets, specifies printer
behaviour on receipt of these messages and defines how the timing of this behaviour is controlled by the
TIA/EIA-422 signals.
The specification supports the use of the printer to print bar codes, human readable text and/or images on
mail items whilst these are being transported past the print head . It provides explicit support for Bar/No Bar
(BNB), Bar/Half Bar (BHB) and four state bar codes, but allows full user control over the specification of bar
patterns to support more complex bar coding formats.
NOTE 3 Printers that comply with the specification are required to support printing of the three above mentioned bar
coding formats, character printing and two images; support for additional formats and a greater number of images is
optional and, in particular, can depend on the available printer memory
The different TCP/IP sockets have different functions that may be fulfilled by different subsystems referred to
as sorter control, print control and remote service. Where these are implemented as distinct subsystems, they
will need to intercommunicate. The interfaces between them nevertheless fall outside the scope of this
specification and are not covered herein.
EXAMPLE Before initialisation, during printer OFF mode and if a fatal error is reported by the printer, print control
should desist from sending print instructions to the printer. It therefore needs to be kept aware of printer status. Similarly,
print control might need to forward print error information to sorter control. Use of the control and service sockets also
needs to be coordinated, since new initialisation messages or new software downloaded from remote service will overwrite
initialisation settings and software from sorter control, and vice versa.
This specification does not address the physical construction of printers or their mechanical integration into
sorting systems, neither does it specify electrical power connections to the printer.

No explicit limit is placed on the transport speed. However, the specification was drawn up in the context of existing
equipment with transport speeds that are typically in the range 2,0 m/s to 4,0 m/s. Its applicability outside of this range
requires further study, in particular to determine, for higher speeds, whether the 500 KHz timing signal referred to in 7.2
remains adequate.
This document includes three annexes and a bibliography. Annex A is normative; Annexes B and C are
informative.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, or references to a version number, only the edition cited applies. For undated references and
where there is no reference to a version number, the latest edition of the referenced document (including any
amendments) applies.
ISO standards
NOTE 1 ISO standards are available from national standards institutes or from the International Organization for
Standardization (ISO):
1, rue de Varembé, Case postale 56, 1211 Genève 20, SWITZERLAND
Tel: +41 22 749 0111; Fax: +41 22 733 3430; www.iso.ch
ISO/IEC 10646, Information technology - Universal Multiple-Octet Coded Character Set (UCS)
NOTE 2 ISO/IEC 10646 is technically equivalent to UNICODE 4.0.0 [5]
UPU standards
NOTE 3 UPU standards are available on subscription from the UPU International Bureau:
Weltpoststrasse 4, Case postale 13, 3000 Berne 15, SWITZERLAND
Tel: +41 31 350 3111; Fax: +41 31 350 3110; www.upu.int
UPU Standards glossary
IEEE specifications
NOTE 4 IEEE specifications are available on-line from IEEE:
IEEE Corporate Office, 3 Park Avenue - 17th Floor, New York, NY 10016-5997, U.S.A.
Tel: +1 212 419 7900; Fax: +1 212 752 4929; shop.ieee.org/ieeestore
IEEE 802.3:2002, Information Technology - Telecommunication & Information Exchange Between Systems -
LAN/MAN - Specific Requirements - Part 3: Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications
NOTE 5 Commonly referred to as the Ethernet standard.
TIA/EIA specifications
NOTE 6 TIA/EIA specifications can be ordered online from Global Engineering Documents: http://global.ihs.com
TIA/EIA-422-B-94 (R2000), Electrical Characteristics of Balanced Voltage Digital Interface Circuits
NOTE 7 Commonly referred to as RS-422.
TIA/EIA-568-B-1, Commercial building telecommunications cabling standards - Part 1: General requirements
TIA/EIA-568-B-2, Commercial building telecommunications cabling standards – Part 2: Balanced twisted-pair
cabling components
Internet RFCs
NOTE 8 Internet RFCs (Requests for Comment) are available from the Internet Engineering Task Force:
c/o Corporation for National Research Initiatives,
1895 Preston White Drive, Suite 100, Reston, VA 20191-5434, U.S.A.
Tel: +1 703 620 8990; Fax: +1 703 620 9071; www.ietf.org
RFC 791, Internet Protocol – DARPA Internet programme – Protocol specification
NOTE 9 Commonly referred to as IP or, in combination with TCP, as TCP/IP.
RFC 793, Transmission Control Protocol – DARPA Internet programme – Protocol specification
NOTE 10 Commonly referred to as TCP or, in combination with IP, as TCP/IP.
3 Terms and definitions
For the purposes of this document, the terms and definitions given in the UPU Standards glossary and the
following apply.
3.1
big endian
method of storing byte oriented data in which the most significant byte of the data is stored in the memory location with the
lowest memory address
3.2
mail entity
mail item or collection of mail items which is constrained to form a physical unit
NOTE In this standard mail entity is used in the sense of a single item on which is printed.
EXAMPLE 1 a single letter, a single parcel, a collection of letters in a tray, a roller cage containing a collection of trays,
several pallets containing trays that are loaded onto a vehicle or an airplane.
3.3
UNICODE
universal character encoding, maintained by the Unicode Consortium (http://www.unicode.org/), that provides the basis
for processing, storage and interchange of text data in any language
NOTE This standard uses UNICODE version 4.0.0 [5] subset UTF-8 and stores strings as big endian (see 3.1).
3.4
sequencing
process in which one or more input streams of mail entities are merged into a single output stream in which the sequence
of individual entities has operational significance for further processing
EXAMPLE 2 The organisation of a group of mail entities that are to be delivered by a delivery agent during a single
delivery round into the sequence in which the agent will pass their delivery points.
NOTE Sorting and sequencing can be combined into a single process. In this case, each output stream resulting from
sorting is sequenced.
3.5
sorter
sorting machine
sorting system
equipment capable of sorting mail entities
3.6
sorting
process in which an input stream of mail entities is separated into multiple output streams, the entities in each of which
share one or more features in common with other entities in the same output stream, but which differ from those in other
streams
NOTE Postal sorting systems are used to group mail entities which require common processing or transportation. For
example, the first sortation process primarily segregates mail based on the location of the processing facility which serves
the geographic area in which its delivery address is situated, with exception streams being created for mail which is
underpaid, has an unreadable delivery address, etc.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in the UPU Standards glossary and
the following apply.
0x hexadecimal value – the 0x indicates that the following characters represent hexadecimal digits
EXAMPLE 0x2C represents the 8-bit (single byte) value 2C = 00101100 = 44 .
16 2 10
ASCII: American Standard Code for Information Interchange, a method of representing character data in
8 bit binary form that is defined in ISO/IEC 646 [1].
EIA: Electronics Industries Alliance
IP: Internet Protocol as defined in RFC 791
TCP: Transmission Control Protocol as defined in RFC 793
TIA: Telecommunications Industry Association
UTF-8: acronym given to a UNICODE representation in which common characters are represented as a
single byte, with less common ones being represented by a string of up to 6 bytes
5 Overview of the interface
The main function of a printer in a sorting system is to print information on mail entities that are handled by the
sorting system. The printer requires instructions on what to print, on which entities and at what position on
them. Since the movement of entities past the print head is controlled by the sorting system, this translates
into the need to control the timing of execution of the print instructions. The sorter control unit needs feedback
in order to monitor the functioning of the printer, enabling it to take exception action when necessary, for
example when the printer runs out of ink. If printer maintenance is performed by a third party, there will also be
a need for communication between the printer and a separate diagnostic or service system.
The instructions on what to print and the feedback from the printer are conveyed in the form of messages to
and from the printer; the timing of printing is controlled through electrical signals. These messages and signals
require a transport mechanism. Message transport is achieved through a data communications interface (see
Clause 6); signalling through two TIA/EIA-422 interfaces (see Clause 7), one of which provides a clock signal
(see 7.2); the other a print initiation trigger referred to as PrintGo (see 7.3).
The initiation of printing by means of the PrintGo signal is subject to timing constraints which are described in
7.3 and Annex A. Constraints on the usage of particular messages are also required both from a logical
perspective and to ensure that the behaviour of the printer remains predictable at all times. These constraints,
which are described in Clause 9, require that the printer support (at least) three states:
• on-line: the state in which the printer is capable of accepting and executing printing instructions;
• off-line: the state in which the printer is under the control of the sorting system but is not capable of
accepting and executing printing instructions;
• maintenance: the state in which the printer is under the control of a (possibly remote) service system.
EXAMPLE It would clearly not make sense to trigger printing unless the data to be printed had already been sent to,
and received and processed by, the printer. Equally, it would not make sense to reset or to download new software to the
printer whilst it was busy printing, since it would not then be known whether the printing instructions concerned had been
properly executed. The use of different states supports deterministic control over which messages are accepted at any
given time.
The use of these states, and the mechanisms for transition between them, are described in 10.1
6 Data communications interface
The communication of data to and from the printer shall be achieved using the TCP/IP protocol over a
standard 100Mbit Ethernet network. A standard shielded Ethernet patch cable (Category 6 or better) with
RJ45 plugs shall be used.
NOTE 1 TCP/IP is a proven protocol providing for error free communication of a stream of data bytes between two end
points (sockets) across an intervening communications channel that might be prone both to errors and to disturbance of
the sequence of transmitted data. The TCP/IP protocol deals with any retransmission needed to correct errors and with
restoration of the sequence of data. Interpretation of the data stream (e.g. as a series of individual messages as in this
specification) is application dependent. Applications are required to cope with the hand-over, from TCP/IP, of arbitrary-
length ‘chunks’ of data at arbitrary times and to hold incoming data which is incomplete, from a processing perspective,
until it is completed by the reception of further data.
IP version 4 shall be used.
NOTE 2 IP version 6 is not supported by this specification.
The printer shall handle 3 TCP/IP communications sockets:
 control socket, which is used for initialisation, control and on-request status reporting;
 print socket, which is used for print data and associated status reporting;
 service socket, which is used to support (remote) diagnostic and maintenance functions.
NOTE 3 This specification does not define specific socket numbers. The particular socket numbers used should be a
configurable parameter of each sorter-printer interface.
Use of the three TCP/IP sockets, and the format of the messages that may be sent across them, are defined
in clauses 8 and 9.
NOTE 4 Use of the service socket can interfere with operational use of the printer. It is strongly recommended that
procedures be put in place to ensure that use of the service socket occurs only whilst the printer is not in operational use
and only with the full knowledge and consent of operational staff. The definition of such procedures is, however, outside
the scope of this specification.
NOTE 5 Coordination is also required between use of the service and control sockets. To support diagnostic and
maintenance functions, certain configuration messages that are normally sent via the print socket can also be sent on the
service socket. In many cases, configuration data sent across the service socket will overwrite earlier data sent across the
control socket and vice versa. Careful coordination is therefore needed if the printer configuration is updated by the remote
service system. After remote testing, either the printer should be set back to its original configuration, or sorter control
should be updated with the new configuration – otherwise it will return the printer configuration to its previous state the
next time it performs an initiation procedure. The procedure for updating sorter control is outside the scope of this
specification.
The sending of print data is time critical and it is therefore required that the subsystems which use the print
socket are located within a local Ethernet. The subsystems which use the control and service sockets can be
located on separate local networks interconnected via a gateway. The diagram below shows a typical
Ethernet layout. The shaded area shows devices in the sorter that are connected over the local sorter’s
Ethernet. Remote diagnostics are provided by a remote service system which is on a separate network,
interconnected with the sorter’s network by a combined gateway and firewall.
NOTE 6 Though this is not shown, the remote service system could be at the supplier’s site, interconnected with the
postal operator’s site via a secure telecommunications link.

Figure 1 —Typical Ethernet layout
7 Signalling interfaces
7.1 Physical connections
The printer shall be connected to the sorter control unit via a 4-conductor shielded cable with twisted pairs and
shield connected to chassis ground via the connector body. The cable is connected to the printer by a Sub-D
9 connector. The "male" connector is mounted at the printer. The signal conductors are connected as shown
below:
Pin Signal name
1 -
2 -
3 -
4 -
5 -
6 Print Go (pos.)
7 Print Go (neg.)
8 Print Clock (pos.)
9 Print Clock (neg.)
The pair connected to pins 6 and 7 is used for the PrintGo signal (see 7.3); that connected to pins 8 and 9 for
the print clock (see 7.2).
7.2 Print clock signal
The print clock signal is a sorter tachometer signal reflecting the movement of mail entities past the print head.
It is used by the printer to control the position and pitch at which bar codes, and the lines of dots making up
characters and images, are printed.
NOTE 1 Generally, though this is not a requirement, the print head is fixed, with mail entities being moved past it by
means of a belt-driven transportation mechanism. Where this is the case, the print clock signal can be derived from the
movement of the belt or from the rotation of a capstan in the region of the print head.
The print clock signal is sent to the printer via TIA/EIA-422 drivers over pins 8 and 9 of the physical connection
defined in 7.1 above.
NOTE 2 In theory, a single TIA/EIA-422 connection could be used to provide the print clock signal to up to 10 printers
provided that the transport speed was the same past all of them. However, this possibility is not supported by this
standard, which requires a dedicated 4-conductor cable connected to each printer.
The interval between the rising edges of two consecutive pulses shall correspond to a known movement past
the print head. This movement, being not less than 10 µm and not less than the maximum transport speed of
mail entities past the print head in m/sec divided by 500 KHz, is referred to as the print clock distance (see
also 9.6). Circuitry shall be designed to accept a transmission clock frequency of up to 500 KHz.
NOTE 3 This allows a print clock distance of 10 µm (0,01 mm) to be used on equipment with a maximum transport speed
of 5,0 m/sec. If the maximum transport speed were higher than this, a correspondingly larger print clock distance would
have to be used. For example, at 7,5 m/sec, the transport distance corresponding to a single clock cycle would have to be
0,015 mm or greater. In all cases, the maximum frequency of the clock signal is limited to 500 KHz.
NOTE 4 Print clock distance is only one of several factors that determine the position and pitch of printing. Other factors
include the frequency of the print head, the number of dots in one vertical scan (typically 10-13) and the parameter print
pitch, defined in 9.2. For example, if the print head operates at 48 KHz and paints 12 dots per vertical scan, 0,25 ms will
elapse between scans. If the belt speed is 4 m/sec, the horizontal positioning of printing, on a mail entity, can be controlled
only to within +0,5 mm and the dots of successive scans will be at least 1 mm apart. The parameter print pitch is used to
further control the pitch of bar codes: it defines the desired pitch in units of 0,01 mm. Typically this will be converted by the
printer into the number of print clock cycles which should elapse between successive bars. Thus, for example, if the print
clock distance is 0,02 mm and desired print pitch is 130 (1,3 mm), 65 clock cycles need to elapse between bars. At the
speed of 4 m/sec, the clock frequency will be 4000/0,02 = 200 KHz, so 65 cycles will take 0,325 msec. This is not a
multiple of the printer’s intrinsic cycle time of 1/48 msec, so bars will actually have a pitch of 1,25 mm (corresponding to 15
printer clock cycles) or 1,33 mm (corresponding to 16 printer clock cycles).
NOTE 5 It is permissible for the printer to interpolate mail entity movement within print clock cycles. For example, if the
print clock distance is 10 µm and the current belt speed is only 0,5 m/sec, print clock will have a cycle time of 20 µsec. The
printer may interpolate that, in 4 µsec, the mail entity will have moved 4/20 * 10 = 2 µm.
The use of a print clock signal is not mandatory. An internal printer clock can be used to calculate the mail
entity’s movement. Bit 0 of the Configuration Bits needs to be cleared to use an internal clock (see also 9.6.2).

7.3 PrintGo signal
The PrintGo signal is used to trigger printing after the data to be printed have been supplied to the printer in a
PrintData message (see 9.2).
After PrintGo is raised it remains high for at least 50 µsec. If the PrintData message specifies a print delay,
this delay shall commence after PrintGo has been continuously high for 50 µsec.
NOTE 1 The requirement for PrintGo to remain high for at least 50 µsec is to avoid printing on glitches: it is assumed that
the raising of PrintGo for a shorter period results from electrical interference and should therefore be ignored. The actual
initiation of printing has to await the commencement of the next printer cycle (which could, for example, be up to 20 µsec
later for a 50 KHz printer).
NOTE 2 It should be noted that placement precision is limited by the printer cycle and by the accuracy with which the
sorter is able to detect the positioning and movement of the mail entity.
The timing of PrintGo and the parameter Print delay in the PrintData message determines when the printer
starts printing and thus the location of the first drop on the mail entity. If print delay is zero, printing starts 50
µs after the raising of the PrintGo signal.
NOTE 3 As internal processing time of a printer may vary, adjustment of the timing of PrintGo is a task of integrating a
specific printer and mail sorting system.
To control the position of printing on the mail entity, the sorter needs to take account of the transport speed
and the time taken for ink drops to reach the mail entity surface. This time, typically of the order of a few
milliseconds in the case of continuous deflected inkjet technology, depends on ink, technology and
manufacturer dependent parameters including the printer’s internal processing time, the velocity of ink drops
as they leave the print head and the distance between the print head and the mail entity. The method of
achieving this control is outside the scope of this standard.
NOTE 4 Adjustment of the timing of PrintGo is a task of integrating a specific printer and mail sorting system. Typically
the timing is linked to an edge detector.
The sorter should not issue the PrintGo signal until at least 10 msec have elapsed since the completion of
transmission of the PrintData message whose printing is to be triggered by the signal. In the event of
premature rising of PrintGo, the printer may disregard the trigger but shall, in such case, report a status error
by means of a PrinterStatus message (see 9.25).
NOTE 5 The 10 msec interval is defined to allow the printer sufficient time to pre-calculate the print. If it is able to do this
faster, and thus to action a premature PrintGo trigger, it may, but is not required to, do so. If it is unable, or chooses not, to
action a premature PrintGo, it is required to report this by means of a status message.
8 Messages and their usage
The following tables define the various types of data messages that may be sent to, and received from the
printer. There are two tables, one for messages that may be sent to the printer; the second for messages that
may be generated by the printer.
Each type of message has a message identifier which is used, in the message header (see 9.1), to distinguish
the particular type of message from other message types. Each table is in the sequence of these message
identifiers, which are shown in the first column as hexadecimal values. The following columns specify:
 message name and the number of the subclause in which a detailed definition of the format of the
message can be found;
 indication of the function or purpose of the message;
 whether support for the message is mandatory (M) or optional (O);
 TCP/IP socket or sockets the message may be sent on, being C for the control socket; P for the print
socket and/or S for the service socket. For messages that can only be sent in response to other
messages, value F (feedback) is used to indicate that the response is sent using the socket on which the
related request message was received;
 state or states in which use of the message is valid, being A for on-line (active), X for off-line (inactive)
and/or R for maintenance (remote access).
Table 1 — Message types that may be sent to the printer
Message ID Message name Message function Support Socket(s) State(s)
0x00 PrintData (9.2) Specify data to be printed M P A
0x01 ClearPrintData (9.3) Instruct printer to discard print M P A
data
0x10 SoftwareDownload (9.4) Update printer software O C, S X, R
0x11 InitManufacturer (9.5) Printer initialisation O C, S X R
0x12 InitCustomer (9.6) Printer initialisation M C, S X, R
0x13 LoadPattern (9.7) Specification of predefined O C, S X, R
print images
0x14 LoadBarCodeFormat Specification of bar code O C, S X, R
...