Data acquisition storage method and system, organic light emitting diode inkjet printing equipment and storage medium

Abstract

The application relates to the technical field of distributed data processing, in particular to a data collection and storage method and system, an organic light-emitting diode inkjet printing equipment and a storage medium. The method comprises the following steps: a collection client obtains a collection task of the organic light-emitting diode inkjet printing equipment; based on a preset data type classification rule, the collection task is split into multiple independent subtasks, wherein the number of the independent subtasks is adapted to the number of the collection clients; each collection client collects original data of the organic light-emitting diode inkjet printing equipment in parallel according to each independent subtask, and sends the original data to a master node of a distributed cache cluster; each master node receives original data of a corresponding type, divides a storage partition according to a type corresponding to the preset data type classification rule, and directly writes the original data into a local memory to complete real-time storage, so that the data storage delay of the organic light-emitting diode inkjet printing equipment multi-type data collection is low.

Description

Technical Field

[0001] This application relates to the field of distributed data processing technology, and in particular to a data acquisition and storage method, system, organic light-emitting diode inkjet printing equipment, and storage medium. Background Technology

[0002] As industrial manufacturing upgrades towards higher precision and higher capacity, high-frequency and large-volume data acquisition scenarios are becoming increasingly common in various industrial equipment. These scenarios place stringent requirements on the real-time performance and stability of data storage systems—ensuring that data is not lost while minimizing storage latency to support the generation and execution of real-time control commands for the equipment.

[0003] Organic light-emitting diode (OLED) inkjet printing equipment is a typical example of this type of application. Its display technology is rapidly evolving towards higher resolution, larger size, and higher throughput. The amount of data collected is experiencing a "massive explosive growth." It is necessary to simultaneously collect multiple types of data, such as real-time sensor data, operation logs, and printhead debugging data, with a collection frequency of up to 20Hz and more than 200 collection points.

[0004] Currently, the industry's common approach to handling this type of high-frequency, large-volume data is to develop an API (Application Programming Interface) to collect data from the sub-device PLC (Programmable Logic Controller), store multiple data entries in a buffer, and then transmit them in batches to the storage system. While this method reduces the burden on network and database operations, it has two major drawbacks: First, it lacks classification and processing logic for the diverse data types in OLED inkjet printing equipment, making it prone to transmission conflicts when different types of data are transmitted together. Second, the batch transmission + disk storage mode is prone to data write latency (often exceeding 500ms), and this equipment is extremely sensitive to latency. A latency exceeding 500ms will prevent the control system from obtaining the actual working status of the printhead, forcing it to generate control commands based on lagging data. This directly causes the printhead positioning deviation to exceed the allowable range of ±2μm, leading to irreversible defects such as dead pixels, color differences, and uneven brightness. Ultimately, this results in the scrapping of the entire batch of products, causing waste of core raw materials, production time occupation, and other additional costs, severely weakening the company's production efficiency and market competitiveness.

[0005] Therefore, there is an urgent need for a technical solution that adapts to the diverse data acquisition needs of organic light-emitting diode inkjet printing equipment and can reduce storage latency. Summary of the Invention

[0006] The main objective of this application is to provide a data acquisition and storage method, system, organic light-emitting diode inkjet printing equipment, and storage medium, aiming to reduce data storage latency in various data acquisition scenarios of organic light-emitting diode inkjet printing equipment.

[0007] To achieve the above objectives, this application provides a data acquisition and storage method applied to a data acquisition and storage system of an organic light-emitting diode inkjet printing equipment. The data acquisition and storage system includes a data acquisition client cluster and a distributed cache cluster. The distributed cache cluster includes at least three master nodes, and the data acquisition client cluster includes at least three data acquisition clients. The data acquisition and storage method includes:

[0008] The acquisition client obtains the acquisition task from the organic light-emitting diode inkjet printing equipment. Based on the preset data type classification rules of the organic light-emitting diode inkjet printing equipment, the acquisition task is divided into multiple independent sub-tasks. The number of independent sub-tasks is adapted to the number of acquisition clients.

[0009] Each acquisition client collects raw data from the organic light-emitting diode inkjet printing equipment in parallel according to its own independent sub-task, and sends the raw data to the master node of the distributed cache cluster.

[0010] Each master node receives raw data of the corresponding type, divides the storage into partitions according to the type corresponding to the preset data type classification rules, and writes the raw data directly into local memory to complete real-time storage.

[0011] In addition, to achieve the above objectives, this application provides a data acquisition and storage system, which is a data acquisition and storage system for organic light-emitting diode inkjet printing equipment. The data acquisition and storage system includes a data acquisition client cluster and a distributed cache cluster. The distributed cache cluster includes at least three master nodes, and the data acquisition client cluster includes at least three data acquisition clients.

[0012] The acquisition client is used to acquire acquisition tasks from organic light-emitting diode inkjet printing equipment. Based on the preset data type classification rules of organic light-emitting diode inkjet printing equipment, the acquisition task is divided into multiple independent sub-tasks, wherein the number of independent sub-tasks is adapted to the number of acquisition clients.

[0013] Each acquisition client is used to acquire raw data from the organic light-emitting diode inkjet printing equipment in parallel according to each independent subtask, and send the raw data to the master node of the distributed cache cluster.

[0014] Each master node is used to receive raw data of the corresponding type, divide the storage partitions according to the type corresponding to the preset data type classification rules, and write the raw data directly into local memory to complete real-time storage.

[0015] In addition, to achieve the above objectives, this application also provides an organic light-emitting diode inkjet printing apparatus, which includes a memory, a processor, and a data acquisition and storage program stored in the memory and executable on the processor. When the data acquisition and storage program is executed by the processor, it implements the steps of the above-described data acquisition and storage method.

[0016] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, and stores a data acquisition and storage program thereon. When the data acquisition and storage program is executed by a processor, it implements the steps of the above-described data acquisition and storage method.

[0017] This application provides a data acquisition and storage method applied to a data acquisition and storage system for an organic light-emitting diode (OLED) inkjet printing equipment. The system includes a client acquisition cluster and a distributed cache cluster. The distributed cache cluster includes at least three master nodes, and the client acquisition cluster includes at least three clients. The acquisition clients acquire acquisition tasks from the OLED inkjet printing equipment, preventing a single client from overloading and crashing due to excessive tasks, avoiding data backlog and delays caused by acquisition interruptions, and ensuring the continuity of the acquisition process. Based on the preset data type classification rules of the OLED inkjet printing equipment, the acquisition tasks are divided into multiple independent sub-tasks. The number of independent sub-tasks is adapted to the number of acquisition clients, realizing task splitting by data type. This provides a preliminary classification basis for subsequent steps, ensuring smooth data flow throughout the entire process. The system avoids conflicts caused by mixed transmission of multiple data types from the source. Each acquisition client collects raw data from the OLED inkjet printing equipment in parallel according to its own independent sub-task. Parallel acquisition eliminates the need for serial waiting, shortening the total acquisition time for multiple data types and significantly improving acquisition efficiency. This adapts to the high-frequency data generation needs of the equipment. The raw data is then sent to the master node of the distributed cache cluster, preventing collisions between different data types during transmission and reducing additional losses from data verification and retransmission. Each master node receives the corresponding type of raw data and divides the storage into partitions according to the preset data type classification rules. Partitioned storage allows for the structured separation of different data types at the storage level, facilitating subsequent idle-time transfer, data retrieval, and management, reducing storage chaos and time consumption. The raw data is directly written to local memory for real-time storage. Local memory writing eliminates the need for disk I / O waiting, directly breaking through the latency bottleneck of traditional disk storage and providing core support for ultimately reducing overall storage latency. Ultimately, this reduces data storage latency in scenarios involving the acquisition of multiple data types from OLED inkjet printing equipment. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the first embodiment of the data acquisition and storage method of this application;

[0019] Figure 2 This is a flowchart of the Redis cluster fault diagnosis process for the OLED inkjet printing equipment involved in this application;

[0020] Figure 3 This is a flowchart of the Redis cluster fault handling process for the OLED inkjet printing equipment involved in this application;

[0021] Figure 4 This is a diagram showing the equipment deployment and task allocation of the OLED inkjet printing equipment involved in this application;

[0022] Figure 5 This is a diagram illustrating the distributed acquisition and caching data interaction of the OLED inkjet printing device involved in this application;

