Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
FLUIDIC DIE ACTUATION DATA AND CONFIGURATION DATA ON AN ACTUATION DATA CHANNEL
Document Type and Number:
WIPO Patent Application WO/2021/216062
Kind Code:
A1
Abstract:
Examples of a fluidic die are described. Some examples of the fluidic die may include actuation logic that selectively enables fluidic actuators of the fluidic die based on actuation data received on an actuation data channel. The fluidic die may also include configuration registers that include memory cells to store operational parameters for the fluidic die based on configuration data. The fluidic die may also include monitoring logic connected between the actuation data channel and the actuation logic. The monitoring logic may determine whether a data packet received on the actuation data channel includes actuation data or configuration data and may transmit the data packet to the actuation logic or the configuration registers accordingly.

Inventors:
ANDERSON DARYL EUGENE (US)
MARTIN ERIC THOMAS (US)
Application Number:
PCT/US2020/029323
Publication Date:
October 28, 2021
Filing Date:
April 22, 2020
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
HEWLETT PACKARD DEVELOPMENT CO (US)
International Classes:
B41J2/14; B41J2/175; B41J29/38
Foreign References:
US20010013948A12001-08-16
US6246486B12001-06-12
US5165014A1992-11-17
Attorney, Agent or Firm:
HOOPES, Benjamin et al. (US)
Download PDF:
Claims:
CLAIMS

1. A fluidic die, comprising: actuation logic that selectively enables fluidic actuators of the fluidic die based on actuation data received on an actuation data channel; configuration registers comprising memory cells to store operational parameters for the fluidic die based on configuration data; and monitoring logic connected between the actuation data channel and the actuation logic, the monitoring logic to determine whether a data packet received on the actuation data channel includes actuation data or configuration data and to transmit the data packet to the actuation logic or the configuration registers accordingly.

2. The fluidic die of claim 1 , wherein the actuation data and the configuration data are transmitted on the actuation data channel.

3. The fluidic die of claim 1 , wherein the monitoring logic is further connected to the configuration registers.

4. The fluidic die of claim 1 , further comprising configuration control logic connected to the configuration registers.

5. The fluidic die of claim 4, wherein the configuration control logic is connected to a two-way configuration data channel.

6. The fluidic die of claim 5, wherein the configuration control logic receives configuration data via the configuration data channel, and the configuration control logic updates the configuration registers based on the received configuration data.

7. The fluidic die of claim 1 , wherein the monitoring logic transmits the data packet to the actuation logic in response to determining that the data packet includes actuation data.

8. The fluidic die of claim 1 , wherein the monitoring logic accesses and stores configuration data in the configuration registers in response to determining that the data packet includes configuration data.

9. A method by a fluidic die, comprising: receiving a data packet on an actuation data channel; determining whether the data packet includes actuation data or configuration data based on a data protocol that indicates whether actuation data or configuration data is present in the data packet; and transmitting the data packet to actuation logic or configuration registers in response to determining whether the data packet includes actuation data or configuration data.

10. The method of claim 9, wherein the data protocol comprises a number of start bits that indicate a start of the data packet.

11. The method of claim 9, wherein the data protocol comprises a descriptor field that indicates whether actuation data or configuration data is present in the data packet.

12. The method of claim 11 , wherein the descriptor field further indicates an amount, format or type of data in the data packet.

13. The method of claim 11 , wherein the data protocol further comprises a data field having a variable length based on actuation data or configuration data present in the data field.

14. A printing device, comprising: a print controller to send a data packet on a high-speed actuation data channel, the data packet comprising a data protocol that indicates whether actuation data or configuration data is present in the data packet; and a fluidic die to transmit the data packet received on the high-speed actuation data channel to actuation logic or configuration registers based on whether the data protocol indicates actuation data or configuration data is present in the data packet.

15. The printing device of claim 14, wherein the print controller uses a low- speed configuration data channel to read the configuration data transmitted to the configuration registers.

Description:
FLUIDIC DIE ACTUATION DATA AND CONFIGURATION DATA ON AN

ACTUATION DATA CHANNEL

BACKGROUND

