Production line data acquisition method and device, equipment and storage medium

Abstract

The application belongs to the technical field of intelligent manufacturing, and discloses a production line data acquisition method, device, equipment and storage medium. The method comprises the following steps: verifying version point position data and redundant point position data in work data to obtain effective work data; and uploading the effective work data to a server to complete production line data acquisition. It should be noted that, in actual production, the number of devices is very large, and it is impossible for all devices to operate and upgrade together in the device updating operation process. Therefore, on the basis of version point verification, some redundant point positions are set to verify whether the data collected by the control device can be compatible with the upper computer and the server in the data acquisition process under the condition that the versions are inconsistent, thereby effectively solving the technical problem of management difficulty in the production line data acquisition process.

Description

Technical Field

[0001] This invention relates to the field of intelligent manufacturing technology, and in particular to a method, apparatus, equipment and storage medium for production line data acquisition. Background Technology

[0002] In lithium battery industrial production, the winding process is a core link in the series of upstream and downstream processes, and the stability of its equipment operation directly affects the overall production efficiency. However, the current function block version management of winding equipment has significant shortcomings. Specifically, due to the large number of devices on the production line and the complexity of equipment management, different equipment maintenance is handled by different production lines or departments, while data is uniformly planned and managed. This leads to inconsistencies between the PLC program and the host computer function blocks across different devices, and the lack of a unified version verification mechanism increases the risk of equipment operation, necessitating a systematic solution.

[0003] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this invention is to provide a production line data acquisition method, apparatus, equipment, and storage medium, aiming to solve the technical problem of complex production line equipment management in the prior art.

[0005] To achieve the above objectives, the present invention provides a production line data acquisition method, the method comprising the following steps:

[0006] Collect working data from the control equipment; verify the version consistency of the working data based on the version location data and redundant location data in the working data to obtain valid working data, wherein the redundant location data is used to characterize the function of the working data; upload the valid working data to the server to complete the production line data collection.

[0007] It should be noted that, due to the large number of devices in actual production, it is impossible to upgrade all devices simultaneously during equipment updates. This is because equipment upgrades may affect production line operations, and the upgrade process needs to be determined based on the actual situation of the production line. Different versions are not necessarily incompatible with each other. Therefore, based on version point verification, some redundant points are set to verify whether the data collected by the control device can be compatible with the host computer and server when versions are inconsistent. This effectively solves the technical problem of difficult management during production line data collection.

[0008] In some embodiments, verifying the version consistency of the working data based on the version point data and redundant point data in the working data to obtain valid working data includes: matching the version of the working data with the corresponding version number stored in the working data; if the version matching is successful, verifying the functionality of the working data based on the redundant point data; and if the consistency verification result is consistent, determining that the working data is valid working data.

[0009] It's worth noting that the verification logic can be improved by first filtering version information. This is because versions are differentiated by major and minor versions, such as v2.1.3, which has three levels. If a major version doesn't match, it can be directly identified as a significant difference and an error can be reported. However, when the version changes are within a smaller version range, version compatibility may occur. This can be verified using redundant points, which can be used to characterize version functionality or data format. Consistency in these points indicates that the data is usable and valid. Therefore, verifying by version first and then functionality can greatly improve verification efficiency, especially in scenarios with massive equipment like production lines, where the improvement in production efficiency is very significant.

[0010] In some embodiments, the step of verifying the consistency of the working data based on redundant point data includes: determining point marker information and process data based on the redundant point data; verifying the validity of the working data based on the point marker information; performing data matching based on the process data and the preset current version of the equipment function; and determining the consistency verification result as consistent if the data matching result is a successful match and the working data is valid.

[0011] It should be noted that redundant point data can be generated based on process data. Process data represents the process parameters collected by the control equipment, such as product temperature, humidity, speed, output, etc. By checking whether the type of each process parameter is consistent with the type of the current version, consistency can be determined, improving compatibility between versions and increasing production efficiency.

[0012] In some embodiments, before acquiring the working data in the acquisition and control device, the following method is further included:

[0013] A dynamic link library file is generated based on the process logic code; the dynamic link library file is subjected to compatibility verification; if the compatibility verification is passed, the dynamic link library file is bound to the control device to obtain a binding relationship; the collection of working data in the control device further includes: collecting working data in the control device according to the binding relationship.

