Data coupling method based on Ethercat

Abstract

The embodiment of the invention relates to a data coupling method based on Ethercat. The method comprises the following steps: defining a first mapping relation from expansion card type codes to expansion card modules in an XML (Extensible Markup Language) equipment description file; during power-on initialization, the slave station obtains the type codes of the expansion cards at the slot positions and writes the type codes into the sub-indexes of the object dictionary 0xF050 to form a second mapping relation; the master station is powered on to load the slave station XML file, the second mapping relation is read to determine the expansion card module, and master-slave station PDO communication mapping is established; the slave station receives the configuration parameters sent by the SDO communication of the master station, analyzes the configuration parameters, determines the type and slot number of the target expansion card according to the first and second mapping relations, calculates the offset position of the configuration parameters in the SP I bus, and sends the configuration parameters to the target expansion card through a protocol conversion module after data conversion; and the master station obtains input information of the input type expansion card according to the PDO communication mapping table, sends a command to the output type expansion card and obtains state data of the output type expansion card.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data coupling method and system based on Ethercat. Background Technology

[0002] Currently, coupler-type products are widely used in the field of industrial control. Traditional coupler-type products have a limited number of expandable modules, and the master station is not flexible enough in sending configuration parameters to the slave station. Furthermore, expansion cards often cannot effectively transmit their own status to the master station in real time.

[0003] With the diversification of application scenarios and the integration of controllers in the industrial control field, controllers are also developing towards generalization and large-scale, which requires couplers to have stronger expansion capabilities and be able to support more expansion cards. During the power-on initialization process, expansion cards require configuration parameter information from the master station, which requires coupler products to be able to flexibly configure the operating parameters of the expansion cards. During operation, expansion cards may experience various failures due to wear and tear, electromagnetic interference, and improper human operation. Traditional coupler structures are often open-loop control, lacking a data channel for expansion cards to send their status from the slave station to the master station. Summary of the Invention

[0004] The purpose of this application is to provide a data coupling method and system based on Ethercat to address the shortcomings of existing technologies and solve the problems existing in the prior art.

[0005] To achieve the above objectives, this application provides a data coupling method based on Ethercat, the method comprising:

[0006] The XML device description file defines the first mapping relationship between each expansion card type code and the expansion card module;

[0007] During power-on initialization, the slave station obtains the expansion card type code of each slot and writes the expansion card type code of each slot into the sub-index of the object dictionary 0xF050 index in sequence to obtain the second mapping relationship.

[0008] After the master station is powered on, it loads the XML device description file of the slave station, reads the second mapping relationship, and then determines the expansion card module in each slot.

[0009] Establish PDO communication mapping between the master station and the slave station;

[0010] The slave station receives configuration parameters sent by the master station via SDO communication, parses 0xW and 0xUV in the 0x8UVW index sent by the master station, determines the target expansion card type and its slot number; calculates the offset position of the configuration parameters in the SPI bus according to the expansion card type and the length of configuration parameters required by the expansion card module, converts the SDO data into SPI bus data, and sends it to the corresponding target expansion card through the protocol conversion module.

[0011] The master station obtains the input information of the input type expansion card, sends output commands to the output type expansion card, and obtains the status data of the expansion card according to the mapping table in the PDO communication mapping.

[0012] In one possible implementation, defining the first mapping relationship between each expansion card type encoding and expansion card module in the XML device description file specifically includes:

[0013] In the XML device description file, a type code is assigned to each type of expansion card, and a corresponding expansion card module is defined for each type code, thus obtaining the first mapping relationship between each expansion card type code and the expansion card module.

[0014] In one possible implementation, during power-on initialization, the slave station obtains the expansion card type code for each slot and sequentially writes the expansion card type code for each slot into the sub-index of the object dictionary 0xF050 to obtain the second mapping relationship, specifically including:

[0015] During the system power-on initialization process, the protocol conversion module initiates a scan operation on the expansion cards on the backplane bus to obtain the expansion card type codes of each slot on the backplane bus;

[0016] The slave station interacts with the protocol conversion module via the SPI bus to obtain the expansion card type code for each slot;

[0017] Create an object dictionary with the maximum number of sub-indexes for the 0xF050 index. The slave station maps the expansion card type code of each slot to the corresponding sub-index according to the expansion card type code of each slot. The object dictionary has a second mapping relationship from each sub-index to the expansion card type code of each slot.

[0018] In one possible implementation, after the master station powers on, it loads the slave station's XML device description file, reads the second mapping relationship, and determines the expansion card module in each slot, specifically including:

[0019] After the main station is powered on, the XML device description file is preloaded, and the first mapping relationship is built in memory;

[0020] The system sends a read request for the 0xF050 index of the object dictionary to the slave station via SDO communication, and sequentially reads the second mapping relationship in the object dictionary. Combined with the first mapping relationship in the XML device description file, the expansion card for each slot is obtained.

[0021] In one possible implementation, establishing the PDO communication mapping between the master station and the slave station specifically includes:

[0022] A physical device list is generated from within the station based on the expansion card in each slot; the physical device list includes the correspondence between the slot number and the expansion card type in each slot.

[0023] The main station consults the XML device description file to determine the communication definition of each identified expansion card module. The communication definition is a standardized and structured set of descriptions within the XML device description file. The communication definition includes two parts: the communication definition for the PDO channel and the communication definition for the SDO channel. The PDO channel communication definition includes the expansion card type code, name, and the basic mapping index, application object index, and sub-indexes of the application object index for that expansion card module, as well as the data type and data length of the application data corresponding to the sub-indexes. The SDO channel communication definition includes the index of configuration data and its sub-indexes, as well as the name, data type, and data length of the configuration data corresponding to the sub-indexes. The expansion card type includes input type and output type.

[0024] The master station combines all PDOs that need to be transmitted according to the slot number order. For TxPDOs, it puts all TxPDOs of the expansion card modules into the offset corresponding to the Ethercat protocol frame to form uplink data; for RxPDOs, it puts all RxPDOs of the expansion card modules into the offset corresponding to the Ethercat protocol frame to form downlink data.

[0025] When assembling packets from the slave station, an offset position is assigned to each PDO data block in the Ethercat data frame to generate a global PDO mapping table; the global PDO mapping table includes the offset position of the input and status data of each slot in TxPDO, and the offset position of the output of each slot in RxPDO.

[0026] Establish PDO communication based on the PDO mapping table.

[0027] In one possible implementation, the slave station receives configuration parameters sent by the master station via SDO communication, parses the 0xW and 0xUV in the 0x8UVW index sent by the master station, determines the target expansion card type and its slot number; calculates the offset position of the configuration parameters in the SPI bus according to the expansion card type and the required configuration parameter length of the expansion card module, converts the SDO data into SPI bus data, and sends it to the corresponding target expansion card through the protocol conversion module. Specifically, this includes:

[0028] The master station reads the data corresponding to the sub-index of the 0xF050 index in the slave station object dictionary, determines the expansion card type corresponding to different slots, and determines the expansion card type code of different expansion cards;

[0029] The main station queries the XML device description file to determine the configuration parameter index of the target expansion card, where the configuration parameter index is 0x8UVW;

[0030] The main station obtains the UVW field of 0x8UVW based on the first and second mapping relationships, and obtains the target index of the target expansion card; the UV field is obtained by subtracting 1 from the slot number and converting it to hexadecimal.

[0031] The master station performs write operations on the object dictionary of the slave station through non-periodic SDO communication. The content of the write operation includes the data corresponding to the sub-index of the target index, i.e., configuration parameters.

[0032] The slave station receives the write operation, parses the target index, and determines the target expansion card corresponding to the target index;

[0033] Calculate the offset position of each sub-index data in the SPI data frame; fill the configuration parameter values ​​into the communication data area of ​​the SPI bus according to the offset position to obtain SPI messages with different configuration parameters grouped according to the corresponding offset positions;

