An object-oriented logic configuration compiling method and system

Abstract

The application discloses an object-oriented logic configuration compiling method and system, which comprises the following steps: collecting POU participating in compiling according to the task information of a target compiling device; acquiring variables participating in compiling according to the target compiling device and the POU, and acquiring the data type of the variables participating in compiling according to the variables; allocating addresses to the variables according to the data type of the variables; generating function call symbol information according to the pre-allocated task, the address slot of the POU and the method thereof; traversing and analyzing all the POU participating in compiling, generating a syntax tree and symbol information, associating the function call symbol information with a function call node, constructing a function call syntax tree, traversing the syntax tree, and generating binary instructions; and integrating the POU and the generated binary instructions to obtain a final logic binary file. According to the application, the specific private format binary file supports the object-oriented programming characteristics, is compatible with the original hardware and retains the real-time performance under the premise that only the compiler is reformed and the runtime system is not changed.

Description

Technical Field

[0001] This invention belongs to the field of industrial automation control, and specifically relates to an object-oriented logic configuration compilation method and system. Background Technology

[0002] In the field of industrial automation control, logic configuration software is mainly used for programming industrial production control processes. With the continuous advancement of industrial production technology, the complexity and diversity of production processes are increasing, leading to a continuous rise in the complexity of control logic. Due to the high coupling of systems, upgrading a single function by modifying the configuration logic almost requires regression testing of the entire system, which is time-consuming and labor-intensive. Object-oriented logic configuration technology improves the maintainability, reusability, and stability of configuration logic through encapsulation, inheritance, and modularization, solving the problems of existing products being difficult to maintain, having poor reusability, and having long stable transition periods.

[0003] In existing technologies, object-oriented logic configuration techniques have at least the following technical problems: 1. Existing object-oriented logic configuration technology relies on runtime polymorphism (virtual functions, interface calls). Polymorphic calls cannot be fully parsed at compile time and require dynamic binding at runtime, which leads to a decrease in real-time performance.

[0004] 2. Existing industrial control system logic configuration compilation tools generate proprietary format binary files, and their runtime environments only support procedural instruction sets, unable to directly parse object-oriented programming features. To support object-oriented programming, traditional solutions require modifications to both the compiler and the runtime system, leading to at least the following technical problems: compatibility is compromised, old programs cannot execute on the new runtime; development cycles are long, requiring re-verification of the runtime system's real-time performance. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a compilation method and system for object-oriented logic configuration based on supporting FB (Function Block) inheritance. This allows an FB to inherit from another FB or implement one or more interfaces, thereby improving the efficiency of configuration logic development and testing.

[0006] The present invention adopts the following technical solution.

[0007] An object-oriented logic configuration compilation method includes the following steps: Based on the task information of the target compilation device, collect the program organization units that participate in the compilation; Obtain the variables involved in compilation based on the target compilation device and the program organization unit involved in compilation, and obtain the data type of the variables involved in compilation based on the variables involved in compilation; The compiler allocates memory addresses for variables that participate in the compilation process based on their data types. Based on the pre-assigned tasks, the program organization units involved in compilation, and the address slots of their methods, function call symbol information is generated; The compiler traverses and parses all program organization units involved in compilation, generates a syntax tree and symbol information, associates the function call symbol information with function call nodes, constructs a function call syntax tree, traverses the syntax tree, and generates binary instructions. The program organization units involved in the compilation and the generated binary instructions are integrated to obtain the final logical binary file, thus completing the compilation of the logical configuration.

[0008] Preferably, the collection of program organization units participating in compilation specifically includes: Based on the task information of the target compilation device, the program organization units mounted under each task and other program organization units they reference are used as program organization units participating in the compilation.

[0009] Preferably, the variables involved in compilation obtained based on the target compilation device and the program organization unit participating in compilation include: all variables of the program type program organization unit and all variables in the variable table of the target compilation device.

[0010] Preferably, the data types of the variables include: basic data types and user-defined data types; Among them, the basic data types are those defined in the IEC61131-3 international standard; the custom data types include structures, arrays, enumerations, unions, and the function block types corresponding to each function block type program organization unit.

[0011] Preferably, the allocation of addresses for variables participating in compilation specifically includes: Iterate through the variables involved in compilation and allocate global address space for the variables according to their types and byte alignment requirements. The alignment requirement for basic data types is to match the byte length of that type. The alignment requirement for custom data types is the maximum value among the alignment requirement values ​​of each sub-member of that type.