[0014] It should be noted that the code of the function block is compiled into an independent module DLL (Dynamic Link Library) file to ensure its compatibility with the winding process and to provide a binding basis for the control equipment, host computer and server.

[0015] In some embodiments, the compatibility verification of the dynamic link library file includes: obtaining communication protocol information of the control device and data format information of the server; performing compatibility verification with the control device based on the communication protocol information of the control device and the dynamic link library file; performing compatibility verification with the server based on the data format information of the server and the dynamic link library file; and determining the compatibility of the dynamic link library file based on the compatibility verification results of the control device and the server.

[0016] It should be noted that by matching communication protocols and data formats, smooth data flow between control equipment, host computer, and server is ensured, compatibility is verified, and smooth data interaction is guaranteed, ensuring the lower limit of normal operation of the production system. By decoupling interaction capabilities and data validity in a layered manner, the efficiency of the production system is improved and the speed of fault location is increased.

[0017] In some embodiments, binding the dynamic link library file to the control device includes: obtaining version information of the control device; determining a binding relationship based on the version information of the control device and the version information of the dynamic link library file; determining the version difference between the control device and the dynamic link library file based on the binding relationship; and binding the dynamic link library file to the control device when the version difference is less than a preset version difference value.

[0018] It should be noted that the binding relationship ensures that the version remains within a certain acceptable range, rather than strictly judging the system's availability based on the version. By automatically parsing the function block version information of the PLC and the host computer, and dynamically binding the matching function block versions, manual intervention to resolve version associations is reduced. This improves the consistency level of function block versions in the winding equipment while minimizing the impact of version differences on production efficiency.

[0019] In the event of an abnormal verification result, after verifying the version consistency of the working data based on the version point data and redundant point data in the working data, the method further includes: determining the abnormality type, abnormality level, and version information based on the abnormal result; determining the abnormal alarm method and abnormal alarm channel based on the abnormality type and abnormality level; determining the alarm content based on the version information; and issuing an abnormal alarm based on the alarm content, abnormal alarm method, and abnormal alarm channel.

[0020] It should be noted that when an abnormal version of a function block is detected in the host computer, the field industrial control machine will proactively prompt the availability of a new version. Users can select and execute the update based on the system's recommendations, ensuring the compatibility and stability of the equipment operation and improving the system's stability.

[0021] Secondly, to achieve the above objectives, the present invention also provides a production line data acquisition device, the production line data acquisition device comprising:

[0022] The acquisition module is used to collect working data from the control equipment; the processing module is used to verify the version consistency of the working data based on the version point data and redundant point data in the working data to obtain valid working data, wherein the redundant point data is used to characterize the function of the working data; and the communication module is used to upload the valid working data to the server to complete the production line data acquisition.

[0023] Thirdly, to achieve the above objectives, the present invention also provides a production line data acquisition device, the production line data acquisition device comprising: a memory, a processor, and a production line data acquisition program stored in the memory and executable on the processor, the production line data acquisition program being configured to implement the steps of the production line data acquisition method described above.

[0024] Fourthly, to achieve the above objectives, the present invention also provides a storage medium storing a production line data acquisition program, wherein the production line data acquisition program, when executed by a processor, implements the steps of the production line data acquisition method described above. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the first embodiment of the production line data acquisition method of the present invention;

[0026] Figure 2 This is a schematic diagram of the control architecture of an embodiment of the production line data acquisition method of the present invention;

[0027] Figure 3 This is a flowchart illustrating the second embodiment of the production line data acquisition method of the present invention;

[0028] Figure 4 This is a flowchart illustrating the third embodiment of the production line data acquisition method of the present invention;

[0029] Figure 5 This is a flowchart illustrating the fourth embodiment of the production line data acquisition method of the present invention;

[0030] Figure 6 This is a flowchart illustrating the fifth embodiment of the production line data acquisition method of the present invention;

[0031] Figure 7This is a structural block diagram of the first embodiment of the production line data acquisition device of the present invention.

[0032] 101: Machine 1; 102: Machine 2; 103: Machine 3;

[0033] 201: Host computer;

[0034] 202: Control equipment;

