EtherNet / IP modular information identification method and device

Abstract

The present invention relates to the field of industrial network communication technology and provides an EtherNet / IP modular information identification method, which performs modular information identification on slave stations and sub-slaves through a preset device description file. To this end, the present invention imports the corresponding file mixed package into the master station device module through a controller; if the match is unsuccessful, the slave station device information is first obtained based on the EDS file, and the sub-module information is replaced in sequence with the logical station information in the XML file containing the logical station information; the slave station device information is matched with the XML file containing the logical station information, and communication is performed according to the description of the XML file containing the logical station information, and then all sub-modules under this slave station are identified in sequence according to the logical station information. The present invention supports dynamic adjustment of the number of logical stations according to the network topology, and realizes flexible identification and control of sub-station devices by dynamically importing a mixed package containing device information and logical station descriptions, thereby improving deployment efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of industrial network communications, and in particular to an EtherNet / IP modular information identification method and device. Background Art

[0002] like Figure 1 As shown in Figure 2, the three major mainstream industrial Ethernet protocols include EtherCAT, Ethernet / IP, and Profinet. Ethernet / IP is an application layer protocol built on top of TCP / IP. It utilizes standard Ethernet layer protocols and the Common Industrial Protocol (CIP) to establish inter-node communication through specific connections. It employs a star topology with an unlimited number of nodes. The EtherNet / IP protocol is widely used in industrial settings due to its openness, high transmission speed, strong compatibility, and strong real-time performance. Despite being open source and boasting a wide range of related products, the EtherNet / IP protocol faces a significant challenge in the increasingly prevalent industrial automation market for distributed control systems. Compared to EtherCAT and Profinet, its rack and submodule technology solutions have been slow to gain adoption among major automation equipment manufacturers. This is due in part to the slow transition from centralized to distributed control systems. Furthermore, the device description files (EDS) associated with EtherNet / IP products are highly standardized and difficult to encode. Furthermore, with the exception of a few major companies, many EtherNet / IP devices do not provide these files. Consequently, most EtherNet / IP controllers are only able to identify, configure, and control EtherNet / IP slaves themselves, failing to identify attached slaves. This makes it difficult to determine if a slave failure is occurring and prevents the timely detection of illegally attached slaves. This makes it impossible to upgrade slaves or perform process data expansion and mapping on them.

[0003] In this regard, in the prior art, the invention patent with patent publication number CN117706983A, "A method for visually configuring a coupler expansion module on a KEYENCE platform," provides a method for visually configuring a coupler expansion module on a KEYENCE platform. Specifically, the method includes creating a spreadsheet file, filling in manufacturer information in the spreadsheet file, creating an XML file for the coupler and expansion module, describing the information in the XML file, establishing a connection bridge and input / output address table for the coupler and expansion module, setting the starting address, offset address, and data type of the digital and analog modules, searching for the address in the XML file, connecting the coupler and expansion module through the connection bridge, and then using an address calculation method to automatically allocate the expansion module address. To avoid address preemption, the starting address of the analog module is set backward. This method solves the problem of fixed and inconvenient expansion module configuration due to the cumbersome calculation of traditional methods, and also solves the problem of difficult address recognition of Ethernet / IP coupler configurations on the KEYENCE platform.

[0004] However, while this patent aims to address addressing issues, drafting errors result in some incorrect descriptions. For example, in EtherNet / IP scenarios, the term "Rack" is typically translated as "rack." In EtherNet / IP scenarios, multiple modules, such as input / output modules or communication modules, are often installed on a rack. Rack accurately represents the location and connection status of these physical modules. However, the referenced document translates it as "connection bridge," clearly misinterpreting it as a "remote attachment connection kit (RACK)." This incorrect description renders the technical solution in the referenced document incomplete and inaccurate, making it unimplementable. Furthermore, even if the solution described in the referenced document is implemented, if the attachment location of a slave station changes, or if the slave station's configuration changes, the existing settings will not be able to quickly respond and automatically adjust. This can result in the master station being unable to locate the slave station's slave station, or even if it can detect the existence of the slave station, it will be unable to connect to it. In such cases, the existing technology often requires rewriting the XML file, which affects work efficiency. Summary of the Invention

[0005] The purpose of the present invention is to provide an EtherNet / IP modular information identification method. On the basis of not departing from the EtherNet / IP protocol, a solution for EtherNet / IP related products is provided for identifying and controlling devices loaded on slave stations. Even if the modular information of slave stations and sub-slaves can be identified through preset device description files,

