Ink jet printers are non-contact printers in which dots of ink are ejected from one or more nozzle orifices so as progressively to build up a printed image on a substrate moved relative to the nozzle. One form of ink jet printer comprises a source of ink under pressure, typically a reservoir or bottle of ink which is pressurised to from 0.1 to 2 bar, notably about 1 bar. The pressure is created, for example, by pressurising the air space above the ink in the bottle or reservoir from which ink is fed to the nozzle orifice (s) in a print head through which it is ejected as a series of droplets onto the surface of the substrate. The flow of ink through the each nozzle orifice is controlled by a solenoid valve. Typically, such a valve comprises an electromagnetic plunger journalled for axial movement within an axially extending electric coil. The distal end of the plunger is located within a valve head chamber through which ink flows from the reservoir to the nozzle orifice. When current is fed through the coil, this generates a magnetic field which acts on the plunger to move it axially and thus open, or shut, the inlet to nozzle orifice. Typically, the magnetic field acts to retract the plunger against the bias of a coil spring to create a flow path between the valve head chamber and the nozzle orifice. When the electric current no longer flows in the coil, the magnetic field ceases and the

plunger returns under the bias of the spring to seat against sealing ribs, lips or other means located at or around the inlet to a bore leading to the nozzle orifice to close the flow path to the nozzle orifice. For convenience, the term drop on demand printer will be used to denote in general such types of ink jet printer.

Conventional ink jet print heads have employed electro- mechanical control and actuation systems that open the valve for a pre-determined period of time so that an ink drop can be ejected. The time for which the valve is held open determines the quantity of ink that is ejected from the valve and hence the size of the drop that will be formed on the substrate that is being printed upon. Mechanical variations in the manufacture and assembly of the valves will lead to each valve ejecting a different volume of ink when the valve is held open for a pre-determined period of time. Thus it is essential that all the valves used within a print head matrix are adjusted such substantially equal volumes of ink are ejected when the valves are held open for the same period of time. This adjustment of the valves is time consuming and laborious as typically a manual adjustment must be made to each valve within the print head matrix.

According to a first aspect of the present invention there is provided a method of controlling a printing system comprising a print controller and one or more print heads, the method comprising the steps of: (i) establishing communication between the print controller and the or each print head; (ii) determining the identity of the or each print head; (iii) the

print controller accessing a data source associated with the or each print head; and (iv) the print controller controlling the or each print head in accordance with the contents of the associated data source.

According to a second embodiment of the present invention, there is provided a data carrier comprising computer code for executing a method as described above.

According to a third embodiment of the present invention, there is provided a printing system comprising a print controller and one or more print heads, the print controller comprising storage means, processing means and communication means, the print controller, in use, establishing communication with the or each print head via the communication means, determining the identity of the or each print head, accessing a data source associated with the or each print head stored within the storage means and the print controller controlling the or each print head in accordance with the contents of the associated data source.

A preferred embodiment of the invention and its operation under on-line software control will now be described by way of illustration only and with respect to the accompanying drawing, in which Figure 1 shows a schematic depiction of a system according to the present invention.

Figure 1 shows a schematic depiction of a system according to the present invention. The system comprises controller 100, a plurality of print stations 200 and a further plurality of print heads 300. Controller 100 comprises CPU 110, memory means 120, storage device 130, input means 140, display means 150 and network interface 160. The input means 140 is arranged to be in communication with the CPU 110, memory means 120 and storage device 130 so that data entered by an operator can be processed and/or stored, as appropriate. The controller is operated by software that is stored within the storage device 130, loaded into the memory means 120 and executed by the CPU 110. The CPU 110, memory means 120 and storage device 130 are also in communication with the display means 150 and the network interface 160 such that operating parameters can be displayed, user commands confirmed etc, to a user of the controller and so that data can be transmitted to and from the plurality of print stations 200.

The plurality of print stations 200 are connected to the controller 100 via communications cable 170. Figure 1 shows the plurality of print stations 200 comprising print stations 210, 220,230 and 240 (although it will be understood that the number of print stations connected to the controller is not limited by the present invention). Each of the plurality of print stations 200 is connected to a plurality of print heads 300; in Figure 1 print heads 312,314 and 316 are shown in communication with print station 210 via communications cable 215 and print heads 342,344 and 346 are shown in communication with print station 240 via communications cable 245. For the sake of clarity, the print heads connected to

print stations 220 and 230 are not shown. It will be understood that the number of print heads connected to a print station may vary and is not limited by the present invention.

The controller 100 can be operated by a user to create and manage variable print layouts that will be transmitted to one or more print heads, where the print layouts will be printed.

The controller may also be used to configure various parameters associated with one or more of the print stations and/or one or more of the print heads.

A print layout may be printed across a number of print heads belonging to one print station. A print layout comprises a number of strips, which when appropriately arranged form an image comprising graphics and alphanumerical characters.

Each of the print heads connected to a print station will have its own image for printing and the controller will send a separate image for each print head. If a print layout comprises real-time information, such as the time and/or date of printing, or production data, sequence numbers etc., then this data can be updated by sending a partial update of the print layout that comprises the image data that has changed.

