Patent Description:
When printing a document, a print engine controller of a printing device may send commands in control data packets to the fluid ejection devices (e.g., print heads), via a data path, that control when the individual nozzles of the fluid ejection devices "fire" or dispense fluid (e.g., ink, toner in the case of an inkjet printing device, or a detailing agent in the case of a three dimensional printing device). For high-density print applications, the various nozzles may be grouped into a plurality of "primitives," such that one nozzle in each primitive fires at any given time based on the data loaded from the print engine controller (e.g., one bit of data per primitive). For lower density print applications, a plurality of primitives may be combined to form a "virtual" primitive in which one nozzle in each virtual primitive fires at any given time (thus, some primitives in the virtual primitive may not fire any nozzles).

Some shift register fluid ejection implementations may allow the insertion of random data in the header of a control data packet. A variable number of random data bits may be added to the header. The random data bits may have no functional impact on real nozzle data and/or control word data, but can provide benefits such as identifying data integrity issues and effectively randomizing or dithering the fire period to spread the frequency of fire-related electromagnetic compatibility emissions. However, some fluid ejection device designs may not utilize a receiver that is compatible with random length headers. These fluid ejection device designs may not operate properly in systems where random length headers are utilized. For example, some fluid ejection device designs may utilize a different control word or datapath structure, so a remapping of bits within the data packet may be performed to provide compatibility. Such a remapping involves a capability to align to the random length header to determine the location of the true control word / data packet.

Some examples of the present disclosure are directed to a fluid ejection array controller interface that determines the location of random data within a control data packet. Alignment to the random length header allows removal of the random header and/or modification of the data packet (including the control word). Some examples of the present disclosure are directed to a fluid ejection array controller interface that removes randomly inserted bits from the header of a control data packet before the control data packet is provided to the fluid ejection device. Some examples disclosed herein allow a system defined for compatibility with a shift register fluid ejection implementation to be used with alternative fluid ejection devices (e.g., by removing the random header), or a system defined for a specific control word bit ordering (e.g., address bit locations) to be used with alternative fluid ejection devices (e.g., by modifying the control word data and/or bit mapping to rearrange the control word bits). Some examples provide a flexible system design for future, undefined fluid ejection architectures.

In one example, the fluid ejection array controller interface includes clock recovery logic to receive a burst mode input clock signal and generate a free-running clock signal. The fluid ejection array controller interface may include counter logic to identify locations of the randomly inserted bits based on the free-running clock signal. The fluid ejection array controller interface includes output logic to remove the randomly inserted bits based on the identification performed by the counter logic, and outputs a modified data packet to the fluid ejection device with the randomly inserted bits removed. The output logic also generates an output clock signal by masking the free-running clock signal during times corresponding to positions of the randomly inserted bits.

Although examples of the disclosure may be discussed within the context of inkjet printing, the techniques disclosed herein may be further applied to control the fluid ejection devices of three dimensional printing devices and other devices that eject fluid such as ink, toner, or the like, or detailing agents (e.g., binder materials, powders, or the like) used in additive manufacturing processes.

<FIG> is a block diagram illustrating elements of a printing device <NUM> according to one example. Printing device <NUM> includes a print engine controller <NUM>, a fluid ejection array controller interface <NUM>, and a fluid ejection device <NUM>. In one example, the fluid ejection device <NUM> may be one of a plurality of fluid ejection devices (e.g., print heads) arranged in a fluid ejection array (e.g., a print bar) of a printing device (e.g., an inkjet printing device or a three dimensional printer). The fluid ejection device <NUM> includes a nozzle array <NUM>, which further includes nozzle columns <NUM>(<NUM>)-<NUM>(X) (hereinafter collectively referred to as "nozzle columns <NUM>") arranged in rows along the fluid ejection device <NUM>. Each nozzle column <NUM> includes a plurality of nozzles arranged to dispense fluid onto a substrate, where the nozzles may be arranged into groups called "primitives. " The primitives may be further arranged into groups called "virtual primitives. " The number and arrangement of the nozzles may vary depending on the desired print density. The fluid ejection device <NUM> also includes a fluid ejection array controller <NUM>, which is connected to the nozzle array <NUM>. In some examples, the fluid ejection array controller <NUM> may also be referred to as a fluid ejection controller, and the fluid ejection array controller interface <NUM> may also be referred to as a fluid ejection controller interface.