[0001] A printing device may eject a print substance on print media. For example, a printing device may deposit a printing fluid, such as ink, on the print media. In some examples, the printing device may include a fluidic die to deposit the print substance on the print media. In other examples, a printing device may be used for bio-medical applications, such as to perform tests on fluids, or additive manufacturing, such as 3D printing.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples will be described below by referring to the following figures.

[0003] FIG. 1 illustrates an example of a printing device having a number of components;

[0004] FIG. 2 illustrates examples of data protocols for an actuation data packet and a configuration data packet;

[0005] FIG. 3 is a block diagram illustrating an example of a fluidic die;

[0006] FIG. 4 is a flow diagram illustrating an example method for transmitting actuation data and configuration data on an actuation data channel; [0007] FIG. 5 is a flow diagram illustrating another example method for transmitting actuation data and configuration data on an actuation data channel; [0008] FIG. 6 is a sequence diagram illustrating power supply leakage testing using configuration data transmitted on the actuation data channel; [0009] FIG. 7 is a sequence diagram illustrating a thermal operation using configuration data transmitted on the actuation data channel; and [0010] FIG. 8 is a sequence diagram illustrating an actuator health sensing operation using configuration data transmitted on the actuation data channel. [0011] Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the example shown. Moreover, the drawings provide examples and/or implementations in accordance with the description; however, the description is not limited to the examples and/or implementations provided in the drawings.

DETAILED DESCRIPTION

[0012] Printing devices may deposit a print substance (referred to herein as printing fluid) on print media. In some examples, the printing device may include a fluid ejection device that deposits printing fluid. A printing device may include a fluidic die (also referred to as a printhead die) that includes fluidic actuators (also referred to as nozzles) to transport printing fluid. A printing device may also include a print controller to send data to the fluidic die.

[0013] In some examples, the print substance may include printing agents or colorants. The printing device may apply the print substance to a substrate. A substrate is a superset of print media, such as plain paper, and can include any suitable object or materials to which a print substance from a printing device is applied including materials, such as powdered build materials, for forming three- dimensional articles. In addition, in some examples, a printing device may print on various media such as inanimate objects, skin, books, wood, plastic, metal, concrete, wallpaper, or other materials. Print substances, including printing agents and colorants, can include liquid inks, or other suitable marking material that may or may not be mixed with fusing agents, detailing agents, or other materials and can be applied to the substrate.

[0014] In other examples, the printing device may be used in life-science applications (e.g., lab-on-chip fluidic designs), bio-printing, printed manufacturing features and sensors for additive manufacturing applications. These applications may use a print substance other than ink or toner.

[0015] In some examples, the fluidic die may include advanced complementary metal-oxide-semiconductor (CMOS) features that allow for increased functionality on the fluidic die. For example, advanced on-die sensors may result in more data being conveyed from the fluidic die to the print controller, and more data conveyed from the print controller to the fluidic die that is to be synchronized with actuation data and firing events.

[0016] In other examples, there may be cases where there is limited time available for die shut-down and re-initialization. For example, such cases may include between-swath servicing, between-page servicing and/or during leakage tests. To address these cases, rapid initialization of on-die configuration registers is described.

[0017] In some approaches, a fluidic die may utilize simple, fixed protocols for data communication. In these approaches, the data protocols may have a fixed number of header bits for configuration, followed by a fixed actuation data packet. Furthermore, in some approaches, on-die configuration registers may be readable and writeable via a low-frequency configuration data channel. Additionally, there are some cases (e.g., actuator health sensing) where configuration bits are to be synchronized with actuation data packets and correlated fire events. In these approaches, a hard-wired nozzle data protocol is used that includes configuration bits for actuator health sensing on every packet, whether actuator health sensing is being executed or not.

[0018] Examples of a fluidic die and data protocol are described that provide for greater flexibility over these approaches. These examples provide for an actuation data channel to communicate either actuation data to the actuation logic, or configuration data to the configuration registers, based on information contained in the data stream. As used herein, a data stream includes data packets transmitted to the fluidic die on the actuation data channel. The described data protocol allows for a flexible configuration of fluidic dies and can be used by a variety of fluidic dies. As used herein, a data packet is a formatted unit of data. A data packet may include a payload and control information. [0019] FIG. 1 illustrates an example of a printing device 102 having a number of components. The printing device 102 may include a print controller 104 and a fluidic die 106. Examples of printing devices 102 include printers, copiers, fax machines, multifunction devices including additional scanning, copying, and finishing functions, all-in-one devices, pad printers to print images on three dimensional objects, and three-dimensional printers (additive manufacturing devices).