[0023] Figure 6 This is a diagram of the distributed acquisition and caching hardware architecture involved in this application;

[0024] Figure 7 This is a schematic diagram of the organic light-emitting diode inkjet printing equipment involved in the embodiments of this application.

[0025] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0026] This application provides a data acquisition and storage method, referring to... Figure 1 As shown, Figure 1 This is a flowchart illustrating the first embodiment of the data acquisition and storage method of this application.

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.

[0028] As OLED (Organic Light-Emitting Diode) display technology upgrades towards ultra-high definition and large size, the data acquisition volume of inkjet printing equipment is increasing exponentially, making the requirements for real-time storage increasingly stringent. Currently, the industry's approach is to collect data through API interfaces and then upload it in batches to storage nodes. This method is prone to significant delays in massive data scenarios, causing equipment control commands to lag and affecting printing accuracy and production yield.

[0029] This application provides a data acquisition and storage method, an organic light-emitting diode inkjet printing device, and a storage medium, which realizes low-latency data storage and stable transmission, ensuring the real-time control requirements of the equipment and production efficiency.

[0030] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, mobile phone, database system, etc., or a device capable of performing the above functions, such as an organic light-emitting diode inkjet printing device. The following description uses an organic light-emitting diode inkjet printing device as an example to illustrate this embodiment and the subsequent embodiments.

[0031] The data acquisition and storage method of this application is applied to the data acquisition and storage system of organic light-emitting diode inkjet printing equipment. The data acquisition and storage system includes an acquisition client cluster and a distributed cache cluster. The distributed cache cluster includes at least three master nodes, and the acquisition client cluster includes at least three acquisition clients. The data acquisition and storage method includes the following implementation steps S10 to S30.

[0032] Step S10: The acquisition client obtains the acquisition task of the organic light-emitting diode inkjet printing equipment. Based on the preset data type classification rules of the organic light-emitting diode inkjet printing equipment, the acquisition task is divided into multiple independent sub-tasks. The number of independent sub-tasks is adapted to the number of acquisition clients.

[0033] Optionally, as an example, the target application scenario can be a high-frequency, multi-collection-point industrial data acquisition and storage scenario, such as a single piece of equipment generating more than 20KB of data per second, and a daily (24-hour) cumulative data volume exceeding 1.7GB. When the printhead is being debugged, a large amount of ink droplet volume velocity data needs to be collected and stored, and the daily data volume can exceed 4GB. The printing accuracy of organic light-emitting diode inkjet printing equipment needs to be controlled within ±2μm, with a target yield of ≥95%.

[0034] Optionally, the technical solution of this application is deeply adapted to the application scenarios of OLED inkjet printing equipment, and the specific correspondence is as follows: For the massive data demand of the equipment with more than 200 acquisition points and an acquisition frequency of 20Hz, the "multi-acquisition client parallel acquisition + distributed cache partition storage" is used to avoid the overload of a single node and ensure that the data acquisition latency is ≤200ms, meeting the real-time control requirements of pixel-level positioning (±2μm error); For the equipment's high requirements for data continuity (i.e., storage interruption of more than 10 minutes will cause the production line to stop), the data loss rate is controlled to below 0.001% through technologies such as 100ms-level heartbeat detection, fault switching within 30s, and incremental synchronization (i.e., synchronization latency ≤50ms); For the production rhythm of the equipment operating at high capacity during the day and idle at night, the "idle time transfer" strategy is adopted to complete the persistence of cached data during the non-production period of the equipment from 22:00 to 8:00, avoiding the impact of disk I / O occupation on printing accuracy during peak periods.

[0035] Optionally, the acquisition client cluster is a collection of multiple terminal devices with data acquisition capabilities; the distributed cache cluster contains at least three master nodes for distributed storage of the acquired data; the master node is the core node in the distributed cache cluster responsible for receiving and storing data; organic light-emitting diode inkjet printing equipment refers to industrial equipment for organic light-emitting diode inkjet printing that requires high-frequency, large-volume data acquisition.

[0036] Optionally, the acquisition client first obtains the acquisition task of the OLED inkjet printing equipment, and then splits the task into multiple independent sub-tasks based on preset data type classification rules. Subsequently, each acquisition client acquires the raw data of the equipment in parallel, with an acquisition frequency of up to 20Hz, and the acquisition points cover data from more than 200 sensors such as the ink path system and motion system. After the acquisition is completed, the raw data is sent to the master node of the distributed cache cluster according to type. The master node receives and stores the raw data sent by each acquisition client. Through this distributed acquisition and storage method, the load on a single node can be avoided, the data storage latency can be effectively reduced, and the real-time control requirements of the OLED inkjet printing equipment can be met.

[0037] like Figure 2 As shown, Figure 2This is a flowchart illustrating the Redis cluster fault diagnosis process for the OLED inkjet printer involved in this application. The process includes: Redis Cluster Startup: Initialization and operation of the Redis distributed cache cluster, which caches core information such as print task data and printhead control parameters of the inkjet printer; Management Node: Loading Fault Thresholds: The cluster management node pre-imports quantitative standards for fault judgment, based on the inkjet printer's requirements for real-time and complete data transmission; Master / Slave: Sending Heartbeat Packets Every 100ms: The master and slave nodes send signal packets containing their own operating status to the management node every 100ms; Startup Monitoring: The management node begins continuous monitoring of the cluster node status, focusing on the performance of nodes related to data interaction with the inkjet printer; Three Consecutive Packet Losses: The management node determines whether it has failed to receive heartbeat packets from the target node three consecutive times; Judgment: Communication Interruption Fault: If three consecutive packets are not received, the node is judged to have experienced a communication fault, which will cause data transmission interruption between the inkjet printer and the cache cluster, leading to printing stagnation; Parsing Heartbeat Packet Data: If received... Heartbeat packet: The management node extracts node operation data from the packet; Write rate continuously < 50% threshold for 1 second: Determines whether the node data write rate is continuously lower than 50% of the preset threshold for 1 second; Judgment: Performance abnormality fault: If the write rate is below the standard, the node is judged to have a performance fault, which will cause delay in print task data caching, resulting in printhead inkjet asynchrony and pattern misalignment; Verification error rate > 0.1%: Determines whether the error rate of node data verification exceeds 0.1%; Judgment: Data corruption fault: If the error rate exceeds the standard, the node is judged to have a data fault, which will lead to Printed data distortion causes incomplete patterns and color deviations; Judgment: Node Normal: The node is judged to be in a state where all indicators meet the standards. At this time, the cluster can stably provide data caching services for inkjet printers; Continue Monitoring: The management node returns to continuous monitoring state; Trigger Alarm + Master-Slave Switch / Node Isolation: When a node is judged to have communication interruption, performance abnormality, or data corruption failure, fault handling operations are performed. Depending on the fault type, master-slave node role replacement or physical / logical isolation of the faulty node is selected, and alarm notifications are triggered to ensure that the printing tasks of inkjet printers are not interrupted and data is not lost.

[0038] Specifically, starting with "Redis cluster startup," the process begins with "the management node loading the fault threshold," while "Master / Slave sends a heartbeat packet every 100ms," followed by the "startup monitoring" phase. During monitoring, the management node first checks "whether packets have been received three times consecutively?" If the result is "yes," it directly "determines a communication interruption fault." If the result is "no," it "parses the heartbeat packet data," first checking "whether the write rate is consistently less than 50% of the threshold for 1 second." If the result is "yes," it "determines a performance anomaly fault." If the result is "no" (i.e., write...), it "determines a performance anomaly fault." If the data transmission rate is normal and meets the real-time data transmission requirements of the inkjet printer, then the system will proceed to the "Error rate > 0.1%?" check. If the result is "yes", the system will "determine a data corruption fault". If the result is "no" (i.e., the error rate is normal and the integrity of the printed data can be guaranteed), the system will "determine the node is normal" and proceed to "continue monitoring". When a communication interruption, performance abnormality, or data corruption fault is detected, the system will perform the "trigger alarm + master-slave switch / node isolation" operation. After the operation is completed, the management node will return to the "continue monitoring" state to ensure that the inkjet printer continues to receive a stable cache service.

[0039] By employing a logic of "layered progressive detection + branch fault judgment + unified handling", the system achieves full-link fault coverage. Furthermore, 100ms-level heartbeat detection enables fault discovery within seconds, and multi-dimensional indicators avoid misjudgment based on a single condition. The handling combination of "management + master-slave switching + isolation" can complete fault node replacement within 30 seconds, with a data loss rate of <0.001%, meeting the data storage continuity requirements of OLED printing equipment.