The fluid ejection array controller interface <NUM> receives control data packets <NUM> from print engine controller <NUM> for controlling ejection of fluid by the nozzles of the nozzle array <NUM>. The interface <NUM> removes randomly inserted bits from the received control data packets <NUM> to create modified control data packets <NUM> with the randomly inserted bits removed, and outputs the modified control data packets <NUM> to the fluid ejection array controller <NUM>. The fluid ejection array controller <NUM> generates ejection control data <NUM> for the nozzles of the nozzle array <NUM> (or, more specifically in some examples, for the virtual primitives of the nozzle array <NUM>) based on the contents of the modified control data packets <NUM>. A data path interconnects the print engine controller <NUM>, the fluid ejection array controller interface <NUM>, and the fluid ejection array controller <NUM>, and transports the control data packets <NUM> and the modified control data packets <NUM>. The data path may be a high-speed data path, such as a multi-lane serial bus.

In one example, the control data packets <NUM> are "fire pulse group" (or "FPG") packets containing data about which nozzles of the fluid ejection device <NUM> should fire. For instance, the control data packets <NUM> may identify the primitives or virtual primitives containing the nozzles that are to fire, or the packets may contain bits of data for each primitive. One example of a fire pulse group is illustrated in further detail in <FIG>. The fluid ejection array controller interface <NUM> can be configured to remove the randomly inserted bits from the received control data packets <NUM> to create the modified control data packets <NUM>. Based on the information contained in the modified control data packets <NUM>, the fluid ejection array controller <NUM> writes unique primitive data (e.g., one nozzle's worth of data) to each primitive of the fluid ejection device <NUM>. The unique primitive data is contained in the ejection control data <NUM>. This may involve inserting null values into the control data packets <NUM> to indicate that a particular primitive should not fire any nozzles.

The fluid ejection array controller <NUM> may also generate a plurality of nozzle control bits based on the information contained in the modified control data packets <NUM>. The nozzle control bits may include a combination of primitive data, address information, and a FIRE signal local to that primitive. A nozzle control bit instructs an addressed nozzle to fire. In one example, the fluid ejection array controller <NUM> generates one nozzle control bit for each primitive on the fluid ejection device <NUM>. In one example, the fluid ejection array controller <NUM> populates the nozzle control bits with bit values (e.g., "<NUM>" or "<NUM>") that indicate whether a nozzle identified by a corresponding address should fire or not. The fluid ejection array controller <NUM> may also convey address data to the primitives of the fluid ejection device <NUM>. In one example, the address data identifies (e.g., by corresponding address) which nozzles within the primitives of the fluid ejection device <NUM> should be fired.

In one example, the fluid ejection array controller interface <NUM> is implemented as a device that is separate from the fluid ejection device <NUM> and is positioned between the print engine controller <NUM> and the fluid ejection device <NUM>. In another example, the fluid ejection array controller interface <NUM> is integrated into the fluid ejection device <NUM>, and may reside on a common semiconductor die with the fluid ejection array controller <NUM>.

<FIG> is a diagram illustrating a control data packet <NUM> that may be used to communicate commands to fire nozzles of a fluid ejection device according to one example. The control data packet <NUM> is one example of the format of the control data packets <NUM> (<FIG>). In one example, the control data packet <NUM> is a fire pulse group (or FPG) packet. In one example, the control data packet <NUM> includes random data <NUM>, header <NUM>, a payload comprising a set of address bits <NUM> and/or a set of fire data bits <NUM>, and a footer <NUM>. The example illustrated in <FIG> is an abstraction and is not meant to limit the number of bits that may be included in the packet <NUM> or in any particular portion of the packet <NUM>.

Random data <NUM> includes a random number of random data bits added to the front end of the control data packet <NUM> before the header <NUM>. In one example, the random data <NUM> is generated by a pseudo-random number generator (PRNG), such as by using a linear feedback shift register approach. The length of the random data <NUM> (i.e., the number of random data bits included) and the values for the random data bits may both be determined by the PRNG. In one example, the random data <NUM>, having a pseudo-random length, includes <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> bits of pseudo-random data.

In one example, the header <NUM> includes bits that are used by the fluid ejection array controller <NUM> (<FIG>) to detect the start of the control data packet <NUM>. Thus, the header <NUM> may include some predefined sequence of bits that indicates the start of a control data packet. In one example, the header <NUM> additionally includes a set of primitive select bits <NUM>. The primitive select bits <NUM> may be used, for example, to identify which primitive within a virtual primitive is being addressed (and should, consequently, fire). The primitive select bits <NUM> may be contained in a different portion of the control data packet <NUM>, such as the payload or the footer <NUM>.

In one example, the set of address bits <NUM> identifies, for each primitive, an address (also referred to as an "embedded address") corresponding to a nozzle to be fired (i.e., to fire the unique primitive data and eject fluid). In one example, the set of address bits <NUM> may be omitted from the control data packet <NUM>; in this case, the address bits <NUM> may be generated by an address generator of the fluid ejection array controller <NUM>.

In one example, the set of fire data bits <NUM> includes one nozzle's worth of data (e.g., unique primitive data) for each primitive on the fluid ejection device <NUM>. The data included in the set of fire data bits <NUM> determines whether the nozzle that is identified by the set of address bits within a particular primitive should fire. For instance, the fire data bits <NUM> may include a non-null value (e.g., "<NUM>") to indicate that a nozzle of a primitive should fire. The data included in the set of fire data bits <NUM> may be different for each primitive.

In one example, the footer <NUM> comprises bits that are used by the fluid ejection array controller <NUM> to detect the end of the control data packet <NUM>. Thus, the footer <NUM> may include some predefined sequence of bits that indicates the end of a control data packet.

Once the control data packet <NUM> is loaded into the fluid ejection array controller <NUM>, the information bits of data and address are then present at each primitive. It is at this time a fire signal is sent to all primitives (propagated from first to last primitive). This fire signal then generates nozzle control bits, which include a combination of primitive data, address information, and a FIRE signal local to that primitive. The nozzle control bits are then sent to the primitive groups on the fluid ejection device <NUM>, and the primitive groups will fire the nozzles addressed by the nozzle control bits. To fire all of the nozzles on the fluid ejection device <NUM> in one fire pulse group, a virtual primitive control packet <NUM> would thus be loaded for every address value.

<FIG> is a block diagram illustrating a fluid ejection array controller interface <NUM> according to one example. The interface <NUM> shown in <FIG> is one example implementation of the interface <NUM> shown in <FIG>. The interface <NUM> includes DCLK input <NUM>, DATA_x input <NUM>, clock signal generator <NUM>, clock recovery logic <NUM>, trainable gating counters <NUM>, AND gates <NUM> and <NUM>, DCLKout output <NUM>, and DATAXout output <NUM>. The clock signal generator <NUM> may be a phase locked loop or a digitally controlled oscillator. As described in further detail below, data signals and clock signals received by interface <NUM> are immediately re-driven in real time with minimal latency to the receiving fluid ejection device, with random bits removed. <FIG> is described in further detail below with additional reference to <FIG>.

<FIG> is a timing diagram illustrating the timing for signals of the fluid ejection array controller interface <NUM> shown in <FIG> according to one example. <FIG> shows five control data packets <NUM>(<NUM>)-<NUM>(<NUM>) (collectively referred to herein as control data packets <NUM>). In one example, the control data packets <NUM> are "fire pulse group" (or "FPG") packets or data bursts containing data about which nozzles of the fluid ejection device should fire. Each of the control data packets <NUM> includes real packet data (e.g., real packet data <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)) and random data (e.g., random data <NUM>(<NUM>) and <NUM>(<NUM>)).