[0020] Printing device 102 refers to a combination of hardware through which fluids and/or electric signals may propagate and instructions to implement printing operations. The electric signals may include data packets 110. The fluids may include marking fluids, such as inks, and biological fluids, such as blood, by way of example. In one example case, the fluidic die 106 may be capable of delivering printing fluids to fluidic actuators for ejection onto a substrate or build material. In some examples, the printing device 102 may include a number of fluidic dies 106, which may operate in concert to form objects, text, and/or images on a target material.

[0021] In another implementation, the printing device 102 may be used for diagnostic tests on biological fluids. For instance, the fluidic die 106 may comprise a diagnostic test device into which fluids, such as blood, may be introduced for testing. In this case, the fluidic die 106 may refer to a replaceable component, such as after each test, to enable successive tests with reduced amounts of waste and/or cost.

[0022] In yet another implementation, the printing device 102 may be a 3D printing device. In this case, the fluidic die 106 may refer to a component to be used in a 3D printing device. For example, the fluidic die 106 may deliver fusing and/or detailing agents for forming 3D objects.

[0023] As used herein, the fluidic die 106 refers to a die in the context of integrated circuits, which includes a number of structural features and components to form functional circuitry and fluidic elements. For instance, in one implementation, a substrate such as silicon may be used as a base upon which structural features, such as integrated circuit elements (e.g., resistors, capacitors, transistors, etc.) may be formed through processes such as photolithographic processes and other like build-up or machining processes. The fluidic die 106 includes a number of fluidic channels and wire traces, which are used for the propagation of fluids and electric signals, respectively. The fluidic channels and wire traces may also be formed through processes such as photolithographic process and other like build-up or machining processes.

[0024] In some examples, the print controller 104 may send data packets 110 on a high-speed actuation data channel 108. The data packets 110 may be received at the fluidic die 106 on an actuation data channel 108. In some examples, the actuation data channel 108 may be a communication link to communicate the actuation data 110 from the print controller 104 to the fluidic die 106. In some examples, the actuation data channel 108 may be implemented as a single conductive component (e.g., metallic, metalloid, conductive non-metals, etc.) or a number of electrically conductive components (e.g., as a bus) through which the data packets 110 are transmitted.

[0025] The print controller 104 may include a combination of hardware and executable instructions, such as instructions to actuate fluidic actuators 116. For instance, the print controller 104 may include a number of integrated circuits (ICs) to execute instructions. Examples of the print controller 104 may include, for instance, field-programmable gate arrays (FPGAs), general purpose processing units, application-specific integrated circuits (ASICs), and the like, without limitation.

[0026] The data packets 110 sent on the actuation data channel 108 may include actuation data or configuration data. In other words, the actuation data and the configuration data may both be transmitted on the actuation data channel. As used herein, actuation data is data that is transmitted to the fluidic die 106 for use in actuating fluidic actuators 116. The actuation data may also be referred to as print data. In some examples, the actuation data may apply to a single actuation instance (also referred to as a firing event) where a number of fluidic actuators are activated (e.g., fired) to eject or move a fluid.

[0027] In some examples, a fluidic actuator 116 may be an ejecting actuator in a chamber with an orifice or a nozzle. In other examples, a fluidic actuator 116 may be a non-ejecting actuator in a chamber or micro-fluidic channel that forms a microfluidic pump.