[0034] The slave station sends configuration parameters to the protocol conversion module via the SPI bus; the protocol conversion module sends the configuration parameters to the backplane bus, so that the target expansion card reads the configuration parameters from a specific address range of the backplane bus, and configures the operating parameters of the target expansion card according to the configuration parameters.

[0035] In one possible implementation, calculating the offset position of each sub-index data in the SPI data frame specifically includes:

[0036] The slave station receives write operations, the content of which includes the data corresponding to the sub-index of the target index, i.e., the issued configuration parameter values;

[0037] The slave station parses the target index in the write operation to obtain the slot number of the target expansion card; the target index ranges from 0x8000 to 0x8FFF; where W is used as a label for six expansion card types, W=1 represents type A card, W=2 represents type B card, W=3 represents type C card, W=4 represents type D card, W=5 represents type E card, and W=6 represents type F card; the configuration parameter lengths are 32 bits, 16 bits, 64 bits, 64 bits, 32 bits, and 64 bits respectively; the slave station's XML device description file defines the indices of the six types of expansion cards as 0x8001, 0x8002, 0x8003, 0x8004, 0x8005, and 0x8006 respectively;

[0038] When the E-type card is used as the target expansion card and the slot number of the target expansion card is slot 9, 0xUV = 0x09. The configuration parameter value is 5 + 8 * (0xUV) at the starting offset position of the SPI bus, where 5 represents the packet header of the SPI protocol and 8 represents the data area length of each expansion card.

[0039] When the configuration parameter value has 4 sub-indices, the offset positions of the configuration parameter value represented by the 4 sub-indices on the SPI bus are as follows: Sub Index1: 5+8*(0xUV), Sub Index2: 5+8*(0xUV)+1, Sub Index3: 5+8*(0xUV)+2 and Sub Index4: 5+8*(0xUV)+3.

[0040] Determine the offset position of different configuration parameters in the SPI bus.

[0041] In one possible implementation, the master station obtaining the input information of the input type expansion card according to the mapping table in the PDO communication mapping specifically includes:

[0042] Perform periodic PDO communication;

[0043] The master station obtains the slot number of the expansion card through the slave station and the protocol conversion module, and determines the type of expansion card corresponding to the slot number;

[0044] The main station calculates the communication index based on the default PDO mapping predefined in the XML device description file and the slot number of the expansion card; the XML device description file defines a third mapping relationship for input type expansion cards and a fourth mapping relationship for output type expansion cards.

[0045] The third mapping relationship is the mapping relationship between Tt, Y, and Z. Tt is the data type set of the expansion card TxPDO, where Tt = {Tt1, Tt2, Tt3, Tt4, Tt5}, Tt1, Tt2, Tt3, and Tt4 represent four different data types, and Tt5 can be one of Tt1, Tt2, Tt3, and Tt4, or another type. Y is the TxPDO basic mapping index defined in the XML device description file, Y = {Y1, Y2, Y3, Y4, Y5}, where Y1, Y2, Y3, and Y4 take different values ​​and are within the range of 0x1A00 to 0x1A. Y5 is the maximum value in set Y, ranging from 0x1A00 to 0x1A0F; Z is the set of application object dictionary indices, with elements ranging from 0x6000 to 0x6FFF, corresponding to four data types. The basic application object index is defined in the XML device description file as Z = {Z1, Z2, Z3, Z4, Z5}, where Z1, Z2, Z3, and Z4 take different values ​​and are between 0x6000 and 0x600F. Z5 is the maximum value in set Z, ranging from 0x6000 to 0x600F. The least significant bit of Y5 is the same as the least significant bit of Z5.

[0046] The fourth type of mapping relationship is the mapping relationship of Tr, P, and Q. Tr describes the data type set Tr of all expansion card RxPDOs, Tr = {Tr1, Tr2, Tr3}. Its mapping object dictionary index set is P, P = {P1, P2, P3}. The value range of the elements in P is between 0x1600 and 0x17FF, and the values ​​of P1, P2, and P3 are between 0x1600 and 0x160F. The application object dictionary index is set Q, Q = {Q1, Q2, Q3}, corresponding to three data types. Q1, Q2, and Q3 take different values. The value range of the elements in set Q is between 0x7000 and 0x7FFF, and the values ​​of Q1, Q2, and Q3 are between 0x7000 and 0x700F. The least significant bit of P1 is the same as the least significant bit of Q1; the least significant bit of P2 is the same as the least significant bit of Q2; and the least significant bit of P3 is the same as the least significant bit of Q3.

[0047] In one possible implementation, the interaction between the main station and the input type expansion card specifically includes:

[0048] When the target expansion card is an input type expansion card, the target expansion card will refresh the collected input data and status data to the data corresponding to the sub-index of its application object dictionary index set Z;

[0049] The protocol conversion module sends the input data and status data collected by the target expansion card to the slave station via the SPI bus;

[0050] The slave station maps and updates the received input data and status data to the application data corresponding to the sub-index in the application object dictionary index set Z;

[0051] The slave station places the expansion card data into the Ethercat protocol according to the offset position of different expansion cards;

[0052] The master station receives data that the slave station puts into the Ethercat protocol.

[0053] In one possible implementation, the interaction between the main station and the output type expansion card specifically includes:

[0054] When the target expansion card is an output type expansion card, the master station calculates the data offset of the expansion card corresponding to the corresponding slot and writes the output data of the expansion card into the offset address of the Ethercat downlink frame corresponding to the expansion card.

[0055] The slave station receives downlink frames and extracts the data corresponding to the output command from the offset address.

[0056] Based on the first and second mapping relationships, the expansion card type and slot number corresponding to the output command are determined. SPI protocol data packets are generated according to the expansion card type and slot number. The data corresponding to the output command is sent to the protocol conversion module via the SPI bus. The protocol conversion module writes the data to the area of ​​the slot number corresponding to the target expansion card on the backplane bus, so that the target expansion card corresponding to the slot number reads the data corresponding to the output command from the backplane bus and drives its output channel.

[0057] The Ethercat-based data coupling method of this application involves the master station accessing the data at index 0xF050 of the slave station's object dictionary via a read operation. Based on the mapping relationships F and G, it dynamically obtains the coupler expansion card information. On this basis, the coupler slave station can centrally couple configuration parameters from the master station and distribute them to each expansion card. During the periodic data transmission process, the coupler slave station acts as a data relay coupling hub, establishing a data channel for data interaction between the master station and the expansion cards. It provides the Ethercat application data transmission protocol and the Ethercat-to-SPI protocol conversion protocol, establishing a one-to-one mapping relationship between master station data and each expansion card. Furthermore, the number of expansion cards can be expanded to 32, including input type cards, output type cards, and cards with communication protocol types, featuring a large number of coupled expansion cards, large data volume, and rich expansion card types. Attached Figure Description

[0058] Figure 1 Communication topology diagram of the Ethercat-based data coupling method provided in the embodiments of this application;

[0059] Figure 2 This is a schematic diagram of the data coupling method based on Ethercat provided in an embodiment of this application;

[0060] Figure 3 This is a schematic diagram of the first mapping relationship;

[0061] Figure 4 for Figure 2 Flowchart for step 220;

[0062] Figure 5 for Figure 2 Flowchart for step 230;

[0063] Figure 6 for Figure 2 Flowchart for step 240;

[0064] Figure 7 for Figure 2 Flowchart for step 250;

[0065] Figure 8 for Figure 7 Flowchart for step 2506;

[0066] Figure 9 for Figure 2 Flowchart for step 260;

[0067] Figure 10 This is a schematic diagram of the third mapping relationship;