[0006] To achieve the above-mentioned purpose, the present invention provides an EtherNet / IP modular information identification method, which adopts an EtherNet / IP controller. The specific identification steps are as follows: importing the corresponding EDS-XML file mixed package into the EtherNet / IP master device module through the EtherNet / IP controller; the EDS-XML file mixed package contains at least one EDS file and multiple XML files, and at least one of the XML files contains logical station information; first, determine whether the device information recorded in the EDS file in the EDS-XML file mixed package is consistent with that recorded in one of the XML files; if they are consistent, parse the successfully matched EDS file and XML file, determine the process data communication information by the EDS file, and determine the modular information identification path and service data communication path of the slave station by the XML file; if all files are parsed normally, further parse this slave station The Rack information supported by the device, if the supported Rack described in the sub-slave XML file is consistent with the slave Rack, then the XML of all matching Rack sub-slaves will be parsed to obtain the PDO and SDO information access paths, and all supported sub-slaves will be mounted under the corresponding slave paths; if the match is unsuccessful, the slave device information will be obtained according to the EDS file, and the logical station information in the XML file with the logical station information will be used to replace the first sub-slave information in the slave that cannot establish communication until the last sub-slave information in the slave that cannot establish communication; the slave device information will be matched with the XML file with the logical station information, and communication will be performed according to the description of the XML file with the logical station information, and then all sub-slaves under this slave will be identified in sequence according to the logical station information. If unmatched sub-slave information is encountered during the logical station identification process, this sub-slave will be skipped and the execution will continue until there is no sub-slave information response.

[0007] Preferably, the EtherNet / IP controller has an input interface. Before executing the recognition step, a recognition request is first submitted to the EtherNet / IP controller through the input interface. The EtherNet / IP controller filters the XML file based on the recognition request and obtains an output result based on the recognition request. This eliminates the need to fully parse the entire file in some cases, reduces the probability of recognition errors, and improves communication efficiency.

[0008] Preferably, the method for creating the EDS-XML file hybrid package is as follows: obtaining the EDS file from the device vendor and creating an XML file based on the device's technical documentation and relevant standards; the XML file includes XML files of different versions from previous upgrades and XML files with varying amounts of information within the same version; and generating an XML file containing logical stations based on the latest version of the XML file. The number of logical stations recorded in the XML file containing logical stations is based on the topology combination and is always less than or equal to the number of slots. Although this results in a larger EDS-XML file hybrid package, in actual use, it is not necessary to parse all files in the EDS-XML file hybrid package, thus significantly impacting the overall process time.

[0009] Preferably, when the XML file contains multiple logical stations, the number of logical station numbers is consistent with the number of physical station numbers of the device, and the station number value of the logical station is accumulated by the offset of the number of logical stations, which facilitates identification and management in later applications.

[0010] Preferably, the EDS-XML file mixed package automatically generates a file directory based on the files in the mixed package before packaging. Through the file directory, the files to be decompressed can be found more quickly and accurately.

[0011] Preferably, the specific steps for the EtherNet / IP master station device module to perform file matching are: unpacking the EDS-XML file mixed package, extracting the EDS file and performing the import operation; finding multiple related XML files from the file directory according to the identification requirements, parsing the XML files to extract basic device information; comparing the basic device information with the EDS, if an abnormality is found, prompting an abnormality, re-executing the EDS file import and replacing the XML file; if normal, continuing to parse the rack information; traversing and matching the rack file information, if an abnormality is found, prompting an abnormality, re-executing the EDS file import and replacing the XML file; if normal, generating the Slot scan path and the EtherNet / IP protocol specification message, and then starting to parse the device extended information path.

[0012] Preferably, when the extracted basic information of the extended device matches the exception, the EDS file import is re-executed and the XML file is replaced. If the extended device information does not exist or is normal, the extended device information access path and the EtherNet / IP protocol specification message are generated and the device parameter information is parsed. If the parameter device information does not exist or is normal, the device parameter information access path and the EtherNet / IP protocol specification message are generated and the device alarm information is parsed. If there is an exception, an abnormality is prompted, and the EDS file import is re-executed and the XML file is replaced. If the device alarm information does not exist or is normal, the device alarm information access path and the EtherNet / IP protocol specification message are generated and the process data tag information is parsed. If there is an abnormality, an abnormality is prompted, and the EDS file import is re-executed and the XML file is replaced. If the process data tag information is normal, the parsing is completed. If there is no or abnormal information, an abnormality is prompted, and the EDS file import is re-executed and the XML file is replaced.

