Circuit board defect identification method, device, storage medium and product

Abstract

The application discloses a circuit board defect identification method and device, a storage medium and a product, relates to the technical field of defect identification, and the circuit board defect identification method comprises the following steps: importing a circuit board and overall layout coordinates, connecting coordinate points to obtain a software PCS unit of the circuit board, identifying the software PCS unit to determine a software defect unit, identifying an entity PCS unit to obtain an entity defect unit, performing identification accuracy verification based on the software defect unit and the entity defect unit, and generating an identification trace code if the verification is passed. The application generates a PCS unit comprising a polygon based on a point set, identifies the generated PCS unit, so that the PCS unit can be identified through the polygon, the result of identification is verified, the trace code is generated again to complete identification when the verification is passed, the deviation between the software-annotated PCS unit and the actually-annotated PCS unit is prevented from being too large, and therefore, the identification accuracy of the circuit board defect identification is improved.

Description

Technical Field

[0001] This application relates to the field of defect identification technology, and in particular to methods, devices, storage media and products for identifying defects in circuit boards. Background Technology

[0002] Circuit board defect marking is an operation in which defective units that are determined to be unrepairable or do not meet quality standards are marked during the manufacturing process of electronic substrates such as printed circuit boards (PCBs), high-end HDI boards, and IC carrier boards. Currently, circuit boards are often marked using software systems.

[0003] Current methods typically identify PCS units on circuit boards as rectangles by default. However, circuit boards often have irregular wiring, resulting in a large number of non-rectangular PCS units. Current methods struggle to accurately label these non-rectangular PCS units, and the labeling process using software systems is prone to significant discrepancies between the software-labeled PCS units and the actual PCS units. Consequently, the current methods achieve low accuracy in identifying circuit board defects. Summary of the Invention

[0004] The main objective of this application is to provide a method, device, storage medium, and product for identifying circuit board defects, aiming to solve the technical problem of low accuracy in identifying circuit board defects.

[0005] To achieve the above objectives, this application proposes a method for identifying circuit board defects, the method comprising:

[0006] Import the circuit board that needs to be identified, and obtain the overall layout coordinates of the circuit board, wherein the overall layout coordinates include the point set of the circuit board;

[0007] Connecting the coordinate points in the point set yields multiple software PCS units on the circuit board, wherein the shape of the software PCS unit includes polygons;

[0008] The software PCS units in the imported circuit board are identified to determine the software defect units marked with defective tags, and the physical PCS units in the physical circuit board are identified to obtain the physical defect units.

[0009] Based on the software defect unit and the physical defect unit, the accuracy of the circuit board's identification is verified. If the verification passes, an identification traceability code is generated to complete the defect identification of the circuit board.

[0010] In one embodiment, the step of identifying the software PCS units in the imported circuit board and determining the software defective units marked with defective tags includes:

[0011] In response to a user-triggered defect identification operation, the software PCS unit in the imported circuit board is identified to obtain the defect identification;

[0012] Based on the number of coordinate points, the software PCS unit where the defect identifier is located is determined, and the software defect unit with the identifier is identified.

[0013] In one embodiment, the step of determining the software PCS unit where the defect identifier is located based on the number of coordinate points of the coordinate points, and determining the software defect unit marked with the mark, includes:

[0014] If the number of coordinate points is higher than the preset polygon threshold and not the preset rectangle threshold, then a ray is constructed with the defect coordinates of the defect identifier as the origin, and the number of intersections between the ray and each side of the software PCS unit is determined, wherein the polygon threshold is lower than the rectangle threshold.

[0015] If the number of intersections is odd, then the software PCS unit is determined to be the software defect unit;

[0016] If the number of coordinate points is equal to the rectangle threshold, then the maximum horizontal coordinate, maximum vertical coordinate, minimum horizontal coordinate, and minimum vertical coordinate are determined based on the coordinate points of the software PCS unit.

[0017] If the x-coordinate of the defect coordinate is not less than the minimum x-coordinate and not greater than the maximum x-coordinate, and the y-coordinate of the defect coordinate is not less than the minimum y-coordinate and not greater than the maximum y-coordinate, then the software PCS unit is determined to be the software defect unit.

[0018] In one embodiment, the step of verifying the accuracy of the markings on the circuit board based on the software defect unit and the physical defect unit further includes:

[0019] Obtain the coordinates, number, and type of the software defect identified by the defect identifier in the software defect unit;

[0020] Visual inspection is used to determine the coordinates, number, and type of the defect in the defect identifier of the physical defect unit.

[0021] If the difference between the coordinates of the software defect and the coordinates of the entity defect is within a preset coordinate consistency threshold, the difference between the number of software defects and the number of entity defects is within a preset quantity consistency threshold, and the types of software defects and entity defects are consistent, then the verification is deemed successful.

[0022] In one embodiment, after determining the coordinates of the physical defect, the number of physical defects, and the type of physical defect by visual inspection of the defect identifier of the physical defect unit, the method further includes:

[0023] If the difference between the software defect coordinates and the entity defect coordinates is outside the preset coordinate consistency threshold but within the preset coordinate tolerance threshold, then the preset manual confirmation process is initiated.

[0024] If the difference between the coordinates of the software defect and the coordinates of the entity defect is outside the coordinate tolerance threshold, or the difference between the number of software defects and the number of entity defects is outside the preset quantity tolerance threshold, or the type of software defect and the type of entity defect are inconsistent, an alarm will be triggered and a preset abnormality handling process will be initiated.

[0025] In one embodiment, after identifying the software PCS units in the imported circuit board and determining the software defective units marked with defective tags, the method further includes:

[0026] In response to a click operation on the software defect unit, a dialog box corresponding to the software defect unit is displayed;

[0027] In response to a user-triggered scrap number entry operation, the scrap number of the software defect unit is determined;

[0028] Based on the scrap number, the status of the software defect unit is adjusted to the scrap status;

[0029] Adjust the background color of the software defect unit in the preset visualization interface, and mark the software defect unit as unavailable in the preset database.

[0030] In one embodiment, after the step of verifying the accuracy of the circuit board's identification based on the software defect unit and the physical defect unit, and generating an identification traceability code if the verification passes, the method further includes:

[0031] Obtain the target traceability code that needs to be uploaded;

[0032] Based on the target traceability code, target traceability information is determined, and the software defect identifier of the target software defect unit and the entity defect identifier of the target entity defect unit bound to the target traceability information are determined.