[0012] Preferably, the address slots of the pre-allocated tasks, program organization units, and their methods, generating function call symbol information, specifically include: Create a binary instruction address record area, and allocate address slots in the binary instruction address record area. Each address slot occupies a fixed length of address unit. Each task in the device is assigned a 4-byte address slot in sequence, and function symbol information is created for each task. The symbol information records the relative offset of the starting position of the address slot of the corresponding task in the binary instruction address record area. Traverse the program organization units participating in the compilation and allocate an address slot for each participating program organization unit. If the participating program organization unit is of type FB, after allocating the address slot for the participating program organization unit, start allocating address slots for the methods of the participating program organization unit according to the method address allocation principle, starting from the slot after the address slot of the participating program organization unit.

[0013] Preferably, the address allocation principle of the method is as follows: The methods of the interfaces implemented by this FB type are listed first, followed by other methods; If the number of interfaces implemented by the FB type is greater than 1, the methods of the implemented interfaces will be grouped according to the interfaces, including: grouping the methods declared by the same interface into one group, and arranging the interface groups according to the order in which the FB implements the interfaces, with the group of methods of the interfaces implemented first being arranged first. The order of methods within the same interface includes: following the order of method declarations when defining the interface, and maintaining the order consistent with the interface prototype.

[0014] Preferably, when associating the function call symbol information with the function call node, the association of the symbol information and call node of the FB method specifically includes: Extract key information, which includes: the name of the method being called, the FB type of the instance currently being analyzed, and the FB type to which the method currently being analyzed belongs; Based on the method name and FB type information in the key information, search the symbol table for a list of matching method symbols; Based on the program organization unit information to which the method belongs and the virtual method flag, determine the unique and correct method symbol; When associating symbolic information and calling nodes of program organization units, a unique program organization unit symbol is determined based on the name of the program organization unit for association.

[0015] Preferably, the construction of the function call syntax tree specifically includes: When constructing the program organization unit call syntax tree, if the program organization unit type is PRG, then it is not necessary to construct parameter nodes; If the program's organizational unit type is FB, then parameter nodes need to be constructed, including passing the starting address of the FB instance variable to a hidden variable of the FB, associating the FB call node and parameter node, and completing the syntax tree construction of the FB call. If the program organization unit is of type FUN, parameter nodes need to be built for the input and output variables of FUN, and the FUN call node and each parameter node are associated in sequence to complete the construction of the syntax tree of FUN call; When constructing the syntax tree for FB's method calls, parameter nodes need to be built for the method's input and output variables, and another parameter node needs to be built to pass the aforementioned hidden variables of the FB instance. The method call node and parameter node are then linked in sequence to complete the construction of the syntax tree for the method calls.

[0016] This invention also proposes an object-oriented logic configuration compilation system for implementing the object-oriented logic configuration compilation method, comprising: The program organization unit collection module is used to collect the program organization units participating in the compilation based on the task information of the target compilation device; The data type acquisition module is used to obtain the variables involved in compilation based on the target compilation device and the program organization unit involved in compilation, and to obtain the data type of the variables involved in compilation based on the variables involved in compilation. The address allocation module is used to allocate addresses to variables participating in compilation based on their data types. The information generation module is used to generate function call symbol information based on the pre-allocated tasks, the program organization units involved in compilation, and the address slots of their methods. The instruction generation module is used to traverse and parse the program organization units involved in compilation, generate a syntax tree and symbol information, associate the function call symbol information with the function call nodes, construct a function call syntax tree, traverse the syntax tree, and generate binary instructions; The linker module is used to integrate the program organization units involved in compilation and the generated binary instructions to obtain the final logical binary file, thus completing the compilation of the logical configuration.

[0017] The present invention also proposes a terminal, including a processor and a storage medium; The storage medium is used to store instructions; The processor is configured to operate according to the instructions to execute the steps of the object-oriented logic configuration compilation method.

[0018] The present invention also proposes a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the object-oriented logic configuration compilation method.

[0019] The beneficial effects of this invention are that, compared with the prior art, this invention generates binary files that are still compatible with the original proprietary format by only modifying the compiler and without changing the runtime system. The runtime system can parse OOP logic without any modification, ensuring compatibility with existing hardware and preserving real-time performance. The beneficial effects of this application include at least the following: 1. This invention identifies methods within a functional block as a special type of functional program organization unit. It collects and sorts all method symbols by flattening their inheritance tree. Based on the rule that interface implementation methods take precedence over base class virtual methods, and base class virtual methods take precedence over methods newly added to this functional block, a fixed memory address is pre-allocated for each method according to the original private format compilation file. Flattening refers to collecting all methods from functional blocks in their inheritance chain, along with the methods of the functional block itself, into the method list of that functional block, allowing subsequent steps to directly look up and access them.

