Industrial pcb collaborative control method based on open source os and flying dragon cpu

Abstract

The application discloses an industrial PCB collaborative control method based on open source Hongmeng and Feiteng CPU, and particularly relates to the technical field of industrial automation production line control, and is used for solving the problem that quality control instructions and board card physical flow are difficult to accurately synchronize in the existing PCB production line, leading to the problem of adjustment instruction lag or misoperation. A unique identifier is generated for each printed circuit board, and the position thereof is tracked in real time. When the board card enters a synchronous control area, the state of each execution device is acquired by the Feiteng CPU. Based on the state consistency, a data query strategy is selected, and node state feedback and quality data are collected. The system consensus convergence rate and the phase frequency characteristic distortion index are calculated, and the trigger time point of the control instruction is dynamically adjusted when the index is abnormal. The corrected instruction is sent to the execution device through the open source Hongmeng distributed soft bus, so that high-precision collaborative control of the instruction and the board card flow is realized, and the real-time performance and reliability of the closed-loop quality control are improved.

Description

Technical Field

[0001] This invention relates to the field of industrial automated production line control technology, and more specifically, to an industrial PCB collaborative control method based on open-source HarmonyOS and Phytium CPU. Background Technology

[0002] In the industrial printed circuit board (PCB) manufacturing field, especially in surface mount technology production lines, achieving high-precision and high-efficiency production is a core objective. Currently, automated inspection equipment, such as solder paste inspection SPI, automated optical inspection AOI, and manufacturing execution systems (MES), can be integrated to build data-driven intelligent production lines. Existing technologies typically employ centralized or hierarchical control architectures, connecting equipment distributed across various processes on the production line via industrial networks. The aim is to utilize the inspection results from upstream processes to adjust the production parameters of downstream processes in real time, thereby forming a closed-loop quality control system to improve overall yield and process capability.

[0003] However, in the aforementioned data feedback-based control mode, there is an inherent time delay from the acquisition of quality data by the testing equipment to the processing of data and generation of adjustment instructions by the control system, and then to the execution of the equipment response instructions. Under the condition of continuous high-speed operation of the production line, this delay will cause the quality adjustment instructions for a specific board to be unable to be precisely synchronized with the physical circulation process of that board. As a result, the feedback of the control system may lag behind the actual production rhythm, causing the adjustment instructions to be mistakenly applied to subsequent boards. Not only will it fail to effectively correct defects, but it may also interfere with the normal production rhythm, thus restricting the actual application effect of the closed-loop quality control system in high-speed precision manufacturing scenarios. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, this invention provides an industrial PCB collaborative control method based on open-source HarmonyOS and Phytium CPU to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] An industrial PCB collaborative control method based on open-source HarmonyOS and Phytium CPU includes:

[0007] S1. Obtain the unique identifier for each printed circuit board and collect the real-time location information of the printed circuit board;

[0008] S2. The Phytium CPU compares the real-time position information with the preset boundary coordinates of the synchronization control area to determine whether the printed circuit board has entered the synchronization control area.

[0009] S3. When it is determined that the printed circuit board has entered the synchronization control area, the Phytium CPU obtains the real-time status identifiers of each execution device participating in the current collaborative task.

[0010] S4. Based on the consistency of the real-time status identifiers of each execution device, select the corresponding data query strategy, obtain the node status feedback of each execution device participating in the collaboration through the distributed soft bus of the open-source HarmonyOS operating system, and collect the quality detection data stream and the action feedback signal of the execution device.

[0011] S5. Calculate the consensus convergence rate of the distributed system based on node state feedback, and identify the phase frequency distortion index of the control loop based on data flow and feedback signal.

[0012] S6. When the consensus convergence rate is lower than the first threshold or the phase frequency characteristic distortion index exceeds the second threshold, the Phytium CPU adjusts the triggering time of the control instruction and sends the corrected control instruction to the execution device through the distributed soft bus.

[0013] Furthermore, a unique identifier for each printed circuit board is obtained, and real-time location information of the printed circuit boards is collected, including:

[0014] The identification device deployed at the beginning of the production line is triggered to identify the incoming printed circuit board;

[0015] Based on the recognition results, the pre-set identification information on the printed circuit board is analyzed to generate a unique identifier that corresponds one-to-one with the printed circuit board.

[0016] In response to the completion of unique identifier generation, photoelectric position sensors or encoders arranged along the production line are triggered;

[0017] By reading the pulse signals or coordinate data fed back from the position sensor and combining them with the conveyor speed of the production line, the real-time position information of the printed circuit board can be calculated.

[0018] Furthermore, the Phytium CPU compares the real-time position information with the preset boundary coordinates of the synchronization control area to determine whether the printed circuit board has entered the synchronization control area, including:

[0019] Read the boundary coordinates of the synchronization control area from the pre-stored configuration parameters;

[0020] The calculated real-time position information of the printed circuit board is compared algebraically with the boundary coordinates of the synchronous control area.

[0021] When the real-time location information meets the interval conditions defined by the boundary coordinates of the synchronization control area, it is determined that the printed circuit board has entered the synchronization control area, and a status flag indicating that it has entered the area is added to the unique identifier of the printed circuit board.

[0022] Furthermore, when the printed circuit board is determined to have entered the synchronization control area, the Phytium CPU obtains the real-time status identifiers of each execution device participating in the current collaborative task, including:

[0023] Based on the unique identifier of the printed circuit board and the location of the synchronization control area, determine the list of execution devices participating in the current collaborative task from the pre-configured collaborative task mapping relationship;

[0024] The distributed soft bus of the open-source HarmonyOS operating system sends status query requests to each execution device in the execution device list.

[0025] Receive response data packets returned by each execution device, and parse out the real-time status identifiers representing the working status of the device from each response data packet.

[0026] Furthermore, the real-time status indicator includes one of ready, busy, or faulty.

[0027] Furthermore, based on the consistency of the real-time status identifiers of each execution device, a corresponding data query strategy is selected, including:

[0028] Determine whether all real-time status identifiers obtained from the list of execution devices are in a ready state;

[0029] If all are in a ready state, the full data query strategy is selected. The distributed soft bus of the open-source HarmonyOS is used to send a status feedback query command containing a complete parameter request to each execution device in the execution device list, and simultaneously send a data acquisition command requesting a complete historical data stream to the quality inspection device.

[0030] If not all are in a ready state, a simplified data query strategy is selected. The distributed soft bus of the open-source HarmonyOS is used to send status feedback query instructions containing only core status queries to each execution device in the execution device list, and simultaneously send data acquisition instructions requesting only the latest real-time data points to the quality inspection device.

[0031] Furthermore, the distributed soft bus of the open-source HarmonyOS operating system is used to obtain node status feedback from each participating execution device, and to collect quality detection data streams and execution device action feedback signals, including:

[0032] Receive node status feedback data packets returned by each execution device according to the status feedback query command, and receive quality inspection data streams returned by the quality inspection device according to the data acquisition command;