[0033] Determine whether the target traceability information, the software defect identifier, and the entity defect identifier are consistent;

[0034] If they match, a target traceability file is generated based on the target traceability information, the software defect identifier, and the entity defect identifier, and the target traceability file is uploaded to the database.

[0035] In addition, to achieve the above objectives, this application also proposes a circuit board defect identification device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the circuit board defect identification method as described above.

[0036] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the circuit board defect identification method described above.

[0037] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the circuit board defect identification method described above.

[0038] One or more technical solutions proposed in this application have at least the following technical effects:

[0039] Import the circuit board to be identified and obtain its overall layout coordinates, which include a set of points on the circuit board. Connect the coordinate points in the set to obtain multiple software PCS units on the circuit board. The shape of each software PCS unit includes polygons. Identify the software PCS units in the imported circuit board to determine the software defect units marked with defective tags. Identify the physical PCS units in the physical circuit board to obtain physical defect units. Based on the software defect units and the physical defect units, verify the accuracy of the identification on the circuit board. If the verification passes, generate an identification traceability code to complete the defect identification of the circuit board.

[0040] To address the limitations of current methods in accurately labeling non-rectangular PCS units, and the tendency for software-labeled PCS units to deviate significantly from the actual PCS units during software labeling, resulting in low accuracy for circuit board defect identification, this application generates polygonal PCS units and performs verification, thereby improving the accuracy of circuit board defect identification. Specifically, instead of assuming PCS units in the circuit board are rectangular by default, this application generates polygonal PCS units based on point sets and labels these generated PCS units, allowing for identification through polygons. Furthermore, this application simultaneously labels both the imported circuit board and the actual circuit board, and verifies the labeling results. Only upon successful verification is a traceability code generated to complete the labeling, preventing excessive deviation between software-labeled and actual labeled PCS units. Therefore, this application can significantly improve the accuracy of circuit board defect identification. Attached Figure Description

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a flowchart illustrating an embodiment of the circuit board defect identification method of this application.

[0044] Figure 2 This is a flowchart illustrating Embodiment 2 of the circuit board defect identification method of this application;

[0045] Figure 3 This is a flowchart illustrating Embodiment 3 of the circuit board defect identification method of this application;

[0046] Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the circuit board defect identification method in this application embodiment;

[0047] Figure 5 This is a schematic diagram illustrating the data acquisition consent process involved in the circuit board defect identification method in this application embodiment.

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

[0049] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0050] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0051] 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, or mobile phone, or an electronic device or circuit board defect identification device capable of performing the above functions. The following description uses a circuit board defect identification device as an example to illustrate this embodiment and the subsequent embodiments.

[0052] Circuit board defect marking is an operation in which defective units that are determined to be unrepairable or do not meet quality standards are marked during the manufacturing process of electronic substrates such as printed circuit boards (PCBs), high-end HDI boards, and IC carrier boards. Currently, circuit boards are often marked using software systems.

[0053] Current methods typically identify PCS units on circuit boards as rectangles by default. However, circuit boards often have irregular wiring, resulting in a large number of non-rectangular PCS units. Current methods struggle to accurately label these non-rectangular PCS units, and the labeling process using software systems is prone to significant discrepancies between the software-labeled PCS units and the actual PCS units. Consequently, the current methods achieve low accuracy in identifying circuit board defects.

[0054] Based on this, embodiments of this application provide a method for identifying circuit board defects, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the circuit board defect identification method of this application.

[0055] In this embodiment, the circuit board defect identification method includes steps S10 to S40:

[0056] Step S10: Import the circuit board to be marked and obtain the overall layout coordinates of the circuit board, wherein the overall layout coordinates include the point set of the circuit board;

[0057] It should be noted that a circuit board refers to a substrate used to carry and connect electronic components; the overall layout coordinates refer to the set of coordinates that describe all relevant positional information on the circuit board; and the point set refers to a set of multiple coordinate points used to represent the geometric outline or key position of the circuit board in space.

[0058] It should also be noted that the defect information collection framework of this embodiment can be applied to processes such as QR (Quick Response) maintenance, electrical testing, FQC (Final Quality Control), packaging, and laser engraving, and no additional hardware is required when applied to the above processes.

[0059] It is understood that this embodiment imports the circuit board and obtains its overall layout coordinates, and the overall layout coordinates completely represent the spatial geometric features of the circuit board in the form of a point set, so that subsequent processing can be performed based on accurate coordinate information.

[0060] Step S20: Connect the coordinate points in the point set to obtain multiple software PCS units of the circuit board, wherein the shape of the software PCS unit includes polygons;

[0061] It should be noted that a software PCS (Piece) unit refers to an independent functional area unit in the software that is divided based on the coordinates of the circuit board point set and is used for identification or management.

[0062] It should also be noted that after generating the defect identification graphic, this embodiment provides a real-time canvas preview window, which supports mouse drag to adjust the offset and scroll wheel to zoom, and automatically checks whether the click coordinates are within the PCS. If the deviation is too large, such as exceeding the boundary, an alarm is triggered and it is recommended to reload the data.

[0063] This embodiment combines automated annotation with manual fine-tuning to ensure accurate matching of irregular wiring on high-density boards, and introduces real-time mouse coordinate feedback as a special consideration (calculating inverse transformation coordinates in events) to improve debugging accuracy.

[0064] It is understandable that polygons can accurately fit the outline of the actual functional area on the circuit board. In this embodiment, multiple software PCS units with polygon shapes are generated by connecting the coordinate points of the set of connection points, which ensures the consistency between the division result and the actual layout of the circuit board.

[0065] Step S30: Identify the software PCS units in the imported circuit board, identify the software defective units marked with defective tags, and identify the physical PCS units in the physical circuit board to obtain the physical defective units.

[0066] It should be noted that a software defect unit refers to a software PCS unit that is marked as defective in the software. A physical PCS unit refers to a physical functional area or module that actually exists on the circuit board and corresponds to the software PCS unit. A physical defect unit refers to a physical PCS unit on the physical circuit board that is marked as defective, which corresponds to the software defect unit that has been marked as defective.

[0067] Understandably, this embodiment first extracts the overall layout coordinates of PNL (panel) / SET (set / group) from the backend via API (Application Programming Interface). The overall layout coordinates include a rectangle / marker point / point set data structure. Then, an affine transformation matrix is ​​applied to each PCS unit. Specifically, the transformed X coordinate = X offset + original X coordinate × scaling ratio, and the transformed Y coordinate = Y offset - original Y coordinate × scaling ratio, to adapt to the Canvas coordinate system with the Y-axis reversed.