[0013] The above two-stage analysis steps are actually optimized designs based on different judgment requirements.

[0014] Preferably, when an exception occurs in each of the corresponding XML files, the exception information is collected, the XML file with the logical station is parsed, the XML file with the logical station is modified based on the exception information, and the device parameter information access path and EtherNet / IP protocol specification message are generated based on the XML file with the logical station. The XML file with the logical station already exists in the initial EDS-XML file hybrid package, but cannot be used directly. It needs to be modified based on the feedback of the exception information before it can be actually used.

[0015] Preferably, based on identification requirements, the parsing paths of different types of XML files are different: obtaining slave station device information requires parsing the slave station device XML file to at least the extended device information access path; determining whether a sub-slave station exists only requires parsing the rack device XML file to the rack information.

[0016] The present invention also includes an electronic device, including a processing unit and a storage unit, wherein the processing unit is provided with an EtherNet / IP controller with an input interface, the storage unit records an EtherNet / IP modular information identification method, and the EtherNet / IP modular information identification method is executed by the processing unit.

[0017] By adopting the aforementioned technical solution, the proposed EtherNet / IP modular information identification method incorporates the concept of logical stations, supports dynamic adjustment of the number of logical stations based on network topology, and ensures strict correspondence between logical and physical station numbers, adapting to complex network structures. By dynamically generating and parsing hybrid EDS-XML packets, slave device identification is achieved without the need for pre-defined device description files. By dynamically importing hybrid EDS-XML packets containing both device information and logical station descriptions, flexible slave device identification and control are achieved, significantly improving deployment efficiency and applicability.

[0018] Furthermore, the present invention further enhances the robustness of the system through dynamic matching and multi-layer exception handling mechanisms: it supports differentiated processing in full matching, partial matching and non-matching scenarios, can automatically replace logical station information, parse alarm information and generate access paths, thereby ensuring the integrity of process data.

[0019] In addition, the present invention also relates to electronic equipment, which, combined with the overall hardware integrated design solution, surpasses the existing technology in versatility, flexibility, fault tolerance and integration, and is particularly suitable for dynamic expansion scenarios of equipment in complex industrial networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings are used to provide a further understanding of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and do not constitute a limitation of the present invention. In the accompanying drawings:

[0021] Figure 1 This is a schematic diagram comparing the recognition capabilities of the three major industrial Ethernet protocols in the existing technology for slave devices and sub-slaves.

[0022] Figure 2 This is a workflow diagram of an EtherNet / IP modular information identification method of the present invention.

[0023] Figure 3 The present invention is a schematic diagram of a file parsing and comparison process of an EtherNet / IP modular information identification method.

[0024] Figure 4 This is a schematic diagram of SDO object acquisition and configuration in an EtherNet / IP modular information identification method of the present invention. DETAILED DESCRIPTION

[0025] The preferred embodiments of the present invention are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.

[0026] In order to clearly express the contents involved in the present invention, the meanings of some abbreviations involved in the present invention are first explained.

[0027] First, the concept of logical station is introduced in the present invention. The concept of logical station corresponds to the concept of physical station. The physical station refers to the communication node that objectively exists in the physical topology; while the logical station is a conceptual communication node that does not exist objectively but is defined subjectively.

[0028] Logical stations do not rely on specific hardware. Instead, they abstract and encapsulate the functionality of physical devices through software, forming flexibly configurable virtual nodes. These nodes are ideally suited for the scenarios described in this document. A physical station can contain at least one and up to an unlimited number of logical stations. The total resources occupied by a physical station are always an integer multiple of the resources of a single logical station. If this is less than an integer multiple, the resources are aligned upward. The multiple of a physical station to a logical station follows the following rules: The multiple is calculated using the four quadrants of the two dimensions of uplink and downlink data, and digital and analog data, and the maximum is taken.

[0029] Different from slots, logical stations occupy slots as virtual devices. The number of slots is fixed by the Rack file description, while the number of logical stations is flexibly combined according to the topology, but is always less than or equal to the number of slots.