[0033] Meanwhile, the distributed soft bus continuously monitors and collects the action feedback signals generated by each execution device when performing actions.

[0034] Furthermore, the consensus convergence rate of the distributed system is calculated based on node state feedback, including:

[0035] Check the timestamps in the node status feedback data packets returned by each execution device to confirm the order of the node status responses;

[0036] Analyze the status information carried in the status feedback data packets of each node to determine whether all nodes have a consistent understanding of the status of the current collaborative task.

[0037] The efficiency of the entire distributed system in achieving state consensus is evaluated based on the proportion of nodes with consistent state perception to the total number of nodes, and the total time interval from the first node's response to the last node's response. This efficiency is then quantified as the consensus convergence rate.

[0038] Furthermore, the phase-frequency characteristic distortion index of the control loop is identified based on the data stream and feedback signal, including:

[0039] The collected quality inspection data stream is time-aligned with the action feedback signal of the execution device to form the input-output sequence of the control loop;

[0040] The dynamic response characteristics of the control loop are evaluated by analyzing the response speed and waveform consistency of the output sequence following the change of the input sequence.

[0041] The dynamic response characteristics obtained from the current evaluation are compared with the pre-stored baseline dynamic response characteristics, and the phase frequency characteristic distortion index is calculated based on the degree of deviation of the key response parameters.

[0042] Furthermore, when the consensus convergence rate falls below the first threshold or the phase-frequency characteristic distortion index exceeds the second threshold, the Phytium CPU adjusts the triggering time of the control instructions and sends the corrected control instructions to the execution device via the distributed soft bus, including:

[0043] The calculated consensus convergence rate is compared with the pre-stored first threshold, and the identified phase-frequency characteristic distortion index is compared with the pre-stored second threshold.

[0044] If the consensus convergence rate is lower than the first threshold, the amount of time that the control command triggering time needs to be advanced is calculated based on the magnitude of the difference from the first threshold.

[0045] If the phase frequency characteristic distortion index exceeds the second threshold, the amount of time that needs to be delayed to trigger the control command is calculated based on the magnitude of the excess.

[0046] The triggering time of the original control command is adjusted according to the determined time amount, and the corrected control command data packet is generated.

[0047] The modified control command data packets are sent to the corresponding execution devices in the list of execution devices participating in the current collaborative task through the distributed soft bus of the open-source HarmonyOS operating system.

[0048] Compared with the prior art, the present invention has the following beneficial effects:

[0049] 1. By introducing a distributed collaborative control mechanism triggered by physical location, the problem of insufficient synchronization accuracy between quality control commands and physical flow of boards in high-speed PCB production lines is effectively solved. By establishing a unique identifier for each printed circuit board and tracking its position in real time, when a board enters a preset synchronization control area, a collaborative control process for that specific board is immediately initiated. This ensures that the triggering of quality control commands is strictly bound to the physical location of a specific board, avoiding the command misalignment problem caused by production line speed fluctuations or equipment response delays in traditional time-driven control methods. Phytium CPU, as the control core, combined with the distributed soft bus of the open-source HarmonyOS operating system, enables rapid acquisition and collaborative judgment of the status of execution equipment distributed in each process, ensuring that the system status information on which control commands are based has a high degree of real-time performance and consistency.

[0050] 2. By dynamically evaluating the system consensus convergence rate and control loop phase frequency characteristics, adaptive optimization of control timing is achieved. When system response delay or control characteristic distortion is detected, the triggering timing of control commands can be intelligently advanced or delayed, significantly improving the robustness of collaborative control in high-speed dynamic environments. Position synchronization, state coordination, and adaptive timing adjustment are organically integrated. Without making major changes to the existing production line hardware, high-precision synchronization between quality control commands and board physical flow is achieved, thereby significantly improving the practicality and reliability of the closed-loop quality control system in high-speed precision manufacturing scenarios. Attached Figure Description

[0051] Figure 1 This is a flowchart of the industrial PCB collaborative control method based on open-source HarmonyOS and Phytium CPU, as described in this invention. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0053] Example: Figure 1 This invention presents an industrial PCB collaborative control method based on open-source HarmonyOS and Phytium CPU, including:

[0054] S1. Obtain the unique identifier for each printed circuit board and collect the real-time location information of the printed circuit board;

[0055] S2. The Phytium CPU compares the real-time position information with the preset boundary coordinates of the synchronization control area to determine whether the printed circuit board has entered the synchronization control area.

[0056] S3. When it is determined that the printed circuit board has entered the synchronization control area, the Phytium CPU obtains the real-time status identifiers of each execution device participating in the current collaborative task.

[0057] S4. Based on the consistency of the real-time status identifiers of each execution device, select the corresponding data query strategy, obtain the node status feedback of each execution device participating in the collaboration through the distributed soft bus of the open-source HarmonyOS operating system, and collect the quality detection data stream and the action feedback signal of the execution device.

[0058] S5. Calculate the consensus convergence rate of the distributed system based on node state feedback, and identify the phase frequency distortion index of the control loop based on data flow and feedback signal.

[0059] S6. When the consensus convergence rate is lower than the first threshold or the phase frequency characteristic distortion index exceeds the second threshold, the Phytium CPU adjusts the triggering time of the control instruction and sends the corrected control instruction to the execution device through the distributed soft bus.

[0060] S1. Obtain the unique identifier for each printed circuit board and collect the real-time location information of the printed circuit board. The specific implementation is as follows:

[0061] In the implementation of the industrial PCB collaborative control method based on open-source HarmonyOS and Phytium CPU, obtaining the unique identifier of each printed circuit board and collecting its real-time position information is the initial step of collaborative control. This process begins by triggering an identification device deployed at the starting station of the surface mount technology production line. This identification device can be an industrial-grade QR code scanner or a high-frequency RFID reader. When the conveyor belt transports a new printed circuit board to the starting station, a photoelectric sensor installed at the entrance of the starting station detects the board's arrival and then sends a high-level trigger signal to the Phytium CPU. Upon receiving this trigger signal, the Phytium CPU immediately sends a start command to the identification device through its general-purpose input / output interface. Upon receiving the command, the identification device begins image acquisition or radio frequency signal scanning of the printed circuit board entering its field of view or sensing area.

[0062] Based on the raw data collected by the identification device, the system begins the step of parsing the pre-installed identification information on the printed circuit board. If the identification device is a QR code scanner, it images the QR code pattern pre-installed on the printed circuit board fixture or edge, and converts the QR code pattern information in the image into a string of character codes using the decoding algorithm integrated within the scanner. If the identification device is an RFID reader / writer, it transmits radio frequency signals through an antenna and reads the encoded information stored in the RFID electronic tags pre-embedded in the printed circuit board or its carrier board. The raw encoded information directly obtained in this process may contain basic information such as production batch and board model, but in order to generate a unique identifier that strictly corresponds to the physical board within the global scope of this production task, the system will reconstruct the raw encoded information. One implementation of the reconstruction includes concatenating the read raw code with a timestamp accurate to milliseconds generated by the system's global clock, and then generating a fixed-length hash value string using a specific hash operation function such as the SHA-256 algorithm. This string is defined as a unique identifier that corresponds one-to-one with the current printed circuit board. For example, the original code is PCB2024A1. Combined with the timestamp 20240520103030000, a unique identifier similar to a1b2c3d4e5f6 may be generated after hashing. This identifier will be immediately recorded by the Phytium CPU in a specific data structure in memory and associated with all subsequent operation processes of this board.