[0068] Furthermore, the algorithm in this embodiment also supports automatic switching between top and bottom surfaces, and uses the path API of 2DContext (Canvas 2D rendering context) to generate X-out identifiers (defect identifiers) during graphics rendering.

[0069] In this embodiment, the software PCS units that have been divided in the imported circuit board are marked, and the units with defects are identified and marked to form software defect units. The physical PCS units are then physically or visually marked on the physical circuit board to obtain physical defect units.

[0070] By identifying software defective PCS units through defect identification, and further mapping the identification to the corresponding physical PCS units on the physical circuit board, physical defective units are obtained, thus achieving consistent identification of defect information between software and physical entities.

[0071] Furthermore, since the software defect unit is generated based on precise polygon division and coordinate information, its spatial position strictly corresponds to the physical PCS unit, which makes the identification of the physical defect unit highly accurate, avoids human judgment error, and improves the accuracy of defect location.

[0072] In one feasible implementation, the specific implementation of identifying the software PCS units in the imported circuit board and determining the software defect units marked with defective tags can also be:

[0073] In response to a user-triggered defect identification operation, the software PCS unit in the imported circuit board is identified to obtain the defect identification. Based on the number of coordinate points of the coordinate point, the software PCS unit where the defect identification is located is judged to determine the software defect unit marked with the mark.

[0074] It should be noted that defect identification operations refer to user-initiated actions used to mark suspected or known defect areas on a circuit board within the software interface, such as clicking, selecting boxes, or drawing polygons. Defect identifiers are markings generated in the software through defect identification operations that indicate the location of defects and are associated with specific software PCS units.

[0075] It is understood that a software PCS unit itself is composed of coordinate points connected in a point set, containing a certain number of coordinate points. When the number of coordinate points covered by a defect identifier meets a preset attribution condition, it can uniquely correspond to a software PCS unit. Therefore, this embodiment generates a defect identifier in response to a user-triggered defect identifier operation, and further determines the software PCS unit to which it belongs based on the number of coordinate points in the area where the defect identifier is located, thereby accurately identifying software defect units and improving the accuracy of circuit board defect identification.

[0076] In one feasible implementation, the specific implementation of determining the software PCS unit where the defect identifier is located based on the number of coordinate points of the coordinate points, and thus identifying the software defect unit marked with the mark, can also be:

[0077] If the number of coordinate points is higher than a preset polygon threshold but not a preset rectangle threshold, a ray is constructed with the defect coordinates of the defect identifier as the origin, and the number of intersections between the ray and each edge of the software PCS unit is determined. The polygon threshold is lower than the rectangle threshold. If the number of intersections is odd, the software PCS unit is determined to be the software defect unit. If the number of coordinate points is equal to the rectangle threshold, the maximum x-coordinate, maximum y-coordinate, minimum x-coordinate, and minimum y-coordinate are determined based on the coordinate points of the software PCS unit. If the x-coordinate of the defect coordinate is not less than the minimum x-coordinate and not greater than the maximum x-coordinate, and the y-coordinate of the defect coordinate is not less than the minimum y-coordinate and not greater than the maximum y-coordinate, the software PCS unit is determined to be the software defect unit.

[0078] It should be noted that the polygon threshold is a preset threshold for the number of coordinate points used to determine whether a software PCS unit is a non-rectangular polygon structure. The rectangle threshold is a preset threshold for the number of coordinate points used to determine whether a software PCS unit is a rectangular structure. Defect coordinates refer to the specific location coordinates specified by the user in the software interface when triggering the defect identification operation, serving as a reference point for determining the software PCS unit to which it belongs. The number of intersections refers to the total number of times the aforementioned ray intersects with each side of the software PCS unit, used to determine whether the defect coordinates are located inside the polygon.

[0079] It should also be noted that in this embodiment, the threshold for the number of coordinate points is 3, the threshold for the rectangle is 4, and this embodiment uses resolution scaling when marking to reduce jagged edges in rendering. At the same time, it integrates a grid background to assist visual alignment, thereby improving the accuracy of the marking.

[0080] Understandably, for polygons of arbitrary shapes, the ray method can accurately determine whether the origin of the ray is inside the polygon. For regular shapes like rectangles, constructing bounding boxes using the maximum / minimum x and y coordinates avoids complex edge intersection calculations and significantly reduces computational overhead. Therefore, this embodiment distinguishes software PCS units as polygonal or rectangular structures based on the number of coordinate points, and uses the ray intersection method and axis-aligned bounding box method respectively to determine defect coordinate attribution, thereby efficiently and accurately identifying software PCS units containing defect coordinates.

[0081] In one embodiment, during automated defect labeling, if the coordinate offset caused by production deformation is within a preset tolerance range, and for irregular wiring, the rendering style is dynamically adjusted, and the top edge gap is specially handled in label rendering to calculate and insert labels, avoiding covering the boundary lines.

[0082] It is understood that, through the above steps, this embodiment significantly improves the recognition accuracy of irregular wiring under the premise of the same readability, while avoiding the risk of mislabeling caused by small errors, achieving the dual effect of high accuracy and low false alarms, and enhancing visual differentiation through special layer rendering.

[0083] In one feasible implementation, when marking defects in the software PCS unit, if the defect marking operation triggered by the user falls on the common boundary of multiple adjacent software PCS units, the assignment weight is calculated based on the distance between the polygon area of ​​each adjacent unit and the centroid of the current defect coordinates; the defect mark is assigned to the software PCS unit with the highest weight, and the defect coordinates are slightly moved to the nearest interior point along its normal direction within that unit to ensure that it is strictly located inside the polygon, thus avoiding subsequent topology verification failure.

[0084] It should be noted that a common boundary refers to a polygonal edge or vertex shared by two or more adjacent software PCS units, typically appearing in areas where functional regions are closely arranged on a circuit board. Centroid distance refers to the Euclidean distance from the defect coordinates to the centroid (geometric center) of a software PCS unit's polygon. Assignment weight is a value calculated by considering both the area of ​​the software PCS unit (higher weight for larger areas) and the centroid distance (higher weight for closer distances), used to determine defect assignment in cases of boundary ambiguity. Normal direction refers to the direction vector perpendicular to the edge at the common boundary, pointing towards the interior of the polygon, used to guide the defect coordinates to move slightly inwards. Nearest interior point refers to the point that falls inside the polygon after moving a minimal distance (e.g., 0.1mm) from the defect coordinates on the boundary along the normal direction, ensuring that the topological closure condition is satisfied.