[0030] Take the EtherNet / IP plug-in coupler and plug-in IO module XB6S-3200 produced by the applicant as an example:

[0031] The XB6S-3200 module is a 32-point digital input module. Its PDO resources are 4 bytes for upstream digital input, 0 bytes for downstream digital input, and 0 bytes for upstream and downstream analog input. If a logical station resource size is defined as 2 bytes for upstream and downstream digital input, the XB6S-3200 occupies two logical stations. If a logical station resource size is defined as 4 bytes for upstream and downstream digital input, the XB6S-3200 occupies one logical station.

[0032] The number of logical stations is limited by factors such as the number of slots, PDO data allocation, and the total length of PDO data. Therefore, the number of physical stations in a topology is also affected by these factors. The resource size occupied by a logical station during communication is dynamically fixed. While the resource size of a logical station can be adjusted dynamically based on the XML file description, the resource size of logical stations within a device series should remain fixed. To optimize performance-to-resource ratios, a device typically does not exceed four logical stations.

[0033] Next, we need to explain the relationship between slaves, sub-slaves, and sub-slaves. Slaves are directly connected to the controller and must use the Ethernet / IP protocol. Sub-slaves, as a layer below slaves, can use some proprietary bus protocols. Because controller node resources are generally limited, this operation can reduce costs and save nodes (slots). Sub-slaves can be understood as sub-slave devices, that is, devices connected to sub-slaves. Depending on the needs, sometimes it is sufficient to simply detect the presence of devices on a sub-slave, while other times it is necessary to communicate and manage devices on the sub-slave. The degree to which extended access paths are generated varies depending on the needs.

[0034] EtherNet / IP device descriptions consist of two files: an EDS file and an XML file. An EDS (Electronic Data Sheet) file, or EDS file, is an electronic data sheet used to describe the various parameters and functions of Ethernet / IP products, such as sensors, actuators, and controllers in industrial Ethernet devices. It is essentially a text file that uses a specific format to store detailed device information. This file is typically provided by the device vendor.

[0035] XML files: XML (Extensible Markup Language) files are typically used to describe device configuration, capabilities, data structures, and other information. Some of the XML files mentioned in this document can be generated by configuration software on other devices by reading device information and then copied for use. However, most XML files are created by technicians based on the device's technical documentation and relevant standards.

[0036] XML files provide a secondary description of slave information, particularly sub-slaves. Compared to the device information contained in EDS files, XML files provide a more detailed description. XML files include three types of files: rack files, which describe the slots within a rack; slave files, which contain basic device information, rack and slot information, and extended object model information; and sub-slave files, which contain basic device information, rack and slot information, and extended object model information. In this invention, even when creating the same type of XML file, different contents can be included, generating different XML files based on potential needs.

[0037] The present invention also relates to PDO mapping and SDO mapping. In the XML file's descriptive object, the extended object model information primarily includes PDO and SDO information. The core application scenario for the solution described in this invention is the field of industrial automation. In industrial communications within this field, PDO and SDO data are the primary types of data exchanged between controllers and slave devices. Therefore, the present invention only has practical application significance if the rules for these two types of data exchange, from controller to slave to sub-slave, are established.

[0038] PDO mapping: PDOs are used to rapidly transmit real-time data between devices. They are a periodic or event-triggered data exchange method. PDO mapping maps specific application objects within a device, such as sensor measurements and actuator control parameters, to PDOs. This ensures real-time and efficient data transmission. In industrial automation production lines, sensors can quickly transmit data such as temperature and pressure collected in real time to controllers through PDO mapping, enabling timely responses and control, enabling real-time monitoring and control of equipment.

[0039] SDO Mapping: SDO is used for device parameter settings and aperiodic data access. SDO mapping associates device parameter objects, such as the device's operating mode and baud rate, with SDOs. This provides flexible access to any object in the device object dictionary. During device commissioning, engineers can use SDO mapping to read and modify device configuration parameters to meet actual application requirements.