<FIG> also shows signals <NUM>, <NUM>, <NUM>, and <NUM>. DATA_x signal <NUM> represents control data packets <NUM> received by the interface <NUM> via input <NUM> and provided in a serial manner to an input of the AND gate <NUM>. DCLK signal <NUM> represents an input clock signal received by the interface <NUM> via input <NUM> and provided to the clock recovery logic <NUM>. DCLKfree_running signal <NUM> is a free-running clock signal generated by the clock recovery logic <NUM> based on the DCLK signal <NUM> and a clock signal provided by the clock signal generator <NUM>. The clock recovery logic <NUM> outputs the DCLKfree_running signal <NUM> to the trainable gating counters <NUM> and to an input of the AND gate <NUM>. DCLKout signal <NUM> is an output clock signal that is output from AND gate <NUM> to output <NUM>. AND gate <NUM> outputs a DATA_xout signal, which represents the real packet data (e.g., real packet data <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)), to output <NUM>. The real packet data for each control data packet that is output by AND gate <NUM> may also be referred to herein as a modified control data packet.

In one example, inputs <NUM> and <NUM> are connected to a print engine controller (e.g., print engine controller <NUM>), and outputs <NUM> and <NUM> are connected to a fluid ejection array controller (e.g., fluid ejection array controller <NUM>). In operation according to one example, clock recovery logic <NUM> receives a burst-mode input DCLK signal <NUM> via input <NUM> and a clock signal provided by the clock signal generator <NUM>. Based on these received clock signals, clock recovery logic <NUM> recovers an internal free-running clock signal, DCLKfree_running signal <NUM>, from the DCLK signal <NUM> using a clock recovery method. In one example, the DCLKfree_running signal <NUM> is a phase-locked and continuous clock signal. The clock recovery method may be a phase locked loop method, an oversampling method, or another clock recovery method. The clock recovery logic <NUM> outputs the DCLKfree_running signal <NUM> to the trainable gating counters <NUM> and to an input of the AND gate <NUM>.