[0085] Understandably, when the defect coordinates generated by a user-triggered defect identification operation happen to fall on the common boundary of two or more software PCS units, the system does not randomly assign or report an error. Instead, it calculates the assignment weight for each adjacent unit. The system assigns the defect identifier to the software PCS unit with the highest weight and further shifts the defect coordinates slightly along the inner normal direction of that unit at the boundary to the nearest inner point, ensuring that it is strictly inside the polygon. This corrected defect coordinate is used to subsequently determine the software defect unit. Therefore, even when there is boundary ambiguity in the user operation, the reasonableness of defect assignment can still be guaranteed, avoiding subsequent topology verification failures due to boundary points.

[0086] In one feasible implementation, after the defect coordinates are slightly moved to the nearest interior point, a displacement vector is generated from the original defect coordinates to the slightly moved coordinates, and the displacement vector, along with the assigned weight and the selected software PCS unit ID, is recorded in the defect metadata. If the defect coordinates are subsequently detected to have been slightly moved, a displacement marker is embedded when generating the identification traceability code, and the original position and the corrected path are displayed in the visualization interface with a dashed arrow overlay.

[0087] It should be noted that the displacement vector refers to the directed line segment from the original defect coordinates clicked by the user to the nearest interior point after a minor shift along the normal direction. It includes direction and length information and is used to record the system's correction behavior to user input. Defect metadata refers to the structured supplementary information bound to the defect identifier, including but not limited to coordinates, type, unit of origin, operation time, and correction record, used to support traceability and auditing. The displacement marker refers to a Boolean or coded field set in the identifier traceability code or its associated data, used to identify that the defect coordinates have undergone automatic minor shift correction by the system. The dashed arrow refers to a graphic element displayed as a non-solid line in the visualization interface, used to visually represent the relationship between the original defect location and the system correction path.

[0088] Understandably, after the defect coordinate micro-shift operation is completed, this embodiment automatically generates a displacement vector from the original defect coordinates to the shifted coordinates. This vector, along with its assigned weight, the selected software PCS unit ID, and other information, is written into the defect metadata. If a displacement record is detected for the defect coordinates, a displacement marker is embedded when generating the identification traceability code. Simultaneously, the path between the original click position and the corrected actual defect coordinates is displayed as a dashed arrow in the visualization interface. This ensures geometric compliance while fully preserving the user's original operational intent, achieving full traceability and transparent visualization of the system's automatic correction behavior.

[0089] Step S40: Based on the software defect unit and the physical defect unit, verify the accuracy of the circuit board's identification. If the verification passes, generate an identification traceability code to complete the defect identification of the circuit board.

[0090] It should be noted that the identification traceability code is a unique code generated for a circuit board that has completed defect identification. It is used to record the defect information, identification time, operator, and verification results of the circuit board, supporting subsequent quality tracking and management.

[0091] It is understandable that software defect units are generated based on precise coordinate point sets and geometric judgment logic, while physical defect units are defect markings applied by the user on the physical circuit board. Only when the consistency between the software defect units and physical defect units is verified will the system confirm the validity of the marking and generate a traceability code, ensuring that each marked circuit board has a reliable defect record. Therefore, this embodiment verifies the accuracy of the marking by comparing the software defect units and physical defect units, and only generates the marking traceability code after the verification is passed, thereby effectively preventing misjudgment or mislabeling caused by inconsistencies between software and physical markings.

[0092] In one embodiment, after generating the identification traceability code, the original defect codes of different devices can be automatically mapped to a unified business defect group code by combining the identification traceability code and a pre-configured correspondence in the database. When new devices need to be added, only a device code and defect code mapping table needs to be added to the graphical interface to achieve standardized classification and storage of defect information.

[0093] Understandably, in existing technologies, defect collection is mostly handled in siloed manner. However, this embodiment avoids the inconsistency problem of traditional manual conversion by using a fully data-driven conversion model. Furthermore, in scenarios where multiple vendors' equipment is used together, it ensures that all defective data can be seamlessly integrated into the central database to form a unified quality view across processes.

[0094] In summary, this embodiment imports the circuit board that needs to be identified and obtains the overall layout coordinates of the circuit board. The overall layout coordinates include a set of points on the circuit board. Connecting the coordinate points in the set of points yields multiple software PCS units of the circuit board. The shape of each software PCS unit includes polygons. The software PCS units in the imported circuit board are identified to determine software defect units marked with defective tags. The physical PCS units in the physical circuit board are also identified to obtain physical defect units. Based on the software defect units and the physical defect units, the accuracy of the identification of the circuit board is verified. If the verification passes, an identification traceability code is generated to complete the defect identification of the circuit board.

[0095] To address the current limitations of accurate labeling of non-rectangular PCS units and the tendency for software-labeled PCS units to deviate significantly from the actual PCS units during software labeling, resulting in low accuracy for circuit board defect identification, this embodiment generates polygonal PCS units and performs verification to improve the accuracy of circuit board defect identification. Specifically, instead of assuming PCS units in the circuit board are rectangular by default, this embodiment generates polygonal PCS units based on point sets and labels these generated PCS units, allowing for identification through polygons. Furthermore, this embodiment simultaneously labels both the imported circuit board and the actual circuit board, and verifies the labeling results. Only upon successful verification is a traceability code generated to complete the labeling, preventing excessive deviation between software-labeled and actual labeled PCS units. Therefore, this embodiment can improve the accuracy of circuit board defect identification.

[0096] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Before step S40, the circuit board defect identification method further includes steps S41 to S43:

[0097] Step S41: Obtain the software defect coordinates, number of software defects, and type of software defect of the defect identifier in the software defect unit;

[0098] It should be noted that software defect coordinates refer to the specific coordinate values ​​of the defect location identified in the software, corresponding to the spatial position of the defect identifier within the software PCS unit. The number of software defects refers to the total number of defects identified in a single software defect unit or the entire circuit board, used to quantify the defect scale. The software defect type refers to the category label assigned to the identified defects in the software according to preset classification standards, used to distinguish defects of different natures.