[0040] like Figure 3 As shown, Figure 3This is a flowchart illustrating the Redis cluster fault handling process for the OLED inkjet printer involved in this application. The flowchart details the following steps: Management node detects a node failure: The cluster management node identifies an abnormal operation of a Redis node, which is used to cache core data such as printhead pressure and ink flow of the inkjet printer. Fault node type determination: The abnormal node is distinguished as either a "master node failure" or a "slave node failure." This is a core decision point in the flowchart, strictly matching the text in the diamond-shaped judgment boxes. Master node failure: An abnormal operation of the core storage node in the Redis cluster will cause an interruption in the print data cache, leading to printhead stoppage. Slave node failure: An abnormal operation of the replica node in the Redis cluster will reduce print data redundancy. To mitigate the risk of data loss, a master-slave switch is immediately triggered: The slave node of the failed master node is upgraded to a temporary master node, ensuring uninterrupted real-time data caching for the inkjet printer. A new slave node is selected from the backup node pool, added as a new replica node. The new slave node establishes a connection with the temporary master node, with a data synchronization latency of <50ms, avoiding printhead control parameter caching delays and ensuring printing accuracy. Data writing functionality is restored to ensure uninterrupted business operations. Core data for inkjet printing tasks is continuously stored; a node is selected from the backup node pool to serve as a new slave node: a node is selected from the backup storage node set to directly replace the failed slave node; the new slave node adopts an incremental data synchronization strategy, synchronizing only the data added by the master node during the failure period: only the incremental printing data during the failure period is synchronized to avoid full synchronization occupying bandwidth and ensure data transmission for other printing devices; data recovery time is controlled within 30 seconds: data synchronization time is strictly controlled within 30 seconds to prioritize the high-frequency data acquisition needs of inkjet printing devices; the failed node automatically recovers and comes back online: the original failed node completes repair and reconnects to the cluster; data consistency verification is performed with the current master node / temporary master node. Compare data differences: Use hash comparison (such as SHA-256) to verify the integrity of print data between faulty nodes and core nodes, ensuring that data such as printhead pressure and ink flow are accurate; Only supplement missing data to avoid duplication / conflict: Only supplement the missing print data of faulty nodes to prevent printhead control command errors caused by data redundancy; Switch faulty nodes to standby nodes and add them to the standby node pool: The repaired nodes are converted to standby nodes and stored in the standby storage node set to improve the cluster's redundancy capabilities and cope with subsequent faults; After fault handling is completed, the management node continues to monitor the cluster status: After the fault handling is completed, the management node returns to continuous monitoring, which meets the closed-loop requirements for Redis cluster fault handling.

[0041] Specifically, starting with "the management node detected a node failure," the process first executes "determine the type of the failed node," strictly following the flowchart's "from left to right, from top to bottom" sequence: If the determination result is "yes" (i.e., the master node failed), the process proceeds sequentially: "immediately trigger master-slave switch (i.e., the slave node of the failed master node → temporary master node)" → "select a node from the standby node pool → new slave node" → "establish a connection between the new slave node and the temporary master node, with data synchronization latency < 50ms" → "restore data writing function to ensure uninterrupted business operations"; if the determination result is "no" (i.e., the slave node failed), the process continues... The process is executed in two steps: "Select a node from the standby node pool → add it as a new slave node" → "The new slave node adopts an incremental data synchronization strategy, only synchronizing data added by the master node during the failure" → "Data recovery time is controlled within 30 seconds"; after the above two branch processes are completed, both enter "Automatic recovery and online of the failed node", and then execute in sequence: "Data consistency verification, comparing data differences with the current master node / temporary master node" → "Only supplement missing data to avoid duplication / conflict" → "The failed node is switched to a standby node and connected to the standby node pool" → "Fault handling is completed, and the management node continues to monitor the cluster status".

[0042] This process achieves automatic self-healing of cluster faults through a closed-loop design of "fault diagnosis - node replacement - data synchronization - recovery verification". It can control the fault handling RTO (Recovery Time Objective) within 30-50 seconds and the RPO (Recovery Point Objective) within 50 ms, ensuring the storage continuity of high-frequency, large-volume data of inkjet printing equipment and solving the technical problems of high latency and large data deviation in general Redis cluster fault handling.

[0043] like Figure 4 As shown, Figure 4This diagram illustrates the equipment deployment and task allocation of the OLED inkjet printing device involved in this application. Specifically: Operation Client: A client unit integrating "device operation" and "database synchronization" functions, serving as the entry point for users to perform inkjet printing device operations; Acquisition Client Cluster (including Acquisition Client 1, Acquisition Client 2, ..., Acquisition Client M): Parallel client instances responsible for executing data acquisition tasks for inkjet printing sub-devices (such as printheads and ink path valves); Sub-device Data Acquisition Subtasks: A set of inkjet printing sub-device acquisition tasks broken down from the operation client; Task Allocation (Load Balancing): Scheduling logic that distributes sub-device data acquisition subtasks to different acquisition client cluster instances to balance the acquisition load; Distributed Cache Cluster: A temporary storage cluster carrying inkjet printing sub-device acquisition data, supporting high-frequency data read / write; Data Synchronization (Start During Idle Time): A cache data synchronization command triggered by the operation client during idle periods; Transfer Data to Disk Database: An operation that persists inkjet printing data temporarily stored in the distributed cache cluster to the disk database; Delete Cache Data: Clears the persisted inkjet printing data in the distributed cache cluster to prevent cache overflow. In other words, the operating client connects to the acquisition client cluster via multiple links and issues sub-tasks for acquiring data from sub-devices to each acquisition client instance; the acquisition client cluster transmits the acquired inkjet printing sub-device data to the distributed cache cluster for temporary storage through task allocation (load balancing); the distributed cache cluster transmits the data to the "disk database" through a data synchronization link (i.e., started when idle), and performs the data transfer operation to the disk database; after the data transfer to the disk database is completed, a cache data deletion operation is triggered to clear the inkjet printing data that has been transferred in the distributed cache cluster.

[0044] Specifically, taking the "operation client" as the core starting point: On the one hand, the operation client undertakes the "device operation" function (such as controlling the printhead start and stop of the inkjet printer), and on the other hand, it connects to the "acquisition client cluster" (including acquisition client 1 to acquisition client M) through multiple links. First, the operation client breaks down the acquisition requirements of the inkjet printing sub-device into multiple sub-device data acquisition sub-tasks, and distributes them to the corresponding acquisition clients through "task allocation (load balancing)" logic. Each acquisition client independently executes the acquisition task of the corresponding inkjet printing sub-device (such as printhead pressure, ink path flow), realizing parallel acquisition, avoiding excessive load on a single client, and adapting to the high-frequency data acquisition requirements of inkjet printing. After the acquisition is completed, each acquisition client transmits the data to the "distributed cache cluster" for temporary storage through "task allocation (load balancing)". When the operation client is idle, the "9012 database synchronization" function is triggered. Through "data synchronization (i.e., starting when idle)," the inkjet printing data in the distributed cache cluster is transferred to the "disk database" for persistence. At the same time, "delete cache data" is executed to clear the transferred data to avoid cache overflow. Through the design of "operation terminal coordination - parallel acquisition of multiple acquisition terminals - temporary cache storage - persistent storage during idle time", the inkjet printing equipment can efficiently acquire and store high-frequency, large-volume data, which not only ensures acquisition efficiency (i.e., reduced time consumption of parallel acquisition) but also balances storage pressure.

[0045] like Figure 5 As shown, Figure 5 This diagram illustrates the distributed acquisition and caching data interaction of the OLED inkjet printing equipment involved in this application. The components are: OLED equipment PLC sub-device: The programmable logic controller (PLC) of the OLED inkjet printing equipment, serving as the source of sensor data acquisition; PLC acquisition API: The data transmission interface between the OLED equipment PLC sub-device and the acquisition client industrial control computers (M units); Acquisition client industrial control computers (M units): M terminal devices operating in parallel, responsible for executing data acquisition tasks; Cluster management node (fault diagnosis + fault handling): A scheduling unit with both fault diagnosis and fault handling functions; Backup node pool: A pre-configured pool of node resources for replacement in case of failure; Redis cache cluster (N master nodes + N slave nodes for master-slave data synchronization): A distributed cache unit containing N master storage nodes and N slave replica nodes, with master-slave data synchronization performed between master and slave nodes; Operation client industrial control computers: Terminal devices responsible for equipment operation and historical data interaction; Disk database (MySQL): A database storing persistent data.