[0063] In response to the completion of unique identifier generation, the Phytium CPU immediately sends trigger acquisition commands via its control bus to a series of photoelectric position sensors or rotary encoders mounted on the drive shaft along the production line. These position sensors are pre-installed precisely at key nodes along the conveyor belt path, for example, a through-beam photoelectric sensor every 500 mm, or a high-precision incremental rotary encoder with 1000 pulses per revolution installed coaxially with the conveyor belt's drive roller. After the trigger command is issued, the Phytium CPU begins to continuously and cyclically read the electronic signals fed back by the position sensors through its data acquisition interface. For through-beam photoelectric sensors, the feedback is a falling edge pulse signal indicating the front end of the board passes each detection point. For rotary encoders, the feedback is a two-phase (A and B) square wave pulse signal. The Phytium CPU counts the pulses using an internal counter and converts them into coordinate data representing the cumulative displacement of the conveyor belt.

[0064] After reading the feedback signal from the position sensor, the Phytium CPU calculates the real-time position information of the printed circuit board based on the preset conveyor speed of the production line. The specific calculation process is as follows: During the initialization phase, the system has set the constant conveyor speed parameter of the production line through the parameter configuration table, for example, the speed value is set to 150 mm / s. When the system mainly relies on the photoelectric sensor array for positioning, the Phytium CPU accurately records the timestamp of each pulse signal. Combining this with the known installation coordinates of each sensor, it calculates the difference between the sensor coordinates corresponding to the current pulse and the sensor coordinates corresponding to the previous pulse, and performs interpolation compensation by considering the product of the pulse time interval and the conveyor speed, thereby calculating the real-time position of the leading edge of the board relative to the origin of the production line coordinate system. When the system mainly relies on the rotary encoder for positioning, each pulse issued by the encoder corresponds to a fixed small displacement of the conveyor belt. This displacement is determined by the number of pulses per revolution of the encoder and the circumference of the conveyor belt rollers. For example, the configuration result is a displacement of 0.1 mm per pulse. The Phytium CPU directly obtains the precise real-time position coordinates of the printed circuit board's reference point by accumulating the total number of pulses received from a set reference zero point and multiplying it by the displacement of a single pulse. This calculation process is performed continuously and uninterruptedly in a loop controlled by a real-time operating system task, ensuring that the precise position of the printed circuit board moving on the production line can be tracked in real time at a sufficient sampling frequency. The final real-time position information data is bound to its corresponding unique identifier to form a complete position tracking record, providing an accurate data basis for subsequent steps to determine whether the board has entered the synchronization control area.

[0065] S2. The Phytium CPU compares the real-time position information with the preset boundary coordinates of the synchronization control area to determine whether the printed circuit board has entered the synchronization control area. Specifically, the implementation is as follows:

[0066] The process of a Phytium CPU determining whether a printed circuit board has entered the synchronization control area begins by reading the boundary coordinates of the synchronization control area from pre-stored configuration parameters. These configuration parameters are stored in the Phytium CPU's non-volatile memory in structured data form, such as an XML-formatted configuration file. This file is loaded from the storage medium into a specific area of ​​memory by the Phytium CPU's operating system during system initialization. The boundary coordinates of the synchronization control area are defined in this configuration file as a continuous linear interval in the production line coordinate system, determined by both the start and end boundary coordinates. These values ​​are input by technicians during the production line installation and commissioning phase, based on the physical installation location and process sequence requirements of each execution device on the surface mount technology production line, through a human-machine interface and permanently saved to the configuration file. For example, technicians can set the start boundary coordinates of the synchronization control area to 1200 mm and the end boundary coordinates to 1800 mm based on the distance between the placement machine and the soldering oven. Phytium CPU calls a predefined parameter access function, passing a parameter identifier representing the boundary coordinates of the synchronization control region to the function. After the function executes, it returns the specific values ​​of the start and end boundary coordinates from the configuration data block in memory.

[0067] After successfully reading the boundary coordinates of the synchronization control area, the Phytium CPU immediately enters the comparison and judgment stage, which involves performing an algebraic comparison between the calculated real-time position information of the printed circuit board and the read boundary coordinates. The real-time position information, continuously calculated in the preceding steps, represents the distance of the leading edge of the printed circuit board, representing a specific unique identifier, relative to the origin of the production line coordinate system at the current moment, measured in millimeters. The logical purpose of the algebraic comparison is to determine whether the real-time position information value lies within the closed interval defined by the starting and ending boundary coordinates. The specific comparison operation is implemented through conditional statements in the program, which contain two sub-conditions that must be satisfied simultaneously. The first sub-condition checks whether the value of the real-time position information is greater than or equal to the value of the starting boundary coordinate. The second sub-condition checks whether the value of the real-time position information is less than or equal to the value of the ending boundary coordinate. The Phytium CPU's arithmetic logic unit calculates these two Boolean expressions sequentially or in parallel.

[0068] The Phytium CPU will determine that the printed circuit board has entered the synchronization control area only if the logical AND operation of the above two sub-conditions is true, that is, if the real-time position information simultaneously satisfies the condition of being greater than or equal to the starting boundary coordinates and less than or equal to the ending boundary coordinates. Once the entry determination is formed, the system immediately performs a status marking operation. The target of this operation is the status record associated with the unique identifier of the current printed circuit board. The system will index the corresponding record in the information table that manages the status of all online boards through the unique identifier, and find the field specifically used to identify the area status. Then, the value of this field will be updated from the initial state indicating that the board has not entered the area, such as the value 0 or the string "Outside", to the state indicating that the board has entered the area, such as the value 1 or the string "Inside". This action of adding an entry status mark to the unique identifier of the printed circuit board marks that the board has officially entered the physical segment that requires the initiation of collaborative control logic. This status mark will serve as the direct trigger condition for the Phytium CPU to decide whether to obtain the real-time status identifier of the execution device in subsequent steps. The entire comparison and marking process is completed within a strictly defined control cycle, ensuring real-time synchronization between the system response and the physical movement of the printed circuit board.

[0069] S3. When the printed circuit board is determined to have entered the synchronization control area, the Phytium CPU obtains the real-time status identifiers of each execution device participating in the current collaborative task. Specifically, this is implemented as follows:

[0070] Once the Phytium CPU determines, based on the aforementioned steps, that a specific printed circuit board (PCB) has entered the synchronization control area, it immediately triggers a process to obtain the real-time status identifiers of each execution device participating in the current collaborative task. The initiation condition of this process directly depends on the entry area status flag added to the PCB's unique identifier; changes to this flag are notified to the Phytium CPU's application logic layer as a system event. The Phytium CPU first executes the step of determining the list of execution devices from the pre-configured collaborative task mapping relationship based on the PCB's unique identifier and the location of the synchronization control area. The pre-configured collaborative task mapping relationship is a data structure pre-defined and persistently stored by engineers using configuration tools before the system goes into production. Its physical form can be a table in a relational database or a structured configuration file in a file system, such as a database table named TaskDeviceMapping. This mapping table contains multiple fields, among which key fields include the synchronization control area location code, the PCB type code, and the corresponding execution device group identifier. The synchronization control area location code typically corresponds to the numbering of different physical sections on the production line, for example, numbered sequentially from the start of the production line as 1, 2, 3, etc. The printed circuit board (PCB) type code originates from a specific segment of the PCB's unique identifier. The Phytium CPU maps this unique identifier to a standard type code by parsing rules, such as extracting the prefix representing the product model. The Phytium CPU uses the type code parsed from the PCB's unique identifier in the currently entered region and the location code of the current synchronization control region as a composite primary key, performing a query operation in the collaborative task mapping table. Database queries are implemented using standard Structured Query Language (SCL) statements, such as a SELECT statement with a WHERE clause specifying the matching conditions for the type code and region code. The query result returns a record set containing a list of logical addresses or device identifiers of all execution devices that need to participate in collaboration for this type of PCB in that region. For example, for a board with type code PCB_TYPE_A and entering a synchronization control region with location code 3, the query might return a list containing device IDs_DISPENSER_01, ID_PLACER_02, and ID_REFLOW_03. This list is stored by the Phytium CPU in a dynamic array or linked list data structure in memory, called the execution device list.

[0071] Next, the Phytium CPU sends status query requests to each execution device in the execution device list via the distributed soft bus of the open-source HarmonyOS operating system. The distributed soft bus of the open-source HarmonyOS operating system is a built-in cross-device communication framework that provides a set of application programming interfaces for device discovery and data exchange. The control application running on the Phytium CPU calls the device communication functions in the distributed soft bus client library. When calling these functions, the application needs to pass in the logical identifier of the target execution device, the type code of the request message, and necessary parameters. Each logical identifier in the execution device list first needs to be resolved into network-addressable endpoint information, such as the device's IP address and port number, through the service discovery mechanism of the distributed soft bus. The construction of the status query request message follows the protocol format defined by the distributed soft bus, which includes a fixed-length message header and a variable-length message body. The message header contains a message type field, whose value is set to the predefined STATUS_QUERY_CODE, used to identify this as a status query request. The message body can contain fine-grained parameters for the query, such as the level of detail of the requested status information. The Phytium CPU traverses the execution device list, constructing and sending an independent status query request message for each device identifier in the list. Message sending is implemented at the operating system's network socket interface, employing reliable transport protocols such as TCP to ensure no data packets are lost. For each sending request, the Phytium CPU starts an independent timeout timer, with a timeout threshold set to, for example, 3000 milliseconds. This threshold can be configured based on network conditions.

[0072] The Phytium CPU then enters the response reception and parsing phase. The service process running on the Phytium CPU, part of the open-source HarmonyOS distributed soft bus, listens to a designated network port and receives response data packets from various execution devices. Each response data packet also conforms to the distributed soft bus protocol specifications. Upon receiving a data packet, the Phytium CPU first performs integrity checks, such as calculating a checksum to verify that no errors occurred during data transmission. After successful verification, it begins parsing the data packet structure. The parsing process includes extracting the source device identifier from the message header and extracting the status data payload from the message body. The format of the status data payload is pre-defined, such as using JavaScript object notation or a simple key-value pair format. Real-time status identification information is typically contained under a specific key in the payload, such as a value corresponding to a key named "operational_status". This value is a discrete enumeration value or a string code. The Phytium CPU converts the received raw status code into a unified real-time status identifier based on a pre-loaded status mapping table. The state mapping table defines the correspondence between raw codes and standard state identifiers. For example, the code "READY" returned by the device maps to the ready state, the code "BUSY" maps to the busy state, and the code "ERROR" maps to the fault state. Real-time state identifiers are limited to one of three types: ready, busy, or faulty. Each state has a clear semantic definition: ready indicates that the device is idle, functioning normally, and can immediately execute new instructions; busy indicates that the device is processing a task and resources are occupied; faulty indicates that the device's self-test has detected a hardware abnormality or software error, requiring manual intervention. The Phytium CPU maintains a state record entry for each device in the execution device list, updating the corresponding entry with the parsed real-time state identifier. Simultaneously, the Phytium CPU manages response timeouts; if a device's response is not received after the timeout timer expires, the device's real-time state identifier is marked as unknown. The unknown state can be considered a special fault state to simplify subsequent logic. This process continues until all devices in the list have a definite state identifier or the timeout process is complete. Ultimately, the Phytium CPU obtains a complete state snapshot reflecting the availability of each execution device at the current moment, providing a decision-making basis for the data query strategy selection in subsequent steps. The entire acquisition process ensures the real-time performance and reliability of status information collection in a distributed environment.

[0073] S4. Based on the consistency of the real-time status identifiers of each execution device, select the corresponding data query strategy, obtain the node status feedback of each execution device participating in the collaboration through the distributed soft bus of the open-source HarmonyOS operating system, and collect the quality detection data stream and the action feedback signal of the execution device. The specific implementation is as follows:

[0074] The process by which the Phytium CPU selects the corresponding data query strategy based on the consistency of the real-time status identifiers of each execution device is a crucial decision-making step. Here, consistency specifically refers to the consistency or difference in status type among all real-time status identifiers obtained from the execution device list. The Phytium CPU first determines whether all real-time status identifiers obtained from the execution device list are in a ready state. This determination is implemented through a loop comparison algorithm, where the Phytium CPU traverses each real-time status identifier entry stored in the execution device list data structure. The execution device list is a data set determined in the preceding steps from the pre-configured collaborative task mapping relationship based on the unique identifier of the printed circuit board and the location of the synchronization control area. It contains reference information for all execution devices that need to participate in the current collaborative task and their corresponding real-time status identifiers. The real-time status identifiers are obtained in an earlier step by querying each execution device and parsing its response data packets; their values ​​are limited to one of ready, busy, or faulty. The Phytium CPU compares the status identifier value recorded in each entry with a predefined ready state constant value. For example, a ready state might be represented by the integer value 1 in the system, a busy state by the integer value 2, and a faulty state by the integer value 3. During the traversal, the Phytium CPU maintains a temporary flag variable, initially set to a logical true value. Starting with the first entry in the execution device list, the Phytium CPU reads the real-time status flag value stored in that entry and compares it to the ready state value of 1. If they are equal, it continues checking the real-time status flag value of the next entry. If any real-time status flag value is found to be different from the ready state value—for example, a busy state value of 2 or a fault state value of 3—this temporary flag variable is immediately set to a logical false value, and the traversal can be terminated early to optimize performance. After traversing the entire execution device list, the Phytium CPU checks the value of this temporary flag variable. If the flag variable is still logically true, it indicates that all real-time status flags are ready. If the flag variable is logically false, it indicates that at least one non-ready status flag exists, meaning not all are ready. This judgment logic ensures the accuracy and completeness of the state consistency assessment, providing a clear Boolean decision for subsequent strategy selection.