[0099] It is understood that this embodiment obtains relevant information about the defect identifier contained in each software defect unit, specifically including the software defect coordinates of the defect identifier, the corresponding number of software defects, and the software defect type. This information is used to comprehensively describe the location, severity, and nature of the defect in the software model, thereby providing a structured and quantifiable defect data foundation for subsequent verification and traceability.

[0100] Step S42: Through visual inspection, determine the coordinates of the physical defect, the number of physical defects, and the type of physical defect of the defect identifier of the physical defect unit;

[0101] It should be noted that visual inspection refers to the process of automatically or semi-automatically inspecting physical circuit boards using image acquisition equipment and image processing algorithms to identify and locate defects. Physical defect coordinates refer to the physical spatial coordinates corresponding to the actual location of the defect identified on the physical circuit board through visual inspection. The number of physical defects refers to the total number of defects confirmed by visual inspection within a physical defect unit.

[0102] Entity defect type refers to the category of entity defects determined by visual inspection, which is used to characterize the physical properties of the defect.

[0103] It is understood that this embodiment uses visual inspection to analyze physical defect units on the physical circuit board, identify defect identifiers, determine the physical defect coordinates in physical space, count the number of physical defects, and classify the physical defect types based on image features. This allows for the acquisition of structured defect information from the physical layer that corresponds to the software side, providing a basis for subsequent comparison and verification with software defect data.

[0104] Step S43: If the difference between the coordinates of the software defect and the coordinates of the entity defect is within a preset coordinate consistency threshold, the difference between the number of software defects and the number of entity defects is within a preset quantity consistency threshold, and the type of software defect is consistent with the type of entity defect, then the verification is confirmed to be successful.

[0105] It should be noted that the preset coordinate consistency threshold refers to the pre-set range of maximum allowable deviation between the coordinates of software defects and the coordinates of physical defects, used to determine whether the two are sufficiently close in spatial location. The preset quantity consistency threshold refers to the pre-set integer value of the maximum allowable difference between the number of software defects and the number of physical defects, used to determine whether the defect counts are basically consistent.

[0106] Understandably, relying solely on a single dimension can easily lead to misjudgments due to noise or local errors. Multi-dimensional joint verification, however, can effectively eliminate accidental matches. When all three dimensions meet preset conditions, it indicates that the software identifier not only spatially aligns with the physical defect but also maintains consistency in defect scale and nature, thus significantly improving the reliability of the verification results. Therefore, this embodiment introduces consistency judgments across three dimensions—coordinates, quantity, and type—during the verification process, setting reasonable tolerance thresholds and strict type matching requirements for each. This allows for a comprehensive evaluation of the consistency of defect identifiers between software defect units and physical defect units, preventing significant discrepancies between software and actual identifiers and improving the accuracy of the identifiers.

[0107] In one feasible implementation, the specific implementation of determining the physical defect coordinates, quantity, and type of the defect identifier of the physical defect unit through visual inspection can also be:

[0108] If the difference between the coordinates of the software defect and the coordinates of the entity defect is outside the preset coordinate consistency threshold but within the preset coordinate tolerance threshold, a preset manual confirmation process is initiated. If the difference between the coordinates of the software defect and the coordinates of the entity defect is outside the coordinate tolerance threshold, or the difference between the number of software defects and the number of entity defects is outside the preset quantity tolerance threshold, or the type of software defect and the type of entity defect are inconsistent, an alarm is triggered and a preset exception handling process is initiated.

[0109] It should be noted that the preset coordinate tolerance threshold is a more lenient upper limit for allowable deviation than the preset coordinate consistency threshold. It defines the critical range for acceptable manual review. When the coordinate difference exceeds the consistency threshold but not the tolerance threshold, the system does not directly determine it as a failure, but triggers manual confirmation. The manual confirmation process refers to the procedure where operators intervene to visually or interactively review the matching of software and entity defect information and make a final judgment. The anomaly handling process refers to standardized response measures that are automatically initiated when there are significant inconsistencies in defect information. These may include suspending the identification process, recording anomaly logs, notifying quality control personnel, or issuing rework instructions.

[0110] Understandably, minor positioning errors or visual recognition noise may exist in actual manufacturing environments. Complete consistency requirements can easily lead to mistakes. By setting tolerance thresholds, allowing for manual judgment of edge cases, the oversensitivity of automated systems is avoided while retaining the ability to correct obvious errors. Therefore, this embodiment triggers manual verification or anomaly handling processes for different degrees of deviation, achieving a balance between strict quality control and engineering practicality. This ensures the accuracy of defect identification while improving the system's robustness.

[0111] In one feasible implementation, the subsequent specific implementation of verifying the accuracy of the circuit board's identification based on the software defect unit and the physical defect unit, and generating an identification traceability code if the verification passes, may also be:

[0112] Obtain the target traceability code to be uploaded. Based on the target traceability code, determine the target traceability information, and determine the software defect identifier of the target software defect unit and the entity defect identifier of the target entity defect unit bound to the target traceability information. Determine whether the target traceability information, the software defect identifier, and the entity defect identifier are consistent. If they are consistent, generate a target traceability file based on the target traceability information, the software defect identifier, and the entity defect identifier, and upload the target traceability file to the database.

[0113] It should be noted that the target traceability code refers to the generated identification traceability code to be uploaded or queried, used to associate a complete defect identification record of a specific circuit board. Target traceability information refers to the structured data bound to the target traceability code, including but not limited to the circuit board number, identification time, operator, verification results, and defect summary information.

[0114] Software defect identifiers refer to specific defect information marked within a software defect unit, including its coordinates, quantity, and type, and are part of the traceability content. Entity defect identifiers refer to actual defect information obtained through visual inspection or manual verification within an entity defect unit, also including the entity defect coordinates, quantity, and type, used for comparison with the software side. Target traceability documents refer to standardized documents generated after integrating consistent data from target traceability information, software defect identifiers, and entity defect identifiers, used for archiving or uploading.

[0115] It is understood that, after generating the identification traceability code, this embodiment further determines whether to generate and upload the target traceability file by comparing the consistency of the target traceability information, software defect identifier, and physical defect identifier, thus preventing inconsistent or erroneous data from being written to the database. Through the above steps, this embodiment ensures that each record in the database has high reliability, providing a reliable data foundation for subsequent quality analysis, process improvement, and accountability.