[0068] Figure 11 This is a schematic diagram of the fourth mapping relationship. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0070] The technical solution of this application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0071] Figure 1 The topology diagram of the master station, coupler, and expansion card in the Ethercat-based data coupling method provided in the embodiments of this application is as follows: Figure 1As shown, in this application, the slave module of the coupler communicates with the upstream master station using the Ethercat protocol. At the same time, the slave module can communicate with the protocol conversion module in the coupler through the SPI bus. The protocol conversion module can be extended to a backplane bus, on which an expansion card is connected. Thus, the master station and the expansion card are connected through the coupler as a communication forwarding hub, which opens up the data channel between the upstream master station and the downstream expansion card, realizing data interaction between the master station and the expansion card.

[0072] The coupler in this application uses a linear topology to connect to the expansion cards. The expansion cards are mounted on the back end of the coupler, and all information from the expansion cards is ultimately centralized in the coupler, which then packages it into Ethercat protocol format for communication with the master station. The coupler can mount a maximum of 32 expansion cards, with 11 different card types. Due to varying application scenarios, different types of expansion cards are used, and the number of cards mounted also differs. Therefore, the expansion cards exhibit different configurations for different field applications. The coupler in this application can identify different expansion card configurations through a scanning function, thus obtaining the type of expansion card in each slot. When the master station sends a request, the expansion card configuration is sent to the master station, enabling the master station to scan and retrieve expansion card information via the coupler.

[0073] The expansion card information here will primarily use the expansion card type from the expansion card information later. The expansion card type has a corresponding expansion card type code.

[0074] Figure 2 The data coupling method based on Ethercat provided in the embodiments of this application, such as Figure 2 As shown, this application includes the following steps:

[0075] Step 210: In the XML device description file, define the first mapping relationship between each expansion card type encoding and the expansion card module.

[0076] In the XML device description file, a type code is assigned to each type of expansion card, and a corresponding expansion card module is defined for each type code, thus obtaining the first mapping relationship between each expansion card type code and the expansion card module. The expansion card module is a Module.

[0077] In the XML device description file, in addition to including the expansion card type codes, such as the above 11 types of expansion cards, including analog input cards, analog output cards, digital input cards, digital output cards, etc., it also includes the expansion card names, the initial configuration parameters of the expansion card modules in the corresponding slots, such as configuration parameters like filtering parameters, the first mapping relationship, the static third mapping relationship, and the static fourth mapping relationship. The static third mapping relationship and the static fourth mapping relationship will be specifically described later. This static mapping relationship is predefined in the design or manufacturing stage and provides a framework for the subsequent dynamic mapping relationship.

[0078] The expansion card modules in the slots, each expansion card module represents an expansion card type, and each expansion card type corresponds to a type code. There are a total of 11 types of expansion cards in this application, corresponding to 11 expansion card modules. Define the set of expansion card modules as M, and the set of all 11 types of expansion card modules is represented as:

[0079] M = {M1, M2, M3, M4, M5, M6, M7, M8, M9, M10, M11};

[0080] Assume that the set of expansion card type codes is defined as C, and the set of codes for all 11 types is represented as:

[0081] C = {C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11};

[0082] Among them, the elements in set C and the elements in set M have a one-to-one mapping relationship. The mapping relationship diagram is as Figure 3 shown. The above mapping relationship can be expressed as: there exists a mapping relationship F that satisfies C → M. This mapping relationship is the first mapping relationship.

[0083] Step 220, during power-on initialization, the slave station obtains the expansion card type codes of each slot, and writes the expansion card type codes of each slot into each sub-index in the object dictionary index 0xF050 in sequence to obtain the second mapping relationship.

[0084] Specifically, the number of expansion cards mounted on the coupler is represented by the variable N, where 1 << N << 32. The overall mapping relationship is shown in Table 1:

[0085] Index 0xF050 Expansion card type of the slot XML Subindex 1 Expansion card type code Ci for slot 1 Mi type Mould Subindex 1 Expansion card type code Ci for slot 1 Mj type Moudle …… …… …… Sub-index N Expansion card type code Ck for slot N Mk type Mould

[0086] Table 1

[0087] Among them, Ci, Cj, and Ck all belong to the elements in set C, and Mi, Mj, and Mk all belong to the elements in set M.

[0088] Assuming we remove sub-index 0, which represents the number of sub-indexes, from the 0xF050 index, and represent the remaining sub-indexes as a set X, and given that there are N expansion cards in a certain configuration, then X can be represented as:

[0089] X = {1,2,3…N};

[0090] The above mapping relationship can be expressed as: there exists a mapping relationship G that satisfies X→C. This mapping relationship can be defined as the second mapping relationship.

[0091] In one optional implementation, the specific process of step 220 is described in [reference needed]. Figure 4 ,like Figure 4 As shown, it includes the following steps:

[0092] Step 2201: During the system power-on initialization process, the protocol conversion module initiates a scan operation on the expansion cards on the backplane bus to obtain the expansion card type code of each slot on the backplane bus.

[0093] Step 2202: The slave station interacts with the protocol conversion module via the SPI bus to obtain the expansion card type code for each slot;

[0094] Step 2203: Create an object dictionary for the maximum number of sub-indexes of index 0xF050. The slave station maps the expansion card type code of each slot to the corresponding sub-index according to the expansion card type code of each slot. In the object dictionary, there is a second mapping relationship from each sub-index to the expansion card type code of each slot.

[0095] Excluding sub-index 0, there can be 32 other sub-indexes, corresponding to a maximum of 32 slots.

[0096] Step 230: After the master station is powered on, it loads the XML device description file of the slave station, reads the second mapping relationship, and determines the expansion card module on each slot.

[0097] Specifically, such as Figure 5 As shown, step 230 includes the following steps:

[0098] Step 2301: After the main station is powered on, the XML device description file is preloaded, and the first mapping relationship is constructed in memory;

[0099] Specifically, before the master station scans, it has preloaded the XML device description file of the coupler's slave station. This XML device description file includes the first mapping relationship and the detailed communication specifications of each expansion card module.

[0100] Step 2302: Send a read request for the 0xF050 index of the object dictionary to the slave station via SDO communication, and read the second mapping relationship in the object dictionary in sequence. Combined with the first mapping relationship in the XML device description file, the expansion card type of each slot is obtained.

[0101] Specifically, after the master station powers on, it uses the Ethercat SDO read command to sequentially read all sub-indices under index 0xF050 in the slave station object dictionary. After obtaining the second mapping relationship, it obtains the data corresponding to each sub-index, i.e., the type code. This type code refers to the expansion card type code. Combined with the first mapping relationship, it determines the expansion card module corresponding to the expansion card type code.

[0102] Step 240: Establish PDO communication mapping between the slave station and the master station.

[0103] like Figure 6 As shown, step 240 includes the following:

[0104] Step 2401: Generate a physical device list from within the station based on the expansion cards in each slot; the physical device list includes the correspondence between the slot number and the expansion card type in each slot;

[0105] Specifically, the M obtained above can be used to determine, for example, that slot 1 is occupied by an M5 module, slot 2 by an M2 module, and slot 3 by an M8 module.

[0106] Step 2402: The main station consults the XML device description file to determine the communication definition of each identified expansion card module;

[0107] The communication definition includes two parts: the communication definition of the PDO channel and the communication definition of the SDO channel. The communication definition of the PDO channel includes the expansion card type code, name, basic mapping index, application object index, sub-index of the application object index, and data type and data length of the application data corresponding to the sub-index of the application object index. The communication definition of the SDO channel includes the index of configuration data and its sub-index, as well as the name, data type, and data length of the configuration data corresponding to the sub-index.

[0108] Step 2403: The slave station combines all the PDOs that need to be transmitted according to the slot number order. For TxPDO, all TxPDOs of the expansion card modules are put into the offset corresponding to the Ethercat protocol frame to form uplink data; for RxPDO, all RxPDOs of the expansion card modules are put into the offset corresponding to the Ethercat protocol frame to form downlink data.

