Development platform architecture based on CODESYS software

Abstract

The application discloses a development platform architecture based on CODESYS software, which comprises a PC platform and a target machine platform; the PC platform is used for formulating an EXCEL protocol table according to variable forms, generating a device description file, a variable mapping file, an IOController driver program and a Drivers driver program according to the EXCEL protocol table, and generating protocol IO variables according to the device description file and the variable mapping file, so as to be used for IEC logic development by a logic developer; and the target machine platform is used for establishing a mapping channel between an IEC logic task and the Drivers driver program according to the IOController driver program, so as to complete variable mapping, and thus data transmitted by the Drivers driver program and the IEC logic task are interacted. The application brings great work convenience to logic developers and underlying driver developers.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and more particularly to a development platform architecture based on CODESYS software. Background Technology

[0002] CODESYS software is a logic development automation software developed by the German company 3S (3S-Smart Software Solutions GmbH). CODESYS software has a very high market share in China and is widely used in the field of control system manufacturing.

[0003] Problems exist when using CODESYS software for PLC logic development: 1) With a large number of I / O logic variables, adding each variable one by one is too labor-intensive and not conducive to large-scale project development. 2) When handling I / O communication, using the industrial fieldbuses included with CODESYS software is complex to configure, and different industrial fieldbuses provided by CODESYS require payment. Furthermore, CODESYS software does not support many communication methods, such as the MVB communication used in the railway industry.

[0004] Therefore, there is an urgent need to develop a development platform architecture based on CODESYS software that overcomes the above-mentioned shortcomings. Summary of the Invention

[0005] To address the above problems, this invention provides a development platform architecture based on CODESYS software, comprising:

[0006] The PC platform is used to define an EXCEL protocol table based on the variable format, and then generate a device description file, variable mapping file, IOController driver and Driver driver based on the EXCEL protocol table. The CODESYS software generates protocol IO variables based on the device description file and the variable mapping file for logic developers to perform IEC logic development.

[0007] The target machine platform is used to establish a mapping channel between the IEC logical task and the Drivers driver based on the IOController driver to complete variable mapping, thereby enabling the data sent and received by the Drivers driver to interact with the IEC logical task.

[0008] The aforementioned development platform architecture, wherein the PC platform includes:

[0009] The protocol table generation module obtains the EXCEL protocol table based on the variable format through a preset variable hierarchy structure table;

[0010] The CSDEV module generates a multi-layered tree data structure based on the EXCEL protocol table, and generates the device description file, the device variable mapping file, the IOController driver, and the Drivers driver based on the tree data structure.

[0011] The aforementioned development platform architecture, wherein the target machine platform includes:

[0012] The driver module receives the Drivers driver program output by the PC platform;

[0013] The IO control module receives the IOController driver output from the PC platform and constructs shared memory through the IOController driver. It then forms the mapping channel through the shared memory to complete variable mapping. The data sent and received by the driver module interacts with the IEC logical task.

[0014] In the aforementioned development platform architecture, after the IOController driver establishes the shared memory, the shared memory is associated with the codesys IEC variable of the IEC logical task and the Driver driver, so that the codesys IEC variable interacts with the Driver driver.

[0015] In the aforementioned development platform architecture, the tree-shaped data structure includes an Excel protocol table layer. The CSDEV module constructs an IMPORT_VAR node and attaches it to the PLC node. The connection nodes corresponding to the Excel protocol table layer are also attached to the IMPORT_VAR node to form the device description file.

[0016] In the aforementioned development platform architecture, the tree data structure includes at least a variable type layer, a variable hierarchy layer, and a variable layer. The CSDEV module merges the variable type layer and the variable hierarchy layer to form a folder node, and attaches the variable layer to the folder node to form the variable mapping file.

[0017] In the aforementioned development platform architecture, the variable mapping file corresponds to the Excel protocol table layer.

[0018] In the aforementioned development platform architecture, when the IOController driver runs, it determines a codesysIEC variable through the IoConnectorMap and IoChannelMap attributes of each variable, and points the pointer of the codesysIEC variable to the shared memory offset region, wherein the IoConnectorMap and the IoChannelMap correspond to the tree data structure.

[0019] In the aforementioned development platform architecture, each IO variable in the Drivers driver obtains variable hierarchy information, variable attribute information, and the offset region of each variable in the shared memory. The Drivers driver then links each IO variable to the offset region of the shared memory.