[0075] When the judgment result indicates that all real-time status indicators are in a ready state, the Phytium CPU selects the full data query strategy. The full data query strategy is a predefined data acquisition specification designed to obtain the most comprehensive system status information to support refined collaborative control decisions. After selecting this strategy, the Phytium CPU immediately sends a status feedback query instruction containing a full parameter request to each execution device in the execution device list via the distributed soft bus of the open-source HarmonyOS operating system. A full parameter request means that the set of query fields contained in the instruction covers all aspects of the device status. The status feedback query instruction data packet constructed by the Phytium CPU follows the communication protocol format defined by the distributed soft bus. This data packet contains a fixed header and a variable-length body. The header contains information such as the target device identifier and the instruction type code. The instruction type code is set to a specific value, such as FULL_STATUS_QUERY, to indicate that this is a full query request. The body contains a request parameter list, which specifies in detail the categories of status parameters that need to be returned. For example, for a pick-and-place machine, the request parameter list might include dozens of parameters such as the machine's current operating mode code, real-time position coordinates of all motion axes, nozzle vacuum pressure, component feeder status, vision system calibration status, temperature readings of major internal components, current cycle load percentage, detailed error code register contents, and current level status of all digital input / output ports. This parameter list is predefined during the system integration phase based on the capabilities of each device model and the information requirements for collaborative control, and is stored in the Phytium CPU's configuration file. The Phytium CPU constructs corresponding instruction data packets for each device in the execution device list and sends them out through the communication interface of the distributed soft bus. Simultaneously, the Phytium CPU synchronously sends data acquisition commands requesting complete historical data streams to the independently existing quality inspection devices in the system. Here, the complete historical data stream refers to all raw sampling data or pre-processed data point sequences collected and cached by the quality inspection device within the most recent configurable time period. The quality inspection device might be an online optical inspection instrument or X-ray inspection device. The data acquisition commands constructed by the Phytium CPU explicitly specify parameters such as the data time range, sampling point interval, and data format. For example, the instruction might request the optical inspection instrument to return the brightness value sequence, contrast sequence, and coordinate information of each solder joint, acquired over the past 5 seconds at a sampling rate of 1000 Hz. This instruction is also sent to the quality inspection equipment via a distributed soft bus.

[0076] When the judgment result indicates that not all devices are in a ready state, meaning at least one execution device is in a busy or faulty state, the Phytium CPU selects a simplified data query strategy. This simplified data query strategy is another optimized data acquisition specification. Its core objective is to quickly obtain critical status information when the system has potential instability factors, thereby reducing communication overhead and decision latency, and prioritizing system response speed. After selecting this strategy, the Phytium CPU sends a status feedback query instruction containing only the core status query to each execution device in the execution device list via the distributed soft bus of the open-source HarmonyOS operating system. The core status query limits the query to only a few status parameters most critical to the collaborative control decision. These parameters represent the minimum necessary information set to determine whether a device can immediately engage in collaborative tasks. In this case, the instruction type code in the status feedback query instruction data packet constructed by the Phytium CPU is set to another specific value, such as CORE_STATUS_QUERY. The message body of the instruction contains only a simplified list of request parameters. This list typically includes only the device's basic ready status flags, a comprehensive error status code, the emergency stop button status flag, and possible bus communication statuses. For example, for the same pick-and-place machine, a simplified query might only request a single byte representing the overall health status of the device, with specific values ​​indicating ready, busy, faulty, or warning, instead of dozens of detailed parameters. The Phytium CPU synchronously sends a data acquisition command to the quality inspection equipment, requesting only the latest real-time data points. This command no longer requests historical data streams, but only requires the quality inspection equipment to return a single or a few latest data points acquired within the most recent sampling period. For example, the command might only request the optical inspection instrument to return the brightness value of the most recently inspected solder joint, a pass / fail result code, and the coordinates of that solder joint, without returning historical waveform data from the past. This simplified request significantly reduces network data transmission volume and processing time, enabling the Phytium CPU to obtain system core state snapshots more quickly.

[0077] After issuing the corresponding status feedback query command and data acquisition command, the Phytium CPU begins executing the steps of obtaining node status feedback from each participating execution device and collecting quality detection data streams and execution device action feedback signals through the distributed soft bus of the open-source HarmonyOS operating system. First, the Phytium CPU receives node status feedback data packets returned by each execution device according to the status feedback query command. Regardless of whether a complete or simplified query command was previously sent, each execution device, upon receiving the query command, identifies the query type based on the command type code, collects the requested parameter data from its internal status registers or variables, constructs a response data packet conforming to the distributed soft bus protocol format, and returns it to the Phytium CPU. The Phytium CPU's network communication layer listens to the network port and receives these data packets. Upon arrival of each data packet, the Phytium CPU first performs basic communication verification, such as cyclic redundancy check, to ensure data integrity. After successful verification, it parses the packet header to identify the source device identifier, and then parses the packet body according to the command type. For responses to complete query commands, the data packet payload is larger, containing a complete list of requested status parameters and their current values. The Phytium CPU extracts these values ​​according to a predefined parameter mapping table and fills them into the corresponding fields of a unified status feedback data structure. For responses to simplified query commands, the data packet payload is small, containing only the values ​​of the core status parameters. The Phytium CPU also parses these values ​​and updates the core status fields of the status feedback data structure. Simultaneously, the Phytium CPU receives the quality inspection data stream returned by the quality inspection device based on the data acquisition command. If the command previously sent requested a complete historical data stream, the received data may be a large data block or a stream of data over a specified period, containing a sequence of historical data within a specified time range. The Phytium CPU needs to allocate sufficient buffer space to receive and store this data. If the command previously sent requested the latest real-time data point, the received data is typically a smaller packet containing only the latest sampled value and its associated timestamp. The quality inspection data stream is stored in a dedicated data buffer or queue for subsequent analysis.