[0046] In other words, the OLED equipment PLC sub-devices transmit data to the acquisition client industrial control computers (M units) via the PLC acquisition API; the acquisition client industrial control computers (M units) transmit data to the Redis cache cluster via the "data write" link; the cluster management node (fault diagnosis + fault handling) monitors the Redis cache cluster via the "monitoring / management / fault switching" link; simultaneously, the cluster management node schedules nodes with the backup node pool via the "activation and replacement" link; the Redis cache cluster provides data services to the operating client industrial control computers via the "data query" link; the Redis cache cluster writes data to the disk database (MySQL) via the "data persistence and synchronization" link; and the operating client industrial control computers interact with the disk database (MySQL) via the "historical data interaction" link.

[0047] Specifically, the data collected by the PLC sub-devices of the OLED equipment is transmitted to the acquisition client industrial control computer (M units) via the PLC acquisition API. The M acquisition clients transmit the data in parallel to the Redis cache cluster via the "data write" link. After the N master nodes in the cluster receive the data, the N slave nodes synchronously perform "master-slave data synchronization" to achieve data redundancy with multiple replicas. The cluster management node (fault diagnosis + fault handling) continuously monitors the Redis cache cluster through the "monitoring / management / fault switching" link. If the "fault diagnosis" determines that a node is abnormal, "fault handling" is immediately performed, and the node is activated from the backup node pool through the "activation and replacement" link to complete the replacement, ensuring the continuity of the cache function. The Redis cache cluster provides data query services to the operation client industrial control computer through the "data query" link. On the other hand, it writes data to the disk database (MySQL) through the "data persistence synchronization" link. At the same time, the operation client industrial control computer can interact with the disk database (MySQL) through the "historical data interaction" link to exchange historical data, thus fully covering the entire process of "data acquisition → distributed caching → fault fallback → persistent storage → data interaction". By employing designs such as parallel operation of multiple acquisition terminals, redundancy of master-slave caches, and replacement of faulty nodes, the system enables low-latency acquisition and stable storage of high-frequency, large-volume data from OLED inkjet printers, thus meeting their requirements for real-time and continuous data processing.

[0048] like Figure 6 As shown, Figure 6This is a hardware structure diagram of the distributed data acquisition and caching involved in this application. Specifically: Redis nodes (10 in total): corresponding to the top-of-the-line labels Master1, Slave1, Master2, Slave2, Master3, Slave3, Master4, Slave4, Master5, and Slave5, representing the smallest storage unit of the distributed caching cluster, divided into 5 groups of "1 master, 1 slave". Each group of master / slave nodes is connected to its corresponding server by a dotted line, serving as a hardware association identifier between the node and the server, clearly defining their one-to-one binding relationship. Servers (5 in total): corresponding to Server1, Server2, Server3, Server4, and Server5 in the diagram, each bound to a Redis master / slave node group: Server1 corresponds to Master1 + Slave1, Server2 corresponds to Master2 + Slave2, Server3 corresponds to Master3 + Slave3, and Server5 corresponds to Master3 + Slave3. Node 4 corresponds to Master4+Slave4, and server 5 corresponds to Master5+Slave5, providing the hardware operating environment for the nodes. The switch is the core networking device, and all servers, acquisition clients, and operation clients are connected to it in real time via solid lines, using a star topology to handle data forwarding. The solid lines are real-time data communication links. Acquisition clients (3 in total): Acquisition Client 1, Acquisition Client 2, and Acquisition Client 3, are dedicated to performing data acquisition tasks for sub-devices such as printhead pressure and ink flow of the inkjet printing equipment, and establish communication connections with the switch via solid lines. Operation clients: are responsible for adjusting the equipment parameters of the inkjet printing equipment and querying the acquired data, and establish communication connections with the switch via solid lines. At the same time, the operation clients are connected to the database via dashed arrows, which is the historical data retrieval link, used by the operation clients to initiate historical data query requests to the database. Database: is the storage hardware used to persistently store the cached data of the inkjet printing equipment. Figure 6 All solid lines represent real-time data transmission links, while dashed lines indicate hardware ownership or non-real-time interaction. All connections are valid functional links.

[0049] Specifically, the hardware architecture uses "5 servers + 10 Redis nodes" as the core of the cache: each server deploys 2 Redis nodes, and the node-server binding relationship is clearly defined by dotted lines. The 10 nodes together form a distributed cache cluster adapted to inkjet printing equipment. Data acquisition link: 3 acquisition clients establish network connections with 5 servers through solid lines on the switch, and transmit the collected data of inkjet printing equipment sub-devices (such as printhead pressure and ink flow) to the corresponding server's Redis node to complete the real-time acquisition of high-frequency data. Data transfer link: the operation client accesses the server through the solid lines on the switch and directly accesses the Redis node to obtain the real-time operating data of the inkjet printing equipment. When the operation client needs to retrieve historical data, it initiates a request through the dotted arrow link between itself and the database to retrieve the historical operating data of the inkjet printing equipment from the database, avoiding the occupation of real-time data transmission bandwidth. The core technical features of the entire hardware architecture are "'server-node' dotted line attribution binding + switch star-shaped real-time networking + inkjet printing equipment scenario adaptation": It not only distributes the storage load of high-frequency and large-volume data of inkjet printing equipment through 10 Redis nodes, but also uses dotted lines to clarify hardware associations and solid lines to ensure real-time communication stability. At the same time, the switch realizes efficient networking of multiple devices, fully supports the entire process of data collection, caching and querying of inkjet printing equipment, and perfectly matches the hardware connection and identification relationship in the attached diagram.

[0050] Optionally, the acquisition task refers to the specific requirements for collecting various types of data from the organic light-emitting diode (OLED) inkjet printing equipment, including sensor data, operation logs, and anomaly information. An independent subtask is the smallest independently executable task unit after the acquisition task is broken down according to preset rules. OLED inkjet printing equipment specifically refers to industrial equipment that requires high-frequency, large-volume data acquisition. The preset data type classification rules are task decomposition standards pre-defined for the data acquisition scenario of OLED inkjet printing equipment. Their core purpose is to clarify how to break down the overall acquisition task into independent subtasks, specifically including two core classification dimensions: one is classification by sub-device modules, and the other is classification by the type of data itself, which can be flexibly selected according to the actual acquisition needs of the equipment.

[0051] Optionally, in the data acquisition scenario of OLED inkjet printing equipment, this type of equipment integrates core sub-devices such as ink path systems, motion systems, and glove boxes, with over 200 acquisition points and an acquisition frequency of 20Hz. After the acquisition client obtains the acquisition task, it splits it into independent sub-tasks using the "sub-device module classification" dimension in the preset data type classification rules. Each sub-task corresponds to the acquisition of data from all acquisition points of a category of sub-devices. During the splitting process, the data volume of each sub-device (e.g., the ink path system contains over 130 sensors, and the motion system contains over 58 sensors) and the real-time acquisition requirements are taken into account to ensure that the load of each independent sub-task is balanced and to avoid acquisition congestion caused by excessive data volume in a single sub-task.

[0052] Optionally, when the OLED inkjet printing equipment needs to simultaneously collect real-time sensor data, operation logs, and printhead calibration data (such as droplet volume velocity data) during operation, the acquisition client, after receiving the acquisition task, splits it into independent subtasks according to the "data type classification" dimension in the preset data type classification rules, treating the real-time sensor data, operation logs, and printhead calibration data as independent subtasks respectively. During the splitting process, a load-adaptive allocation logic is used, referencing the generation frequency of each type of data (e.g., sensor data at 20Hz, operation logs recorded on demand) and the data volume to ensure that the independent subtasks match the resource status of the acquisition client.

[0053] This embodiment utilizes two core splitting logics based on preset data type classification rules to divide the data acquisition task into multiple independent sub-tasks, effectively avoiding acquisition congestion caused by a single task being concentrated. This design is precisely adapted to the high-frequency, large-volume data acquisition needs of LED inkjet printing equipment, while laying the foundation for subsequent parallel acquisition stages, improving the flexibility and scalability of the acquisition system, and ensuring that the acquisition latency meets the real-time control requirements of the equipment.