[0116] In one feasible implementation, after the verification is passed but before the identification traceability code is generated, a topological closure verification is performed on the defect coordinates based on the polygon boundary of the software defect unit: if the defect coordinates are located inside or on the boundary of the polygon, the defect identifier is retained; if the defect coordinates are located outside the polygon, the defect coordinates are automatically corrected to the nearest boundary point of the polygon, and a coordinate correction log is recorded before continuing to generate the identification traceability code.

[0117] It should be noted that topological closure verification refers to the mathematical operation in computational geometry to determine whether a point belongs to the closure of a polygon, used to ensure the logical belonging relationship between a point and a region is valid. The nearest boundary point refers to the point on the polygon boundary with the shortest Euclidean distance to a given external point, serving as the correction position for projecting the external point back into the valid region. Coordinate correction log: refers to a structured record automatically generated by the system, containing the original defect coordinates, corrected coordinates, the ID of the software defect unit to which it belongs, and the reason for correction, used for auditing and traceability.

[0118] Understandably, in this embodiment, after the verification process is deemed successful but before the formal generation of the identification traceability code, an additional accuracy check based on geometric topology is performed: using the polygonal boundary of the software defect unit, the attribution of each defect coordinate is rigorously verified; if it is found that a defect coordinate falls outside the polygon due to user error or input noise, the system will not directly reject the verification, but will automatically correct it to the nearest point on the polygon boundary and generate a coordinate correction log. Subsequently, the corrected coordinates are used to participate in the traceability code generation and file construction, thereby ensuring the rigor of data logic while avoiding the failure of the entire verification due to minor input deviations, thus improving the fault tolerance and engineering robustness of the system.

[0119] In one feasible implementation, if the defect coordinates are located outside the polygon, the defect coordinates are automatically corrected to the nearest boundary point of the polygon, and a coordinate correction log is recorded before generating the identification traceability code. Another possible implementation is:

[0120] If the defect coordinates are located outside the polygon of the software defect unit, then based on the edge contour point set obtained by visual detection of the entity defect unit, the minimum Euclidean distance from the defect coordinates to the contour point set is calculated; if the minimum distance is less than a preset contour tolerance threshold, then the defect coordinates are corrected to the projected coordinates of the nearest point in the contour point set, and the polygon boundary of the software defect unit is locally reconstructed to include the projected coordinates, generating an updated polygon vertex sequence for subsequent traceability file construction.

[0121] It should be noted that the edge contour point set refers to the discrete coordinate set of the actual physical edges of the physical defect unit extracted from the physical circuit board through high-precision visual inspection, which is closer to the actual manufacturing form than the idealized polygon on the software side. The preset upper limit of the contour tolerance threshold is used to determine whether the external defect coordinates are close enough to the actual physical edge of the physical defect, thus allowing it to be included in the correction range.

[0122] Projected coordinates refer to the coordinates of a target point on the edge contour of a physical defect, mapped perpendicularly or approximately perpendicularly along the shortest path from the original defect coordinates. Local polygon boundary reconstruction refers to dynamically inserting projected coordinates between adjacent points in the original polygon vertex sequence without altering the overall topology of the software defect unit, making the updated polygon more closely resemble the true geometry of the physical defect.

[0123] It is understandable that when this embodiment detects that a defect coordinate is located outside the polygon of a software defect unit, it no longer simply projects it onto the ideal polygon boundary. Instead, it further calls the acquired edge contour point set of the physical defect unit, calculates the Euclidean distance from the defect coordinate to all contour points, and takes the minimum value. If this minimum distance is less than a preset contour tolerance threshold, it indicates that although the defect coordinate deviates from the software model, it actually falls near the physical edge of the physical defect, which is a reasonable deviation. At this time, the system corrects the defect coordinate to the projected coordinate of the corresponding contour point and performs local reconstruction of the polygon vertex sequence of the original software defect unit. Specifically, local reconstruction includes inserting the projected coordinate between the two nearest vertices to form an updated polygon. This updated polygon will be used for subsequent identification traceability code binding and traceability file generation. Therefore, this embodiment achieves dynamic calibration of the software defect geometric model based on the actual edge of the entity through the above steps, making the defect representation closer to physical reality.

[0124] In this embodiment, when the defect coordinates are located outside the polygon of the software defect unit, the minimum Euclidean distance is calculated using the edge contour point set obtained by visual inspection of the physical defect unit. Under the condition of satisfying the contour tolerance threshold, the defect coordinates are corrected to the projected coordinates. At the same time, the polygon boundary of the software defect unit is locally reconstructed to include the projected coordinates. This makes the updated polygon vertex sequence more accurately reflect the actual geometric shape of the physical defect, thereby improving the accuracy of circuit board defect identification.

[0125] In one feasible implementation, after locally reconstructing the polygonal boundary of the software defect unit, the area change rate is calculated based on the updated polygon vertex sequence; if the area change rate exceeds a preset geometric stability threshold, the manual confirmation process is triggered, and the overlapping and difference areas of the original polygon and the updated polygon are highlighted in the dialog box for the user to determine whether to accept the local reconstruction result.

[0126] It should be noted that the area change rate refers to the ratio of the absolute value of the difference between the area of ​​the reconstructed polygon and the area of ​​the original polygon, divided by the original area. This quantifies the degree of geometric shape change. The geometric stability threshold has a preset upper limit for the area change rate (e.g., 10%), used to determine whether local reconstruction has caused a significant shift in the geometric shape of the software defect unit. The overlapping region refers to the area spatially covered by the original and updated polygons, representing the stable, unchanged region. The difference region refers to the area where the original and updated polygons do not overlap, including newly added or reduced areas, used to visually demonstrate the scope of the reconstruction's impact.

[0127] Understandably, after completing the local reconstruction of the polygon boundary, the system automatically calculates the rate of change of area between the updated polygon area and the original polygon area. If this rate of change exceeds a preset geometric stability threshold, it indicates that the local reconstruction has caused a significant shift in the geometric shape of the defective unit, which may affect the rationality of subsequent identification or traceability. At this point, the system triggers a manual confirmation process and highlights the overlapping and difference areas of the original and updated polygons in different colors in the corresponding dialog box to help users intuitively evaluate the reconstruction results. Users can choose to accept, reject, or manually adjust. The system decides whether to use the updated polygon for traceability file construction based on the user's decision, thereby establishing a dynamic balance between automated correction and manual supervision to prevent overfitting of entity noise from causing software model distortion.