[0040] like Figure 1As shown, the three major industrial Ethernet protocols currently in use include EtherCAT, Ethernet / IP, and Profinet. With increasingly fierce competition in the industrial automation market, market demands for cost, ease of use, and maintainability of industrial Ethernet devices are rising. Consequently, more and more automation equipment manufacturers are choosing to mount sub-slaves within protocol slaves. Automation equipment manufacturers choose to mount sub-slaves within protocol slaves primarily to expand functionality, enabling devices to meet more complex industrial control scenarios. For example, a device may originally only have basic digital input and output capabilities. By mounting a sub-slave, analog I / O capabilities can be added, enabling the acquisition and control of analog signals such as temperature, pressure, and flow, greatly expanding the device's application range. This approach also offers a high degree of flexibility, allowing manufacturers to configure devices based on the individual needs of different users by mounting sub-slaves with different functions. This is similar to an industrial robot controller mounting a sub-slave for visual recognition or end-effector control, thereby enhancing the device's versatility and competitiveness in the market. In terms of system integration, devices equipped with slave stations can be better integrated into industrial automation systems. As multifunctional nodes, they can effectively exchange information and coordinate actions with other slave stations, master stations, and upper-level monitoring systems, making the system integration process easier and improving the overall system performance. Furthermore, from the perspective of cost control and equipment upgrade optimization, manufacturers can first produce core modules and then, based on market conditions and user orders, add slave stations to achieve different functional levels. This avoids the need to produce multiple complete devices of varying complexity and reduces production costs. Furthermore, during subsequent use of the equipment, users can optimize and upgrade device performance by replacing or adding slave stations without having to replace the entire device, saving the cost and resources of equipment updates.

[0041] However, installing slaves in automated equipment presents multiple security risks. From a data security perspective, the communication links and data interaction between slaves become more complex. Vulnerabilities in the slave communication protocol or software can lead to data leaks. For example, hackers could exploit the slave-master interface to steal sensitive production data such as product formulas and process parameters, compromising corporate intellectual property and trade secrets. From an operational safety perspective, a slave failure or malicious manipulation could lead to equipment loss of control, potentially even causing serious safety incidents in high-speed, high-precision equipment. Complex slave configurations can also lead to operational errors. Due to improper software logic or parameter settings, the device can incorrectly respond to control signals and perform the wrong action at the wrong time. In terms of network security, each slave can become a potential entry point for malicious attacks. Furthermore, the presence of slaves complicates security updates. Different vendors offer varying update cycles and methods for their slaves, making it difficult to ensure timely security patches, leaving equipment exposed to prolonged security risks. Now, under the EtherCAT and ProfiNet protocols, slave devices can identify their sub-slaves, which can effectively reduce these risks. However, under the EtherNet / IP protocol, slave devices cannot identify their sub-slaves.

[0042] To this end, the present invention provides an EtherNet / IP modular information identification method, which uses an EtherNet / IP controller with an input interface, such as Figure 2As shown, the specific identification steps are as follows: an identification requirement is put forward to the EtherNet / IP controller through the input interface; the EtherNet / IP controller screens the XML file according to the identification requirement, obtains the output result according to the identification requirement, and imports the corresponding EDS-XML file mixed package into the EtherNet / IP master device module; the EDS-XML file mixed package contains at least one EDS file and multiple XML files, and at least one of the XML files contains logical station information; first, it is determined whether the device information recorded in the EDS file in the EDS-XML file mixed package is consistent with that in one of the XML files; if they are consistent, the successfully matched EDS file and XML file are parsed, and the process data communication information is determined by the EDS file, and the modular information identification path and service data communication path of the slave station are determined by the XML file. If all files are parsed normally, the Rack information supported by this slave device is further parsed. If the supported Rack described in the sub-slave XML file is consistent with the slave Rack, the XML of all matching Rack sub-slaves is parsed to obtain the PDO and SDO information access paths, and all supported sub-slaves are mounted to the corresponding slave paths. If the match is unsuccessful, the slave device information is first obtained according to the EDS file, and the logical station information in the XML file with the logical station information is used to replace the first sub-slave information in the slave that cannot establish communication until the last sub-slave information in the slave that cannot establish communication. The slave device information is matched with the XML file with the logical station information, and communication is performed according to the description of the XML file with the logical station information. Then, all sub-slaves under this slave are identified in sequence according to the logical station information. If unmatched sub-slave information is encountered during the logical station identification process, this sub-slave will be skipped and the execution will continue until there is no sub-slave information response.