[0035] 301: Server.

[0036] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0037] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0038] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0039] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0040] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0041] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0042] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0043] In the description of the embodiments of this application, the technical terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the embodiments of this application and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0044] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0045] The content disclosed in this application is mainly applied to the battery production control process. The control architecture of this embodiment is divided into control equipment (such as PLC), host computer and server. However, the following technical problems exist in the actual process control: the version information of the PLC and host computer function blocks in the winding process is not centrally stored, and the version differences between equipment cannot be automatically identified, resulting in low efficiency due to reliance on manual intervention; the version compatibility of the PLC function blocks and host computer function blocks in the winding process lacks an automated verification mechanism, which poses a risk of version conflict; (no unified version management platform is deployed, making it impossible to realize online real-time verification or offline batch comparison, resulting in version errors being difficult to detect in a timely manner, increasing the risk of equipment downtime.)

[0046] Therefore, this solution uses a server to automatically parse and match the function block versions of the winding equipment. Based on the version information collection, verification, and binding logic of the PLC and the host computer, it ensures the accuracy of the function block versions and the consistency of operation, thereby guaranteeing the stable operation of the winding equipment.

[0047] Specifically, this embodiment uses the host computer as the execution entity and is explained from the host computer's perspective. Version points, confirmation points, and redundant points (confusion variables) are set in the winding equipment PLC. Combined with point data collected by the host computer, candidate points similar to the version information are selected. The accuracy is verified using confirmation points, and version points are further confirmed using confusion variables. After filtering invalid data, the final version information is uploaded to the server. The host computer's winding function block is compiled into an independent DLL module. A self-test mechanism verifies whether this module is suitable for the winding process and can interact normally with the PLC function block. The verified DLL is encrypted with a digest and uploaded to the server along with the function block version number. The system identifies the function block version that can run normally through parsing. Based on the host computer's self-test results, the compatibility between its function block and the PLC program function block is confirmed, the matching version binding relationship is extracted, and it is marked as a valid pairing on the server. This logic ensures dynamic matching between the PLC and host computer function block versions, reducing operational risks.

[0048] According to some embodiments of this application, such as Figure 1 The diagram illustrates a production line data acquisition method, the method comprising:

[0049] Step S10: Collect working data from the control equipment; Step S20: Verify the version consistency of the working data based on the version point data and redundant point data in the working data to obtain valid working data, wherein the redundant point data is used to characterize the function of the working data; Step S30: Upload the valid working data to the server to complete the production line data collection.

[0050] It should be noted that the control equipment is the equipment used to directly control the field equipment on the production line (winding machine, needle clamp, etc.), such as PLC. This embodiment does not limit the type of control equipment, but only uses PLC as an example for explanation.

[0051] It should be noted that version point data refers to the field that records version information in the working data stream, while redundant point data is a field used to characterize other information. Redundant point data can be parameters used to characterize working variables. Taking a PLC controlling a winding machine as an example, redundant points can be, for example, points controlling OH (overhang), points controlling variable winding needles, etc., used to characterize some production control functions that the PLC can collect. Redundant point data can also be parameters of some flag bits, such as: running flag bits indicating "Is the motor started?", emergency stop flag bits indicating "Is the emergency stop button pressed?", or fault flag bits indicating "Is the equipment malfunctioning?", etc., used to characterize parameters of operating status functions. By matching production functions, status functions, or other functions, version consistency can also be determined, that is, there are functional differences between two versions, avoiding situations where useful data is not collected or a large amount of useless data is collected.

[0052] Therefore, by using both version point data and redundant point data in the working data for dual verification, the consistency between PLC acquisition and server requirements is ensured.

[0053] Furthermore, such as Figure 2 As shown, server 301 is the central node for all equipment and production lines, responsible for data aggregation, data analysis, data processing, task distribution, version updates, and information configuration. Sub-nodes include machines (e.g., machine 101 in the example), PLC 202, host computer 201, and production line equipment. The consistency of software versions and functions between the central node and sub-nodes is crucial, determining the overall system's operating efficiency and failure rate.