The trainable gating counters <NUM> include counter logic to determine the locations of the random bits of the random data (e.g., random data <NUM>(<NUM>) and <NUM>(<NUM>)) within the control data packets <NUM> based on the received DCLKfree_running signal <NUM>. The real packet data (e.g., real packet data <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)) has a fixed burst period. Because the idle period (TIDLE) between real data bursts (non-inclusive of random data insertion) has a fixed period (i.e., a fixed number of DCLKfree_running cycles), the gating counters <NUM> can be used to count a fixed number of DCLKfree_running cycles (equal to the idle period) and remove/mask these DCLKfree_running cycles from the output clock (DCLKout) during the idle period. During time periods corresponding to the real packet data (e.g., real packet data <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)), gating counters <NUM> output a DCLK_enable signal having a logical high value via communication link <NUM> to an input of the AND gate <NUM>. This enables the AND gate <NUM> to output a DCLKout signal <NUM> that corresponds to the DCLKfree_running signal <NUM> at the input of the AND gate <NUM>. During time periods corresponding to the random data (e.g., random data <NUM>(<NUM>) and <NUM>(<NUM>)), gating counters <NUM> change the DCLK_enable signal to a logical low value, which causes the AND gate <NUM> to mask the received DCLKfree_running signal <NUM>.

During time periods corresponding to the real packet data (e.g., real packet data <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)), gating counters <NUM> output a DATA_x_enable signal having a logical high value via communication link <NUM> to an input of the AND gate <NUM>. This enables the AND gate <NUM> to output a DATAXout signal that corresponds to the DATA_x signal <NUM> at the input of the AND gate <NUM>, and the real packet data is serially driven by the AND gate <NUM> to the fluid ejection device (e.g., fluid ejection device <NUM>) via output <NUM>. During time periods corresponding to the random data (e.g., random data <NUM>(<NUM>) and <NUM>(<NUM>)), gating counters <NUM> change the DATA_x_enable signal to a logical low value, which causes the AND gate <NUM> to mask the received DATA_x signal <NUM>, thereby blocking the random data. Multiple DATA lanes may also be masked in the manner described above.

The gating counters <NUM> use a counter target value corresponding to the idle period. The counter target value may be fixed within the gating counters <NUM>, or the gating counters <NUM> may be adaptive/trainable to determine the idle period and use a corresponding counter target value. Since the real packet data (e.g., real packet data <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>)) has a fixed period (i.e., a fixed number of DCLKfree_running cycles), the gating counters <NUM> can determine the idle period based on the length of the real packet data and the position of the end of the data burst.

One example of the present disclosure is directed to a fluid ejection controller interface. <FIG> is a block diagram illustrating an example of a fluid ejection controller interface <NUM>. The fluid ejection controller interface <NUM> may include clock recovery logic <NUM> to receive a burst mode input clock signal <NUM> and generate a free-running clock signal <NUM>. The interface <NUM> includes output logic <NUM> to receive control data packets <NUM>. Each control data packet <NUM> includes a set of primitive data bits and a set of random bits. The interface <NUM> includes counter logic <NUM> to cause the output logic <NUM> to output modified control data packets <NUM> to a fluid ejection controller <NUM> of a fluid ejection device <NUM>. In other examples, the interface <NUM> may include more or fewer elements, such as the clock recovery logic <NUM> not being included in the interface <NUM>.

The counter logic <NUM> may identify positions of the random bits in the received control data packets based on the free-running clock signal. The set of random bits for each control data packet <NUM> may have a pseudo-random length. Values for the set of random bits for each control data packet <NUM> may have pseudo-random number values. The counter logic <NUM> may count clock cycles of the free-running clock signal <NUM> to identify the positions of the random bits. The output logic <NUM> may include a logic component to receive the free-running clock signal <NUM> and output an output clock signal to the fluid ejection controller <NUM>. The counter logic <NUM> may cause the logic component to mask the free-running clock signal <NUM> during periods corresponding to the set of random bits for each control data packet <NUM>. The output logic <NUM> may include a logic component to receive the control data packets <NUM> and output the modified control data packets <NUM>, and the counter logic <NUM> may cause the logic component to mask the received control data packets <NUM> during periods corresponding to the set of random bits for each received control data packet <NUM>. The fluid ejection controller interface <NUM> may be implemented separate from the fluid ejection device <NUM>. The fluid ejection controller interface <NUM> may be integrated into the fluid ejection device <NUM>. The fluid ejection controller interface <NUM> may reside on a common semiconductor die with the fluid ejection controller <NUM>.