[0020] In the aforementioned development platform architecture, after the target machine platform calls the ReadInput function to read the IO input variables, it executes the IEC logical task. After each IEC logical task finishes running, it calls writeOutput to send the IO output variables.

[0021] In summary, the advantages of this invention compared to existing technologies are as follows: This invention designs a complete platform architecture for CODESYS, firstly defining a variable format that can be used in any project's protocol. Furthermore, based on this, methods for variable import and I / O mapping are designed to solve the aforementioned variable import and I / O communication problems, facilitating large-scale project development for logic developers.

[0022] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description and the drawings. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a schematic diagram of the development platform architecture of the present invention;

[0025] Figure 2 This is a schematic diagram of a tree-like data structure;

[0026] Figure 3 A graph connecting variable nodes;

[0027] Figure 4 This is a diagram of the IO mapping structure. Detailed Implementation

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

[0029] The illustrative embodiments and descriptions of the present invention are used to explain the invention, but are not intended to limit the invention. Furthermore, elements / components using the same or similar reference numerals in the drawings and embodiments are used to represent the same or similar parts.

[0030] The terms "first," "second," "S1," "S2," etc., used in this document do not specifically refer to any order or sequence, nor are they intended to limit the invention. They are merely used to distinguish elements or operations described using the same technical terms.

[0031] The directional terms used in this article, such as up, down, left, right, front, or back, are for reference only when referring to the accompanying drawings. Therefore, the use of directional terms is for illustrative purposes and not to limit this work.

[0032] The terms “include,” “including,” “have,” “contain,” etc., used in this article are all open-ended terms, meaning that they include but are not limited to.

[0033] The term "and / or" as used herein includes any or all of the things mentioned.

[0034] The term "multiple" in this article includes "two" and "more than two"; the term "multiple groups" in this article includes "two groups" and "more than two groups".

[0035] The terms "approximately," "about," etc., used herein are intended to modify any quantity or error that may vary slightly, but these slight variations or errors do not change the essence of the quantity or error. Generally, the range of slight variations or errors modified by such terms may be 20% in some embodiments, 10% in others, 5% in still others, or other values. Those skilled in the art should understand that the aforementioned values ​​can be adjusted according to actual needs and are not limited thereto.

[0036] Certain terms used to describe this application will be discussed below or elsewhere in this specification to provide additional guidance to those skilled in the art in describing the application.

[0037] Please refer to Figure 1 , Figure 1 This is a schematic diagram of the development platform architecture of the present invention. Figure 1 As shown, the development platform architecture of this invention includes: a PC platform 11 and a target platform 12. The PC platform 11 is used to formulate an EXCEL protocol table according to the variable form, and then generate a device description file, a variable mapping file, an IOController driver, and a Driver driver according to the EXCEL protocol table. The CODESYS software generates protocol IO variables according to the device description file and the variable mapping file for logic developers to perform IEC logic development. The target platform 12 is used to establish a mapping channel between the IEC logic task and the Driver driver according to the IOController driver to complete the variable mapping, thereby enabling the data sent and received by the Driver driver to interact with the IEC logic task.

[0038] Specifically, on the PC platform 11, the CODESYS platform defines variable formats and, based on these formats, develops an Excel protocol table. Using this table, a device description file and a variable mapping file are generated. These two files are then imported into the CODESYS software to generate protocol variables for use by logic developers. After logic development is complete, Lua scripting technology is used to generate IOController and Drivers drivers with a single click. On the target platform 12, the IOController establishes shared memory, forming a bridge between the codesys runtime and the IO drivers, completing variable mapping. In this way, the data sent and received by the IODrivers interacts with the codesys logical variables.

[0039] Furthermore, the PC platform 11 includes:

[0040] The protocol table generation module 111 obtains the EXCEL protocol table according to the variable format through a preset variable hierarchy structure table.

[0041] Specifically, the core idea of ​​the Codesys platform is data platformization. Only one type of variable is defined here; the protocol, port, and offset of other variables exist as variable attributes. This allows variables from any project to be represented. See Table 1 below for the detailed variable hierarchy definition:

[0042] Table 1 Variable Hierarchy Structure

[0043]

[0044]

[0045] By defining the variables above, an EXCEL communication protocol can be formulated, and different protocol variables can be stored in different EXCEL protocol tables.