[0054] It should be noted that, due to the large number of devices in actual production, it is impossible to upgrade all devices simultaneously during equipment updates. This is because equipment upgrades may affect production line operations, and the upgrade process needs to be determined based on the actual situation of the production line. Different versions are not necessarily incompatible with each other. Therefore, based on version point verification, some redundant points are set to verify whether the data collected by the control device can be compatible with the host computer and server when versions are inconsistent. This effectively solves the technical problem of difficult management during production line data collection.

[0055] In some embodiments, such as Figure 3 As shown, step S20 may further include: step S21: matching the version point data in the working data with the corresponding version number stored; step S22: if the version matching is successful, performing consistency verification on the function of the working data based on the redundant point data; step S23: if the consistency verification result is consistent, determining that the working data is valid working data.

[0056] Understandably, the verification logic can first filter the version information. This is because versions are differentiated by major and minor versions, such as v2.1.1. These version numbers can be divided into three levels. By comparing the version numbers, we can determine the extent of the version differences. For example, if the current working data in the PLC holds version number V2.1.1 while the host computer holds version V2.1.3, it means that the version difference is small and a successful match is accepted. However, if the version of the function in the host computer is V3.1.1, it means that there is a qualitative difference between the two versions, with significant differences in functionality and even data transmission format. Therefore, there is no need to further compare redundant points. This saves comparison time and creates some redundancy for version differences. It does not force all devices to keep the same version, improving the flexibility and convenience of upgrading the software and hardware versions of the devices.

[0057] Redundant data points can be parameters characterizing operational variables, such as temperature and humidity data, used to represent production functions that the PLC can collect. Redundant data points can also be flag parameters, such as "Is the motor started?" (running flag), "Is the emergency stop button pressed?" (emergency stop flag), or "Has the equipment malfunctioned?" (fault flag), used to characterize operational status functions. Matching production functions, status functions, or other functions can also determine version consistency, i.e., whether there are functional differences between two versions, avoiding situations where useful data is not collected or a large amount of useless data is collected. When version differences are minor, using these functional variables for comparison ensures functional consistency.

[0058] It's worth noting that the verification logic can be improved by first filtering version information. This is because versions are differentiated by major and minor versions, such as v2.1.3, which has three levels. If a major version doesn't match, it can be directly identified as a significant difference and an error can be reported. However, when the version changes are within a smaller version range, version compatibility may occur. This can be verified using redundant points, which can be used to characterize version functionality or data format. Consistency in these points indicates that the data is usable and valid. Therefore, verifying by version first and then functionality can greatly improve verification efficiency, especially in scenarios with massive equipment like production lines, where the improvement in production efficiency is very significant.

[0059] In some embodiments, such as Figure 4As shown, step S22 may further include: step S221: determining point marker information and process data based on the redundant point data; step S222: verifying the validity of the working data based on the point marker information; step S223: performing data matching between the process data and the preset current version of the equipment function; step S224: if the data matching result is a successful match and the validity of the working data is valid, determining the consistency verification result as consistent.

[0060] It should be noted that in actual deployment, different suppliers or deployment parties may use the same logical functions or code on the same batch of equipment, and the above-mentioned situations may occur during maintenance and upgrades. If these functions or code have the same naming or points, it will be difficult to distinguish between functions and versions. Based on this situation, this embodiment sets up confirmation points to identify the version and functional blocks deployed by the user. Therefore, when confirmation points exist, the validity of the working data is confirmed based on the point marking information, wherein the confirmation points correspond to the working data deployed by this party.

[0061] It is understandable that verification through three key points, such as in the PLC (Programmable Logic Controller) of a winding device, involves pre-setting function block version points (registers or variables used to store function block version information), confirmation points (check bits used to verify data accuracy), and redundant points (confusion variables, backup signals used to interfere with data filtering). Version points store the function block version number (e.g., "213"), confirmation points are used to mark whether the data is valid (e.g., "1" indicates valid, "0" indicates invalid), and redundant points are used for subsequent data verification. Here, "confusion variable" typically refers to a third-party variable introduced during data analysis or modeling, i.e., an auxiliary variable used to verify or distinguish valid data; it is an important judgment point in the data processing stage. In this embodiment, the confusion variable is a parameter used to characterize working variables, such as temperature data, humidity data, etc., used to characterize some production functions that the PLC can collect; or, the confusion variable is a parameter of some flag bits, such as: "Is the motor started?" running flag bit, "Is the emergency stop button pressed?" emergency stop flag bit, or "Has the equipment malfunctioned?" fault flag bit, etc., used to characterize the operating status function. By setting up a triple-point confirmation, the robustness of the system is improved, which refers to the ability of the control system to maintain certain performance characteristics under certain parameters (structure, size). In the data analysis and processing stage, data with certain characteristics can retain their original data characteristics even under data disturbances.