[0043] The method for creating the EDS-XML file hybrid package is as follows: obtaining the EDS file from the device supplier and independently creating an XML file based on the device's technical documentation and relevant standards; the XML file includes different versions of XML files from previous upgrades and XML files with different amounts of information within the same version; and generating an XML file with logical stations based on the latest version of the XML file. The number of logical stations recorded in the XML file with logical stations is based on the topological combination and is always less than or equal to the number of slots. When the XML file contains multiple logical stations, the number of logical station numbers is consistent with the number of physical station numbers of the device, and the station number value of the logical station is accumulated by the offset of the number of logical stations. The EDS-XML file hybrid package automatically generates a file directory based on the files in the hybrid package before packaging.

[0044] like Figure 3As shown in the figure, the specific steps for the EtherNet / IP master device module to perform file matching are as follows: unpacking the EDS-XML file mixed package, extracting the EDS file, and executing the import operation; locating multiple relevant XML files from the file directory based on the identification requirements, parsing the XML files to extract basic device information; comparing the basic device information with the EDS; if an anomaly is found, an error message is displayed, re-importing the EDS file and replacing the XML file; if normal, continuing to parse the rack information; traversing and matching the rack file information; if an anomaly is found, an error message is displayed, re-importing the EDS file and replacing the XML file; if normal, generating the slot scan path and EtherNet / IP protocol specification message, and then starting to parse the device extended information path. If the extracted extended device basic information matches the anomaly, re-importing the EDS file and replacing the XML file; if the extended device information is missing or normal, generating the extended device information access path and EtherNet / IP protocol specification message, and starting to parse the device parameter information; if the parameter device information is missing or normal, generating the device parameter information access path and EtherNet / IP protocol specification message; if an anomaly is found, parsing the device alarm information. When an exception occurs in all corresponding XML files, the exception information is collected, the XML file with the logical station is parsed, the XML file with the logical station is modified based on the exception information, and the device parameter information access path and EtherNet / IP protocol specification message are generated based on the XML file with the logical station. After the device parameter information access path and EtherNet / IP protocol specification message are generated in the XML file with the logical station, the process data tag information is processed: the process data tag information is parsed; if there is no exception in the process data tag information, the process ends; if there is an exception, an exception prompt is given, and the information recognition fails at this time. Based on the recognition requirements, the parsing paths of different types of XML files are different: to obtain the slave device information, the slave device XML file needs to be parsed to at least the extended device information access path; to determine whether a sub-slave station exists, only the rack device XML file needs to be parsed to the rack information.

[0045] It should be noted that the present invention includes a step of submitting an identification request to the EtherNet / IP controller via the input interface. This is because different identification requirements lead to different levels of actual identification requirements. This distinction will be further explained in the detailed implementation.

[0046] The present invention does not provide a specific usage model for the EtherNet / IP object model, but rather a relatively vague usage model. This model defines a set of object model usage rules, but does not specify the objects used under these rules. In the EtherNet / IP object model, some objects have specific usage scenarios and meanings fixed as protocol standards. The object model usage rules of this invention only apply to objects that are open for use by the protocol. This makes application development under the present invention more convenient and faster, its application is more extensive, and its application in EtherNet / IP communication networks more secure. This ensures compliance with the object model specifications of the EtherNet / IP protocol while avoiding potential conflicts between different EtherNet / IP devices in the application of the object model.

[0047] Based on the EtherNet / IP modular information identification method described in the present invention, the present invention can further realize the identification and management of slave stations in subsequent specific embodiments, thereby realizing further functions.

[0048] Example 1:

[0049] Background of the sub-slave upgrade compatibility function and the basic upgrade compatibility function:

[0050] When an EtherNet / IP controller cannot identify a slave sub-slave, it cannot detect any functional design or compatibility issues with the module. Furthermore, users cannot intuitively perceive the differences or functional differences after the sub-slave upgrade. Therefore, in the past, sub-slave upgrades generally required additional solutions or tools to reflect the differences between the old and new sub-slave versions. Compatibility issues were not considered from the user and device operation perspectives.