[0020] 2. This invention proposes a two-step assignment and invocation mechanism for interface variables: during assignment, an instance pointer is passed and the address of the first method is written; during invocation, the address of the target method is located through static offset calculation. This method enables efficient and reliable support for method inheritance, overriding, and polymorphic invocation through interfaces in resource-constrained industrial controllers, improving the maintainability, reusability, and runtime performance of the logic. The polymorphic target invocation is determined at compile time, eliminating the need for dynamic binding at runtime. Attached Figure Description

[0021] Figure 1 This is a flowchart of the object-oriented logic configuration compilation method of the present invention; Figure 2 This is a schematic diagram of the main resources of the equipment in this invention; Figure 3 This is a resource diagram of example device 1 in this invention; Figure 4 This is a schematic diagram of variable address allocation in this invention; Figure 5 This is a schematic diagram of the POU and method compilation in this invention; Figure 6 This is the schematic representation of the method symbol of POU in this invention; Figure 7 This is a schematic diagram of the interface variable assignment process in this invention; Figure 8 This is a structural diagram of the object-oriented logic configuration compilation system of this invention. Detailed Implementation

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

[0023] This invention proposes an object-oriented logic configuration compilation method, where the object is a function block instance. The proposed logic configuration compilation method is only applicable to proprietary formats with the following characteristics: Feature 1: It has a contiguous function address area that stores the addresses of the binary machine code of the POUs that participate in the compilation. Each POU occupies one address slot, and the slot stores the starting address of the binary machine code of that POU. Feature 2: There are no absolute address accesses or jumps within the file. Jumping to execution of the POU requires obtaining the starting address of the POU's binary machine code by reading the contents of that POU address slot before jumping to execution. Feature 3: It has a contiguous binary machine code area to store all the binary machine code generated during compilation.

[0024] Feature 4: It has a contiguous variable area. The addresses of the sub-members of user-defined type variables are contiguous.

[0025] like Figure 1 As shown, the method includes the following steps: Step 1: Collect the POUs (Program Organization Units) participating in the compilation based on the task information of the target compilation device. Step 2: Obtain the variables involved in the compilation based on the target compilation device and the POU involved in the compilation, and obtain the data type of the variables involved in the compilation based on the variables involved in the compilation; Step 3: Assign memory addresses to the variables involved in compilation based on their data types; Step 4: Generate function call symbol information based on the pre-allocated tasks, the POUs involved in compilation, and their method address slots; Step 5: Traverse and parse all POUs involved in compilation, generate syntax trees and symbol information, associate the function call symbol information with function call nodes, construct function call syntax trees, traverse syntax trees, and generate binary instructions; Step 6: Integrate the POUs involved in the compilation and the generated binary instructions to obtain the final logical binary file, thus completing the compilation of the logical configuration.

[0026] Specifically, the collection of POUs involved in compilation in step 1 includes: Based on the task information of the target compilation device, all POUs attached to each task and other POUs they reference (e.g., function block type POUs or function type POUs) are collected into the list of POUs participating in the compilation.

[0027] Among them, the types of POU include: PRG type, FB type, and FUN type.

[0028] Only PRG (Program) type POUs are allowed to be mounted under a task. FB (Function Block) type POUs cannot be called directly. To reference an FB type POU, the FB must first be instantiated, and then the POU can be called using the FB instance. When a POU under a task references an FB instance, the FB is also collected as a POU participating in the compilation.

[0029] Step 2, obtaining the variables involved in compilation based on the target compilation device and the POUs involved in compilation, further includes: Obtain the PRG type POU from the POUs involved in the compilation, and then obtain all variables of the PRG type POU; Retrieve all variables from the variable table of the target compilation device; The final compiled variables include all variables of type PRG POU and all variables in the variable table of the target compilation device.

[0030] Furthermore, the data types of variables include: basic data types and user-defined data types; Among them, the basic data types include the basic data types defined in the IEC 61131-3 international standard; Custom data types include structs, arrays, enumerations, unions, and the FB type corresponding to each FB type POU; Specifically, each FB type POU corresponds to one FB data type, and each interface corresponds to one interface data type. The interface data type is actually a special structure type containing two sub-members, namely the data starting address of the FB object pointed to by the interface and the address slot offset of the first method of the interface.

[0031] Step 3, which allocates memory addresses for variables participating in compilation based on their data types, further includes: Iterate through the variables collected for compilation and allocate global address space for each variable based on its data type and byte alignment requirements.