[0109] Specifically, the slave station combines all PDOs that need to be transmitted according to the slot number order. For TxPDOs, it combines the TxPDOs of all expansion card modules in sequence to form uplink data. For RxPDOs, it combines the RxPDOs of all expansion card modules in sequence to form downlink data.

[0110] Step 2404: When the slave station is assembling packets, an offset position is assigned to each PDO data block in the Ethercat data frame, and a global PDO mapping table is generated.

[0111] The global PDO mapping table includes the offset position of the input and status data of each slot in TxPDO, and the offset position of the output of each slot in RxPDO.

[0112] Specifically, the data is first assembled at the station. The assembly process involves placing different PDO data at different offset positions within the data packet. For example, for uplink data, the input data for slot 1 (M1) has an offset of 0, a length of 4 bytes, and status data of 2 bytes, for a total length of 6 bytes. For the expansion card in slot 2 (M2), which is an output-type expansion card but needs to upload status data, a TxPDO channel is required, with an offset of 6 (4+2) and a length of 2 bytes. The input data for slot 3 (M5) has an offset of 8 (6+2), a length of 8 bytes, and status data of 2 bytes, for a total length of 10 bytes. For RxPDO offset calculation: for the output data of slot 2 (M2), the offset is 0, and the length is 2 bytes.

[0113] Finally, a global PDO mapping table is generated. In the global PDO mapping table, the analog input values ​​of the slot 1 expansion card are defined in bytes 0-3 of TxPDO, the status data of the slot 1 expansion card is defined in bytes 4-5 of TxPDO, and the digital output commands of the slot 2 expansion card are defined in byte 0 of RxPDO.

[0114] After the packet is assembled, the assembled data packet is transmitted to the Ethercat protocol stack, which then sends out the message.

[0115] The slave station obtains the actual expansion card configuration by reading the card type under index 0xF050 and by using the first and second mappings, and obtains the offset position and data length corresponding to each expansion card.

[0116] Step 2405: Establish PDO communication based on the PDO mapping table.

[0117] Thus, PDO communication between the slave station and the master station can be established through step 240.

[0118] Step 250: The slave station receives the configuration parameters sent by the master station via SDO communication, parses the 0xW and 0xUV in the 0x8UVW index sent by the master station, determines the target expansion card type and its slot number; calculates the offset position of the configuration parameters in the SPI bus according to the expansion card type and the required configuration parameter length of the expansion card module, converts the SDO data into SPI bus data, and sends it to the corresponding target expansion card through the protocol conversion module.

[0119] Specifically, the master station sends configuration parameters to configure the expansion card module. This transmission of configuration parameters occurs before the formal periodic data exchange. After receiving the SDO configuration parameter data, the slave station sends it to the protocol conversion module via the SPI bus. The protocol conversion module converts the data into backplane bus data and then sends it to the corresponding target expansion card via the backplane bus.

[0120] like Figure 7 As shown, step 250 includes the following steps:

[0121] Step 2501: The master station reads the data corresponding to the sub-index of the 0xF050 index in the slave station object dictionary, determines the expansion card type corresponding to different slots, and determines the expansion card type code of different expansion cards.

[0122] Specifically, the system has completed power-on scanning and PDO communication mapping establishment. The master station is ready to send specific configuration parameters to a specific expansion card, which can be called the target expansion card. Specific configuration parameters include the number of filters, etc.

[0123] Step 2502: The main station queries the XML device description file to determine the configuration parameter index of the target expansion card, wherein the configuration parameter index is 0x8UVW;

[0124] Specifically, the main station determines the value of W based on the target expansion card model and the value of UV based on the slot where the target expansion card is located. For example, in slot 10, 0xUV = 0x09, thus combining to obtain the target SDO index, which is the configuration parameter index 0x8UVW. This application sets the configuration parameter index to the format 0x8UVW, which is a 16-bit address that can be decomposed into 0x8. A fixed prefix identifies this as a configuration parameter index area, U is a hexadecimal number representing the high four bits of the slot number, V is a hexadecimal number representing the low four bits of the slot number, and W is a hexadecimal number representing the expansion card type.

[0125] Step 2503: The main station obtains the UVW field of 0x8UVW based on the first mapping relationship and the second mapping relationship, and obtains the target index of the configured target expansion card;

[0126] The UV field is obtained by subtracting 1 from the slot number and converting it to hexadecimal.

[0127] Specifically, for example, when configuring an E-type card in slot 10, entering the UV field of 0x8UVW will result in a target index of 0x8095.

[0128] Step 2504: The master station performs a write operation on the object dictionary of the slave station through non-periodic SDO communication. The content of the write operation includes the data corresponding to the sub-index of the target index, i.e., the configuration parameters.

[0129] The target index includes the index and its sub-indexes, and the mapping data for each sub-index is the configuration parameter.

[0130] Specifically, the master station sends the configuration parameter data to the slave station via 0x8UVW through an SDO write operation.

[0131] Step 2505: The slave station receives the write operation, parses the target index, and determines the target expansion card corresponding to the target index;

[0132] Step 2506: Calculate the offset position of each sub-index data in the SPI data frame; fill the configuration parameter values ​​into the communication data area of ​​the SPI bus according to the offset position to obtain SPI messages with different configuration parameters grouped according to the corresponding offset positions;

[0133] Among them, see Figure 8 Step 2506 includes the following steps:

[0134] Step 810: The slave station receives a write operation, the content of which includes the data corresponding to the sub-index of the target index, i.e., the issued configuration parameter value;

[0135] The target index includes the index itself and its sub-indexes, and the mapping data for each sub-index is the configuration parameter value.

[0136] Step 820: The slave station parses the target index in the write operation to obtain the slot number of the target expansion card;

[0137] The target index ranges from 0x8000 to 0x8FFF; W represents six types of expansion cards: W=1 for type A, W=2 for type B, W=3 for type C, W=4 for type D, W=5 for type E, and W=6 for type F; the configuration parameter lengths are 32 bits, 16 bits, 64 bits, 64 bits, 32 bits, and 64 bits respectively; the base indices for the six types of expansion cards defined in the slave station XML device description file are 0x8001, 0x8002, 0x8003, 0x8004, 0x8005, and 0x8006 respectively.

[0138] Specifically, after receiving an SDO write operation from the slave station, it parses 0x8UVW. The target card type is obtained from the W field. For example, if it receives 0x8095, it knows that it is an E-type card. The target slot number is obtained from the UV field. For example, if UV = 0x09, the slot is 10.

[0139] Step 830: When the E-type card is used as the target expansion card and the slot number of the target expansion card is slot 10, 0xUV = 0x09. The configuration parameter value is 5 + 8 * (0xUV) at the starting offset position of the SPI bus, where 5 represents the packet header of the SPI protocol and 8 represents the data area length of each expansion card.

[0140] Step 840: When the configuration parameter value has 4 sub-indices, the offset positions of the configuration parameter values ​​corresponding to the 4 sub-indices on the SPI bus are as follows: Sub Index1: 5+8*(0xUV), Sub Index2: 5+8*(0xUV)+1, Sub Index3: 5+8*(0xUV)+2 and Sub Index4: 5+8*(0xUV)+3;

[0141] Step 850: Determine the offset position of different configuration parameters in the SPI bus.

[0142] Specifically, the slave station fills the data corresponding to sub-indexes 1-K in the SDO data packet into the SPI data frame according to the offset positions calculated above, and sends it to the protocol conversion module via the SPI protocol. The protocol conversion module broadcasts the data frame through the backplane bus, and all expansion cards can see it, but only the target expansion card with the matching slot number will respond.

[0143] The following is a detailed description of steps 810-850 above:

[0144] The configuration parameters between the master station and the coupler slave station use the SDO communication method, with the SDO data object dictionary indexing from 0x8000 to 0x8FFF. When the master station sends configuration parameters to the expansion card via the slave station, the slave station, acting as a data relay coupling hub, needs to parse the master station's configuration parameters and map each parameter to the specific expansion card type and slot. The challenges here are: First, expansion card types can vary depending on the needs, and the slave station needs to obtain the corresponding card type when parsing the configuration parameters. Different types of expansion cards have different configuration parameter lengths and require different numbers of sub-indexes; the expansion card needs to parse all sub-index information to obtain the complete configuration parameters. Second, it needs to obtain the expansion card slot information corresponding to the configuration parameter to calculate the parameter's offset position in the SPI bus protocol.

[0145] To address the aforementioned challenges, this application designs reasonable indexes for different expansion cards. The slave station obtains the type and slot number of the expansion card represented by the index through the index transmitted from the master station. Specifically:

[0146] This application specifies that 6 out of 11 types of expansion cards require configuration parameters, namely Type A, Type B, Type C, Type D, Type E, and Type F. The configuration parameter lengths are 32 bits, 16 bits, 64 bits, 64 bits, 32 bits, and 64 bits, respectively. For ease of transmission, the configuration parameters are transmitted in USINT type, i.e., 8-bit unsigned integer data. Therefore, the configuration parameter lengths can be represented as 4, 2, 8, 8, 4, and 8, respectively, and can be described by 4, 2, 8, 8, 4, and 8 sub-indices.

[0147] The values ​​in the index range of 0x8000-0x8FFF are represented by variable letters, i.e., 0x8UVW. In hexadecimal representation, the value ranges of U, V, and W are:

[0148] 0< <U<<0x0f,0<<V<<0x0f,0<<W<<0x0f

[0149] This application uses W as the label for six expansion card types: W=1 for type A, W=2 for type B, W=3 for type C, W=4 for type D, W=5 for type E, and W=6 for type F. Therefore, the indices for these six expansion card types are defined as 0x8001, 0x8002, 0x8003, 0x8004, 0x8005, and 0x8006 in the web application's XML file, with an increment of 16. In this application, slot numbers start from 1, while 0xUV starts from 0. Therefore, 0xUV+1 can be used as the label for the expansion card slot number to calculate the offset of this configuration parameter on the SPI bus.

[0150] Taking the E-type card as an example, if the scan result is in slot 10, 0xUV = 0x09, then its configuration parameters' initial offset position on the SPI bus is 5 + 8 * (0xUV), where 5 represents the SPI protocol packet header and 8 represents that the data area length of each expansion card is 8 bytes. If we consider that the E-type card has 4 sub-indices, then the offsets of the configuration parameter data corresponding to the four sub-indices on the SPI bus are as follows:

[0151] Sub Index1: 5 + 8 * (0xUV);

[0152] Sub Index2: 5 + 8 * (0xUV) + 1

[0153] Sub Index3: 5 + 8 * (0xUV) + 2

[0154] Sub Index4: 5 + 8 * (0xUV) + 3

[0155] This application enables the slave station to receive configuration parameters from the master station by setting a reasonable index for SDO data. It can then parse the corresponding expansion card type and slot information, allowing the data to be placed correctly on the SPI bus, thus achieving the conversion of Ethercat SDO data to SPI data. The protocol conversion module then forwards the SPI data to the backplane bus, allowing the expansion card to parse the required configuration parameters.

[0156] Step 2507: The slave station sends the configuration parameters to the protocol conversion module via the SPI bus; the protocol conversion module sends the configuration parameters to the backplane bus so that the target expansion card reads the configuration parameters from a specific address range of the backplane bus and configures the operating parameters of the target expansion card according to the configuration parameters.

[0157] Step 260: The master station obtains the input information of the input type expansion card according to the mapping table in the PDO communication mapping, sends the output command to the output type expansion card, and obtains the status data of the expansion card.

[0158] Specifically, such as Figure 9 As shown, step 260 includes the following steps:

[0159] Step 2601: Perform periodic PDO communication;

[0160] Step 2602: The master station obtains the slot number of the expansion card through the slave station and the protocol conversion module, and determines the type of expansion card corresponding to the slot number;

[0161] Step 2603: The master station calculates the communication index based on the default PDO mapping predefined in the XML device description file of the expansion card and the slot number of the expansion card.

[0162] The XML device description file defines a third mapping relationship for input type extension cards and a fourth mapping relationship for output type extension cards.

[0163] Specifically, the third mapping relationship is the mapping relationship between Tt, Y, and Z. Tt is the data type set of the expansion card TxPDO, where Tt = {Tt1, Tt2, Tt3, Tt4, Tt5}, Tt1, Tt2, Tt3, and Tt4 represent four different data types, and Tt5 can be one of Tt1, Tt2, Tt3, and Tt4, or another type. Y is the TxPDO basic mapping index defined in the XML device description file, Y = {Y1, Y2, Y3, Y4, Y5}, where Y1, Y2, Y3, and Y4 take different values ​​and are in the range of 0x1A00 to 0x Between 1A0F, Y5 is the maximum value in set Y, ranging from 0x1A00 to 0x1A0F; Z is the application object dictionary index set, with elements ranging from 0x6000 to 0x6FFF, corresponding to four data types. The basic application object index is defined in the XML device description file as Z = {Z1, Z2, Z3, Z4, Z5}, where Z1, Z2, Z3, and Z4 take different values ​​and are between 0x6000 and 0x600F. Z5 is the maximum value in set Z, ranging from 0x6000 to 0x600F. The least significant bit of Y5 is the same as the least significant bit of Z5.

[0164] For details, see the third mapping relationship. Figure 10 For the fourth mapping relationship, see [link / reference]. Figure 11 .

[0165] The fourth type of mapping relationship is the mapping relationship of Tr, P, and Q. Tr describes the data type set Tr of all expansion cards RxPDO, Tr = {Tr1, Tr2, Tr3}. Its mapping object dictionary index set is P, P = {P1, P2, P3}. The value range of the elements in P is between 0x1600 and 0x17FF, and the values ​​of P1, P2, and P3 are between 0x1600 and 0x160F. The application object dictionary index is set Q, Q = {Q1, Q2, Q3}, corresponding to three data types. Q1, Q2, and Q3 take different values. The value range of the elements in set Q is between 0x7000 and 0x7FFF, and the values ​​of Q1, Q2, and Q3 are between 0x7000 and 0x700F. The least significant bit of P1 is the same as the least significant bit of Q1; the least significant bit of P2 is the same as the least significant bit of Q2; and the least significant bit of P3 is the same as the least significant bit of Q3.

[0166] Based on the third and fourth mapping relationships, the interaction between the main station and the input type expansion card specifically includes:

[0167] When the target expansion card is an input type expansion card, the target expansion card will refresh the collected input data and status data to the data corresponding to the sub-index of its application object dictionary index set Z;

[0168] The protocol conversion module sends the input and status data collected by the target expansion card to the slave station via the SPI bus.

[0169] The slave station maps and updates the received input and status data to the application data corresponding to the sub-index in the application object dictionary index set Z.

[0170] The slave station places the expansion card data into the Ethercat protocol according to the offset position of different expansion cards.

[0171] The master station receives data that the slave station puts into the Ethercat protocol.

[0172] Based on the third and fourth mapping relationships, the interaction between the main station and the output type expansion card specifically includes:

[0173] When the target expansion card is an output type expansion card, the master station calculates the data offset of the expansion card corresponding to the corresponding slot and writes the output data of the expansion card into the offset address of the Ethercat downlink frame corresponding to the expansion card.

[0174] The slave station receives downlink frames and extracts the data corresponding to the output command from the offset address.