[0062] It should be noted that redundant point data can be generated based on process data. Process data represents the process parameters collected by the control equipment, such as product temperature, humidity, speed, output, etc. By checking whether the type of each process parameter is consistent with the type of the current version, consistency can be determined, improving compatibility between versions and increasing production efficiency.

[0063] In some embodiments, such as Figure 5 As shown, before step S10, step S01: generate a dynamic link library file based on the process logic code; step S02: perform compatibility verification on the dynamic link library file; step S03: if the compatibility verification passes, bind the dynamic link library file to the control device to obtain a binding relationship; step S10': collect working data from the control device based on the binding relationship; step S20: verify the version consistency of the working data based on the version point data and redundant point data in the working data to obtain valid working data, wherein the redundant point data is used to characterize the function of the working data; step S30: upload the valid working data to the server to complete the production line data collection.

[0064] It should be noted that this embodiment illustrates the verification process before intelligent data acquisition. Before step S10, the code of the function blocks in the host computer is compiled into independent DLL (Dynamic Link Library) files to ensure compatibility with the winding process. The compatibility of the DLL module is verified through a self-test mechanism. The purpose of this verification is to ensure compatibility between the PLC, the host computer, and the server to a minimum. Specifically, this embodiment proposes an implementation method, for example: digest encryption is performed on the DLL module that passes the self-test to generate a unique identifier, ensuring data integrity. The encrypted DLL module and its corresponding function block version information (such as "V2.1.2") are uploaded to the server. The server parses the uploaded DLL module, identifies its function block version, and matches it with the version information on the PLC.

[0065] Furthermore, the server verifies the DLL module's operability by parsing its version number and self-test results. If the DLL module is compatible with the PLC function block, the system marks it as a valid version and records its binding relationship with the PLC version; if incompatible, an exception will be displayed.

[0066] It should be noted that the code of the function block is compiled into an independent module DLL (Dynamic Link Library) file to ensure its compatibility with the winding process and to provide a binding basis for the control equipment, host computer and server.

[0067] In some embodiments, such as Figure 6As shown, step S02 can specifically be as follows: Step S021: Obtain the communication protocol information of the control device and the data format information of the server; Step S022: Perform compatibility verification with the control device based on the communication protocol information of the control device and the dynamic link library file; Step S023: Perform compatibility verification with the server based on the data format information of the server and the dynamic link library file; Step S024: Determine the compatibility of the dynamic link library file based on the compatibility verification results of the control device and the server.

[0068] Understandably, the specific verification process can be performed after deployment, separately with the PLC and the server. For example, the compatibility of the DLL module can be verified using a self-test mechanism. First, interface compatibility is checked by verifying whether the DLL module conforms to the PLC's communication protocol (such as Modbus, Profinet) and function block interface specifications. Further data format verification is performed by confirming that the data format output by the DLL module (such as version number and status code) matches the server's expected format. Finally, an interaction capability test is conducted, simulating communication between the PLC and the DLL module to verify whether its winding points can correctly respond to commands and return valid data.

[0069] It should be noted that by matching communication protocols and data formats, smooth data flow between control equipment, host computer, and server is ensured, compatibility is verified, and smooth data interaction is guaranteed, ensuring the lower limit of normal operation of the production system. By decoupling interaction capabilities and data validity in a layered manner, the efficiency of the production system is improved and the speed of fault location is increased.

[0070] In some embodiments, version information of the control device is obtained; a binding relationship is determined based on the version information of the control device and the version information of the dynamic link library file; the version difference between the control device and the dynamic link library file is determined based on the binding relationship; and when the version difference is less than a preset version difference value, the dynamic link library file is bound to the control device.