[0028] As used herein, configuration data is data that is stored in configuration registers 118 of the fluidic die 106. For example, the configuration registers 118 may include memory cells 120 to store operational parameters for the fluidic die 106. The configuration data may include the operational parameters that are stored in the memory cells 120. Some examples, of configuration data include firing energy values for the fluidic actuators 116, temperature control values, temperature setpoints for on-die components, sensor settings, actuator health sensing configuration information, thermal measurement (e.g., fine-grain thermal (FGT)) configuration information, etc. [0029] The configuration data may be persistent as compared with actuation data. For example, the actuation data may apply to a single actuation instance, at which point the actuation data may no longer be stored by the fluidic die 106. The configuration data, by contrast, may be stored in the configuration registers 118 and may persist over multiple actuation instances (e.g., multiple firing events).

[0030] In some examples, the actuation data channel 108 may be a high speed channel for communicating data packets 110 at a high rate of speed. This may be contrasted with a configuration data channel (not shown) for communicating configuration data (e.g., firing energy values, temperature control values, setpoints, sensor settings) to the fluidic die 106. In some examples, the configuration data channel may communicate data at a lower rate of speed (e.g., lower frequency) than the actuation data channel 108. In other examples, the configuration data channel may communicate data at a speed that is equal to or greater than the actuation data channel 108.

[0031] The data packets 110 sent by the print controller 104 may include a data protocol that indicates whether actuation data or configuration data is present in the data packets 110. Because actuation data and configuration data may be sent on the actuation data channel 108, the data protocol may be used to enable the fluidic die 106 to differentiate between the data types (e.g., actuation data or configuration data) included in the data packet 110. Examples of the data protocol are described in FIG. 2.

[0032] In some examples, the data protocol may include a number of start bits that indicate a start of the data packet 110. For example, an encoding of the start bits may indicate that information follows on the actuation data channel 108. The start bits may be transmitted at the beginning of the data packet 110 to enable the fluidic die 106 to determine whether a data packet 110 is being transmitted on the actuation data channel 108.

[0033] In some examples, the data protocol may include a descriptor field that indicates whether actuation data or configuration data is present in the data packet 110. For example, the descriptor field may be a number of bits that indicate what type of data (e.g., actuation data or configuration data) is included in the data packet 110. The descriptor field may also indicate an amount of data that is included in the data packet 110.

[0034] For actuation data, the descriptor field may specify that actuation data is to follow. In some examples, the descriptor field may also specify which fluidic actuators 116 are the intended targets of the actuation data.

[0035] For configuration data, the descriptor field may specify that configuration data is to follow. In some examples, the descriptor field may also specify the amount of configuration data included in the data packet 110. In some examples, the descriptor field may also specify the format of the configuration data in the data packet 110. For instance, the descriptor field may specify that the format of the configuration data is an address/data pair. In this case, the descriptor field may indicate that N address/data pairs are included in the data packet 110, where A/is the number of address/data pairs, the “address” is an address for the configuration registers 118, and the “data” is the configuration data that is to be stored. The address and the configuration data values may then follow in the data field of the data packet 110.

[0036] In some examples of the data protocol, a data packet 110 for actuation data may include header bits that include actuation data-specific configuration information. In other words, the header bits may include configuration information for the actuation instance associated with the actuation data included in the data packet 110. An example of the actuation data-specific configuration information is actuator health sensing settings.

[0037] In some examples of the data protocol, the data packet 110 may include a data field having a variable length that is based on actuation data or configuration data present in the data field. For example, instead of a fixed data field, the data packets 110 may have a variable length data field. In some examples, the data field may include the actuation data or the configuration data. In one approach, the length of the data field may be specified in the descriptor field. In another approach, the variable length data field may include end bits to signify the end of the data field.

[0038] In some examples of the data protocol, the descriptor field may specify a fluidic die mode that is to follow. Data for the fluidic die mode may be included in the data field of the data packet 110. In an example, the “fluidic die mode” may be whether the fluidic die 106 is in a first mode to receive actuation data on the actuation data channel 108, or a second mode to receive configuration data on the actuation data channel 108.

[0039] The configuration data that is to be stored in the configuration registers 118 on the fluidic die 106 may be transmitted in a data packet 110 on the actuation data channel 108. The actuation data channel 108 may be a high speed channel that is synchronized with the actuation data stream. Writing configuration data using the actuation data channel 108 may be performed as an alternative to register writes using a low-speed configuration data channel. In some examples, the same configuration data may be written to the configuration registers 118 using either the actuation data channel 108 or the configuration data channel. However, using the actuation data channel 108 may be much faster and may occur with respect to the flow of actuation data to the fluidic die 106. It should be noted that configuration registers 118 written by the high speed actuation data channel 108 may also be read by the configuration data channel.