[0046] CSDEV module 112 generates a multi-layered tree data structure based on the EXCEL protocol table, and generates the device description file, the device variable mapping file, the IOController driver, and the Drivers driver based on the tree data structure. The tree data structure includes the Excel protocol table layer. The CSDEV module constructs an IMPORT_VAR node and attaches it to the PLC node, and attaches the connection node corresponding to the Excel protocol table layer to the IMPORT_VAR node to form the device description file.

[0047] The tree-like data structure includes at least a variable type layer, a variable hierarchy layer, and a variable layer. The CSDEV module merges the variable type layer and the variable hierarchy layer to form a folder node, and attaches the variable layer to the folder node to form the variable mapping file.

[0048] Specifically, CSDEV module 112 reads the Excel protocol table and generates a four-level tree data structure. These are: the variable root node, the Excel protocol table layer, the category + level 1 + ... + level n layers, and the variable layer. See details... Figure 2 .

[0049] During the variable import process, two XML files need to be generated: a device description file and a variable mapping file. The device description file assigns I / O channels to each I / O variable, but it lacks the mapping relationship between I / O channels and I / O protocol variables, requiring logic developers to manually map them. In large projects, there are numerous I / O variables, so automatic mapping is necessary. This is where the variable mapping file comes in. This file automatically associates I / O variables with I / O channels. Finally, importing these two files into the CODESYS software completes the I / O variable import, making it available for logic developers to use.

[0050] Importing variables requires three concepts: Connector (connection node), HostParameterSet (folder), and Channel (variable). These correspond to... Figure 2The variable hierarchical data structure is as follows: Connector corresponds to Excel, HostParameterSet corresponds to Typen+level1+...+leveln, and Channel corresponds to Var n. See the detailed diagram of variable node connections. Figure 3 .

[0051] 1) Generate the device description file. The device description file is... Figure 3 The left half of the structure

[0052] Each connector will have a parent node pointer and multiple child node pointers. Figure 3 In the codesys project, the PLC node is the root node. This node, as a parent node, is represented as follows:

[0053] <ConnectormoduleType="256",interface="Common.PCI",role="parent">

[0054] The IO_Var node is represented as a child node as follows. Since the interface content is the same as that of the PLC node, and its role is child, the IO_Var node can be attached to the PLC node.

[0055] <Connector moduleType="257"interface="Common.PCI"role="child">

[0056] The IO_Var node as a parent node is represented as follows:

[0057] <ConnectormoduleType="40100"interface="Interface"role="parent">

[0058] The Excel1_name node is represented as a child node as follows. Since its interface content is the same as that of the IO_Var node, and its role is child, the Excel1_name node can be attached to the IO_Var node.

[0059] <Connector moduleType="40105"interface="Interface"role="child">

[0060] Through the above connections, connections between connctors can be formed, organized into a connctor tree structure, and thus a device description file can be created.

[0061] 2) Generate a variable mapping file, the variable mapping file is... Figure 3 The right half of the structure

[0062] The variable mapping file is used to associate I / O channels with specific protocol variables. It adds a variable description section to the framework of the device description file, with the following main format:

[0063]

[0064] The variable mapping file corresponds to the Excel protocol layer. In the aforementioned file, ParameterSection is used to construct the folder name, corresponding to... Figure 3 The HostParameterSet section in the file. Parameters contain information about the constructed variables, corresponding to... Figure 3 The Channel section is as follows: Mapping maps variables to channels, Value is the default value of the variable, Attributes are the variable's input and output attributes, Description is the variable's description, Type is the variable's type, and ParameterId is the index of this variable in the Excel table. This information is obtained when the CSDEV module reads the Excel protocol table and corresponds to the variable hierarchy table in Table 1.

[0065] Furthermore, the target platform 12 includes:

[0066] Driver module 121 receives the Drivers driver program output by the PC platform;

[0067] The IO control module 122 receives the IOController driver output by the PC platform and constructs shared memory through the IOController driver. It forms the mapping channel through the shared memory to complete variable mapping. The data sent and received by the driver module interacts with the IEC logical task.

[0068] After the IOController driver establishes the shared memory, it associates the shared memory with the codesys IEC variable of the IEC logical task and the Driver driver to enable the codesysIEC variable to interact with the Driver driver. During runtime, the IOController driver determines a codesysIEC variable through the IoConnectorMap and IoChannelMap attributes of each variable, and points the pointer of the codesysIEC variable to the offset region in the shared memory. The IoConnectorMap and IoChannelMap correspond to the tree data structure. Each IO variable in the Driver driver obtains variable hierarchy information, variable attribute information, and the offset region of each variable in the shared memory. The Driver driver associates each IO variable with the offset region in the shared memory. After the target platform calls the ReadInput function to read the IO input variable, it executes the IEC logical task. After each IEC logical task finishes running, it calls writeOutput to send the IO output variable.