[0032] When allocating the address of a custom type variable, the data type information of the variable is found from the list of custom data types collected in step 2. Based on the total size of the custom type and the byte alignment requirements, the address space of the total size of the custom type is allocated to the variable, and global address offsets are allocated to all sub-variables of the variable according to the order of the sub-member types of the custom type.

[0033] When allocating addresses for FB instance variables, all variables defined in FB (including input / output type variables and local variables) are child variables of the FB instance, meaning they all need to be allocated global addresses.

[0034] There is no need to allocate global addresses for variables of type FUN (Function). Treating POU methods as special FUN type POUs also does not require allocating global addresses for variables defined inside the method.

[0035] like Figure 5 As shown, in step 4, the pre-allocation of address slots for tasks, POUs, and their methods, and the generation of function call symbol information, further include: Create a binary instruction address record area, and allocate Renault address slots in this area. Each address slot occupies a fixed length of address units.

[0036] First, each task in the device is assigned a 4-byte address record slot in sequence, and a function symbol is created for each task. The symbol information records the relative offset of the starting position of the address slot of the corresponding task in the binary instruction address record area.

[0037] Secondly, iterate through the collected POUs participating in the compilation, allocating an address slot for each POU. If the POU is of type FB, after allocating the address slot for this POU, immediately allocate an address slot for its method. A POU's method is an extension of the method in the IEC 61131-3 standard; a method is not an independent POU but belongs to a functional block. Each method contains a declaration and an implementation, and a method can access all variables of its parent POU. An interface is a collection of abstract methods; abstract methods are method prototypes, containing only declarations and not implementations.

[0038] Furthermore, the address slot allocation rules for FB type POUs are as follows: Address slot allocation principle: 1. The implemented interface methods are listed first, followed by other methods; 2. Interface method priority sorting: Methods are arranged according to the declaration order of the FB implementation interfaces; Example: If FB implements the ITERFACE1 and ITERFACE2 interfaces in sequence... Prioritize all interface methods of ITERFACE1 Then, all the interface methods of ITRFACE2 are listed. 3. Method ordering within the interface: Methods within the same interface must strictly follow the order of declaration when the interface is defined, maintaining an order completely consistent with the interface prototype.

[0039] In step 5, the compilation module traverses and parses the POUs involved in compilation, generates a syntax tree and symbol information, and associates the function symbols described in step 4 with function call nodes. Traversing the syntax tree to generate binary instructions further includes: The compilation module selects the corresponding parser based on the POU's programming language (such as ST, CFC, or LD), parses the POU logic code, and generates a syntax tree.

[0040] When generating function call nodes (e.g., POU calls, method calls), the node information is marked to indicate whether the call method uses an interface variable. If it does, the method's binary instruction address is located by first calculating the address slot position: using the first method address slot offset sub-member value of the interface variable + 4 bytes * the method's declaration position index in the interface corresponding to the interface variable (method indexes start from 0), and then reading the value in the address slot. This value is the binary instruction address of the method. For other call nodes, the address slot position can be directly obtained, and the value in the address slot can be read; this value is the binary instruction address of the method.

[0041] The above-described calls include three types: FUN calls, FB calls, and FB method calls. Specifically, assuming a functional block (i.e., FB1) implements an interface ITF1, an instance of FB1 can be used to assign a value to a variable of that interface type, and then the interface variable can be used to call a method of FB1. For example, assuming the interface ITF1 declares abstract methods meth1 and meth2, then FB1 implementing this interface should implement all methods declared in this interface, that is, FB1 should implement the two methods ITF1.meh1 and ITF1.meh1. Define an instance of FB1 inst_FB1:FB1; define an interface variable itf_var:ITF1; assign the value itf_var:= inst_FB1 to itf_var; then you can use the call statement itf_var.meth1(); to call the meth1 method of FB1. The itf_var.meth1() calling method requires special handling, so the call node must be marked as using this interface method calling method calling method. The special handling refers to the fact that for methods called via FUN, FB, or methods not using the interface, the address slot of the callee can be directly obtained. The value retrieved from that address slot is the actual location of the callee's binary code, allowing execution to jump to that location. However, for methods like `itf_var.meth1()`, the address slot of the method cannot be directly obtained. When processing the statement `itf_var:= inst_FB1`, the address slot of the first method of the ITF1 implementation corresponding to the POU `FB1` of `inst_FB1` is assigned to `itf_var`'s `ADDR_OFFSET`. Since `meth1` is the nth declared method of the ITF1 interface, and interface methods allocate method address slots sequentially after the FB1 address slot according to specified address allocation rules, the method address slot can be located using `ADDR_OFFSET + offset`, and then the binary instruction address of the method can be retrieved from that address slot.