The output logic <NUM> includes modification logic to modify positions and/or values of bits in the received control data packets <NUM> to facilitate the creation of the modified control data packets <NUM>, and the modified control data packets <NUM> may or may not include the set of random bits.

Another example of the present disclosure is directed to a method of processing control data packets. <FIG> is a flow diagram illustrating a method <NUM> of processing control data packets according to one example. At <NUM>, the method <NUM> includes generating, by clock recovery logic, a free-running clock signal based on a received burst mode input clock signal. At <NUM>, the method <NUM> includes receiving, by output logic, control data packets, each control data packet including a set of primitive data bits and a set of random bits. At <NUM>, the method <NUM> may include identifying, by counter logic, positions of the random bits in the received control data packets based on the free-running clock signal. At <NUM>, the method <NUM> includes outputting, by output logic, modified control data packets to a fluid ejection controller of a fluid ejection device. In other examples, the method <NUM> may include more or fewer steps, such as the identifying at <NUM> not being included in the method <NUM>.

The set of random bits for each control data packet in method <NUM> may have a pseudo-random length, and the values for the set of random bits for each control data packet may be pseudo-random number values. The method <NUM> may further include receiving, by the output logic, the free-running clock signal; and controlling the output logic, by the counter logic, to generate an output clock signal by masking the free-running clock signal during periods corresponding to the set of random bits for each control data packet. The method <NUM> may further include removing, by the output logic, the random bits from the received control data packets based on the identified positions of the random bits to create the modified control data packets.

Yet another example of the present disclosure is directed to an apparatus, which includes clock recovery logic to recover a free-running clock signal from a received burst mode input clock signal. The apparatus includes a first output logic component to receive control data packets. Each control data packet includes a set of primitive data bits and a set of random bits. The apparatus includes a second output logic component to receive the free-running clock signal. The apparatus includes counter logic to cause the first output logic component to output modified control data packets to a fluid ejection controller of a fluid ejection device, and to cause the second output logic component to output an output clock signal to the fluid ejection controller.

The counter logic may identify positions of the random bits in the received control data packets based on the free-running clock signal. The counter logic may count clock cycles of the free-running clock signal to identify the positions of the random bits. The counter logic may cause the first output logic component to mask the received control data packets based on the identified positions, and cause the second output logic component to mask the free-running clock signal based on the identified positions.

Aspects of the present disclosure can be implemented by machine readable instructions and/or in a combination of machine readable instructions and hardware, e.g., using application specific integrated circuits (ASIC), a programmable logic array (PLA), including a field-programmable gate array (FPGA), or a state machine deployed on a hardware device, a general purpose computer or any other hardware equivalents, e.g., computer readable instructions pertaining to the method(s) discussed herein can be used to configure a hardware processor to perform the blocks, functions and/or operations of the disclosed methods.

Furthermore, when a hardware processor executes instructions to perform "operations", this could include the hardware processor performing the operations directly and/or facilitating, directing, or cooperating with another hardware device or component, e.g., a co-processor and the like, to perform the operations. The processor executing the machine readable instructions relating to method(s) described herein can be perceived as a programmed processor or a specialized processor. As such, modules for controlling devices disclosed herein, including associated data structures, of the present disclosure can be stored on a tangible or physical (broadly non-transitory) computer-readable storage device or medium, e.g., volatile memory, non-volatile memory, ROM memory, RAM memory, magnetic or optical drive, device or diskette and the like. More specifically, the computer-readable storage device may comprise any physical devices that provide the ability to store information such as data and/or instructions to be accessed by a processor or a computing device such as a computer or an application server.

Claim 1:
A fluid ejection controller interface (<NUM>), comprising:
output logic (<NUM>) configured to receive control data packets (<NUM>, <NUM>, <NUM>, <NUM>); and
counter logic (<NUM>) configured to cause the output logic (<NUM>) to output modified control data packets (<NUM>, <NUM>) ;
characterised in that each of the received control data packets (<NUM>, <NUM>, <NUM>, <NUM>) includes a set of primitive data bits and a set of random bits, and the output logic (<NUM>) includes modification logic to modify positions and/or values of bits in received control data packets (<NUM>, <NUM>, <NUM>, <NUM>) to facilitate creation of the modified control data packets (<NUM>, <NUM>).