[0051] In the technical solution provided by the present invention, the product version of the sub-slave station is strictly bound to the XML version, so when the EtherNet / IP controller identifies the sub-slave station, the corresponding version information will also be matched. With this technical foundation, there is a solution to the compatibility problem of sub-slave station upgrades. In the present invention, non-critical iterations of sub-slaves are first considered. At this time, only the software version of the sub-slave station is updated, and the functional differences of the modules themselves are not large. Generally, they are upgrades such as bug fixes and performance improvements. At this time, the version iteration of the sub-slave station is limited to the software version, and the XML file itself does not need to be modified. There is no compatibility problem at this time. When there are large functional changes or iterations in the sub-slave station, and the XML file needs to be modified for adaptation, the product version in the sub-slave station device information can be iterated, and the corresponding iterative XML file can be iterated to keep the product version consistent with the XML version, and the XML is installed in the EtherNet / IP master station host computer. When identifying the sub-slave station, the product version of the sub-slave station is matched with the XML version and the corresponding PDO and SDO and other information, such as Figure 4 As shown, even if sub-slaves have the same model, product code, and other information, they can still be distinguished by version information, thus enabling compatible upgrades for sub-slaves of the same model. If any sub-slaves are unrecognizable, the logical station information in the XML file containing the logical station information is used to sequentially replace the unrecognizable sub-slaves in the slave station, ensuring communication is established using the logical station information. In this embodiment, traversing and matching the rack file information is sufficient to support the upgrade.

[0052] Example 2: Expansion logic of process data volume:

[0053] The EtherNet / IP protocol specification generally specifies a maximum PDO data size of 504 bytes for a CIP I / O connection opened with a Forward Open instruction. However, this is far from sufficient in some special application scenarios. For example, the involvement of special-function slaves such as motion control and serial communication can lead to a surge in CIP I / O process data volume. To address this issue, the EtherNet / IP protocol also specifies a Large Forward Open connection opening command. Using this command, the total CIP I / O data volume can reach 65,535 bytes. With support for this connection command, the data volume expansion issue in the EtherNet / IP link can be resolved.

[0054] Mapping logic of process data volume: In a modular solution, when using Large Forward Open to expand process data, the PDO mapping logic of each sub-slave station is different from the processing measures of the Forward Open instruction. When expanding the process data volume, the basic idea is still to regard the overall process data as a whole. The difference is that the original ForwardOpen instruction treats the fixed maximum data volume of 504Bytes as a whole, while the extended instruction treats the total process data resources actually occupied by the number of logical stations as the fixed maximum number as a whole. In other words, the overall data volume is different under different topologies. At this time, the partitioning of digital process data and analog process data is no longer allocated according to a fixed ratio, but is allocated according to the actual number of resources occupied by the logical stations. Correspondingly, in this embodiment, a complete sub-slave station identification process needs to be completed.

[0055] It should be noted that in the field of industrial Internet, logical stations are a widely used technology. Its core goal is to aggregate scattered industrial equipment, data flows and control logic into a whole. However, in the scenario involved in the present invention, that is, most EtherNet / IP protocol controllers can only reach the slave station itself when identifying, configuring and controlling the EtherNet / IP slave station, and cannot identify the sub-slaves mounted under the slave station, the existing technology cannot configure the logical station normally. The present invention obtains sufficient information for configuring the logical station from the feedback after the failure of the early EDS-XML file mixed package configuration, thereby configuring the XML file with the logical station information. Only in this way can the above-mentioned technical effects be achieved.

[0056] Although the present invention is disclosed as above with preferred embodiments, it is not intended to limit the scope of implementation of the present invention. Any person of ordinary skill in the art can make some improvements without departing from the scope of the invention of the present invention, that is, all equivalent improvements made in accordance with the present invention should be covered by the scope of the present invention. In the description of this specification, the description of the reference terms "one embodiment / method", "some embodiments / methods", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment / method or example are included in at least one embodiment / method or example of the present application. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment / method or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments / methods or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments / methods or examples described in this specification and the features of different embodiments / methods or examples without contradicting each other.

[0057] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of such features. Throughout the description of this application, "plurality" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0058] Those skilled in the art will appreciate that the above embodiments are merely intended to clearly illustrate the present disclosure and are not intended to limit the scope of the present disclosure. Other changes or modifications may be made based on the above disclosure, and such changes or modifications are still within the scope of the present disclosure.

Claims