[0042] When processing FB method call statements, the parser performs the following steps: 1. Extract key information: Key information includes: the name of the method being called, the instance type (FB) currently being analyzed, and the FB type to which the method being analyzed belongs; 2. Symbol table retrieval: Based on the method name and FB type information extracted in the previous step, search for a list of matching method symbols in the symbol table; 3. Exact match: The unique and correct method symbol is determined based on the following attributes: the POU information to which the method belongs and the virtual method flag; 4. Construct the complete syntax tree nodes.

[0043] When handling a call to an FB instance, the starting address of the FB instance variable is passed as a parameter to the FB's THIS property. When handling a method call, the FB instance's THIS property is passed as a parameter to the method so that the method can access the parent FB's variables.

[0044] When handling FUN calls, a stack is used to manage FUN variables. FUN input parameters are passed to the corresponding FUN input variables via the stack, and output parameters are passed the address of external variables to FUN output variables. Internally, FUN directly modifies the value of external variables through this address. Further preferably, to verify the effectiveness of the method proposed in practical applications, the following examples are provided: The main resources of the equipment are as follows Figure 2 As shown: Device resources mainly include POU, variables, interfaces, tasks, and data types.

[0045] Interface: An interface describes a set of abstract methods and properties. A prototype means that the methods and properties only contain declarations and have no implementations.

[0046] Methods are extensions of the IEC 61131-3 standard. A method contains method variables and logic; abstract methods only contain variables. A method is not an independent POU; it belongs to a function block. A method can access all variables of its parent POU.

[0047] according to Figure 3 As shown in the example device resource diagram, device1 has 3 POU resources: main, FB1, and FB2. Main is a PRG type POU, and FB1 and FB2 are FB type POUs. FB2 inherits from FB1. Device1 has 1 task resource, and this task has 1 POU attached, namely main.

[0048] Device1 has two interface resources, INTERFACE_1 and INTERFACE_2. INTERFACE_1 declares an abstract method itf_method1, and INTERFACE_2 declares an abstract method itf_method2. INTERFACE_2 inherits from INTERFACE_1, and FB1 implements the interface INTERFACE_2.

[0049] Step 1: Collect the POUs that participated in the compilation.

[0050] All POUs attached to a task under a device are POUs that participate in the compilation. In this example, device1 has a task MainTask, which has one POU attached as main. main is recorded in the compilation POU list. main contains an instance of FB2, inst_FB2, which is recorded in the compilation POU list.

[0051] Step 2: Collect the variables and custom types involved in the compilation.

[0052] All variables in the variable table are variables; Variables in the PRG type POU that are involved in the compilation are also recognized as variables, but they are only visible within the POU.

[0053] The variables in the variable table for this example are as follows: VAR_GLOBAL g_cnt1 : DINT; END_VAR The main variable table is defined as follows: VAR inst_FB2 : device1.FB2; lastN : INT; ITF: INTERFACE_2; END_VAR The FB2 variable table is defined as follows: VAR_INPUT tp1: INT; END_VAR VAR_OUTPUT ret : INT; END_VAR The FB1 variable table is defined as follows: VAR_INPUT var1 : INT; var2 : INT; END_VAR When collecting variables, add the variable g_cnt1 from the variable table to the variable list that participates in the compilation; add the variables in the POU that the task is mounted to the variable list, that is, add inst_FB2, lastN, and ITF from main to the variable list.

[0054] Step 3: Assign addresses to the variables involved in compilation; In this example, the compilation variables are g_cnt1, main.inst_FB2, main.LastN, and main.ITF, respectively. The result of variable address allocation is as follows Figure 4 As shown: The starting address of variable g_cnt1 is offset by 0 from the beginning address of the variable area. Since the variable type is DINT, its length is 4 bytes. In `main`, the starting address of the variable `inst_FB2` is the offset of the starting address of `g_cnt` plus the space length of `g_cnt`. `inst_FB2` belongs to the `FB` type and has child variables. Its space length is the sum of the space lengths of all child variables. `FB2` inherits from `FB1`, so it inherits the variable resources of `FB1`. Therefore, the child variables of the `FB2` instance `inst_FB2` are the collection of variables defined in `FB1` and variables defined in `FB2`, and the child variables are arranged according to the inheritance relationship: variables defined in `FB1` come first, and variables defined in `FB2` come second, namely `var1`, `var2`, `tp1`, and `ret`. All variables are of type `INT` and occupy 2 bytes. Therefore, `inst_FB2` occupies a total of 8 bytes.