[0078] Meanwhile, the Phytium CPU continuously monitors and collects the action feedback signals generated by each execution device during its actions via a distributed soft bus. This process is asynchronous and does not rely on the aforementioned query-response pattern; instead, it is based on the event publish-subscribe mechanism provided by the distributed soft bus. During system initialization, the Phytium CPU subscribes to event types of interest to the distributed soft bus. These event types are related to the completion of specific actions or state transitions of each execution device. When each execution device completes a specific action or undergoes a significant state change, it actively publishes an event message to the distributed soft bus; this message is the action feedback signal. For example, when a pick-and-place machine successfully completes a cycle of picking up and placing a component, it publishes an event message. The payload of this message may include the X, Y, and Z coordinates of the placement position, the pressure value used during placement, the nozzle number, the component number, and the timestamp of the action completion. Similarly, when a reflow oven reaches a set temperature or triggers an alarm, it also publishes a corresponding event. The distributed soft bus is responsible for routing these event messages in real time to all subscribers who have subscribed to that event type, and the Phytium CPU, as one of the subscribers, will receive these messages. The Phytium CPU internally runs an event processing loop that continuously checks for new event messages. Whenever an action feedback signal is received, the event processing logic parses it from the message format into an internal representation, extracting key information such as device identifier, action type, feedback data, and timestamp, and recording this information in a dedicated action feedback log or real-time database. This data acquisition architecture, combining synchronous querying and asynchronous listening, ensures that the Phytium CPU can obtain detailed device status information on demand and perceive the dynamic operation results of the device in near real-time. This provides a comprehensive, timely, and multi-granular data foundation for subsequent calculations of consensus convergence rate and identification of phase-frequency characteristic distortion index. The entire data acquisition process demonstrates the intelligence of adaptively adjusting the monitoring granularity according to the real-time system status, balancing information detail with system overhead.

[0079] S5. Calculate the consensus convergence rate of the distributed system based on node state feedback, and identify the phase-frequency distortion index of the control loop based on data flow and feedback signals. The specific implementation is as follows:

[0080] The process by which the Phytium CPU calculates the consensus convergence rate of a distributed system based on node state feedback begins with a thorough analysis of the received node state feedback data packets. These packets, obtained in the previous steps via the distributed soft bus of the open-source HarmonyOS operating system, are acquired from the participating execution devices in the current collaborative task. Each packet contains a timestamp added by the source device when generating its response, along with information reflecting the device's understanding of the current collaborative task's state. The Phytium CPU first examines the timestamps in the node state feedback data packets returned by each execution device. The timestamp is typically a high-precision clock value, such as Coordinated Universal Time (UTC) in milliseconds obtained from a distributed system clock synchronization service. The Phytium CPU parses the timestamp information in the header or specific fields of each data packet, converting it into a unified internal time representation format. Then, the Phytium CPU sorts all data packets in ascending order of their timestamp values. The sorting algorithm can be a simple bubble sort or a more efficient quicksort algorithm, the purpose of which is to determine the chronological order of the node state responses. This order reveals the latency differences in the response state queries from different execution devices, forming the basis for evaluating the system's response dispersion. For example, Phytium CPUs might detect that the response timestamp of the pick-and-place machine is 1000 milliseconds, the response timestamp of the soldering machine is 1002 milliseconds, and the response timestamp of the detector is 1005 milliseconds.

[0081] Next, the Phytium CPU analyzes the status information carried in the status feedback data packets of each node to determine whether all nodes have a consistent understanding of the current collaborative task. The status information is located in the payload of the data packets, and its format and semantics are predefined. For each data packet, the Phytium CPU extracts key status fields, which describe the executing device's understanding of key parameters of the current collaborative task, such as whether the device itself is ready, whether it considers other associated devices ready, and whether the current task step can be started. The Phytium CPU compares a predefined standard value or standard pattern representing the ideal consistent state with the status content reported by each device. The logic for determining consistency is to check whether the status content reported by all devices matches this standard state. For example, the standard state might require all devices to report their collaborative readiness flag as true and without error codes. If the status content reported by all devices meets this condition, the state perception is considered consistent. If any device reports an error code or a false readiness flag, the state perception is considered inconsistent. The Phytium CPU counts the number of nodes with consistent state perception.

[0082] Then, Phytium CPU evaluates the efficiency of the entire distributed system in achieving state consensus based on the proportion of nodes with consistent state awareness to the total number of nodes, and the total time interval from the first node's response to the last node's response. The total number of nodes is the total number of devices in the execution device list. The proportion is calculated by dividing the number of nodes with consistent state awareness by the total number of nodes, resulting in a decimal or percentage between 0 and 1. The total time interval is calculated by subtracting the first timestamp from the last timestamp in the sorted timestamp sequence. The consensus convergence rate is an indicator of how quickly the system can get all nodes to a consistent state. Phytium CPU uses the calculated proportion and total time interval as input to an evaluation function. The basic logic of this function is that the higher the proportion and the shorter the total time interval, the higher the consensus convergence rate, indicating better efficiency. A specific quantification method is to divide the proportion value by the total time interval to obtain a measure of effective consensus achieved per unit time, which can be measured in seconds or milliseconds. For example, if the proportion of consistent nodes is 100% (1.0) and the total time interval is 5 milliseconds, then the consensus convergence rate can be calculated as 0.2 per millisecond. Phytium CPU stores this calculation result as the consensus convergence rate value at the current moment.

[0083] In another parallel thread, the Phytium CPU performs the step of identifying the phase-frequency distortion index of the control loop based on the data stream and feedback signal. Here, the control loop refers to a closed-loop control system model that uses the quality inspection data stream as input reference and the execution device action feedback signal as output response. The Phytium CPU first performs timing alignment between the acquired quality inspection data stream and the execution device action feedback signal. The quality inspection data stream is a time-stamped sequence of data received from the quality inspection device. The execution device action feedback signal is a time-stamped sequence of event messages received asynchronously from a distributed soft bus. Since these two data sources may be acquired independently and the timestamp references may have slight deviations, the Phytium CPU needs to perform timing alignment. The alignment method involves finding time-correlated event points in the two sequences, such as the start time of a solder joint inspection in the quality inspection data stream and the completion time of the corresponding placement action in the execution device action feedback signal. Then, a linear interpolation algorithm is used to align the unaligned data points to a unified time axis, thereby forming a time-strictly corresponding input-output sequence pair for the control loop.

[0084] Next, the Phytium CPU evaluates the dynamic response characteristics of the control loop by analyzing the response speed and waveform consistency of the output sequence following changes in the input sequence. The response speed can be evaluated by calculating the delay time of the output sequence relative to the input sequence; for example, finding the time point when the input sequence undergoes a step change, and then finding the time point of the corresponding start point of the change in the output sequence. The difference between the two is the delay. Waveform consistency can be evaluated by calculating the Pearson correlation coefficient between the input sequence and the output sequence after appropriate translation and alignment within a specific time period, or by calculating the mean square error between them. The Phytium CPU may preprocess the input and output sequences, such as using a low-pass filter for noise reduction, and then extract feature parameters, such as rise time, overshoot, and settling time—dynamic performance indicators from classical control theory. These indicators together constitute a quantitative description of the dynamic response characteristics of the current control loop.