[0175] Based on the first and second mapping relationships, the expansion card type and slot number corresponding to the output command are determined. SPI protocol data packets are generated according to the expansion card type and slot number. The data corresponding to the output command is sent to the protocol conversion module via the SPI bus. The protocol conversion module writes the data to the area of ​​the slot number corresponding to the target expansion card on the backplane bus, so that the target expansion card corresponding to the slot number reads the data corresponding to the output command from the backplane bus and drives its output channel.

[0176] The process is described in detail below:

[0177] The implementation scheme for functions such as the master station sending output commands to output-type expansion cards in real time via couplers, the master station acquiring input information from input-type expansion cards in real time via couplers, and the master station acquiring status data of expansion cards in real time is as follows:

[0178] Because this function requires real-time interactive transmission of Ethercat protocol data, the PDO function of the Ethercat protocol architecture is used. Different slots can randomly accommodate different types of expansion cards, each corresponding to a specific PDO. For example, output-type expansion cards need to receive output commands forwarded from the master station by the slave station; therefore, their corresponding PDO type is RxPDO. Input-type expansion cards need to forward their collected data to the master station via the slave station; therefore, their corresponding PDO type is TxPDO. Since the expansion card's status data needs to be forwarded to the master station via the slave station, it also corresponds to a TxPDO type PDO.

[0179] Combining the aforementioned expansion card information scanning function, when the master station retrieves expansion card information from the coupler via the 0xF050 index, it obtains the connection configuration of different expansion cards, thus achieving dynamic expansion card scanning. Correspondingly, the TxPDO and RxPDO under each expansion card's corresponding module also have different configurations in the Ethercat protocol messages. The master station scans and obtains the configurations of different expansion card modules mounted on the coupler, thereby dynamically obtaining combinations of different PDOs. Based on this, it establishes the data channel for Ethercat protocol messages used for data transmission between the master and slave stations. This data channel contains information such as the offset position and data type of the data from different expansion card modules within the message.

[0180] Dynamic PDO composition relies on the slave XML to allocate appropriate indexes and sub-indexes to TxPDOs and RxPDOs under different modules based on their data types. Common communication data types in the Ethercat system include BOOL, REAL, STRING, UDINT, USINT, and UINT.

[0181] Based on the TxPDO and RxPDO classifications, the data types used to describe all expansion card TxPDOs can be represented by a set Tt. In this application, Tt contains four data types, denoted as:

[0182] Tt = {Tt1, Tt2, Tt3, Tt4}

[0183] The data types used to describe all expansion card RxPDOs can be represented by the set Tr. In this application, Tr contains three data types, denoted as:

[0184] Tr = {Tr1, Tr2, Tr3}

[0185] Considering that each expansion card in this application needs to transmit status data, a data type Tt5 is added to the set Tt, i.e., T = {Tt1, Tt2, Tt3, Tt4, Tt5}, where Tt5 can be one of the types Tt1, Tt2, Tt3, and Tt4, or other types as needed.

[0186] If data transmission is via TxPDO, the corresponding mapping object dictionary index can be represented as a set Y. The values ​​of elements in set Y range from 0x1A00 to 0x1BFF, corresponding to the four basic data types. The XML device description file defines the TxPDO basic mapping index as Y = {Y1, Y2, Y3, Y4}, where Y1, Y2, Y3, and Y4 take different values ​​and are between 0x1A00 and 0x1A0F. The application object dictionary index is defined as a set Z, where the values ​​of elements in set Z range from 0x6000 to 0x6FFF, corresponding to the four data types. The XML device description file defines the basic application object index as Z = {Z1, Z2, Z3, Z4}, where Z1, Z2, Z3, and Z4 take different values ​​and are between 0x6000 and 0x600F. The least significant bit of Y1 is the same as the least significant bit of Z1, the least significant bit of Y2 is the same as the least significant bit of Z2, the least significant bit of Y3 is the same as the least significant bit of Z3, and the least significant bit of Y4 is the same as the least significant bit of Z4.

[0187] In addition, the process data in this application includes the transmission of expansion card status data. This status data, which is the expansion card's own status data sent to the main station via a coupler, is input type data. When input type cards transmit status data, they can directly use the TxPDO channel, adding a sub-index to the sub-index of the application object index corresponding to the input type data for transmission. When output type cards transmit status data, since the output type data corresponds to the RxPDO channel, each plugged-in output type expansion card module needs to add a TxPDO to its PDO. Therefore, the aforementioned sets Y and Z are expanded, where Y is expanded to Y = {Y1, Y2, Y3, Y4, Y5}, and Z is expanded to Z = {Z1, Z2, Z3, Z4, Z5}. Y5 is the maximum value in set Y, Z5 is the maximum value in set Z, and the value of Y5 is between 0x1A00 and 0x1A0F, while the value of Z5 is between 0x6000 and 0x600F. The least significant bit of Y5 is the same as the least significant bit of Z5.

[0188] The mapping relationship between sets Tt, Y, and Z, such as Figure 10 As shown.

[0189] If data transmission is via RxPDO, the corresponding mapping object dictionary index can be represented as a set P. The values ​​of elements in set P range from 0x1600 to 0x17FF, corresponding to the three basic data types. The XML device description file defines the RxPDO basic mapping index set as P = {P1, P2, P3}, where P1, P2, and P3 take different values ​​and are between 0x1600 and 0x160F. The application object dictionary index is defined as a set Q, where the values ​​of elements in set Q range from 0x7000 to 0x7FFF, corresponding to the three data types. The XML device description file defines the basic application object index set as Q = {Q1, Q2, Q3}, where Q1, Q2, and Q3 take different values ​​and are between 0x7000 and 0x700F. The least significant bit of P1 is the same as the least significant bit of Q1; the least significant bit of P2 is the same as the least significant bit of Q2; and the least significant bit of P3 is the same as the least significant bit of Q3.

[0190] Since the state data does not go through RxPDO, the sets Tr, P, and Q do not need to be expanded. The mapping relationship between sets Tr, P, and Q is as follows: Figure 11 As shown.

[0191] In the XML device description file, the indices in the sets Y, Z, P, and Q are set to increment by 16 based on the slot number. Therefore, as the slot number increases, the indices in the sets Y, Z, P, and Q increase by 16 steps.

[0192] Assuming that each expansion card inserted increases the slot number by one, let's assume the slot number is S, and the expansion card in this slot is of output type. The output data corresponds to the corresponding RxPDO channel, denoted as RxPDO1, with a data type of Tr2, corresponding to the base index P2 of the mapping object and the base index Q2 of the application object. Additionally, the expansion card status data is represented by TxPDO, denoted as TxPDO1, with a fixed data type of Tt5, corresponding to the base index Y5 of the mapping object and the base index Z5 of the application object. Therefore, the module of this expansion card slot corresponds to two PDOs. The mapping object index corresponding to RxPDO1 of this expansion card slot is P2 + (S – 1) * 16, and the application object index is Q2 + (S – 1) * 16; the mapping object index corresponding to TxPDO1 of this expansion card slot is Y5 + (S – 1) * 16, and the application object index is Z5 + (S – 1) * 16.

[0193] Based on the aforementioned mapping relationship and the slot-incrementing mechanism of the PDO index, each expansion card module has its own independent mapping index and application index, which plays a crucial role in the master-slave Ethercat application data protocol format agreement. Using this method, the master and slave stations can complete Ethercat data interaction and parsing, and can rationally divide the Ethercat application data into data channels according to the plugged-in expansion cards, their input / output types, expansion card types, and slots, thus achieving the function of centralized data coupling in the linear structure of the coupler-extension expansion card.

[0194] This cyclical data coupling function includes: the coupler slave station creating an object dictionary of PDO indexes for all expansion cards; scanning and identifying different expansion cards; filling data into the Ethercat process data packet according to the expansion card type and slot; and the master station parsing XML and, combined with the expansion card information scanned by SDO, obtaining information such as the PDO type, data offset position, and data type of each expansion card in the Ethercat data packet. Thus, a slave-based data coupling function is achieved.