Only the regions of the print image that are changing are updated in this fashion and whole print images will only be retransmitted when the selected print layout is altered by the user.

The print layout data sent by the controller may comprise data that controls colour and grey scale printing. This data

will be interpreted by a print station (or a print head) into a format that can be acted on by the print station to provide the desired print effect, for example, transmitting a byte code specifying the time period that a valve is to be opened for to provide a specific grey scale. A complete print layout may be transmitted as a sequence comprising a number of partial images. The maximum size for a partial image will be one packet because the packets will need to be buffered at the print station in order to verify the checksum of the packet before processing the packet.

Packets are also used to transmit configuration and control parameters between the controller and print heads and/or print stations. The system uses two types of parameter ; write only parameters and read/write parameters. These parameters will be transmitted by the controller in response to a user action or when one of the current print layouts are changed. Packets may contain multiple parameters, but it is preferred to limit these packets such that write parameters are only used in write parameter packets and read/write parameters are only used in read/write parameter packets.

Table 1 below shows the details of a generic packet used with the system of the present invention. PADDING BYTES 28 Bytes SOH 1 Byte SEQUENCE NUMBER 4 Bytes PACKET LENGTH 2 Bytes PACKET TYPE 2 Bytes PACKET ID 2 bytes STX 1 Byte DATA Up To 1400 bytes ETX 1 Byte CHECKSUM 4 Bytes

The data section of the packets is made up of register address low byte, register address high byte, length of data in bytes and data for each parameter to be transmitted. The minimum packet size is So bytes in order to exceed the minimum Ethernet packet size. The maximum packet size, including headers and footers, will be 1500 bytes (the packets will have standard Ethernet headers, MAC addresses, etc.). Details of some specific packets that are used in the system are given in Appendix A.

When the controller is initialised the controller polls each of the print stations with a Request Status packet. Each of the print stations will respond with a Send Status packet, which contains data that allows the controller to recognise the print station, the various print heads that are connected to the print station and the print technology contained within the print heads. After reading the Send Status packet, the controller will send Request Read/Write Parameters and Update Write Parameters packets to each of the print stations to configure them in accordance with the data held within the storage device of the controller.

If no print station is found on initialisation the controller will periodically poll the network interface 160 to check if a print station has been connected. If a print station is power cycled or communication is lost, then the controller will also periodically poll the network interface to check for a print station.

The controller stores a number of driver files within the storage device 160. Each if these driver files is specific to a particular print station or a print head and enables the automatic configuration of different print stations and/or print heads by the controller. For example, if a new print head is added to a print station, the polling of the print station by the controller (using Request Status packets) will identify the type and specification of the print head. The controller will load the driver file specific to the print head and will be able to send print data to the print head without any user intervention at the controller terminal.

The driver files define the print hardware, how to drive it and how control information is presented to the user by defining each of the registers which control the operation of the hardware, with each register corresponding to a system parameter. Each system parameter may be defined using a number of attributes including maximum, minimum and permissible values.

The system parameters may be divided into three sub-classes based upon the nature of the data that they represent and the way in which the parameter may be controlled by the user:

'bit field parameters are derived from binary registers, that is a register that is in one of two states (normally ON/OFF or enabled/disabled). Bit field parameters may be presented to the user by the user interface of the controller as a check box, with associated text indicating the current state of the register and/or the effect of changing the state of the register; 'value parameters are derived from multiple bit registers that take a numeric value. The upper limit to the value that can be set may be related to the number of bits in the register, although either or both of the upper or lower limits may be defined by to the operation of the hardware. For example, the open time for a valve may be controlled by an eight bit value parameter with the value of the parameter in the range of 80 to 250 indicating the number of micro-seconds for which the valve is held open for. Value parameters may be controlled by the user by entering a numerical value or by selecting a value from a pull-down menu on the user interface of the controller. selection parameters are derived from registers that use one or more numerical values to define a range of different hardware states. These may be presented to the user as a list on the user interface of the controller from which a value can be selected.

The print hardware may be defined using a number of status bytes-for example one byte may signify the print station

type, the second byte may signify the print station hardware version and the third byte may signify the print station software revision. Similar schemes may be used to define and classify the print heads. The controller may use additional bits (or bytes) to assign unique identities to each of the print heads and the print stations It is important that the system is able to cope with lost or corrupted packets. Thus, when a packet is sent (either by the controller or by a print station) a timer is started and if the packet is received without an error then an Acknowledge packet is returned. If the packet contains an error then it will be ignored and no Acknowledge packet will be sent ; eventually the sender's timer will expire and the packet will be resent. If the Acknowledge packet is lost or contains an error then the senders timer will expire, the original packet will be resent and a further Acknowledge packet generated.

The controller may log the reliability of the communications protocol by recording the number and variations of failed messages over time. The expiry times for timers and the number of retries before protocol failure should be transmitted to all of the print stations.

All packets are transmitted with equal priority, with no mechanism by which packets can be transmitted preferentially.