[0040] The fluidic die 106 may include actuation logic 114 that selectively enables fluidic actuators 116 of the fluidic die 106 based on actuation data received on the actuation data channel 108. For example, the actuation data may indicate which fluidic actuators 116 are to be activated during an actuation instance. The actuation logic 114 may select which fluidic actuators 116 to activate based on the actuation data. The actuation logic 114 may include a combination of hardware and executable instructions, such as instructions to selectively activate fluidic actuators 116.

[0041] The fluidic die 106 may also include configuration registers 118. As described above, the configuration registers 118 may include memory cells 120 to store operational parameters for the fluidic die 106 based on configuration data. In some examples, the memory cells 120 may be volatile and/or non volatile memory, such as Dynamic Random Access Memory (DRAM), EEPROM, magnetoresistive random-access memory (MRAM), phase change RAM (PCRAM), memristor, flash memory, and the like. The configuration registers 118 may include register addresses to identify the memory cell(s). [0042] The fluidic die 106 may include monitoring logic 112. In some examples, the monitoring logic 112 may be connected between the actuation data channel 108 and the actuation logic 114. The monitoring logic 112 may also be connected to the configuration registers 118. The monitoring logic 112 may include a combination of hardware and executable instructions, such as instructions to monitor data packets 110 received on the actuation data channel 108.

[0043] The monitoring logic 112 may determine whether a data packet 110 received on the actuation data channel 108 includes actuation data or configuration data. For example, the monitoring logic 112 may read the descriptor field of the data packet 110 to determine whether the data packet 110 includes actuation data or configuration data. In the case that the data protocol uses a descriptor field, the monitoring logic 112 may also read the descriptor field to determine the amount of data that is included in the data packet 110. [0044] The monitoring logic 112 may transmit the data packet 110 to the actuation logic 114 or the configuration registers 118 accordingly. In other words, the monitoring logic 112 may transmit the data packet 110 to the actuation logic 114 or the configuration registers 118 based on determining the type of data included in the data packet 110. [0045] The monitoring logic 112 may transmit the data packet 110 to the actuation logic 114 in response to determining that the data packet 110 includes actuation data. In this case, the actuation logic 114 may process the actuation data for selecting fluidic actuators 116 for an actuation instance.

[0046] The monitoring logic 112 may accesses and store configuration data in the configuration registers 118 in response to determining that the data packet 110 includes configuration data. In this case, the monitoring logic 112 may perform a write operation to save the configuration data to the configuration registers 118. In some examples, the monitoring logic 112 may read the data field of the data packet 110 to determine the address for a given memory cell 120 to store the configuration data.

[0047] As described herein, the high-speed actuation data channel 108 may be used for communicating configuration data to the fluidic die 106. In some examples, this may allow for rapid initialization of configuration registers 118. These examples also provide a flexible data protocol that may be used by a wide variety of fluidic dies 106. Furthermore, the configuration data may be synchronized with actuation data packets and firing events.

[0048] FIG. 2 illustrates examples of data protocols for an actuation data packet 210a and a configuration data packet 210b. Example (a) illustrates a data protocol for an actuation data packet 210a. In this example the actuation data packet 210a is transmitted on the actuation data channel 208a. In this case, start bits 226a may indicate the start of the actuation data packet 210a. For instance, the start bits 226a may be an encoded series of bits that indicate the beginning of the actuation data packet 210a.

[0049] A descriptor field 228a may follow the start bits 226a. The descriptor field 228a may indicate that actuation data 232 is included in the actuation data packet 210a. In this example, the descriptor field 228a has a value of “0x10”, where the Ί” indicates that actuation data 232 follows.

[0050] The data field 222a of the actuation data packet 210a may include a header 230 and the actuation data 232. In some examples, the header 230 may include a number of bits that convey actuation data-specific configuration information. The actuation data 232 may be instructions to implement an actuation instance with a number of fluidic actuators 116.