[0195] The Ethercat-based data coupling method in this application involves the master station accessing the data at index 0xF050 of the slave station's object dictionary via a read operation. Based on the mapping relationships F and G, it dynamically obtains the coupler expansion card information. On this basis, the coupler slave station can centrally couple configuration parameters from the master station and distribute them to each expansion card. During the periodic data transmission process, the coupler slave station acts as a data relay coupling hub, establishing a data channel for data interaction between the master station and the expansion cards. It also provides the Ethercat application data transmission protocol and the Ethercat-to-SPI protocol conversion protocol, establishing a one-to-one mapping relationship between master station data and each expansion card.

[0196] This application pertains to a data coupling design for multi-functional, multi-data-type, and multi-expansion-card systems. It simultaneously features functions such as scanning expansion cards to obtain their type and slot information, the master station sending configuration parameters to expansion cards via couplers during initialization, the master station sending output commands to output-type expansion cards in real-time via couplers, the master station acquiring input information from input-type expansion cards in real-time via couplers, and the master station acquiring status data from expansion cards in real-time. The transmitted data is categorized by data object type (including SDO and PDO) and by data function type (including scan data, configuration data, periodic process data, and status data). Furthermore, the system can expand to 32 expansion cards, including input-type cards, output-type cards, and cards with communication protocol types, offering advantages such as a large number of coupled expansion cards, large data volume, and diverse expansion card types.

[0197] This application features flexible configurable expansion card parameters. During the power-on initialization phase, the master station sends expansion card configuration parameters via an SDO type index, which are then forwarded to the expansion card by the slave station. The SDO configuration data index is rationally designed and divided using slave station XML. After parsing and processing by the master station, based on the auto-incrementing rules specified in the XML and the expansion card module configuration determined by the scanning function, the issued SDO configuration data type index can carry information such as the expansion card type and slot number. By parsing the configuration data index, the slave station can parse the master station's SDO data, place the configuration data at the corresponding offset position on the SPI bus, and then send it to the expansion card, thus realizing the configuration parameter distribution function.

[0198] This application achieves dynamic combination of PDOs by designing a reasonable communication index, namely the PDO data index, to define the offset, communication format, and data type of Ethercat application data. PDO communication defines the basic mapping object and basic application object indexes based on the expansion card data type. The least significant bit of the hexadecimal index is used to mark the data type. Through an auto-incrementing mechanism based on the slot number, the PDO index increases in increments of 16. The middle eight bits of the hexadecimal index represent the slot number of the expansion card, thus enabling dynamic combination of PDOs for different expansion card modules. This application can accommodate random configurations of 32 slots for 11 types of expansion cards. Based on this mechanism, it completes the data interaction and parsing between the master and slave Ethercat stations, enabling centralized coupling of data from each expansion card via the coupler and interaction with the master station.

[0199] This application supports the uploading of expansion card status data. The coupler slave station designs a reasonable PDO index based on the configured data type and length of different expansion card types. For input type expansion cards, the sub-index of the application object index for periodic process data is expanded to include a status data sub-index. For output type expansion cards, a TXPD0 for transmitting status data is added. The status data is sent by the expansion card, relayed through the coupler, and then sent to the master station, thereby enabling the master station to monitor the expansion card status in real time.

[0200] After the master station loads the slave station's XML device description file, it uses its scanning function to obtain the slot module information of the coupler expansion card. Simultaneously, the user can load the default configuration information from the XML device description file and modify it according to the application requirements of the expansion card. This generates a file carrying the expansion card scanning information and configuration information, which is downloaded to the master station. After the system is powered on again, the master station can send configuration parameters to the expansion card via the coupler. Based on the scan results, the master station matches the scanned modules with the expansion card through the coupler, enabling it to send output commands to output-type expansion cards via the coupler. The coupler can also centrally transmit data from input-type expansion cards to the master station.

[0201] Meanwhile, this application establishes a data transmission channel for the expansion card status data, which can transmit the expansion card status to the main station in real time. The main station logic makes control decisions based on the expansion card status, thereby improving the reliability and stability of the system.

[0202] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0203] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0204] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above description is only a specific embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A data coupling method based on Ethercat, characterized in that, The method includes: The XML device description file defines the first mapping relationship between each expansion card type code and the expansion card module; During power-on initialization, the slave station obtains the expansion card type code of each slot and writes the expansion card type code of each slot into the sub-index of the object dictionary 0xF050 index in sequence to obtain the second mapping relationship. After the master station is powered on, it loads the slave station's XML device description file, reads the second mapping relationship, and determines the expansion card module in each slot; it then establishes the PDO communication mapping between the master station and the slave station. The slave station receives configuration parameters sent by the master station via SDO communication, parses 0xW and 0xUV in the 0x8UVW index sent by the master station, determines the target expansion card type and its slot number; calculates the offset position of the configuration parameters in the SPI bus according to the expansion card type and the length of configuration parameters required by the expansion card module, converts the SDO data into SPI bus data, and sends it to the target expansion card through the protocol conversion module. The master station obtains the input information of the input type expansion card, sends output commands to the output type expansion card, and obtains the status data of the expansion card according to the mapping table in the PDO communication mapping.

2. The method according to claim 1, characterized in that, The definition of the first mapping relationship between each expansion card type code and the expansion card module in the XML device description file specifically includes: In the XML device description file, a type code is assigned to each type of expansion card, and a corresponding expansion card module is defined for each type code, thus obtaining the first mapping relationship between each expansion card type code and the expansion card module.

3. The method according to claim 2, characterized in that, During power-on initialization, the slave station obtains the expansion card type code for each slot and sequentially writes the expansion card type code for each slot into the sub-index of the object dictionary 0xF050, obtaining the second mapping relationship, which specifically includes: During the system power-on initialization process, the protocol conversion module initiates a scan operation on the expansion cards on the backplane bus to obtain the expansion card type codes of each slot on the backplane bus; The slave station interacts with the protocol conversion module via the SPI bus to obtain the expansion card type code for each slot; Create an object dictionary with the maximum number of sub-indexes for the 0xF050 index. The slave station maps the expansion card type code of each slot to the corresponding sub-index according to the expansion card type code of each slot. The object dictionary has a second mapping relationship from each sub-index to the expansion card type code of each slot.

4. The method according to claim 1, characterized in that, After the master station powers on, it loads the slave station's XML device description file, reads the second mapping relationship, and determines the specific expansion card modules in each slot, including: After the main station is powered on, the XML device description file is preloaded, and the first mapping relationship is built in memory; The system sends a read request for the 0xF050 index of the object dictionary to the slave station via SDO communication, and sequentially reads the second mapping relationship in the object dictionary. Combined with the first mapping relationship in the XML device description file, the expansion card type of each slot is obtained.

5. The method according to claim 1, characterized in that, The establishment of the PDO communication mapping between the master station and the slave station specifically includes: A physical device list is generated from within the station based on the expansion card in each slot; the physical device list includes the correspondence between the slot number and the expansion card type in each slot. The main station consults the XML device description file to determine the communication definition of each identified expansion card module. The communication definition is a standardized and structured set of descriptions within the XML device description file. The communication definition includes two parts: the communication definition for the PDO channel and the communication definition for the SDO channel. The PDO channel communication definition includes the expansion card type code, name, and the basic mapping index, application object index, and sub-indexes of the application object index for that expansion card module, as well as the data type and data length of the application data corresponding to the sub-indexes. The SDO channel communication definition includes the index of configuration data and its sub-indexes, as well as the name, data type, and data length of the configuration data corresponding to the sub-indexes. The expansion card type includes input type and output type. The master station combines all PDOs that need to be transmitted according to the slot number order. For TxPDOs, it puts all TxPDOs of the expansion card modules into the offset corresponding to the Ethercat protocol frame to form uplink data; for RxPDOs, it puts all RxPDOs of the expansion card modules into the offset corresponding to the Ethercat protocol frame to form downlink data. When assembling packets from the slave station, an offset position is assigned to each PDO data block in the Ethercat data frame to generate a global PDO mapping table; the global PDO mapping table includes the offset position of the input and status data of each slot in TxPDO, and the offset position of the output of each slot in RxPDO. Establish PDO communication based on the PDO mapping table.