[0128] This embodiment introduces the area change rate as a geometric stability criterion after local reconstruction of the polygon boundary, and triggers a manual confirmation process when the threshold is exceeded. At the same time, the overlapping area and difference area of ​​the original and updated polygons are visualized in the dialog box, thereby effectively preventing unreasonable distortion of the geometric model of the software defect unit due to entity contour noise or abnormal projection.

[0129] In summary, this embodiment obtains the coordinates, quantity, and type of software defects in the software defect unit, determines the coordinates, quantity, and type of physical defects corresponding to the physical defect unit through visual inspection, and compares the software and physical defect information in multiple dimensions based on preset coordinate consistency thresholds, quantity consistency thresholds, and type consistency requirements. The verification is only considered successful when all three conditions are met.

[0130] By introducing strict consistency checks on software and entity defect information across three dimensions—coordinates, quantity, and type—and combining this with a tiered processing mechanism under tolerance thresholds, the accuracy and robustness of defect identification results are significantly improved. Furthermore, after successful verification, this embodiment further integrates target traceability information, software defect identifiers, and entity defect identifiers to generate a target traceability file, which is then uploaded to the database, ensuring the accuracy and reliability of the defect data.

[0131] Based on the first and second embodiments of this application, in the third embodiment of this application, the content that is the same as or similar to that in embodiments one and two above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 After step S30, the circuit board defect identification method further includes steps S100~S400:

[0132] Step S100: In response to the click operation on the software defect unit, a dialog box corresponding to the software defect unit is displayed;

[0133] It is understood that in this embodiment, when a user clicks on a software defect unit on the software interface, the system responds to the operation by automatically popping up a dialog box corresponding to the software defect unit. The dialog box is used to present detailed defect information of the unit and provide further operation entry points, thereby realizing interactive access between the user and the defect identification results, improving the convenience of operation and the readability of information.

[0134] Step S200: In response to the scrap number entry operation triggered by the user, determine the scrap number of the software defect unit;

[0135] It should be noted that the scrap number entry operation refers to the user actively inputting or selecting a unique code in the software interface to identify circuit boards or their defective units that need to be scrapped. The scrap number is a unique identifier assigned to a specific software defective unit, used to mark the unit in the production management system as determined to be irreparable or needing to be discarded, supporting subsequent scrap tracking and inventory management.

[0136] It should also be noted that in this embodiment, when entering / revoking data, the system calls the built-in verification model to automatically determine the probability of misjudgment. In irregular wiring scenarios, this avoids human subjective errors and improves the reliability of automated annotation.

[0137] Understandably, binding scrap numbers to software defect units ensures that each scrap record corresponds to a specific defect location and type. Therefore, this embodiment establishes an association between scrap numbers and specific software defect units by responding to the user's scrap number entry operation, thereby making scrap decisions traceable.

[0138] Step S300: Based on the scrap number, adjust the status of the software defect unit to the scrap status;

[0139] It should be noted that the scrap status refers to a specific status identifier that marks a software defective unit as unusable or to be discarded during its life cycle. This identifier is used to distinguish between normal, repair-pending, and scrapped units in the system and to trigger corresponding business processes.

[0140] Step S400: Adjust the background color of the software defect unit in the preset visualization interface, and mark the software defect unit as unusable in the preset database.

[0141] It should be noted that the visual interface refers to a graphical user interface used to display information such as the circuit board and its software PCS units, defect identifiers, etc., and supports visual feedback in the form of colors, icons, or labels. The unavailable mark refers to a logical flag or status field set in the database for software defect units, used to indicate that the unit has been determined to be unsuitable for subsequent production, testing, or assembly processes due to defects.

[0142] Understandably, after the status of the software defect unit is adjusted to the scrapped state, this embodiment adjusts the background color of the software defect unit to the preset scrapped color in the preset visualization interface to provide an intuitive visual warning, and marks the record of the software defect unit as unusable in the preset database so that it is automatically excluded in subsequent query, scheduling or processing logic, thereby effectively preventing human error or system miscall.

[0143] In one embodiment, after generating the traceability file, the work order number or circuit board code can be entered through the query interface to export the table with one click. Each scrap record is bound to the coordinates of the PCS point set, which improves the analysis efficiency and serves as a supplementary means of automated annotation to improve the management accuracy of complex wiring.

[0144] In summary, in this embodiment, after the user clicks on the software defect unit, the system pops up a corresponding dialog box to support information viewing or operation. When the user performs the scrap number entry operation, the system obtains and binds the scrap number to the current software defect unit, updates the status of the software defect unit to the scrap status based on the scrap number, adjusts the background color of the unit in the visualization interface to provide visual warning, and marks it as unavailable in the database.

[0145] This embodiment visually distinguishes scrapped PCS units by changing the background color, and the unusable marker in the database prevents subsequent misuse of the PCS unit. Furthermore, by binding the scrap number to the software defect unit, this embodiment ensures that every scrapping decision is traceable, thereby significantly improving the accuracy and error prevention capabilities of scrapping processing.

[0146] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the circuit board defect identification method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0147] This application provides a circuit board defect identification device, 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, which are executed by the at least one processor to enable the at least one processor to perform the circuit board defect identification method in Embodiment 1 above.

[0148] The following is for reference. Figure 4 The diagram illustrates a structural schematic suitable for implementing a circuit board defect identification device according to embodiments of this application. The circuit board defect identification device in embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, tablets, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The circuit board defect identification device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0149] like Figure 4 As shown, the circuit board defect identification device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that 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 circuit board defect identification device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the circuit board defect identification device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show circuit board defect identification devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0150] 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.

[0151] The circuit board defect marking device provided in this application, employing the circuit board defect marking method in the above embodiments, can solve the technical problem of low marking accuracy of circuit board defects. Compared with the prior art, the beneficial effects of the circuit board defect marking device provided in this application are the same as those of the circuit board defect marking method provided in the above embodiments, and other technical features in this circuit board defect marking device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0152] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0153] 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.

[0154] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the circuit board defect identification method in the above embodiments.

[0155] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0156] The aforementioned computer-readable storage medium may be included in the circuit board defect identification device; or it may exist independently and not assembled into the circuit board defect identification device.

[0157] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the circuit board defect identification device, cause the circuit board defect identification device to perform the aforementioned circuit board defect identification method.

[0158] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0159] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0160] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0161] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described circuit board defect identification method, thereby solving the technical problem of low identification accuracy of circuit board defects. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the circuit board defect identification method provided in the above embodiments, and will not be repeated here.