Once the packets have been received, either by the controller or at a print station then they will be passed to tasks with differing priorities. The highest priority task is printing

compiled print images and the next highest priority task is compiling print images using received print image updates.

The other packets should be dealt with using an equal priority.

The print stations should comprise sufficient memory to store two printable images, such that one image can be printed whilst the next is being downloaded. The print station should be capable of performing the following functions, amongst others, both individually and in combination with other functions; inverted printing, reverse printing, rotation of the print image through pre-set angles (for example 90', 180°, 270°, etc. ) inverse video printing, raster repeat and auto repeat print. Preferably, all print images sent to a print station will be horizontally rastered.

Preferably, the physical link between the controller and the print station will be shielded Cat5 cable, supporting a 100BaseT Ethernet system. The cable shielding must be sufficient to mitigate the effects of electrical noise that could degrade the performance of the system: preferably the protocol can operate with 4kV induced noise for a period of 2 minutes.

APPENDIX A Acknowledge Packet-this packet will be sent by both the controller and the print station to acknowledge the correct delivery of a packet. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH 00 PACKET TYPE 01 PACKET ID 00 STX ASCII 02 ETX ACSII 03 CHECKSUM 4 Bytes

Request Status Packet-this packet will be sent by the controller to request any status parameters that need to be polled. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE N BER PACKET LENGTH L length of data between the STX and ETX PACKET TYPE 02 PACKET ID ID There can be multiple definitions of this packet type defined in the driver file STX ASCII 02 DATA Low byte add High byte add Length of data x number of status parameter ETX ASCII 03 CHECKSUM 4 Bytes

Send Status Packet-this packet will be sent by the print station to the controller to update the status either when an error occurs or as a response to the Request Status packet. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER'N PACKET LENGTH L length of data between the STX and ETX PACKET TYPE 03 PACKET ID ID There can be multiple definitions of this packet type defined in the driver file STX ASCII 02 DATA Low byte add High byte add Length of data Data x number of status parameter ETX ASCII 03 CHECKSUM 4 Bytes

Request Read/Write Parameters Packet-this packet will be sent by the controller to request any read/write parameters from a print station. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH L length of data between the STX and ETX PACKET TYPE 04 PACKET ID ID There can be multiple definitions of this packet type defined in the driver file STX ASCII 02 DATA Low byte add High byte add Length of data x number of status parameter ETX ASCII 03 CHECKSUM 4 Bytes

Send Read/Write Parameters Packet-this packet will be sent by a print station as a response to the Request Read/Write parameters packet. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH L length of data between the STX and ETX PACKET TYPE 05 PACKET ID ID There can be multiple definitions of this packet type defined in the driver file STX ASCII 02 DATA Low byte add High byte add Length of data Data x number of status parameter ETX ASCII 03 CHECKSUM 4 Bytes

Update Read/Write Parameters Packet-this packet will be sent by the controller to update any read/write parameters to the print station. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH L length of data between the STX and ETX PACKET TYPE 06 PACKET ID ID There can be multiple definitions of thi packet type defined in the driver file STX ASCII 02 DATA Low byte add High byte add Length of data Data x number of status parameter ETX ASCII 03 CHECKSUM 4 Bytes

Update Write Parameters Packet-this packet will be sent by the controller to update any write parameters to the print station. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH L length of data between the STX and ETX PACKET TYPE 07 PACKET ID ID There can be multiple definitions of this packet type defined in the driver file STX ASCII 02 DATA Low byte add High byte add Length of data Data x number of status parameter ETX ASCII 03 CHECKSUM 4 Bytes Print Data Packet-this packet will be sent by the controller to update a section of the printed image. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH L length of data between the STX and ETX PACKET TYPE 08 PACKET ID 00 STX ASCII 02 LEFT CO ORD 2 Bytes RIGHT Y CO ORD 2 Bytes BOTTOM CO ORD 2 Bytes TOP CO ORD 2 Bytes DATA 8 Bits per byte for black & white printing, a minimum of 1 byte per pixel for colour or grey scale. All to be defined in the driver file. Co-ord 0, 0 is always bottom left of field. ETX ASCII 03 CHECKSUM Bytes

Finished Updating Print Data Packet-this packet is a signal from the OCS to print station that the printable image is ready for printing. PADDING BYTES 28 Bytes SOHASCII 01 SEQUENCE NUMBER N PACKET LENGTH 00 PACKET TYPE 09 PACKET ID 00 STX ASCII 02 ETX ASCII 03 CHECKSUM 4 Bytes

Print Go Packet-this packet is transmitted by the print station to signal to the controller that the printing of an image has been initiated. PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH 00 PACKET TYPE 10 PACKET ID 00 STX ASCII 02 ETX ASCII 03 CHECKSUM 4 Bytes Print Done Packet-this is transmitted by the print station to signal to the controller that a print has finished.

PADDING BYTES 28 Bytes SOH ASCII 01 SEQUENCE NUMBER N PACKET LENGTH 00 PACKET TYPE 11 PACKET ID 00 STX ASCII 02 ETX ASCII 03 CHECKSUM 4 Bytes