1. An EtherNet / IP modular information identification method, characterized in that: An EtherNet / IP controller is used, and its specific identification steps are as follows: importing the corresponding EDS-XML file mixed package into the EtherNet / IP master device module through the EtherNet / IP controller; the EDS-XML file mixed package contains at least one EDS file and multiple XML files, and at least one of the XML files contains logical station information; first, determine whether the device information recorded in the EDS file in the EDS-XML file mixed package is consistent with that in one of the XML files; if they are consistent, parse the successfully matched EDS file and XML file; if the parsing of the successfully matched EDS file and XML file is normal, further parse the rack information supported by the sub-slave station in the EtherNet / IP master device module, if the supported racks described in the sub-slave station's XML file are consistent with the slave station rack, parse the XML of all sub-slaves that can match the rack into PHP Data objects, service data object information access path, all sub-slaves of the matching rack are mounted under the corresponding slave path; when the match is unsuccessful, the slave device information is first obtained according to the EDS file, and the logical station information in the XML file with the logical station information is replaced in sequence with the first sub-slave information in the slave that cannot establish communication until the last sub-slave information in the slave that cannot establish communication; the slave device information is matched with the XML file with the logical station information, and communication is performed according to the description of the XML file with the logical station information, and then all sub-slaves under this slave are identified in sequence according to the logical station information. If unmatched sub-slave information is encountered during the logical station identification process, this sub-slave will be skipped and the execution will continue until there is no sub-slave information response; the multiple XML files include different versions of XML files that have been upgraded and XML files with different amounts of information recorded in the same version; an XML file with logical station information is generated based on the latest version of the XML file; when the XML file contains multiple logical station information, the logical station information contains the station number value of the logical station, the number of logical station numbers is consistent with the number of physical station numbers of the device, and the station number value of the logical station is accumulated by the offset of the number of logical stations.

2. The EtherNet / IP modular information identification method according to claim 1, wherein: The EtherNet / IP controller has an input interface. Before executing the identification step, an identification requirement is first submitted to the EtherNet / IP controller through the input interface. The EtherNet / IP controller screens the XML file according to the identification requirement and obtains the output result according to the identification requirement.

3. The EtherNet / IP modular information identification method according to claim 1, wherein: The EDS-XML file mixed package automatically generates a file directory according to the files in the mixed package before packaging.

4. The EtherNet / IP modular information identification method according to claim 3, wherein: The specific steps for the EtherNet / IP master device module to perform file matching are as follows: unpack the EDS-XML file mixed package, extract the EDS file, and perform the import operation; find multiple related XML files from the file directory according to the identification requirements, parse the XML files to extract the extended device information; compare the extended device information with the EDS file; if an anomaly is found, prompt an anomaly, re-execute the EDS file import and replace the XML file; if normal, continue to parse the rack information; traverse and match the rack information; if an anomaly is found, prompt an anomaly, re-execute the EDS file import and replace the XML file; If normal, the slot scan path and EtherNet / IP protocol specification message are generated, and the extended device information path is parsed.

5. The EtherNet / IP modular information identification method according to claim 4, wherein: When the extracted extended device information matches the exception, re-execute the EDS file import and replace the XML file; if the extended device information does not exist or is normal, generate the extended device information access path and EtherNet / IP protocol specification message and start parsing the device parameter information. If the device parameter information does not exist or is normal, generate the device parameter information access path and EtherNet / IP protocol specification message and perform device alarm information parsing; if it is abnormal, prompt the exception, re-execute the EDS file import and replace the XML file; if the device alarm information does not exist or is normal, generate the device alarm information access path and EtherNet / IP protocol specification message and perform process data tag information parsing; if it is abnormal, prompt the exception, re-execute the EDS file import and replace the XML file; if the process data tag information is normal, the parsing is completed, if it does not exist or is abnormal, prompt the exception, re-execute the EDS file import and replace the XML file.

6. The EtherNet / IP modular information identification method according to claim 5, characterized in that: When exceptions occur in all corresponding XML files, the exception information is collected, the XML file with the logical station is parsed, the XML file with the logical station is modified according to the exception information, and the device parameter information access path and EtherNet / IP protocol specification message are generated according to the XML file with the logical station.

7. The EtherNet / IP modular information identification method according to claim 3, wherein: Based on identification requirements, the parsing paths of different types of XML files are different: to obtain slave device information, the slave device XML file needs to be parsed to at least the extended device information access path; to determine whether a sub-slave exists, only the rack device XML file needs to be parsed to the rack information.

8. An electronic device, characterized in that: It includes a processing unit and a storage unit, wherein the processing unit is provided with an EtherNet / IP controller with an input interface, the storage unit records the EtherNet / IP modular information identification method according to any one of claims 1 to 7, and the EtherNet / IP modular information identification method is executed by the processing unit.

Images