[0054] Step S20: Each acquisition client acquires raw data from the organic light-emitting diode inkjet printing equipment in parallel according to its respective independent sub-task, and sends the raw data to the master node of the distributed cache cluster.

[0055] Optionally, an independent subtask is the smallest unit that can be executed independently after the acquisition task is broken down, specifically including data acquisition of sub-device modules, acquisition of specific types of data, etc.; raw data is unprocessed data generated during the operation of organic light-emitting diode inkjet printing equipment, specifically including sensor data, operation logs, debugging data, etc.; parallel acquisition is a method in which multiple acquisition clients execute their respective assigned subtasks simultaneously without interfering with each other.

[0056] Optionally, the OLED inkjet printing equipment includes sub-devices such as an ink path system, a motion system, and a glove box, with over 200 data collection points and a collection frequency of 20Hz. Three data collection clients correspond to three independent sub-tasks, each broken down by sub-device module. These sub-tasks are responsible for collecting pressure and level data from the ink path system, position and speed data from the motion system, and temperature, humidity, and pressure data from the glove box, respectively. Each data collection client starts collecting data synchronously, sending the data to the corresponding master node in the distributed cache cluster via preset mapping rules. This ensures centralized storage of data within the same module and prevents data conflicts between multiple data collection clients—because each client collects different sub-device or data types and writes to different master node addresses, data transmission conflicts are directly avoided.

[0057] Optionally, the OLED inkjet printing equipment needs to collect real-time operational data, fault warning data, and parameter configuration data. Four data acquisition clients are divided into independent sub-tasks based on data type, each responsible for collecting the three types of data and equipment environment data. During the acquisition process, a load-adaptive allocation logic is used, dynamically adjusting the acquisition pace based on the CPU utilization and memory usage of each client. After parallel acquisition is completed, the data is sent to the corresponding master node according to type to avoid data transmission conflicts. Simultaneously, acquisition clients can be dynamically added; new client nodes can be added and acquisition tasks assigned without shutting down the cluster, thus adapting to the needs of expanding the number of acquisition points or increasing data volume in the OLED inkjet printing equipment.

[0058] This embodiment effectively reduces the load on a single client by splitting independent subtasks according to different dimensions and executing parallel acquisition, ensuring that the acquisition frequency and data volume match the device performance; at the same time, the data transmission is accurately oriented, which greatly improves the acquisition efficiency and data transmission stability, and can meet the real-time requirements of high-frequency, large-volume data acquisition scenarios.

[0059] Step S30: Each master node receives the raw data of the corresponding type, divides the storage partitions according to the type corresponding to the preset data type classification rules, and writes the raw data directly into the local memory to complete real-time storage.

[0060] Optionally, the master node is the core node in the distributed cache cluster responsible for receiving data and performing storage operations; the raw data is the unprocessed data collected by the client from the organic light-emitting diode inkjet printing equipment, specifically including sensor monitoring data, equipment operation logs, parameter debugging data, etc.

[0061] Optionally, the distributed caching cluster can use other caching technologies besides Redis, such as InfluxDB. Redis is chosen because it supports distributed data collection across nodes and can load frequently used data from the database into memory, improving software speed and adapting to real-time requirements. Other caching technologies can be flexibly replaced based on data security and other needs. Taking an OLED inkjet printer with over 200 collection points and a collection frequency of 20Hz as an example: the master node receives different types of raw data (including ink path system pressure data, motion system position data, and glove box temperature and humidity data) sent directionally from three collection clients. During the reception process, a basic verification mechanism is used to determine whether the data format is compliant. After successful verification, the data is directly written to local memory, thus avoiding disk I / O latency and ensuring real-time data storage.

[0062] Optionally, if the device needs to collect three types of raw data—vacuum level, temperature, and speed—simultaneously, the master node will receive data sent in parallel by four acquisition clients and divide the storage into partitions according to data type, with each partition allocated memory space independently. At the same time, the storage cache size will be dynamically adjusted according to the amount of data received in real time. When the write rate of a single type of data exceeds 50MB / s, the cache partition will be automatically expanded to ensure that the storage process does not block data reception and adapt to high-frequency data influx scenarios.

[0063] This embodiment, through master node directional reception and partitioned storage, combined with the high-speed read and write characteristics of local memory, avoids data transmission and storage conflicts and reduces the storage pressure on a single node. At the same time, it adapts to the needs of high-frequency, large-volume data acquisition, ensures that the storage latency is controlled within 200ms, provides data support for real-time device control, and improves the stability and scalability of data storage.

[0064] This embodiment acquires the acquisition tasks of the OLED inkjet printing equipment through a acquisition client, avoiding overload and crashes caused by a single acquisition client handling too many tasks. Based on the preset data type classification rules of the OLED inkjet printing equipment, the acquisition tasks are divided into multiple independent sub-tasks. The number of independent sub-tasks is adapted to the number of acquisition clients, realizing task splitting by data type, ensuring orderly data flow throughout the entire link, and avoiding conflicts caused by mixed transmission of multiple data types from the source. Each acquisition client acquires the raw data of the OLED inkjet printing equipment in parallel according to its respective independent sub-task. Parallel acquisition eliminates the need for serial waiting, shortening the total acquisition time for multiple data types, and directing the raw data to the master node of the distributed cache cluster, thus avoiding collisions between different data types in the transmission link and reducing the additional losses from data verification and retransmission. Each master node receives the raw data of the corresponding type, divides the storage into storage partitions according to the type corresponding to the preset data type classification rules, and partitions the storage to structurally separate different data types at the storage level, reducing storage chaos and time consumption. The raw data is directly written to local memory for real-time storage, and local memory writing does not require disk I / O. By directly overcoming the latency bottleneck of traditional disk storage, this approach provides core support for ultimately reducing overall storage latency, thereby reducing data storage latency in various data acquisition scenarios of organic light-emitting diode inkjet printing equipment.

[0065] Furthermore, based on the above, a second embodiment of the data acquisition and storage method of this embodiment is proposed. In some feasible embodiments, step S10 above includes the following implementation steps B201-B202.

[0066] Step B201: Each data acquisition client matches and assigns each independent subtask to the corresponding data acquisition client based on the load requirements of each independent subtask and its own resource status.

[0067] Step B202: Each acquisition client collects raw data from the organic light-emitting diode inkjet printing equipment in parallel according to the assigned independent sub-task, and sends the raw data of the same type to the corresponding master node of the distributed cache cluster according to the preset data type classification rules.

[0068] Optionally, load requirements refer to the hardware resources and data processing requirements of an independent subtask; resource status refers to the real-time operating status of the acquisition client, such as CPU utilization and memory usage; same-type directional transmission refers to the transmission method of sending the same type of raw data to the preset corresponding master node, which is mainly used to ensure the accuracy and orderliness of data transmission.

[0069] Optionally, taking an OLED inkjet printing equipment containing sub-devices such as an ink path system, motion system, and glove box as an example, this equipment has over 200 data acquisition points and a data acquisition frequency of 20Hz. Each acquisition client first obtains the load requirements of all independent sub-tasks, specifically including core indicators such as the data acquisition volume and processing time requirements of each sub-task; then, it monitors its own resource status in real time and uses load-adaptive allocation logic to accurately allocate the sub-tasks to the corresponding clients with sufficient resources. A specific allocation example is as follows: the pressure and liquid level data sub-task from over 130 sensors in the ink path system is allocated to an acquisition client with CPU utilization below 40% and memory usage below 30%; the position and speed data sub-task from over 58 sensors in the motion system is allocated to another client with sufficient resources; and the various sensor data sub-tasks from the glove box are allocated to a third client.

[0070] Optionally, each client synchronously initiates parallel data acquisition according to its assigned task. After acquiring the raw data from the OLED inkjet printing equipment, it combines the data with the corresponding type according to the preset data type classification rules and uses a hash algorithm to send data of the same type to the corresponding master node of the distributed cache cluster. For example, data related to the ink path system is sent to master node 1, data related to the motion system is sent to master node 2, and data related to the glove box is sent to master node 3.