[0069] Specifically, the overall structure of IO communication is as follows: Figure 1 In the target machine portion of the CODESYS platform architecture, the IOController program establishes shared memory and associates the codesys IEC variables with this shared memory. During the IO Driver generation process, it also establishes an association with shared memory. Using shared memory as a bridge, the codesysIEC variables interact with the IODriver to send and receive IEC variables, thus completing the IO communication function. The implementation of IO communication will be explained below from three parts: IO mapping, IEC task execution, and IO Driver execution.

[0070] 1) I / O mapping

[0071] IoConnectorMap corresponds to Figure 2 In a hierarchical data structure, EXCEL and IoChannelMap correspond to... Figure 2 Var in a hierarchical data structure.

[0072] During the process of reading the EXCEL protocol table, the CSDEV software remembers the EXCEL number i (starting from 1) of each variable, the EXCEL number j (starting from 1) of each variable, and the number k of each variable in all protocol table protocol variables. The number k is the offset of that variable in shared memory.

[0073] The sorting rule for i is: starting from 1, increment by 1 for each Excel file read.

[0074] The sorting rule for j is: starting from 1, increment by 1 for each variable read, and restart the incrementing from 1 when reading a new Excel file.

[0075] The sorting rule for k is: starting from 1, increment by 1 for each variable read, and continue to increment by 1 when reading a new Excel file.

[0076] IEC variables and shared memory mapping:

[0077] When the IOController runs, it can uniquely identify an IEC variable through the IoConnectorMap and IoChannelMap properties of each variable, and then point the dwDriverSpecific pointer of this IEC variable to the shared memory offset k region, thus completing the mapping between the IEC variable and the shared memory.

[0078] IO Driver and Shared Memory Mapping:

[0079] In the IO Driver program, each IO variable obtains its variable hierarchy information, variable attribute information, and its offset k in shared memory. The IO Driver associates each IO variable with the shared memory offset k, thus completing the mapping between the IO Driver and shared memory.

[0080] 2) IEC task execution

[0081] When the Codesys runtime runs IEC tasks, it executes them in the order set from task0 to taskn. Before each IEC task runs, the `ReadInput` function is called to read the I / O input variables. Then, the IEC logic task is executed. After each IEC task finishes running, `writeOutput` is called to send the I / O output variables (no I / O operations are performed during the execution of the IEC task). The management of each variable is organized according to Task, Connector, and Channel; see details. Figure 4 The Codesysruntime section.

[0082] The operation for reading IO input variables is as follows: the dwDriverSpecific pointer of each IEC variable is pointed to the local memory area, and copied to the IEC variable in 4-byte size for use by the IEC logic execution.

[0083] The operation for sending IO output variables is as follows: the value of each IEC variable is converted into a 4-byte variable, and the dwDriverSpecific pointer points to the memory region.

[0084] 3) IO Driver Execution

[0085] An IO driver can be any developed IO driver, such as MVB, CAN, MODBUS, etc., or a combination of different IO drivers, as long as the execution cycle of the IO driver meets the user's project requirements. The IO driver reads and sends IO variables according to the set execution cycle, enabling IO communication between the controller and other devices.

[0086] In the I / O driver protocol, I / O variables belong to a specific port and a specific word offset or bit offset within the I / O protocol. These configuration values ​​are defined in Table 1, the variable hierarchy structure. Taking MVB communication as an example, the port number of the receive variable is 0x201, the word offset is 0, the bit offset is 0, and the type is BYTE. Therefore, there is one variable hierarchy, with hierarchy 1 being the MVB port, 0x201. There are two variable attributes: attribute 1 is word offset 0, attribute 2 is bit offset 0, and the variable type is BYTE.

[0087] The operation for reading I / O input variables is as follows: The I / O driver is invoked to receive the I / O variable value from the specified port and offset. The I / O variable value is then copied to the specified memory location in shared memory, according to its variable type and size.

[0088] The operation for sending IO output variables is as follows: retrieve the memory location at the specified offset in shared memory, and with the variable type and size, call the IO driver to send it to the specified port and offset bus location.