[0162] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the circuit board defect identification method described above.

[0163] The computer program product provided in this application can solve the technical problem of low identification accuracy of circuit board defects. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the circuit board defect identification method provided in the above embodiments, and will not be repeated here.

[0164] All user-related data involved in this application was obtained with the user's permission or consent, as per [reference]. Figure 5 In other words, when this application is applied to a specific product or technology, user permission is required to acquire and process the relevant data, and the processing of the relevant data must comply with the relevant laws, regulations and regulatory standards of the relevant countries and regions.

[0165] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for identifying defects on a circuit board, characterized in that, The method includes: Import the circuit board that needs to be identified, and obtain the overall layout coordinates of the circuit board, wherein the overall layout coordinates include the point set of the circuit board; Connecting the coordinate points in the point set yields multiple software PCS units on the circuit board, wherein the shape of the software PCS unit includes polygons; The software PCS units in the imported circuit board are identified to determine the software defective units marked with defective tags, and the physical PCS units in the physical circuit board are identified to obtain physical defective units. The software defective unit is the software PCS unit marked as having a defect in the software, and the physical defective unit is the physical PCS unit marked as having a defect on the physical circuit board. The physical PCS unit is a physical functional area or module on the circuit board that corresponds to the software PCS unit. Based on the software defect coordinates, number of software defects, and type of software defects of the software defect unit, and the physical defect coordinates, number of physical defects, and type of physical defects of the physical defect unit, the accuracy of the circuit board identification is verified. If the verification passes, an identification traceability code is generated to complete the defect identification of the circuit board. The steps preceding the generation of the identification traceability code after the verification is passed also include: Based on the polygonal boundary of the software defect unit, topological closure verification is performed on the software defect coordinates. If the software defect coordinates are located inside or on the boundary of the polygon, the defect mark is retained. The topological closure verification is a mathematical operation in computational geometry to determine whether a point belongs to the polygon closure. If the coordinates of the software defect are located outside the polygon, the coordinates of the software defect are automatically corrected to the nearest boundary point of the polygon, a coordinate correction log is recorded, and the identification traceability code is generated.

2. The method as described in claim 1, characterized in that, The step of identifying the software PCS units in the imported circuit board and determining the software defect units marked with defective tags includes: In response to a user-triggered defect identification operation, the software PCS unit in the imported circuit board is identified to obtain the defect identification; Based on the number of coordinate points, the software PCS unit where the defect identifier is located is determined, and the software defect unit with the identifier is identified.

3. The method as described in claim 2, characterized in that, The step of determining the software PCS unit where the defect identifier is located based on the number of coordinate points of the coordinate points, and identifying the software defect unit with the identifier, includes: If the number of coordinate points is higher than the preset polygon threshold and not the preset rectangle threshold, then a ray is constructed with the defect coordinates of the defect identifier as the origin, and the number of intersections between the ray and each side of the software PCS unit is determined, wherein the polygon threshold is lower than the rectangle threshold. If the number of intersections is odd, then the software PCS unit is determined to be the software defect unit; If the number of coordinate points is equal to the rectangle threshold, then the maximum horizontal coordinate, maximum vertical coordinate, minimum horizontal coordinate, and minimum vertical coordinate are determined based on the coordinate points of the software PCS unit. If the x-coordinate of the defect coordinate is not less than the minimum x-coordinate and not greater than the maximum x-coordinate, and the y-coordinate of the defect coordinate is not less than the minimum y-coordinate and not greater than the maximum y-coordinate, then the software PCS unit is determined to be the software defect unit.

4. The method as described in claim 1, characterized in that, The step of verifying the accuracy of the circuit board's identification based on the software defect coordinates, number of software defects, and type of software defect units, and the physical defect coordinates, number of physical defects, and type of physical defect units, further includes: Obtain the coordinates, number, and type of the software defect identified by the defect identifier in the software defect unit; Visual inspection is used to determine the coordinates, number, and type of the defect in the defect identifier of the physical defect unit. If the difference between the coordinates of the software defect and the coordinates of the entity defect is within a preset coordinate consistency threshold, the difference between the number of software defects and the number of entity defects is within a preset quantity consistency threshold, and the type of software defect and the type of entity defect are consistent, then the verification is deemed successful.

5. The method as described in claim 4, characterized in that, After determining the coordinates, quantity, and type of the defect identifier of the physical defect unit through visual inspection, the method further includes: If the difference between the software defect coordinates and the entity defect coordinates is outside the preset coordinate consistency threshold but within the preset coordinate tolerance threshold, then the preset manual confirmation process is initiated. If the difference between the coordinates of the software defect and the coordinates of the entity defect is outside the coordinate tolerance threshold, or the difference between the number of software defects and the number of entity defects is outside the preset quantity tolerance threshold, or the type of software defect and the type of entity defect are inconsistent, an alarm will be triggered and a preset abnormality handling process will be initiated.

6. The method as described in claim 1, characterized in that, After identifying the software PCS units in the imported circuit board and determining the software defective units marked with defective tags, the method further includes: In response to a click operation on the software defect unit, a dialog box corresponding to the software defect unit is displayed; In response to a user-triggered scrap number entry operation, the scrap number of the software defect unit is determined; Based on the scrap number, the status of the software defect unit is adjusted to the scrap status; Adjust the background color of the software defect unit in the preset visualization interface, and mark the software defect unit as unavailable in the preset database.

7. The method as described in claim 1, characterized in that, The step of verifying the accuracy of the circuit board's identification based on the software defect coordinates, number of software defects, and type of the software defect unit, and the physical defect coordinates, number of physical defects, and type of physical defect unit, and generating an identification traceability code if the verification passes, further includes: Obtain the target traceability code that needs to be uploaded; Based on the target traceability code, target traceability information is determined, and the software defect identifier of the target software defect unit and the entity defect identifier of the target entity defect unit bound to the target traceability information are determined. Determine whether the target traceability information, the software defect identifier, and the entity defect identifier are consistent; If they match, a target traceability file is generated based on the target traceability information, the software defect identifier, and the entity defect identifier, and the target traceability file is uploaded to the database.

8. A circuit board defect identification device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the circuit board defect identification method as described in any one of claims 1 to 7.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the circuit board defect identification method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the circuit board defect identification method as described in any one of claims 1 to 7.

Images