[0071] This embodiment effectively avoids overload of a single client by dynamically allocating resources based on the load requirements of subtasks and the resource status of the acquisition client. Combined with a targeted transmission mechanism for the same type of data, it ensures accurate data transmission without mixing and works in synergy with the distributed cache cluster architecture to further improve the overall efficiency of acquisition and transmission, ultimately guaranteeing the real-time performance of data acquisition and the operational stability of the cache cluster.

[0072] Furthermore, based on the above, in some feasible embodiments, step S20 includes the following implementation steps C301-C302.

[0073] Step C301: According to the preset data integrity verification rules, the master node automatically verifies the received raw data. The preset data integrity verification rules include the original data identifier, format and content integrity verification rules.

[0074] Step C302: If the automatic verification is successful, write the original data to the corresponding type of storage partition and local memory to complete real-time storage.

[0075] Optionally, preset data integrity verification rules are the criteria for ensuring the validity of raw data, and the core includes three dimensions: raw data identifier verification, format integrity verification, and content integrity verification. Specifically, the raw data identifier is the unique identification information of the raw data, used to distinguish data from different sources or types; the format integrity verification rules are used to check whether the format of the raw data conforms to the preset standards; the content integrity verification rules are used to check whether the content of the raw data is complete, without missing or disordered parts; and local memory is the high-speed storage medium built into the master node, specifically used for temporary storage of real-time acquired data.

[0076] Optionally, taking an organic light-emitting diode inkjet printer with a sampling frequency of 20Hz and over 200 sampling points as an example, its raw data covers various types, including ink path system pressure data, motion system position data, and glove box temperature and humidity data. After receiving various types of raw data sent by the acquisition client, the master node will strictly execute an automatic verification process according to preset data integrity verification rules: First, it checks whether the raw data identifier is unique and conforms to preset coding rules to ensure that the data source is traceable; then, it checks whether the data format matches the preset type, for example, pressure data must be double type and equipment status data must be boolean type; finally, it checks whether the data content is complete and without missing fields to ensure that no core data information is omitted. If the error rate exceeds 0.1% during the verification process, the corresponding data is determined to be corrupted and directly rejected for storage; if the verification passes, the raw data is directly written to the corresponding type of storage partition and local memory, quickly completing real-time storage.

[0077] This embodiment uses multi-dimensional preset data integrity checks to accurately filter invalid or damaged data, preventing such data from occupying valuable storage resources. At the same time, by leveraging the high-speed write characteristics of local memory, it further shortens data storage latency and precisely adapts to the real-time requirements of high-frequency, large-volume data acquisition scenarios of LED inkjet printing equipment.

[0078] Furthermore, based on the above, in some feasible embodiments, the data acquisition and storage system further includes an operation client and a disk database, and the data acquisition and storage method further includes the following implementation steps D401 to D402.

[0079] Step D401: The client monitors its own business load. When the business load is detected to be lower than the preset threshold, the client reads the original data in batches from the local memory of the corresponding storage partition according to the preset batch size and type, and then transfers the original data to the disk database.

[0080] Step D402: After the original data is transferred to the disk database, the master node cleans up the cache space of the corresponding type of original data that has been transferred in the local memory.

[0081] Optionally, the operation client is a terminal unit that integrates device operation and data synchronization functions, and is also the core entry point for users to perform equipment operations; the disk database is a hardware storage system for persistent data storage, specifically designed to meet long-term data retention needs; business load refers to the resource consumption of the operation client in handling tasks such as device operation and data interaction; the preset threshold is a quantitative standard for judging whether the business load is at a low point, and in this embodiment, the threshold is set to 30%; the preset batch size is a quantitative value for reading cached data in batches, and in this embodiment, it is set to 1GB. In actual applications, it can be flexibly adjusted to tens or hundreds of megabytes according to the data type to adapt to the transmission needs of different scenarios such as critical location data and real-time directory data.

[0082] Optionally, in practical application scenarios, the operation client mainly undertakes core tasks such as device motion control and printing operations. Its peak business hours are from 8:00 to 22:00, with 22:00 to 8:00 being the off-peak period. The operation client monitors its own CPU utilization, data interaction frequency, and other business load indicators in real time. When the load is detected to be below a preset threshold of 30%, the data transfer process is automatically triggered. During the transfer process, the operation client reads raw data from the master node's local memory in batches of 1GB. This data includes various types such as ink path system pressure data, motion system position data, glove box temperature and humidity data, operation logs, and printhead debugging data. To avoid consuming too many network resources in a single read, the reading process adopts a streaming transmission method; at the same time, data acquisition is stopped during the transfer to prevent new data from being written before the marked deletion, which could cause conflicts. Since there are no core tasks such as printing during this period, the monitoring operations related to data transfer will not affect the normal operation of the device, ensuring that the data is completely transferred to the disk database.

[0083] Optionally, after the disk database completes data reception and sends a transfer completion signal, the master node will use a mark-and-delete mechanism to clear the cache space of the corresponding type of original data that has been transferred in local memory, freeing up valuable memory resources for subsequent data collection. If transfer fails due to insufficient disk space, the system will automatically trigger an alarm mechanism, clearly indicating to the user the amount of data successfully transferred and the amount that failed. After the user clears the disk space, the system supports manual or automatic retrying of the transfer of unsuccessful data to ensure the integrity of data storage.

[0084] This embodiment precisely avoids peak business periods through an "idle-time transfer" strategy, effectively preventing resource contention between data transfer and real-time device operation, and ensuring the stable operation of the device's core functions. The combination of batch reading and streaming transmission reduces data transmission and storage pressure. The cache cleanup mechanism after transfer ensures that memory resources are always sufficient. These designs together improve the system's continuous operation capability and data storage security, adapting to the long-term stable operation requirements of LED inkjet printing equipment.

[0085] Furthermore, based on the content of any of the above embodiments, in some feasible embodiments, the distributed cache cluster includes slave nodes that correspond one-to-one with the master node, and the following implementation steps E501-E504 are included after step C302.

[0086] Step E501: The master node records the data change portion of the original data of the corresponding type in its local memory, triggers the incremental synchronization instruction, and transmits the data change portion to the corresponding slave node according to the preset fragment size;

[0087] Step E502: After receiving the changed data from the node and writing it to the corresponding type of storage partition, send a synchronization confirmation signal back to the master node;

[0088] Step E503: After receiving the confirmation signal, the master node calculates the data difference between its local memory data and the storage data returned by the slave node;

[0089] Step E504: When the master node detects that the data difference exceeds the preset difference threshold, it triggers a full synchronization operation to transmit the complete original data of the corresponding type to the slave node.

[0090] Optionally, the data change portion refers to changes such as additions, modifications, and deletions that occur in the original data within local memory; the incremental synchronization instruction is a synchronization signal that triggers the transmission of only the data change portion, primarily used to improve synchronization efficiency; the preset fragment size is a quantified value for splitting the data change portion, set to 50MB in this embodiment; the data difference degree refers to the inconsistency ratio of data stored between the master node and the slave node; the preset difference threshold is the difference degree standard for triggering full synchronization, set to 0.5% in this embodiment; the full synchronization operation is a synchronization method that transmits the complete original data of the corresponding type to the slave node, used as a fallback to correct data differences.

[0091] Optionally, in actual deployment, the master node and its corresponding slave node are deployed on different servers to avoid simultaneous failure of both master and slave nodes due to a power outage of a single server, effectively improving the resilience of the distributed cache cluster. Taking a master node storing raw data from over 200 collection points at a collection frequency of 20Hz as an example, its data synchronization process is as follows: The master node records the data changes of the corresponding type of raw data in its local memory in real time, and splits the changed data into 50MB shards; then it triggers an incremental synchronization command to transmit the sharded changed data to the corresponding slave node; after receiving the data changes, the slave node quickly writes them to the corresponding type of local storage partition, and immediately sends a synchronization confirmation signal back to the master node after the write is completed.

[0092] Optionally, after receiving the synchronization confirmation signal from the slave node, the master node calculates the data difference between its local memory data and the stored data reported by the slave node using methods such as hash comparison. When the detected data difference exceeds a preset difference threshold of 0.5%, the master node immediately triggers a full synchronization operation, transmitting the complete original data of the corresponding type to the slave node to ensure complete data consistency between the master and slave nodes; if the data difference does not exceed the preset threshold, incremental synchronization mode is maintained to continuously ensure the high efficiency of data synchronization.