[0051] Example (b) illustrates a data protocol for a configuration data packet 210b. In this example, the configuration data packet 210b is also transmitted on the actuation data channel 208b. In this case, start bits 226b may indicate the start of the configuration data packet 210b, as described above.

[0052] A descriptor field 228b may follow the start bits 226b. The descriptor field 228b may indicate that configuration data is included in the configuration data packet 210b. In this example, the descriptor field 228b has a value of “0x23”, where the “2” indicates that configuration data follows in the form of register address/data pairs. The “3” indicates how many address/data pairs will follow.

[0053] In this example, the data field 222b of the configuration data packet 210b includes configuration data for three configuration registers. The first configuration data 234a may include an address (e.g., Reg 0x3F) and configuration data for a first configuration register. The second configuration data 234b may include an address (e.g., Reg 0xA8) and configuration data for a second configuration register. The third configuration data 234c may include an address (e.g., Reg 0x25) and configuration data for a third configuration register.

[0054] FIG. 3 is a block diagram illustrating an example of a fluidic die 306. In this example, the fluidic die 306 may include circuits to decode the data protocol for transmitting both actuation data 332 and configuration data 334 on the actuation data channel 308. The fluidic die 306 may transmit a data packet 310 received on the high-speed actuation data channel 308 to actuation logic 314 or configuration registers 318 based on whether the data protocol indicates actuation data 332 or configuration data 334a is present in the data packet 310. [0055] In this example, the fluidic die 306 may include monitoring logic 312 that receives a data packet 310 on the actuation data channel 308. The monitoring logic 312 may be connected between the actuation data channel 308 and actuation logic 314. The monitoring logic 312 may also be connected to configuration registers 318. [0056] The monitoring logic 312 may receive and decode the data packet 310 to determine whether the data packet 310 includes actuation data 332 or configuration data 334a. In some examples, the data packet 310 may be encoded according to the data protocol described in FIGS. 1 and 2. The monitoring logic 312 may transmit the actuation data 332 from the data packet 310 to the actuation logic 314 in response to determining that the data packet 310 includes actuation data 332.

[0057] In the case that the monitoring logic 312 determines that the data packet 310 includes configuration data 334a, the monitoring logic 312 may write the configuration data 334a to the configuration registers 318. The monitoring logic 312 may read the register address(es) 340a for the configuration data 334a from the data packet 310. The monitoring logic 312 may then perform a register write 342a to save the configuration data 334a to the register address(es) 340a of the configuration registers 318.

[0058] The fluidic die 306 may also include configuration control logic 338 connected to the configuration registers 318. The configuration control logic 338 may be connected to a two-way configuration data channel 336. The configuration control logic 338 may communicate (e.g., transmit and/or receive) configuration data 334b from a print controller via the configuration data channel 336. For example, the configuration control logic 338 may receive configuration data 334b via the configuration data channel 336. The configuration control logic 338 may update the configuration registers 318 based on the received configuration data 334b. In an example, the configuration control logic 338 may perform a register write 342b to save the configuration data 334b to the register address(es) 340b of the configuration registers 318.

[0059] The configuration control logic 338 may also read configuration data 334b stored in the configuration registers 318. For example, the configuration control logic 338 may perform a register read 344 to read the configuration data 334b from the register address(es) 340b of the configuration registers 318. [0060] It should be noted that configuration data 334a written at high speed to the configuration registers 318 via the actuation data channel 308 may be read back via the configuration data channel 336 at low speed. The configuration control logic 338 may retrieve and send the configuration data 334b to a print controller. For example, the print controller may use a low-speed configuration data channel 336 to read the configuration data 334a transmitted to the configuration registers 318. Therefore, the print controller may read configuration data 334a transmitted on the high-speed actuation data channel 308 to the configuration registers 318 using the low-speed configuration data channel 336.

[0061] FIG. 4 is a flow diagram illustrating an example method 400 for transmitting actuation data and configuration data on an actuation data channel 108. The method 400 may be implemented by a fluidic die 106.