[0085] Finally, the Phytium CPU compares the currently evaluated dynamic response characteristics with pre-stored baseline dynamic response characteristics. The baseline dynamic response characteristics are a set of reference dynamic performance index values ​​measured and saved using the same method during the system calibration phase, when the control system performance is considered to be in an ideal state. The comparison process is performed for each key response parameter; for example, comparing the current rise time with the baseline rise time, and comparing the current overshoot with the baseline overshoot. For each parameter, the relative or absolute deviation between its current value and the baseline value is calculated. The phase frequency distortion index is a comprehensive quantitative value of the deviation of these key response parameters. The Phytium CPU can calculate this index using a weighted average method, that is, assigning a weight to the deviation of each response parameter. The weight can be pre-set according to the importance of the parameter to system stability, and then summing the weighted deviations of all parameters to obtain the phase frequency distortion index. The larger the index value, the more severe the distortion of the actual dynamic characteristics of the current control loop relative to the ideal baseline state. The Phytium CPU stores this index value for subsequent decision logic. The entire calculation and identification process makes full use of the data collected in real time, providing a quantitative basis for system performance monitoring and early warning of potential faults.

[0086] S6. When the consensus convergence rate is lower than the first threshold or the phase frequency characteristic distortion index exceeds the second threshold, the Phytium CPU adjusts the triggering time of the control command and sends the corrected control command to the execution device through the distributed soft bus. Specifically, the implementation is as follows:

[0087] The Phytium CPU continuously monitors system performance metrics. When it needs to determine whether to adjust control commands, it first compares the calculated consensus convergence rate with a pre-stored first threshold, and simultaneously compares the identified phase-frequency distortion index with a pre-stored second threshold. The first and second thresholds are values ​​pre-set and stored in the Phytium CPU's non-volatile memory during system initialization based on historical operating data or theoretical calculations. The first threshold represents the minimum acceptable consensus convergence rate, determined by analyzing the distribution of consensus convergence rates in a large amount of historical data during stable operation and taking its statistical lower limit, such as the 5th percentile. The second threshold represents the maximum tolerable phase-frequency distortion, set by artificially introducing known minor faults during system calibration and observing changes in the phase-frequency distortion index to determine the critical point at which it begins to significantly affect system stability. The Phytium CPU reads the currently calculated consensus convergence rate and the currently identified phase-frequency distortion index from memory and performs arithmetic comparisons with the first and second threshold values ​​read from configuration memory. The comparison operation is performed using the processor's comparison instructions. For the consensus convergence rate, its value is checked to see if it is less than a first threshold. For the phase-frequency distortion index, its value is checked to see if it is greater than a second threshold. These two comparison operations can be performed sequentially or in parallel, and the comparison results are both Boolean values ​​and are temporarily stored.

[0088] If the comparison result for a consensus convergence rate falling below a first threshold is true, the Phytium CPU calculates the amount of time needed to advance the control instruction triggering time based on the magnitude of the deviation below the first threshold. The magnitude of the deviation is calculated using arithmetic subtraction: subtracting the current consensus convergence rate from the first threshold value yields a positive difference. This difference reflects the severity of the system's consensus efficiency falling below the expected level. The Phytium CPU then inputs this difference into a preset mapping function or lookup table. This mapping function defines the conversion relationship from consensus convergence rate deviation to displacement compensation time. The basic logic is that the larger the deviation, the greater the advance time required for compensation, attempting to offset the impact of slow system response by issuing instructions earlier. The mapping function can be a simple linear function, where the time amount equals a scaling factor multiplied by the difference. The scaling factor is determined through system simulation or experimentation, and can be set to, for example, ten milliseconds per unit rate deviation. The calculated time amount is a positive value in milliseconds, representing the amount by which the instruction triggering point needs to be moved forward on the time axis.

[0089] If the comparison result of the phase frequency distortion index exceeding the second threshold is true, the Phytium CPU calculates the amount of time delay required for the control command triggering time based on the magnitude of the excess. The magnitude of the excess is also calculated using arithmetic subtraction, i.e., subtracting the second threshold value from the current phase frequency distortion index value to obtain another positive difference. This difference reflects the severity of the dynamic characteristic distortion of the control system exceeding the tolerance range. This difference is input into another independent mapping function or lookup table program. This mapping function defines the conversion relationship from the phase frequency distortion index deviation to the amount of delay time. The logic is that the more severe the distortion, the greater the amount of delay time needed to wait for the system transient response to subside or to avoid issuing commands during unstable periods. This function may also be a linear relationship, where the delay time equals another scaling factor multiplied by the difference, which may be five milliseconds per unit of distortion index deviation. The calculated time is a positive value in milliseconds, representing the amount by which the command triggering point needs to be moved backward on the time axis.

[0090] The Phytium CPU then adjusts the trigger time of the original control instruction based on the determined time amount. The trigger time of the original control instruction is a pre-calculated absolute time point based on standard process timing and stored in the Phytium CPU's planned task queue. The adjustment operation modifies this planned time point. If the calculated amount requires an advance, the Phytium CPU subtracts this amount from the original trigger time point. If the calculated amount requires a delay, the Phytium CPU adds this amount to the original trigger time point. If both adjustments occur simultaneously—that is, a low consensus convergence rate and a high phase-frequency characteristic distortion exponent—the Phytium CPU will handle both comprehensively, for example, by algebraically adding the advance and delay amounts to adjust the original trigger time point. After adjustment, the Phytium CPU uses the corrected trigger time point and other parameters of the original control instruction to regenerate a complete, corrected control instruction data packet conforming to the communication protocol format. The data packet contains fields such as the new trigger timestamp, execution action code, and target parameters.

[0091] Finally, the Phytium CPU sends the corrected control command data packet to the corresponding execution device in the list of execution devices participating in the current collaborative task via the distributed soft bus of the open-source HarmonyOS operating system. The Phytium CPU calls the application programming interface functions provided by the distributed soft bus of the open-source HarmonyOS operating system, specifying the logical identifier of the target execution device and the corrected control command data packet to be sent. The distributed soft bus is responsible for encapsulating this data packet into a low-level network protocol frame, such as an Ethernet frame, and sending it into the industrial network through the network interface controller of the Phytium CPU. The data packet is ultimately routed to the corresponding execution device specified in the execution device list, such as a pick-and-place machine or a soldering machine, based on the device identifier. After receiving the corrected control command data packet, the execution device will execute the corresponding control action according to the corrected trigger time specified in the packet, thereby completing the collaborative control adjustment closed loop based on real-time system performance awareness. The execution of the entire process ensures that the system can dynamically adapt to changes in its internal state, maintaining the accuracy and robustness of collaborative operation. After completing the command transmission, the Phytium CPU resets the relevant flag bits and continues to monitor subsequent performance indicators, preparing for the decision-making of the next control cycle.