[0093] This embodiment adopts a collaborative synchronization strategy of "incremental synchronization as the main approach and full synchronization as a backup": incremental synchronization can significantly reduce the amount of data transmitted and network bandwidth usage, improving synchronization efficiency; full synchronization can accurately correct data differences and ensure data consistency. This strategy balances synchronization efficiency and data reliability, and can be precisely adapted to the distributed cache cluster storage needs of high-frequency, large-volume data scenarios in LED inkjet printing equipment.

[0094] Furthermore, based on the content of any of the above embodiments, in some feasible embodiments, the distributed cache cluster also includes a cluster management node and a backup node pool, and the data acquisition and storage method further includes the following implementation steps F501 to F503.

[0095] Step F501: The cluster management node monitors in real time whether there are faulty nodes among the master and slave nodes through preset detection rules;

[0096] Step F502: When the cluster management node detects a faulty node, and the faulty node is a faulty master node, the corresponding slave node of the faulty master node is promoted to a temporary master node, and one node is selected from the standby node pool to supplement it as a new slave node adapted to the temporary master node.

[0097] Step F503: When the cluster management node detects a faulty node, and the faulty node is a faulty slave node, one node is scheduled from the standby node pool to supplement it as a new slave node adapted to the corresponding master node.

[0098] Optionally, the cluster management node is the core scheduling node responsible for monitoring the status of cluster nodes and performing fault handling; the preset detection rules include three core judgment criteria: heartbeat detection, performance indicator detection, and data verification detection, which can be specifically set as quantitative rules such as a 100ms heartbeat interval and three consecutive failures to receive packets to determine communication interruption; a faulty node refers to a node that has experienced abnormal states such as communication interruption, performance abnormality, or data corruption; a temporary master node is a temporary core storage node that is upgraded from the corresponding slave node when the master node fails; the standby node pool is a pre-configured set of standby storage nodes, specifically used to supplement faulty nodes in the cluster.

[0099] Optionally, taking a distributed cache cluster containing a backup node pool of 5 master nodes, 5 slave nodes, and 3 backup nodes as an example, the cluster management node will strictly perform real-time monitoring according to the preset detection rules: receive a heartbeat packet sent by each node every 100ms, first determine whether the target node's heartbeat packet has not been received three times in a row. If the result is yes, the node is directly determined to have a communication interruption failure. If the heartbeat packet can be received normally, the node's running data in the packet is further parsed to detect whether the node's data write rate is lower than 50% threshold for 1 second or whether the data verification error rate exceeds 0.1%. If either condition is met, the corresponding type of fault determination is triggered.

[0100] Optionally, the cluster management node implements differentiated handling strategies for different types of faulty nodes: when a faulty node is detected as a master node, the corresponding slave node is immediately promoted to a temporary master node, and one node is selected from the standby node pool to supplement it as a new slave node adapted to the temporary master node. The new slave node quickly establishes incremental synchronization with the temporary master node, ensuring that the synchronization delay is ≤50ms; when a faulty node is detected as a slave node, one node is directly scheduled from the standby node pool to supplement it as a new slave node adapted to the corresponding master node, and incremental synchronization recovery must be completed within 30 seconds to ensure that the cluster storage capacity quickly returns to normal.

[0101] It should be noted that if communication between the data acquisition client and the master node is interrupted, the acquired data will be discarded directly. The system does not have a local storage policy. Data acquisition will resume after communication is restored. This design can avoid the accumulation of invalid data during the interruption and will not affect the integrity of subsequent data.

[0102] This embodiment can accurately identify various node faults through a hierarchical and progressive preset detection rule; combined with a collaborative handling strategy of master-slave switching and backup node supplementation, it can achieve rapid replacement of faulty nodes, ensure uninterrupted data acquisition and storage, and control the data loss rate to <0.001%, accurately adapting to the continuity requirements of high-frequency, large-volume data scenarios of organic light-emitting diode inkjet printing equipment.

[0103] Furthermore, based on the content of any of the above embodiments, in some feasible embodiments, after step F502, the data acquisition and storage method further includes steps G601-G609.

[0104] Step G601: After the faulty node recovers to normal operation, it connects to the distributed cache cluster and performs data consistency verification with the current temporary master node using preset hash value comparison rules to determine whether there is missing or discrepancy data.

[0105] Step G602: When the faulty node detects missing or differential data, it obtains and supplements the corresponding data from the temporary master node to fill in the missing or differential data.

[0106] Step G603: After the replenishment is completed, the faulty node sends a verification completion signal to the cluster management node;

[0107] Step G604: After receiving the verification completion signal, the cluster management node records the recovery status of the faulty node;

[0108] Step G605: The temporary master node maintains the current read / write task execution state until the preset maintenance window;

[0109] Step G606: After the current read / write task execution status reaches the preset maintenance window, the cluster management node sends a role switchback command to the temporary master node and the faulty master node;

[0110] Step G607: After receiving the role switchback instruction, the temporary master node and the faulty master node perform incremental synchronization to confirm data consistency. After synchronization is completed, they send synchronization confirmation signals to the cluster management node respectively.

[0111] Step G608: After receiving the synchronization confirmation signal sent by both parties, the cluster management node sends a role switchback confirmation command to the temporary master node and the faulty master node;

[0112] Step G609: After receiving the role switchback confirmation command, the temporary master node switches to the slave node, and the faulty master node is restored to the master node.

[0113] Optionally, a faulty node specifically refers to the original master node that has recovered and resumed normal operation after experiencing a fault; the hash value comparison rule is a rule for verifying data consistency by calculating the data hash value, and algorithms such as MD5 and SHA-1 can be used; data consistency verification is the core operation of checking whether the data of the faulty node and the current master node are complete and consistent; the preset maintenance window is a pre-set cluster role adjustment period, which is set to 00:00-02:00 every day in this embodiment. During this period, the business load is low, which can avoid the role adjustment from affecting the core business; the role switchback command is a control signal issued by the cluster management node to restore the original master-slave node role.

[0114] Optionally, taking the scenario where the original master node experiences a communication interruption due to a server power outage as an example, during the fault, its corresponding slave node has been upgraded to a temporary master node, and the nodes in the standby node pool have been supplemented as new slave nodes adapted to the temporary master node. When the faulty node (original master node) resumes normal operation, it will automatically connect to the distributed cache cluster, and then perform data consistency verification with the current temporary master node through a preset hash value comparison rule—specifically, by comparing the hash values ​​of the collected data shard by shard, it accurately determines whether there is any missing or different data between the two.

[0115] Optionally, if the faulty node detects missing or inconsistent data (such as missing ink system pressure data, motion system position data, etc.), it will immediately retrieve and supplement the corresponding data from the temporary master node to complete the data completion. After the data supplementation is completed, the faulty node sends a verification completion signal to the cluster management node. After receiving the verification completion signal, the cluster management node will record the recovery status of the faulty node in real time. At this time, the temporary master node maintains the current read and write task execution status unchanged until the preset maintenance window is reached.

[0116] Optionally, when the preset maintenance window of 00:00-02:00 is reached daily, the cluster management node sends a role rollback command to the temporary master node and the faulty master node (original master node). After receiving the role rollback command, the temporary master node and the faulty master node first perform incremental synchronization operations to further confirm that their data is completely consistent; after synchronization is completed, both send a synchronization confirmation signal to the cluster management node.

[0117] Optionally, after receiving the synchronization confirmation signal from both parties, the cluster management node issues a role switchback confirmation command to the temporary master node and the failed master node. Upon receiving the role switchback confirmation command, the temporary master node switches back to the slave node role, and the failed master node officially resumes its master node role, resuming its core tasks of data acquisition and storage.

[0118] Optionally, this embodiment ensures data consistency after the faulty node recovers by using hash value comparison rules, and avoids conflicts with core business by performing role switching through a preset maintenance window, ultimately achieving seamless recovery of the faulty node. This design not only ensures the stable operation of the distributed cache cluster, but also ensures the continuity of data acquisition and storage, accurately adapting to the needs of high-frequency, large-volume data acquisition scenarios of LED inkjet printing equipment.

[0119] In addition, this application also provides an organic light-emitting diode inkjet printing apparatus. Please refer to... Figure 7 , Figure 7 This is a schematic diagram of the organic light-emitting diode inkjet printing equipment involved in the embodiments of this application.

[0120] This application provides an organic light-emitting diode (OLED) inkjet printing apparatus, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the data acquisition and storage method in Embodiment 1 above.