[0062] The fluidic die 106 may receive 402 a data packet 110 on an actuation data channel 108. The data packet 110 may include either actuation data for actuation logic 114 or configuration data for configuration registers 118. In some examples, the fluidic die 106 may receive 402 the data packet 110 from a print controller 104 that sends the data packet 110 on a high-speed actuation data channel 108.

[0063] The fluidic die 106 may determine 404 whether the data packet 110 includes actuation data or configuration data based on a data protocol that indicates whether actuation data or configuration data is present in the data packet 110. In some examples, the data protocol may include a number of start bits that indicate a start of the data packet 110. The data protocol may also include a descriptor field that indicates whether actuation data or configuration data is present in the data packet 110. The descriptor field may further indicate an amount, format and/or type of data in the data packet 110. The data protocol may also include a data field having a variable length based on actuation data or configuration data present in the data field.

[0064] In some examples, the fluidic die 106 may decode the descriptor field to determine 404 whether the data packet 110 includes actuation data or configuration data. For example, a first encoding of the descriptor field may indicate the presence of actuation data and a second encoding of the descriptor field may indicate the presence of configuration data. [0065] The fluidic die 106 may transmit 406 the data packet 110 to the actuation logic 114 or the configuration registers 118 in response to determining whether the data packet 110 includes actuation data or configuration data. For example, the fluidic die 106 may transmit 406 the data packet 110 to the actuation logic 114 in response to determining that the data packet 110 includes actuation data. The fluidic die 106 may access and store configuration data in the configuration registers 118 in response to determining that the data packet 110 includes configuration data.

[0066] FIG. 5 is a flow diagram illustrating another example method 500 for transmitting actuation data and configuration data on an actuation data channel 108. The fluidic die 106 may monitor 502 the actuation data channel 108. For example, the fluidic die 106 may detect changes in voltage states on the actuation data channel 108.

[0067] The fluidic die 106 may determine 504 whether start bits are detected. For example, a series of bits (e.g., changes in voltage) on the actuation data channel 108 may indicate that a data packet 110 is beginning. If the fluidic die 106 does not detect the start bits, the fluidic die 106 may continue to monitor 502 the actuation data channel 108.

[0068] If the fluidic die 106 determines 504 that start bits are detected, then the fluidic die 106 may detect and decode 506 the descriptor field of the data packet 110. In some examples, the descriptor field may be encoded as described in FIG. 2.

[0069] The fluidic die 106 may determine 508 whether the descriptor field specifies that actuation data is included in the data packet 110. For example, a first encoding of the descriptor field may indicate the presence of actuation data and a second encoding of the descriptor field may indicate the presence of configuration data. If the descriptor field specifies that actuation data is included in the data packet 110, then the fluidic die 106 may detect 510 a fixed amount of actuation data. The fluidic die 106 may direct 512 (e.g., send) the actuation data to actuation logic 114. The fluidic die 106 may then continue to monitor 502 the actuation data channel 108 for an additional data packet 110. [0070] If the fluidic die 106 determines 508 that the descriptor field does not specify that actuation data is included in the data packet 110, then the fluidic die 106 may detect 514 a specified amount of configuration data in the data packet 110. For example, the fluidic die 106 may read the descriptor field to determine the amount of configuration data present in the data packet 110. The fluidic die 106 may read the configuration data from the data packet 110. The fluidic die 106 may store 516 the configuration data in the configuration registers 118. The fluidic die 106 may then continue to monitor 502 the actuation data channel 108 for an additional data packet 110.

[0071] FIG. 6 is a sequence diagram illustrating power supply leakage testing using configuration data transmitted on the actuation data channel. In some examples, power supply leakage testing may be performed in a printing device. For instance, a power supply leakage test may be performed between print jobs, print swaths and/or printed pages. After performing the power supply leakage test, configuration data may be re-initialized. There may be a limited amount of time (e.g., tens of milliseconds) to perform this test. The example described in FIG. 6 enables a quick re-initialization of the fluidic die 606.