[0071] It should be noted that, based on compatibility testing, the binding process allows for a certain range of version differences during binding. This allowed range is the preset version difference, such as allowing a difference of one version, or a difference of V0.1 versions, to improve system robustness. Specifically, compatibility verification is based on the self-test results of the host computer (such as the compatibility information of the DLL module) to confirm the compatibility between its function blocks and the PLC program function blocks. For example, if the DLL module's winding function block version is "V2.1.3", and the self-test confirms that the PLC's winding function block version is also "213" or "212", it is considered compatible; otherwise, it is considered abnormal. Further, version binding relationships are extracted from the version information of the PLC and the host computer to find matching version binding relationships. For example, if the PLC's winding function block version is "213", and the host computer's DLL module version is also "V2.1.3", the binding relationship is "213:V2.1.3", and this is saved to the database. If versions are inconsistent, the system will record the version difference information and prompt the user whether an update or adjustment is needed. It provides reminders and version redundancy of 0. Finally, dynamic binding and risk control are implemented. For example, the server uses dynamic binding logic to monitor the version matching status of the PLC and host computer function blocks in real time. Real-time matching: When the version of the PLC or host computer changes, the system automatically triggers a version matching check to ensure that the versions are consistent. If a version mismatch is detected, the system will mark it as an abnormal pairing and trigger an alarm mechanism. Through dynamic management of binding relationships, communication failures, functional abnormalities, or equipment downtime caused by version mismatches are avoided, ensuring the stable operation of the winding equipment.

[0072] It should be noted that the binding relationship ensures that the version remains within a certain acceptable range, rather than strictly judging the system's availability based on the version. By automatically parsing the function block version information of the PLC and the host computer, and dynamically binding the matching function block versions, manual intervention to resolve version associations is reduced. This improves the consistency level of function block versions in the winding equipment while minimizing the impact of version differences on production efficiency.

[0073] In the event of an abnormal verification result, the abnormality type, abnormality level, and version information are determined based on the abnormal result; the abnormality alarm method and abnormality alarm channel are determined based on the abnormality type and abnormality level; the alarm content is determined based on the version information; and an abnormal alarm is issued based on the alarm content, abnormality alarm method, and abnormality alarm channel.

[0074] Understandably, through anomaly detection logic, the server analyzes the version status of functional blocks in real time using preset rules or machine learning models: if a version mismatch, missing data, or communication anomaly is detected in the wrapper functional block, the system automatically marks it as an anomaly. Different alarm levels are set based on the severity of the anomaly, with different version information displayed.

[0075] Specifically, abnormal verification results may be due to inconsistencies in versions or significant version differences, or discrepancies between the actual functions of the PLC and the functions recorded in the host computer. For example, the PLC may not have collected relevant parameters for overhang (OH) control, while the current version of the host computer requires processing such parameters. This lack of data is considered abnormal. The more mismatched functions, the more severe the abnormality level. Specific abnormality levels can be set according to actual conditions. Another possibility is the disappearance of point marker information. This indicates that the currently deployed function may have been set by another equipment supplier or maintenance provider, suggesting an error in the programming of the data acquisition function, thus also being judged as abnormal.

[0076] Specifically, for abnormal versions, the server automatically pushes alarms through multiple channels such as email, system messages, or enterprise communication platforms to ensure that relevant personnel receive abnormal notifications in a timely manner, improve response efficiency, and prevent the failure from escalating.

[0077] It should be noted that when an abnormal version of a function block is detected in the host computer, the field industrial control machine will proactively prompt the availability of a new version. Users can select and execute the update based on the system's recommendations, ensuring the compatibility and stability of the equipment operation and improving the system's stability.

[0078] Secondly, in order to achieve the above objectives, such as Figure 4 As shown, the present invention also provides a production line data acquisition device, the production line data acquisition device comprising:

[0079] Acquisition module 10 is used to collect working data from the control equipment;

[0080] Processing module 20 is used to verify the version consistency of the working data based on the version point data and redundant point data in the working data to obtain valid working data. The redundant point data is used to characterize the function of the working data.

[0081] The communication module 30 is used to upload the valid working data to the server to complete the production line data collection.

[0082] Thirdly, to achieve the above objectives, the present invention also provides a production line data acquisition device, the production line data acquisition device comprising: a memory, a processor, and a production line data acquisition program stored in the memory and executable on the processor, the production line data acquisition program being configured to implement the steps of the production line data acquisition method described above.