[0055] The starting address of the variable LastN in main is the offset of the starting address of inst_FB2 + the length of inst_FB2, which occupies 2 bytes.

[0056] The starting address of the variable ITF in main is the offset of the first address LastN + the lastN space length. The interface type occupies a fixed 8 bytes. The interface type has two child members THIS and ADDR_OFFSET, each occupying 4 bytes. The total space occupied by ITF is 8 bytes.

[0057] Step 4: Pre-allocate address slots for tasks, POUs and their methods, and generate function call symbol information.

[0058] First, allocate an address slot for the task. Each address slot occupies a fixed 4 bytes. In this example, there is only one task, so allocate slot 0 for it, with the starting address being the first address of the binary instruction address record area. The main slot occupies slot 1, and FB2 occupies slot 2. FB2 contains methods, and the method slot should immediately follow the FB2 slot.

[0059] In this example, FB2 inherits from FB1, FB1 implements the interface INTERFACE_2, and the interface INTERFACE_2 inherits from the interface INTERFACE_1. INTERFACE_1 contains one abstract method `itf_method1`, and INTERFACE_2 contains one abstract method `itf_method2`. FB1 contains 5 methods, including two virtual methods `itf_method1` and `itf_method2`, an abstract method `method_A`, and a defined method `method_B`. FB2 contains the implementation of `method_A`, `itf_method1`, `method_init`, and all methods of FB1. Therefore, the compiled type FB2 of instance `inst_FB2` has a total of 6 non-abstract methods: FB1.itf_method1, FB1.itf_method2, FB1.method_B, FB2.method_A, FB2.itf_method1, and FB2.method_init.

[0060] According to the sorting rules, interface method implementations are listed first, and the order of different interface methods follows the base class interface order. That is, `itf_method1` and `itf_method2` are prioritized, and the remaining methods are listed in the order of their definition. Both `FB1` and `FB2` implement `itf_method1`. When calling the method, `FB2.itf_method1` should be called here. Therefore, the method sorting result for the instance `inst_FB2` of type `FB2` is: `FB2.itf_method1`, `FB1.itf_method2`, `FB1.method_B`, `FB2.method_A`, `FB2.itf_method1`, `FB2.method_init`, allocated to slots 3 to 8 respectively. The starting address of the slot is calculated using the formula relative offset from the starting address of the binary instruction address record area: Relative offset = Slot number * 4 bytes.

[0061] After allocating an address slot to a POU or method, a corresponding function symbol is created, and the relative offset of the slot's starting address is recorded in the symbol information. This allows the code address to be backfilled into the corresponding slot after the POU or method's binary code is generated, so that when the POU or method is called, the binary instruction can be found and executed through the address recorded in the slot.

[0062] Each POU corresponds to one function symbol. If the POU is of type FB, it has a corresponding method symbol table. The method symbol table of FB2 is as follows: Figure 6 As shown, the symbol table uses the method name as the unique value, and method symbols with the same name are recorded in the same list. The method symbol contains information such as the actual POU to which the method belongs and whether it is a virtual method.

[0063] Step 5: The compilation module traverses and parses the POUs involved in the compilation, generates a syntax tree and symbol information, and associates the function call symbol information with the function call nodes. It then traverses the syntax tree to generate binary instructions.

[0064] When analyzing the interface variable assignment syntax ITF:=inst_FB2;, this invention employs a two-step assignment method, such as... Figure 7 As shown: The first step is to assign the THIS parameter value of instance inst_FB2 to ITF.THIS. The THIS of inst_FB2 records the starting address of the variable inst_FB2. The child variables of inst_FB2 are located by inst_FB2.THIS + the relative offset between the child variable and inst_FB2.

[0065] The second step is to set the ITF type to the INTERFACE_2 interface type. FB2 implements the INTERFACE_2 interface. The offset of the first method address slot of INTERFACE_2 is assigned to ITF.ADDR_OFFSET, that is, the starting address offset of the address slot of FB2.itf_method1 is assigned to ITF.ADDR_OFFSET. When calling other methods of INTERFACE_2 through ITF, the offset is calculated based on ITF.ADDR_OFFSET and the slot difference between the target method and the first method.

[0066] When processing interface variable assignment statements, check whether the rvalue instance implements the target interface. If FB2 does not implement INTERFACE_2, a compilation error will occur.