[0072] The print controller 604 may initiate 601 a power supply leakage test. For example, the print controller 604 may initiate 601 a power supply leakage test between swaths/pages/jobs. The print controller 604 may perform a leakage test on power supplies. For example, on a logic supply VDD, the power supply in the printing device may be disconnected from the fluidic die 606. The VDD voltage of the fluidic die 606 (which is maintained through capacitance) may be monitored to measure the droop rate. A high droop rate is indicative of the presence of a leakage path. Depending on how low the VDD supply droops, memory elements on the die (e.g., configuration registers, state machine registers, etc.) may lose their state. A die reset may be triggered to restore the state of the memory elements.

[0073] The print controller 604 may send 603 a die reset command to the fluidic die 606. The die reset command may clear the configuration registers. [0074] The print controller 604 may send 605 data packets with configuration data on the actuation data channel. For example, the print controller 604 may send data packets with a descriptor field indicating that the data packets contain configuration data, not actuation data.

[0075] The fluidic die 606 may detect 607 that the data packets include configuration data. The fluidic die 606 may parse the data packets to determine 609 the register addresses and configuration data included in the data packets. The fluidic die 606 may save 611 (e.g., populate) the configuration data to the configuration registers. Upon populating the configuration registers with the configuration data, the fluidic die 606 may send 613 a re-initialization complete signal to the print controller 604. The print controller 604 may resume printing 615.

[0076] FIG. 7 is a sequence diagram illustrating a thermal measurement operation using configuration data transmitted on the actuation data channel. With increased data rates in advanced CMOS, high speed data may be loaded to memory much faster than fluidic actuators can fire. In this case, actuation data packets can be interspersed with thermal measurement (e.g., fine-grain thermal (FGT)) calibration data and measurement execution requests. One aspect of thermal measurement is the use of multiple well-calibrated sensors on the fluidic die 706.

[0077] The print controller 704 may send 701 an actuation data packet on the actuation data channel. The fluidic die 706 may perform 703 an actuation operation using the actuation data packet.

[0078] The print controller 704 may send 705 a configuration data packet for a selected thermal measurement sensor on the actuation data channel. The print controller 704 may also send 705 a command to perform a thermal measurement.

[0079] The fluidic die 706 may load 707 the on-die calibration register with the calibration data and executes 709 the thermal measurement. The fluidic die 706 may make warming control and/or firing energy control decisions based on the thermal measurement. In some examples, the thermal measurement results can be sent 711 to the print controller 704 on the configuration data channel. [0080] In some examples, the configuration data packet may load calibration values for N thermal measurement sensors at a time. For instance, the fluidic die 706 may have 100 thermal measurement sensors, but memory space to store 10 calibration data words at a time. In this case, the print controller 704 may load 10 calibration data words in a single calibration data packet, along with the command to measure those 10 thermal measurement sensors.

[0081] FIG. 8 is a sequence diagram illustrating an actuator health sensing operation using configuration data transmitted on the actuation data channel. In some examples, actuator data packets can be interspersed with actuator health sensing calibration, measurement control and execution requests. As with the thermal measurement operation described in FIG. 7, one aspect of actuator health sensing is the use of multiple well-calibrated sensors on the fluidic die 706.

[0082] The print controller 804 may send 801 an actuation data packet on the actuation data channel. The fluidic die 806 may perform 803 an actuation operation using the actuation data packet.

[0083] The print controller 804 may send 805 a configuration data packet for actuator health sensing measurement on the actuation data channel. The configuration data packet may include calibration data for actuator health sensing measurement control (e.g., sense current magnitude, integration sample width, sample delay, thresholds for transforming raw actuator health sensing data in the good/bad fluidic actuator data, where the thresholds may vary by fluidic actuator).

[0084] The fluidic die 806 may load 807 the on-die calibration register with the calibration data and executes 809 the actuator health sensing measurement. The fluidic die 806 may assess the actuator health sensing measurements and store good/bad fluidic actuator data.

[0085] In some examples, the actuator health sensing results can be sent 811 to the print controller 804 on the configuration data channel. Reading out actuator health sensing results (e.g., good/bad fluidic actuator data) may use lower data rates than transmitting raw actuator health sensing data.

[0086] It should be noted that while various examples of systems and methods are described herein, the disclosure should not be limited to the examples. Variations of the examples described herein may be implemented within the scope of the disclosure. For example, functions, aspects, or elements of the examples described herein may be omitted or combined.