[0083] Fourthly, to achieve the above objectives, the present invention also provides a storage medium storing a production line data acquisition program, wherein the production line data acquisition program, when executed by a processor, implements the steps of the production line data acquisition method described above.

[0084] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no structural conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A production line data acquisition method, characterized in that, The method includes: Collect operational data from control equipment; The version consistency of the working data is verified by the version point data and redundant point data in the working data to obtain valid working data. The redundant point data is used to characterize the function of the working data. The valid working data is uploaded to the server to complete the production line data collection. The step of verifying the version consistency of the working data based on the version point data and redundant point data in the working data to obtain valid working data includes: Version matching is performed based on the version point data in the working data and the corresponding version number stored. If the version matching is successful, the functionality of the working data is verified for consistency based on the redundant point data. If the consistency verification result is consistent, the working data is determined to be valid working data; The consistency of the working data is verified based on redundant location data, including: The point marking information and process data are determined based on the redundant point data; The validity of the working data is verified based on the location marking information. Data matching is performed based on the process data and the preset functions of the current version of the equipment. If the data matching result is a successful match and the working data is valid, the consistency verification result is determined to be consistent.

2. The method as described in claim 1, characterized in that, Before the working data in the acquisition and control device, it also includes: Generate dynamic link library files based on process logic code; Perform compatibility verification on the dynamic link library files; If the compatibility verification is passed, the dynamic link library file is bound to the control device to obtain a binding relationship; The working data in the acquisition and control device also includes: The operating data of the control device is collected based on the binding relationship.

3. The method as described in claim 2, characterized in that, The compatibility verification of the dynamic link library file includes: Obtain communication protocol information from the control device and data format information from the server; Based on the communication protocol information of the control device and the dynamic link library file, a compatibility verification with the control device is performed; Based on the server's data format information and the dynamic link library file, a compatibility verification with the server is performed; Based on the compatibility verification results of the control device and the server, the compatibility of the dynamic link library file is determined.

4. The method as described in claim 2, characterized in that, The step of binding the dynamic link library file to the control device includes: Obtain the version information of the control device; The binding relationship is determined based on the version information of the control device and the version information of the dynamic link library file; The version differences between the control device and the dynamic link library file are determined based on the binding relationship; When the version difference is less than a preset version difference value, the dynamic link library file is bound to the control device.

5. The method as described in claim 1, characterized in that, After verifying the version consistency of the working data based on the version point data and redundant point data in the working data, the method further includes: In the event of an abnormal verification result, the abnormality type, abnormality level, and version information shall be determined based on the abnormal result; The alarm method and alarm channel are determined based on the anomaly type and anomaly level. Determine the alarm content based on the version information; An abnormal alarm is triggered based on the alarm content, abnormal alarm method, and abnormal alarm channel.

6. A production line data acquisition device, characterized in that, The production line data acquisition device includes: The acquisition module is used to collect working data from the control equipment; The processing module is used to verify the version consistency of the working data based on the version point data and redundant point data in the working data, and to obtain valid working data. The redundant point data is used to characterize the function of the working data. The communication module is used to upload the valid working data to the server to complete the production line data collection; The processing module is also used to perform version matching based on the version point data in the working data and the corresponding version number stored. If the version matching is successful, the functionality of the working data is verified for consistency based on the redundant point data. If the consistency verification result is consistent, the working data is determined to be valid working data; The processing module is also used to determine point marking information and process data based on the redundant point data; The validity of the working data is verified based on the location marking information. Data matching is performed based on the process data and the preset functions of the current version of the equipment. If the data matching result is a successful match and the working data is valid, the consistency verification result is determined to be consistent.

7. A production line data acquisition device, characterized in that, The device includes: a memory, a processor, and a production line data acquisition program stored in the memory and executable on the processor, the production line data acquisition program being configured to implement the steps of the production line data acquisition method as described in any one of claims 1 to 5.

8. A storage medium, characterized in that, The storage medium stores a production line data acquisition program, which, when executed by a processor, implements the steps of the production line data acquisition method as described in any one of claims 1 to 5.

Images