[0067] Example of FB call syntax: inst_FB2(); When processing instance call statements, the offset of the starting address of the FB2 instance variable inst_FB2 relative to the variable area is passed to the logical parameter THIS of FB2. Other variables of FB2 calculate their actual offsets based on the THIS value and the offset of the variable relative to the first child variable of FB2.

[0068] Example of a method call in FB2 logic code: itf_method1(); When calling the `itf_method1` method, `FB2_THIS` is passed as an implicit parameter to the method so that the method can access variables of the parent FB. Variables defined within the method do not have fixed addresses and reside on the stack.

[0069] Method invocation decision: This invention employs a compile-time immediate decision-making strategy. The decision is based on information recorded in the method symbol table, such as the method definition's POU and whether the method is a virtual method.

[0070] The FB2 method symbol table contains two itf_method1 symbols: FB2.itf_method1 and FB1.itf_method1, which are virtual methods. Since the method is virtual, calling itf_method1() in FB1 or FB2 will actually call FB2.itf_method1. If FB2.itf_method1 and FB1.itf_method1 are not virtual methods, then calling itf_method1 in FB1 will actually call FB1.itf_method1, and calling itf_method1 in FB2 will actually call FB2.itf_method1.

[0071] Step 6: The linking module integrates and generates the final logical binary file.

[0072] The compiler header, variable area, binary code address record area, and binary code area are gradually implemented into the compiler file. The compiler header records the starting address and length information of each area so that the system can correctly parse the target file at runtime.

[0073] like Figure 8 As shown, this invention also proposes an object-oriented logic configuration compilation system for implementing the above-mentioned object-oriented logic configuration compilation method. The system includes: The program organization unit collection module is used to collect the POUs participating in the compilation based on the task information of the target compilation device; The data type acquisition module is used to obtain the variables involved in the compilation based on the target compilation device and the POU involved in the compilation, and to obtain the data type of the variables involved in the compilation based on the variables involved in the compilation. The address allocation module is used to allocate addresses to variables participating in compilation based on their data types. The information generation module is used to generate function call symbol information based on the pre-allocated tasks, the POUs involved in compilation, and the address slots of their methods; The instruction generation module is used to traverse and parse the POUs involved in compilation, generate a syntax tree and symbol information, associate the function call symbol information with the function call nodes, construct a function call syntax tree, traverse the syntax tree, and generate binary instructions. The linker module is used to integrate the POUs involved in the compilation and the generated binary instructions to obtain the final logical binary file, thus completing the compilation of the logical configuration.

[0074] The beneficial effects of this invention are that, compared with the prior art, this invention generates binary files that are still compatible with the original proprietary format by only modifying the compiler and without changing the runtime system. The runtime system can parse OOP logic without any modification, and it is compatible with the original hardware and retains real-time performance.

[0075] This disclosure can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for causing a processor to implement various aspects of this disclosure.

[0076] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0077] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0078] Computer program instructions used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing the status information of the computer-readable program instructions to implement various aspects of this disclosure.

[0079] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. An object-oriented logic configuration compilation method, characterized in that, Includes the following steps: Based on the task information of the target compilation device, collect the program organization units that participate in the compilation; Obtain the variables involved in compilation based on the target compilation device and the program organization unit involved in compilation, and obtain the data type of the variables involved in compilation based on the variables involved in compilation; The compiler allocates memory addresses for variables that participate in the compilation process based on their data types. Based on the pre-assigned tasks, the program organization units involved in compilation, and the address slots of their methods, function call symbol information is generated; The compiler traverses and parses all program organization units involved in compilation, generates a syntax tree and symbol information, associates the function call symbol information with function call nodes, constructs a function call syntax tree, traverses the syntax tree, and generates binary instructions. The program organization units involved in the compilation and the generated binary instructions are integrated to obtain the final logical binary file, thus completing the compilation of the logical configuration.

2. The object-oriented logic configuration compilation method according to claim 1, characterized in that, The collection of program organization units participating in compilation specifically includes: Based on the task information of the target compilation device, the program organization units mounted under each task and other program organization units they reference are used as program organization units participating in the compilation.

3. The object-oriented logic configuration compilation method according to claim 1, characterized in that, The variables obtained based on the target compilation device and the program organization unit involved in compilation include: all variables of the program type and program organization unit, and all variables in the variable table of the target compilation device.

4. The object-oriented logic configuration compilation method according to claim 3, characterized in that, The data types of the variables include: basic data types and user-defined data types; Among them, the basic data types are those defined in the IEC61131-3 international standard; the custom data types include structures, arrays, enumerations, unions, and the function block types corresponding to each function block type program organization unit.