[0092] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0093] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0094] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0095] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0096] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0097] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0098] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0099] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0100] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0101] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An industrial PCB collaborative control method based on open-source Hongmeng and Feiteng CPU, characterized in that, The method comprises the following steps: S1, obtaining the unique identifier of each printed circuit board and collecting real-time position information of the printed circuit board; S2, comparing the real-time position information with preset boundary coordinates of the synchronous control area by the Fengteng CPU to determine whether the printed circuit board enters the synchronous control area; S3, when it is determined that the printed circuit board enters the synchronous control area, the Fengteng CPU obtains real-time state identifiers of each execution device participating in the current collaborative task; S4, based on the consistency degree of the real-time state identifiers of each execution device, a corresponding data query strategy is selected, node state feedback of each execution device participating in collaboration is obtained through a distributed soft bus of an open source Hongmeng operating system, and quality detection data stream and execution device action feedback signals are collected; S5, calculating the consensus convergence rate of the distributed system based on the node state feedback, and identifying the phase frequency characteristic distortion index of the control loop based on the data stream and the feedback signals; S6, when the consensus convergence rate is lower than a first threshold or the phase frequency characteristic distortion index exceeds a second threshold, the Fengteng CPU adjusts the triggering time point of the control instruction and sends the corrected control instruction to the execution device through the distributed soft bus; The method for calculating the consensus convergence rate of the distributed system based on the node state feedback comprises: checking the time stamps in the node state feedback data packets returned by each execution device to confirm the sequence of each node state response; analyzing the state information content carried in each node state feedback data packet to determine whether the state cognition of all nodes for the current collaborative task is consistent; according to the proportion of the number of nodes with consistent state cognition to the total number of nodes and the total time interval from the first node response to the last node response, evaluating the efficiency of the entire distributed system to reach state consensus, and quantifying this efficiency as the consensus convergence rate; The method for identifying the phase frequency characteristic distortion index of the control loop based on the data stream and the feedback signals comprises: aligning the collected quality detection data stream and the execution device action feedback signals in time sequence to form an input-output sequence of the control loop; by analyzing the response speed and waveform consistency of the output sequence following the change of the input sequence after the change, evaluating the dynamic response characteristics of the control loop; comparing the currently evaluated dynamic response characteristics with the pre-stored reference dynamic response characteristics, and calculating the phase frequency characteristic distortion index according to the deviation degree of the key response parameters.

2. The open-source Hongmeng and Feiteng CPU-based industrial PCB cooperative control method according to claim 1, characterized in that, The method for obtaining the unique identifier of each printed circuit board and collecting the real-time position information of the printed circuit board comprises: triggering the recognition device deployed at the starting station of the production line to recognize the entering printed circuit board; based on the recognition result, analyzing the identification information pre-stored on the printed circuit board to generate a unique identifier corresponding to the printed circuit board one by one; in response to the completion of the generation of the unique identifier, triggering the photoelectric position sensor or encoder arranged along the production line; reading the pulse signal or coordinate data fed back by the position sensor, and combining the conveying speed of the production line to calculate the real-time position information of the printed circuit board.

3. The open-source Hongmeng and Feiteng CPU-based industrial PCB cooperative control method according to claim 1, characterized in that, The method for comparing the real-time position information with the preset boundary coordinates of the synchronous control area by the Fengteng CPU to determine whether the printed circuit board enters the synchronous control area comprises: reading the boundary coordinates of the synchronous control area from the pre-stored configuration parameters; The calculated real-time position information of the printed circuit board is compared with the boundary coordinates of the synchronous control area in an algebraic manner; When the real-time position information meets the interval condition defined by the boundary coordinates of the synchronous control area, it is determined that the printed circuit board enters the synchronous control area, and a state marker of entering the area is added to the unique identifier of the printed circuit board.

4. The open-source Hongmeng and Feiteng CPU-based industrial PCB cooperative control method according to claim 1, characterized in that, When it is determined that the printed circuit board enters the synchronous control area, the Feiteng CPU obtains the real-time state identifiers of each execution device participating in the current collaborative task, including: According to the unique identifier of the printed circuit board and the position of the synchronous control area, the execution device list participating in the current collaborative task is determined from the pre-configured collaborative task mapping relationship; Through the distributed soft bus of the open source Hongmeng operating system, a state query request is sent to each execution device in the execution device list; The response data packets returned by each execution device are received, and the real-time state identifiers representing the working state of the device are parsed from each response data packet.

5. The open-source-Maemo and Feiteng CPU-based industrial PCB cooperative control method according to claim 4, characterized in that, The real-time state identifier includes one of ready, busy, or failure.

6. The open-source-Maemo and Feiteng CPU-based industrial PCB cooperative control method according to claim 1, characterized in that, Based on the consistency degree of the real-time state identifiers of each execution device, a corresponding data query strategy is selected, including: Determine whether all real-time state identifiers obtained from the execution device list are in the ready state; If all are in the ready state, select the complete data query strategy, send the state feedback query instruction containing the complete parameter request to each execution device in the execution device list through the distributed soft bus of the open source Hongmeng operating system, and simultaneously send the data acquisition instruction requesting complete historical data stream to the quality detection device; If not all are in the ready state, select the simplified data query strategy, send the state feedback query instruction containing only the core state query to each execution device in the execution device list through the distributed soft bus of the open source Hongmeng operating system, and simultaneously send the data acquisition instruction requesting only the real-time latest data point to the quality detection device.

7. The open-source-Maemo and Feiteng CPU-based industrial PCB cooperative control method according to claim 1, characterized in that, The node state feedback of each execution device participating in the collaboration is obtained through the distributed soft bus of the open source Hongmeng operating system, and the quality detection data stream and the action feedback signal of the execution device are collected, including: Receive the node state feedback data packet returned by each execution device according to the state feedback query instruction, and receive the quality detection data stream returned by the quality detection device according to the data acquisition instruction; At the same time, continuously monitor and collect the action feedback signal generated by each execution device when performing the action through the distributed soft bus.

8. The open-source-Maemo and Feiteng CPU-based industrial PCB cooperative control method according to claim 1, characterized in that, When the consensus convergence rate is lower than the first threshold or the phase frequency characteristic distortion index exceeds the second threshold, the Feiteng CPU adjusts the trigger time point of the control instruction and sends the corrected control instruction to the execution device through the distributed soft bus, including: Compare the calculated consensus convergence rate with the pre-stored first threshold, and compare the identified phase frequency characteristic distortion index with the pre-stored second threshold; If the consensus convergence rate is lower than the first threshold, the time amount by which the control instruction trigger time point needs to be advanced is calculated according to the amplitude by which the first threshold is lower; If the phase frequency characteristic distortion index exceeds the second threshold, the time amount by which the control instruction trigger time point needs to be delayed is calculated according to the amplitude by which the second threshold is exceeded; The trigger time point of the original control instruction is adjusted according to the determined time amount, and a revised control instruction data packet is generated; The revised control instruction data packet is sent to the corresponding execution device in the execution device list participating in the current collaborative task through the distributed software bus of the open source OS operating system.

Images