[0121] The following is for reference. Figure 7 , Figure 7This is a schematic diagram of the structure of an organic light-emitting diode (OLED) inkjet printing apparatus according to an embodiment of this application. It illustrates a structure suitable for implementing the OLED inkjet printing apparatus of this application. The OLED inkjet printing apparatus in this application can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 7 The organic light-emitting diode inkjet printing equipment shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0122] like Figure 7 As shown, the organic light-emitting diode (OLED) inkjet printing equipment may include a processing unit 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the OLED inkjet printing equipment. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005, and an input / output (I / O) interface 1006 is also connected to the bus 1005. Typically, devices that can be connected to I / O interface 1006 include: an input device 1007 for acquiring device operation data; an output device for outputting control commands (including but not limited to a cluster scheduling control module, a data acquisition task allocation module, etc.); an output device 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 1003 including, for example, magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 allows the OLED inkjet printing equipment to communicate wirelessly or wiredly with other devices to exchange data. Although an OLED inkjet printing equipment with various devices is shown in the figure, it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0123] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0124] The organic light-emitting diode (OLED) inkjet printing equipment provided in this application, employing the data acquisition and storage method described in the above embodiments, can solve the technical problem of data storage delay in various data acquisition scenarios of OLED inkjet printing equipment. Compared with the prior art, the beneficial effects of the OLED inkjet printing equipment provided in this application are the same as those of the data acquisition and storage method provided in the above embodiments, and other technical features of this OLED inkjet printing equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0125] Furthermore, this application provides a storage medium. This storage medium stores a data acquisition and storage program, which, when executed by a processor, implements the steps of the data acquisition and storage method described above.

[0126] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0127] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0129] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data acquisition and storage method, characterized in that, A data acquisition and storage system for organic light-emitting diode inkjet printing equipment, the data acquisition and storage system comprising a client acquisition cluster and a distributed cache cluster, the distributed cache cluster comprising at least three master nodes, the client acquisition cluster comprising at least three client acquisition nodes, and the data acquisition and storage method comprising: The acquisition client obtains the acquisition task from the organic light-emitting diode inkjet printing equipment. Based on the preset data type classification rules of the organic light-emitting diode inkjet printing equipment, the acquisition task is divided into multiple independent sub-tasks, wherein the number of independent sub-tasks is adapted to the number of acquisition clients. Each of the aforementioned acquisition clients will match and allocate each of the independent subtasks to the corresponding acquisition client based on the load requirements of each independent subtask and its own resource status; Each of the acquisition clients collects raw data from the organic light-emitting diode inkjet printing equipment in parallel according to the assigned independent sub-tasks, and sends the raw data of the same type to the corresponding master node of the distributed cache cluster according to the type corresponding to the preset data type classification rules. Each master node receives the raw data of the corresponding type, divides the storage partitions according to the type corresponding to the preset data type classification rules, and directly writes the raw data into local memory to complete real-time storage.

2. The data acquisition and storage method as described in claim 1, characterized in that, The steps of each master node receiving the raw data of the corresponding type, dividing the storage partitions according to the type corresponding to the preset data type classification rule, and directly writing the raw data into local memory to complete real-time storage include: According to preset data integrity verification rules, the master node automatically verifies the received raw data, wherein the preset data integrity verification rules include raw data identifier, format and content integrity verification rules; If the automatic verification is successful, the original data is written to the corresponding type of storage partition and local memory to complete real-time storage.

3. The data acquisition and storage method as described in claim 2, characterized in that, The data acquisition and storage system further includes an operating client and a disk database, and the data acquisition and storage method further includes: The operating client monitors its own business load. When it detects that the business load is lower than a preset threshold, it reads the original data from the local memory of the corresponding storage partition in batches according to the preset batch size and type, and then transfers the original data to the disk database. After the original data has been transferred, the master node cleans up the cache space of the corresponding type of original data that has been transferred in the local memory.

4. The data acquisition and storage method as described in claim 2, characterized in that, The distributed cache cluster includes slave nodes that correspond one-to-one with the master node. After the step of writing the original data to the corresponding type of storage partition and local memory to complete real-time storage, the cluster further includes: The master node records the data change portion of the original data of the corresponding type in the local memory, triggers an incremental synchronization instruction, and transmits the data change portion to the corresponding slave node according to the preset fragment size; After receiving the data change portion and writing it to the corresponding type of storage partition, the slave node sends a synchronization confirmation signal back to the master node; After receiving the confirmation signal, the master node calculates the data difference between its own local memory data and the storage data returned by the slave node. When the master node detects that the data difference exceeds a preset difference threshold, it triggers a full synchronization operation to transmit the complete original data of the corresponding type to the slave node.

5. The data acquisition and storage method as described in claim 4, characterized in that, The distributed cache cluster also includes a cluster management node and a backup node pool, and the data acquisition and storage method further includes: The cluster management node monitors in real time whether there are faulty nodes among the master node and the slave node through preset detection rules; When the cluster management node detects the faulty node, and the faulty node is a faulty master node, the slave node corresponding to the faulty master node is promoted to a temporary master node, and one node is selected from the backup node pool to supplement it as a new slave node adapted to the temporary master node. When the cluster management node detects the faulty node, and the faulty node is a faulty slave node, it schedules one node from the backup node pool to supplement it as a new slave node adapted to the corresponding master node.

6. The data acquisition and storage method as described in claim 5, characterized in that, The step of upgrading the slave node corresponding to the failed master node to a temporary master node and selecting one node from the backup node pool to supplement it as a new slave node adapted to the temporary master node further includes: After the faulty node recovers to normal operation, it connects to the distributed cache cluster and performs data consistency verification with the current temporary master node using a preset hash value comparison rule to determine whether there is missing or different data. When the faulty node detects missing or discrepancies in data, it retrieves and supplements the corresponding data from the temporary master node to fill in the missing or discrepancies. After the replenishment is completed, the faulty node sends a verification completion signal to the cluster management node; After receiving the verification completion signal, the cluster management node records the recovery status of the faulty node; The temporary master node maintains the current read / write task execution state until the preset maintenance window; After the current read / write task execution status reaches the preset maintenance window, the cluster management node sends a role switchback command to the temporary master node and the faulty master node; After receiving the role switchback instruction, the temporary master node and the faulty master node perform incremental synchronization to confirm data consistency. After synchronization is completed, they respectively send a synchronization confirmation signal to the cluster management node. After receiving the synchronization confirmation signal sent by both parties, the cluster management node sends a role switchback confirmation command to the temporary master node and the faulty master node. Upon receiving the role switchback confirmation instruction, the temporary master node switches to a slave node, and the faulty master node is restored to the master node.

7. A data acquisition and storage system, characterized in that, The data acquisition and storage system is a data acquisition and storage system for organic light-emitting diode inkjet printing equipment. The data acquisition and storage system includes a data acquisition client cluster and a distributed cache cluster. The distributed cache cluster includes at least three master nodes, and the data acquisition client cluster includes at least three data acquisition clients. The acquisition client is used to acquire acquisition tasks from the organic light-emitting diode inkjet printing equipment. Based on the preset data type classification rules of the organic light-emitting diode inkjet printing equipment, the acquisition task is divided into multiple independent sub-tasks, wherein the number of independent sub-tasks is adapted to the number of acquisition clients. Each of the aforementioned acquisition clients will match and allocate each of the independent subtasks to the corresponding acquisition client based on the load requirements of each independent subtask and its own resource status; Each of the acquisition clients collects raw data from the organic light-emitting diode inkjet printing equipment in parallel according to the assigned independent sub-tasks, and sends the raw data of the same type to the corresponding master node of the distributed cache cluster according to the type corresponding to the preset data type classification rules. Each master node is used to receive the raw data of the corresponding type, divide the storage partitions according to the type corresponding to the preset data type classification rules, and write the raw data directly into local memory to complete real-time storage.

8. An organic light-emitting diode inkjet printing device, characterized in that, The organic light-emitting diode inkjet printing equipment includes a processor, a memory, and a data acquisition and storage program stored in the memory that can be executed by the processor, wherein when the data acquisition and storage program is executed by the processor, it implements the steps of the data acquisition and storage method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium stores a data acquisition and storage program, wherein when the data acquisition and storage program is executed by a processor, it implements the steps of the data acquisition and storage method as described in any one of claims 1 to 6.

Images