6. The method according to claim 1, characterized in that, The slave station receives configuration parameters sent by the master station via SDO communication, parses the 0xW and 0xUV in the 0x8UVW index sent by the master station, determines the target expansion card type and its slot number; calculates the offset position of the configuration parameters in the SPI bus according to the expansion card type and the required configuration parameter length of the expansion card module, converts the SDO data into SPI bus data, and sends it to the corresponding target expansion card through the protocol conversion module. Specifically, this includes: The master station reads the data corresponding to the sub-index of the 0xF050 index in the slave station object dictionary, determines the expansion card type corresponding to different slots, and determines the expansion card type code of different expansion cards; The main station queries the XML device description file to determine the configuration parameter index of the target expansion card, where the configuration parameter index is 0x8UVW; The main station obtains the UVW field of 0x8UVW based on the first and second mapping relationships, and obtains the target index of the target expansion card; the UV field is obtained by subtracting 1 from the slot number and converting it to hexadecimal. The master station performs write operations on the object dictionary of the slave station through non-periodic SDO communication. The content of the write operation includes the data corresponding to the sub-index of the target index, i.e., configuration parameters. The slave station receives the write operation, parses the target index, and determines the target expansion card corresponding to the target index; Calculate the offset position of each sub-index data in the SPI data frame; fill the configuration parameter values ​​into the communication data area of ​​the SPI bus according to the offset position to obtain SPI messages with different configuration parameters grouped according to the corresponding offset positions; The slave station sends configuration parameters to the protocol conversion module via the SPI bus; the protocol conversion module sends the configuration parameters to the backplane bus, so that the target expansion card reads the configuration parameters from a specific address range of the backplane bus, and configures the operating parameters of the target expansion card according to the configuration parameters.

7. The method according to claim 6, characterized in that, The calculation of the offset position of each sub-index data in the SPI data frame specifically includes: The slave station receives write operations, the content of which includes the data corresponding to the sub-index of the target index, i.e., the issued configuration parameter values; The slave station parses the target index in the write operation to obtain the slot number of the target expansion card; the target index ranges from 0x8000 to 0x8FFF; where W is used as a label for six expansion card types, W=1 represents type A card, W=2 represents type B card, W=3 represents type C card, W=4 represents type D card, W=5 represents type E card, and W=6 represents type F card; the configuration parameter lengths are 32 bits, 16 bits, 64 bits, 64 bits, 32 bits, and 64 bits respectively; the slave station's XML device description file defines the indices of the six types of expansion cards as 0x8001, 0x8002, 0x8003, 0x8004, 0x8005, and 0x8006 respectively; When the E-type card is used as the target expansion card and the slot number of the target expansion card is slot 9, 0xUV = 0x09. The configuration parameter value is 5 + 8 * (0xUV) at the starting offset position of the SPI bus, where 5 represents the packet header of the SPI protocol and 8 represents the data area length of each expansion card. When the configuration parameter value has 4 sub-indices, the offset positions of the configuration parameter value represented by the 4 sub-indices on the SPI bus are as follows: Sub Index1: 5+8*(0xUV), Sub Index2: 5+8*(0xUV)+1, Sub Index3: 5+8*(0xUV)+2 and Sub Index4: 5+8*(0xUV)+3. Determine the offset position of different configuration parameters in the SPI bus.

8. The method according to claim 1, characterized in that, The main station obtains the input information of the input type expansion card according to the mapping table in the PDO communication mapping, specifically including: Perform periodic PDO communication; The master station obtains the slot number of the expansion card through the slave station and the protocol conversion module, and determines the type of expansion card corresponding to the slot number; The main station calculates the communication index based on the default PDO mapping predefined in the XML device description file and the slot number of the expansion card; the XML device description file defines a third mapping relationship for input type expansion cards and a fourth mapping relationship for output type expansion cards. The third mapping relationship is the mapping relationship between Tt, Y, and Z. Tt is the data type set of the expansion card TxPDO, where Tt = {Tt1, Tt2, Tt3, Tt4, Tt5}, Tt1, Tt2, Tt3, and Tt4 represent four different data types, and Tt5 can be one of Tt1, Tt2, Tt3, and Tt4, or another type. Y is the TxPDO basic mapping index defined in the XML device description file, Y = {Y1, Y2, Y3, Y4, Y5}, where Y1, Y2, Y3, and Y4 take different values ​​and are within the range of 0x1A00 to 0x1A. Y5 is the maximum value in set Y, ranging from 0x1A00 to 0x1A0F; Z is the set of application object dictionary indices, with elements ranging from 0x6000 to 0x6FFF, corresponding to four data types. The basic application object index is defined in the XML device description file as Z = {Z1, Z2, Z3, Z4, Z5}, where Z1, Z2, Z3, and Z4 take different values ​​and are between 0x6000 and 0x600F. Z5 is the maximum value in set Z, ranging from 0x6000 to 0x600F. The least significant bit of Y5 is the same as the least significant bit of Z5. The fourth type of mapping relationship is the mapping relationship of Tr, P, and Q. Tr describes the data type set Tr of all expansion card RxPDOs, Tr = {Tr1, Tr2, Tr3}. Its mapping object dictionary index set is P, P = {P1, P2, P3}. The value range of the elements in P is between 0x1600 and 0x17FF, and the values ​​of P1, P2, and P3 are between 0x1600 and 0x160F. The application object dictionary index is set Q, Q = {Q1, Q2, Q3}, corresponding to three data types. Q1, Q2, and Q3 take different values. The value range of the elements in set Q is between 0x7000 and 0x7FFF, and the values ​​of Q1, Q2, and Q3 are between 0x7000 and 0x700F. The least significant bit of P1 is the same as the least significant bit of Q1; the least significant bit of P2 is the same as the least significant bit of Q2; and the least significant bit of P3 is the same as the least significant bit of Q3.

9. The method according to claim 8, characterized in that, The interaction between the main station and the input type expansion card specifically includes: When the target expansion card is an input type expansion card, the target expansion card will refresh the collected input data and status data to the data corresponding to the sub-index of its application object dictionary index set Z; The protocol conversion module sends the input data and status data collected by the target expansion card to the slave station via the SPI bus; The slave station maps and updates the received input data and status data to the application data corresponding to the sub-index in the application object dictionary index set Z; The slave station places the expansion card data into the Ethercat protocol according to the offset position of different expansion cards; The master station receives data that the slave station puts into the Ethercat protocol.

10. The method according to claim 8, characterized in that, The interaction between the main station and the output type expansion card specifically includes: When the target expansion card is an output type expansion card, the master station calculates the data offset of the expansion card corresponding to the corresponding slot and writes the output data of the expansion card into the offset address of the Ethercat downlink frame corresponding to the expansion card. The slave station receives downlink frames and extracts the data corresponding to the output command from the offset address; Based on the first and second mapping relationships, the expansion card type and slot number corresponding to the output command are determined. SPI protocol data packets are generated according to the expansion card type and slot number. The data corresponding to the output command is sent to the protocol conversion module via the SPI bus. The protocol conversion module writes the data to the area of ​​the slot number corresponding to the target expansion card on the backplane bus, so that the target expansion card corresponding to the slot number can read the data corresponding to the output command from the backplane bus and drive its output channel.

Images