5. The object-oriented logic configuration compilation method according to claim 1, characterized in that, The address allocation for variables involved in compilation specifically includes: Iterate through the variables involved in compilation and allocate global address space for the variables according to their types and byte alignment requirements. The alignment requirement for basic data types is to match the byte length of that type. The alignment requirement for custom data types is the maximum value among the alignment requirement values ​​of each sub-member of that type.

6. The object-oriented logic configuration compilation method according to claim 3, characterized in that, The address slots of the pre-allocated tasks, program organization units, and their methods generate function call symbol information, specifically including: Create a binary instruction address record area, and allocate address slots in the binary instruction address record area. Each address slot occupies a fixed length of address unit. Each task in the device is assigned a 4-byte address slot in sequence, and function symbol information is created for each task. The symbol information records the relative offset of the starting position of the address slot of the corresponding task in the binary instruction address record area. Traverse the program organization units participating in the compilation and allocate an address slot for each participating program organization unit. If the participating program organization unit is of type FB, after allocating the address slot for the participating program organization unit, start allocating address slots for the methods of the participating program organization unit according to the method address allocation principle, starting from the slot after the address slot of the participating program organization unit.

7. The object-oriented logic configuration compilation method according to claim 6, characterized in that, The address allocation principle of the method is as follows: The methods of the interfaces implemented by this FB type are listed first, followed by other methods; If the number of interfaces implemented by the FB type is greater than 1, the methods of the implemented interfaces will be grouped according to the interfaces, including: grouping the methods declared by the same interface into one group, and arranging the interface groups according to the order in which the FB implements the interfaces, with the group of methods of the interfaces implemented first being arranged first. The order of methods within the same interface includes: following the order of method declarations when defining the interface, and maintaining the order consistent with the interface prototype.

8. The object-oriented logic configuration compilation method according to claim 1, characterized in that, When associating the function call symbol information with the function call node, specifically when associating the symbol information and call node of the FB method, the following is included: Extract key information, which includes: the name of the method being called, the FB type of the instance currently being analyzed, and the FB type to which the method currently being analyzed belongs; Based on the method name and FB type information in the key information, search the symbol table for a list of matching method symbols; Based on the program organization unit information to which the method belongs and the virtual method flag, determine the unique and correct method symbol; When associating symbolic information and calling nodes of program organization units, a unique program organization unit symbol is determined based on the name of the program organization unit for association.

9. The object-oriented logic configuration compilation method according to claim 1, characterized in that, The constructed function call syntax tree specifically includes: When constructing the program organization unit call syntax tree, if the program organization unit type is PRG, then it is not necessary to construct parameter nodes; If the program's organizational unit type is FB, then parameter nodes need to be constructed, including passing the starting address of the FB instance variable to a hidden variable of the FB, associating the FB call node and parameter node, and completing the syntax tree construction of the FB call. If the program organization unit is of type FUN, parameter nodes need to be built for the input and output variables of FUN, and the FUN call node and each parameter node are associated in sequence to complete the construction of the syntax tree of FUN call; When constructing the syntax tree for FB's method calls, parameter nodes need to be built for the method's input and output variables, and another parameter node needs to be built to pass the aforementioned hidden variables of the FB instance. The method call node and parameter node are then linked in sequence to complete the construction of the syntax tree for the method calls.

10. An object-oriented logic configuration compilation system, used to implement the object-oriented logic configuration compilation method according to any one of claims 1-9, characterized in that, include: The program organization unit collection module is used to collect the program organization units participating in the compilation based on the task information of the target compilation device; The data type acquisition module is used to obtain the variables involved in compilation based on the target compilation device and the program organization unit involved in compilation, and to obtain the data type of the variables involved in compilation based on the variables involved in compilation. The address allocation module is used to allocate addresses to variables participating in compilation based on their data types. The information generation module is used to generate function call symbol information based on the pre-allocated tasks, the program organization units involved in compilation, and the address slots of their methods. The instruction generation module is used to traverse and parse the program organization units involved in compilation, generate a syntax tree and symbol information, associate the function call symbol information with the function call nodes, construct a function call syntax tree, traverse the syntax tree, and generate binary instructions; The linker module is used to integrate the program organization units involved in compilation and the generated binary instructions to obtain the final logical binary file, thus completing the compilation of the logical configuration.

11. A terminal, comprising a processor and a storage medium; characterized in that: The storage medium is used to store instructions; The processor is configured to operate according to the instructions to perform the steps of the method according to any one of claims 1-9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1-9.

Images