[0089] In summary, this invention designs a complete platform architecture for CODESYS. First, it defines a variable format designed to be usable by any project's protocol. Based on this, it designs methods for variable import and I / O mapping, resolving the aforementioned variable import and I / O communication issues, thus facilitating large-scale project development for logic developers. In practice, this platform architecture has been successfully applied to the Standard Electric 250 and LCU projects. This design brings significant convenience to both logic and underlying driver developers.

[0090] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A development platform architecture based on CODESYS software, characterized in that, include: The PC platform is used to define an EXCEL protocol table based on the variable format, and then generate a device description file, variable mapping file, IOController driver and Driver driver based on the EXCEL protocol table. The CODESYS software generates protocol IO variables based on the device description file and the variable mapping file for logic developers to perform IEC logic development. The target machine platform is used to establish a mapping channel between the IEC logical task and the Driver driver based on the IOController driver to complete the variable mapping, thereby enabling the data sent and received by the Driver driver to interact with the IEC logical task; The PC platform includes: The protocol table generation module obtains the EXCEL protocol table based on the variable format using a preset variable hierarchy structure table. This variable hierarchy structure table includes the following configuration fields: a category field to indicate the variable's category; a variable hierarchy field to record the total number of levels in the variable hierarchy; several hierarchy fields, sequentially including level 1 to level n; a variable type field to limit the variable's data type to those supported by CODESYS; a variable attribute field to describe the variable's own attributes; and several attribute fields, sequentially including attribute 1 to attribute n. The CSDEV module generates a multi-layered tree data structure based on the Excel protocol table. This tree structure includes a root variable node, an Excel protocol table layer, a category + level 1 + ... + level n layers, and a variable layer. Based on this tree structure, it generates the device description file, the variable mapping file, the IOController driver, and the Drivers driver. Lua scripting technology is used to generate the IOController and Drivers drivers with a single click. The tree structure includes an Excel protocol table layer, a variable category layer, a variable hierarchy layer, and a variable layer. The CSDEV module constructs an IMPORT_VAR node and attaches it to the PLC node. It also attaches the connection nodes corresponding to the Excel protocol table layer to the IMPORT_VAR node, forming connections between connectors and organizing them into a connector tree structure to form the device description file. Simultaneously, it merges the variable category layer and the variable hierarchy layer to form folder nodes. The variable mapping file is then attached to the folder nodes, corresponding to the Excel protocol table layer. At the protocol level, Connector corresponds to Excel, HostParameterSet corresponds to Typen+level1+...+leveln, and Channel corresponds to Var n; During the process of reading the EXCEL protocol table, the CSDEV module remembers the EXCEL number i for each variable (starting from 1), the EXCEL number j for each variable (starting from 1), and the number k for each variable in the protocol variables list across all protocol tables. The number k represents the offset of that variable in shared memory. The sorting rule for 'i' is: starting from 1, increment by 1 for each Excel file read; The sorting rule for j is: starting from 1, increment by 1 for each variable read, and restart the increment from 1 when reading a new Excel file; The sorting rule for k is: starting from 1, increment by 1 for each variable read, and continue to increment by 1 when reading a new Excel file; The target machine platform includes: The driver module receives the Drivers driver program output by the PC platform; The IO control module receives the IOController driver output from the PC platform and constructs shared memory through the IOController driver. After the IOController driver establishes the shared memory, the shared memory is associated with the codesys IEC variable of the IEC logical task and the Driver driver, so that the codesys IEC variable interacts with the Driver driver. The shared memory forms the mapping channel to complete the variable mapping. The data sent and received by the driver module interacts with the IEC logical task.

2. The development platform architecture as described in claim 1, characterized in that, When the IOController driver runs, it determines a codesysIEC variable through the IoConnectorMap and IoChannelMap attributes of each variable, and points the pointer of the codesysIEC variable to the shared memory offset region, wherein the IoConnectorMap and the IoChannelMap correspond to the tree data structure.

3. The development platform architecture as described in claim 1, characterized in that, Each IO variable in the Drivers driver obtains variable hierarchy information, variable attribute information, and the offset region of each variable in the shared memory. The Drivers driver then links each IO variable to the offset region of the shared memory.

4. The development platform architecture as described in claim 1, characterized in that, After the target platform calls the ReadInput function to read the IO input variables, it executes the IEC logic task. After each IEC logic task is completed, it calls writeOutput to send the IO output variables.

Images