Call format conversion device, PLC programming device, call format conversion program, and recording medium

Abstract

The present invention makes it possible to easily maintain an ST source file even when performing development in which two types of statements exist in the ST source file.　This call format conversion device comprises: an input unit that receives an argument format and a conversion target; an acquisition unit that reads an ST source file prior to conversion; an ST source file parser unit that has at least syntactic analysis and semantic analysis functions; a POU call management unit that manages argument information and call information with a function / function block definition output by the ST source file parser unit; and an output unit that outputs the ST source file after conversion. The ST source file parser unit performs syntactic analysis and semantic analysis on the ST source file that has been read and outputs, to the POU call management unit, call information and argument information of a function block definition and a function definition. The POU call management unit converts the received argument format on the basis of an argument designation in the call information and causes the output unit to output the ST source file after conversion.

Description

Technical Field

[0001] The present invention relates to a call format conversion device for converting the argument format of functions in an ST source file, a PLC programming device, a call format conversion program, and a recording medium.

Background Art

[0002] In a PLC (Programmable Logic Controller) program, a technique for facilitating the analysis of a user program including a call instruction is known. For example, see Patent Document 1. Also, as a PLC programming method, the ST (Structured Text) language is standardized in IEC61131-3. In IEC61131-3, functions and function blocks are used as means for componentizing a program (POU: Program Organization Unit). Specifically, first, the POU which is a function definition and a function block definition in the ST language will be described. FIG. 20 is a diagram showing an example of an ST source file. FIG. 21 is a diagram showing an example of an ST source file called by the ST source file of FIG. 20. Note that the ST source file of FIG. 20 is a POU of a function block definition and is also referred to as a "calling side POU". Also, the ST source file of FIG. 21 is a POU of a function definition and is also referred to as a "called side POU". As shown in FIG. 21, the called side POU is composed of a "name" for identifying a program, a function, etc., a "variable definition" consisting of the arguments, return value, and internal variables of the POU, and a "processing definition" for describing the processing content of the POU. The called side POU of FIG. 21 can be called from the "processing definition" of the calling side POU of FIG. 20. Note that the "processing definition" of the called side POU of FIG. 21 omits the processing content. Furthermore, the calling POU and the called POU may be described in a single ST source file, or they may be described in separate ST source files. [Prior art documents] [Patent Documents]

[0003] [Patent Document 1] Japanese Patent Publication No. 2021-026642 [Overview of the Initiative] [Problems that the invention aims to solve]

[0004] In the ST language, there are two ways to call functions and function blocks: abbreviated calls and formal calls. In a calling POU defined by the standardized ST language as shown in Figure 22A, when calling the called POU's BETA using a shorthand call, all arguments are written in the order they are defined, such as "ret:=BETA(1.5,0.2);". On the other hand, when calling the BETA function of the called POU in the ST language using a formal call, the argument names and their assigned values ​​are written as "ret:=BETA(X:=1.5,Y:=0.2);". However, in formal calls, this is not the only way; they can also be written in any order, such as "ret:=BETA(Y:=0.2,X:=1.5);". Furthermore, in formal calls, the argument names and assigned values ​​may be omitted, such as "ret:=BETA(X:=1.5);". In this case, the value of argument "Y" will be the initial value "0.0", as shown in Figure 22A. Also, in formal calls, all argument names and assigned values ​​may be omitted, such as "ret:=BETA();". In this case, the values ​​of arguments "X" and "Y" will be the initial values ​​"1.0" and "0.0", as shown in Figure 22A. However, when multiple programmers are involved in development, if the calling POU uses different notation methods—short and formal—as described above, it becomes inconsistent and difficult to maintain. Furthermore, while it's necessary to standardize the coding style to make maintenance easier, modifying a large amount of source code is time-consuming, prone to errors, and could potentially lead to bugs.

[0005] Furthermore, when using either of the two description methods described above for calling a called POU from a calling POU in a program created using the ST language, careful attention is required during programming, which adds to the programmer's burden. For example, as shown in Figure 22B, when calling the BETA of the called POU in Figure 22A, if the argument "S", which does not have an initial value set, is defined first in the argument definition of the called POU's BETA, care must be taken to ensure that the parameters are specified correctly in the order they are defined when using abbreviated calling. That is, if you write "ret:=BETA(vx,vy,vs);" in abbreviated calling, the values ​​of "vx", "vy", and "vs" will be assigned to the arguments "S", "X", and "Y" respectively, resulting in a result different from the intended one. Furthermore, care must be taken to ensure that arguments that should be specified in a formal call are not unintentionally omitted. For example, if you write "ret:=BETA(X:=vx,Y=:vy);" in a formal call, it will compile, but while the values ​​of "vx" and "vy" will be assigned to the arguments "X" and "Y", an undefined value will be assigned to the argument "S", potentially leading to unintended behavior.

[0006] Therefore, it is desirable that ST source files created using the ST language can be easily maintained even when development involves a mix of two different methods for calling functions and function blocks: abbreviated calls and formal calls. [Means for solving the problem]

[0007] (1) One embodiment of the call format conversion device of the present disclosure is a call format conversion device having an argument description format conversion function, comprising: an input unit that accepts an argument format and a target for conversion; an acquisition unit that reads an ST source file before conversion; an ST source file parser unit that has at least syntactic analysis and semantic analysis functions; a POU call management unit that manages argument information and call information from function and function block definitions output by the ST source file parser unit; and an output unit that outputs the converted ST source file, wherein the ST source file parser unit performs syntactic analysis and semantic analysis on the ST source file read by the acquisition unit, outputs argument information and call information of function definitions and function block definitions to the POU call management unit, the POU call management unit converts to the argument format accepted from the input unit based on the argument specification in the call information, and causes the output unit to output the converted ST source file.

[0008] (2) One embodiment of the PLC programming device of the present disclosure comprises the call format conversion device of (1).

[0009] (3) One aspect of the call format conversion program of the present disclosure is a call format conversion program that causes a computer to function as a call format conversion device having an argument description format conversion function, comprising: an input unit that accepts argument format and a target for conversion; an acquisition unit that reads an ST source file before conversion; an ST source file parser unit that has at least syntactic analysis and semantic analysis functions; a POU call management unit that manages argument information and call information from function and function block definitions output by the ST source file parser unit; and an output unit that outputs the converted ST source file, wherein the ST source file parser unit performs syntactic analysis and semantic analysis on the ST source file read by the acquisition unit, outputs argument information of function definitions and function block definitions and function call information to the POU call management unit, the POU call management unit converts to the argument format accepted by the input unit based on the argument specification in the call information, and causes the output unit to output the converted ST source file.

[0010] (4) One embodiment of the recording medium of the present disclosure is a computer-readable recording medium that records a call format conversion program which causes a computer to operate as a call format conversion device having an argument description format conversion function, comprising: an input unit that accepts an argument format and a target for conversion; an acquisition unit that reads an ST source file before conversion; an ST source file parser unit that has at least syntactic analysis and semantic analysis functions; a POU call management unit that manages argument information and call information from function and function block definitions output by the ST source file parser unit; and an output unit that outputs the converted ST source file, wherein the ST source file parser unit performs syntactic analysis and semantic analysis on the ST source file read by the acquisition unit, outputs argument information of function definitions and function block definitions and function call information to the POU call management unit, the POU call management unit converts the argument information to the argument format accepted by the input unit based on the argument specification in the call information, and the output unit outputs the converted ST source file. [Brief explanation of the drawing]

[0011] [Figure 1] This is a functional block diagram showing an example of the functional configuration of the call format conversion system according to the first embodiment. [Figure 2] This figure shows an example of the display screen of the calling POU shown in Figure 20 on the display unit. [Figure 3] This figure shows an example of the conversion range specified in the calling POU in Figure 2. [Figure 4] This figure shows an example of specifying the argument format after conversion. [Figure 5] This figure shows an example of the argument information for the called POU in Figure 19. [Figure 6] This figure shows an example of call information for the calling POU in Figure 18. [Figure 7] This figure shows an example of a calling POU. [Figure 8] This figure shows an example of call information for the calling POU in Figure 7. [Figure 9] It is a diagram showing an example of argument information of a called POU called by a calling-side POU in FIG. 7. [Figure 10] It is a diagram showing an example of the specification of a conversion target range and an argument format. [Figure 11] It is a diagram showing an example of a calling-side POU converted to a short call. [Figure 12] It is a diagram showing an example of call information of a calling-side POU in FIG. 11. [Figure 13] It is a diagram showing an example of the specification of a conversion target range and an argument format. [Figure 14] It is a diagram showing an example of a calling-side POU converted to a formal call. [Figure 15] It is a flowchart for explaining the conversion process of a call format conversion system. [Figure 16] It is a flowchart for explaining the call format conversion process shown in FIG. 15. [Figure 17] It is a functional block diagram showing a functional configuration example of a call format conversion system according to the second embodiment. [Figure 18] It is a diagram showing an example of a display screen when argument interpolation is selected as the argument format after conversion. [Figure 19] It is a flowchart for explaining the call format conversion process shown in FIG. 15. [Figure 20] It is a diagram showing an example of an ST source file. [Figure 21] It is a diagram showing an example of an ST source file called by the ST source file in FIG. 21. [Figure 22A] It is a diagram showing an example of an ST source file of a function definition. [Figure 22B] It is a diagram showing an example of the ST source file in FIG. 22A in which the argument definition is changed.

Mode for Carrying Out the Invention

[0012] <First Embodiment> First, the outline of this embodiment will be described. In this embodiment, the argument format and the target to be converted (conversion range) are accepted, the ST source file before conversion is read, syntactic analysis and semantic analysis are performed on the read ST source file, argument information and call information of the function definition and function block definition are output, the arguments of the ST source file are converted to the accepted argument format based on the argument specification in the call information, and the converted ST source file is output. As a result, according to this embodiment, even when development is carried out in which two different types of descriptions, abbreviated and formal, are mixed in the ST source files created using the ST language, maintenance of the ST source files can be easily performed. The above is an overview of this embodiment.

[0013] Next, the configuration of the first embodiment will be described in detail with reference to the drawings. Figure 1 is a functional block diagram showing an example of the functional configuration of the call format conversion system according to the first embodiment. As shown in Figure 1, the call format conversion system 1 includes a call format conversion device 10 and a PLC programming device 20. The call format conversion device 10 and the PLC programming device 20 may be directly connected to each other via a connection interface (not shown). Alternatively, the call format conversion device 10 and the PLC programming device 20 may be interconnected via a network (not shown), such as a LAN (Local Area Network). In this case, the call format conversion device 10 and the PLC programming device 20 may be equipped with a communication unit (not shown) for communicating with each other via such connection. Although the call format conversion device 10 is described as a separate device from the PLC programming device 20, it may be included in the PLC programming device 20, as will be described later.

[0014] The PLC programming device 20 is a known computer device that creates a PLC program (not shown) in ST language based on user operations. The PLC programming device 20 may also send the created PLC program to the PLC (not shown) and have it executed by the PLC. In addition, the PLC programming device 20 may output the created PLC program (ST source file) along with at least one function, function block, and converted argument format specified by the user to be converted, to the call format conversion device 10 described later, in order to convert the argument format in the created PLC program.

[0015] The call format conversion device 10 is a known computer device and includes a control unit 11, a display unit 12, an input unit 13, and a storage unit 14. The control unit 11 includes an acquisition unit 110, an ST source file parser unit 111, a POU call management unit 112, and an output unit 113.

[0016] <Display section 12> The display unit 12 is, for example, a liquid crystal display. The display unit 12 displays, for example, the ST source file acquired by the acquisition unit 110, which will be described later.

[0017] <Input section 13> The input unit 13 is, for example, a keyboard, a mouse, or a touch panel located on the display unit 12, and accepts input from the user. For example, based on the user's input, the input unit 13 accepts the scope of the call statement to be converted in the called POU in the ST source file (calling POU), and the format of the converted arguments. Figure 2 shows an example of the display screen 40 of the calling POU shown in Figure 20, as displayed on the display unit 12. Based on user operations, the input unit 13 accepts the scope of the call statement to be converted, as shown in Figure 3, by specifying the call statement of the called POU to be converted, which is shown as a shaded rectangle in the calling POU of Figure 2. Furthermore, the input unit 13 displays a context menu 50 on the display unit 12, as shown in Figure 4, based on user operations such as right-clicking with a mouse (not shown). Based on user operations, the input unit 13 accepts the specification of the converted argument format by, for example, selecting "abbreviated call conversion" from "refactoring" in the context menu 50. The input unit 13 outputs the accepted conversion range and argument format to the POU call management unit 112, which will be described later. Here, "formal call conversion" and "abbreviated call conversion" will be described in detail when the POU call management unit 112 is explained later.

[0018] The input unit 13 may accept two or more call statements from called POUs as the scope for conversion based on user operations. Furthermore, the call format conversion device 10 may accept a PLC program (calling POU), the range of the call statement to be converted for the called POU to be converted, and the argument format from the PLC programming device 20 based on the user's operation of the PLC programming device 20.

[0019] <Storage section 14> The storage unit 14 may be an SSD (Solid State Drive) or HDD (Hard Disk Drive), and may store ST source files for operating a PLC device (not shown). The storage unit 14 may also include RAM (Random Access Memory) and store argument information and call information for function definitions and function block definitions, which are generated by the ST source file parser unit 111 (described later) and managed by the POU call management unit 112.

[0020] <Control Unit 11> The control unit 11 includes a CPU (Central Processing Unit), ROM (Read Only Memory), RAM, CMOS (Complementary Metal-Oxide-Semiconductor) memory, etc., which are configured to communicate with each other via a bus, and are known to those skilled in the art. The CPU is a processor that controls the entire call format conversion device 10. The CPU reads the system program and application program stored in ROM via the bus and controls the entire call format conversion device 10 according to the system program and application program. As a result, as shown in Figure 1, the control unit 11 is configured to realize the functions of the acquisition unit 110, the ST source file parser unit 111, the POU call management unit 112, and the output unit 113. Various data such as temporary calculation data and display data are stored in the RAM. The CMOS memory is backed up by a battery (not shown) and is configured as a non-volatile memory that retains its memory state even when the power to the processing program editing device 1 is turned off.

[0021] As described above, when the input unit 13 receives the range to be converted and the argument format, it outputs them to the POU call management unit 112. The range to be converted indicates the range of call statements to be converted within the ST source file (calling POU). The argument format indicates the argument description format to be changed in the called POU of the call statements within the range to be converted (for example, whether to change to abbreviated call format or formal call format).

[0022] The acquisition unit 110 reads, for example, the ST source file before conversion from the storage unit 14. Alternatively, the acquisition unit 110 may acquire the PLC program (ST source file before conversion) from the PLC programming device 20 as an external storage device.

[0023] The ST source file parser unit 111 performs lexical analysis, syntactic analysis, and semantic analysis on the read ST source file. Based on the analysis results, it refers to the argument information (e.g., argument type, argument name, argument type, argument initial value, definition order) from the variable definitions (e.g., input arguments, output arguments, input / output arguments, etc.) of the called POU in the ST source file, and outputs it to the POU call management unit 112. Furthermore, the ST source file parser unit 111 outputs the call information of the calling POU (for example, the POU call location, the calling POU name, the argument format indicating whether it is a formal or abbreviated call, and the argument specifications) to the POU call management unit 112.

[0024] Specifically, the ST source file parser unit 111 performs lexical analysis, syntactic analysis, and semantic analysis of the calling POU in Figure 20 and the called POU in Figure 21, for example, using known compilation techniques. Based on the analysis results, the ST source file parser unit 111 creates argument information from the input arguments (VAR_INPUT), output arguments (VAR_OUTPUT), and input / output arguments (VAR_IN_OUT) of the variable definitions in the called POU in Figure 21. Figure 5 shows an example of the argument information for the called POU in Figure 19. As shown in Figure 5, the argument information has storage areas for "argument type," "argument name," "argument type," "initial value," and "definition order." The "Argument Type" field within the argument information stores input arguments (VAR_INPUT), output arguments (VAR_OUTPUT), and input / output arguments (VAR_IN_OUT), respectively. The "Argument Name" in the argument information stores the "inVal", "outVal", and "ioVal" values ​​set in the argument definition of the called POU in Figure 21. The "Argument Type" field within the argument information stores the data types of the respective arguments: "inVal", "outVal", and "ioVal". The "initial value" in the argument information stores the initial value that would be set if the arguments "inVal", "outVal", and "ioVal" were omitted in a formal call. Specifically, if the argument "inVal" is omitted in a formal call, it is set to "100". As shown in Figure 7, the initial values ​​for the arguments "outVal" and "ioVal" are blank "-". In this case, if the arguments "outVal" and "ioVal" are omitted in a formal call, the default values ​​assigned to the "argument type" are set. IEC61131-3 standardizes the default value for WORD type to be "16#0000" and the default value for STRING type to be "'' (empty string)". The "Definition Order" in the argument information indicates the order in which the arguments "inVal", "outVal", and "ioVal" are defined in the called POU shown in Figure 21.

[0025] Furthermore, the ST source file parser unit 111 generates call information, including the POU call position, calling POU name, argument format, and argument specification of the called POU in Figure 21, based on the processing definition in the calling POU in Figure 20, according to the analysis results. Figure 6 shows an example of call information for the calling POU in Figure 20. As shown in Figure 6, the call information has storage areas for "POU call location," "calling POU name," "argument format," and "argument specification." The "POU call position" in the call information stores the position (for example, "10th line, 2nd character") where the calling POU in Figure 20 calls the called POU in Figure 21. The "Calling POU Name" in the call information stores the function name "MyFunc" of the called POU in Figure 21. The "Argument Format" in the call information stores the argument description format of the called POU in Figure 21 (for example, "Formal Call") in the calling POU's processing definition in Figure 20. The "Argument Specification" field within the call information stores the description of the arguments of the called POU in Figure 21, as shown in the processing definition of the calling POU in Figure 5. The ST source file parser unit 111 then outputs the call information of the generated calling POU and the argument information of the called POU to the POU call management unit 112.

[0026] Note that the call information for the calling POU and the argument information for the called POU are presented in tabular format, as shown in Figures 7 and 8, but are not limited to this format; any data format other than tabular format is also acceptable.

[0027] The POU call management unit 112 manages the call information of the calling POU and the argument information of the called POU, which are generated by the ST source file parser unit 111, in the storage unit 14. Based on the argument information and call information, the POU call management unit 112 converts the arguments of the called POU within the conversion target range of the calling POU, which are received by the input unit 13, into the argument format received based on the argument specification in the call information. The following describes the operation of the POU call management unit 112 in cases where the received argument format is (a) an abbreviated call and (b) a formal call.

[0028] (a) When the accepted argument format is an abbreviated call The operation of the POU call management unit 112 in this case will be explained using an example where, in the calling POU (ST source file) shown in Figure 7, acquired by the acquisition unit 110, the call statement of one of the called POUs in the formal call is specified as the scope to be converted. Note that the call information of the calling POU in Figure 7 is shown in Figure 8, and the argument information of the called POU is shown in Figure 9, and these are stored in the storage unit 14, respectively. As shown in Figure 10, the POU call management unit 112 receives the range to be converted and the argument format for the abbreviated call conversion from the input unit 13 based on the user's operation. Based on the "argument specification" in the call information in Figure 8 and the "argument name" in the argument information in Figure 9, the POU call management unit 112 determines that the arguments "sign" and "high" are omitted in the calling POU in Figure 7. The POU call management unit 112 obtains the initial values ​​"255" and "10.0" for the omitted arguments "sign" and "high" from the "initial values" in the argument information in Figure 9. Based on the "argument specification" in the call information in Figure 8, the POU call management unit 112 deletes the argument name and assignment operator, and supplements the initial values ​​for the omitted arguments "sign" and "high" according to the "definition order" in the argument information in Figure 9, converting the calling POU to an abbreviated call as shown in Figure 11.

[0029] (b) If the accepted argument format is a formal call The operation of the POU call management unit 112 in this case will be explained using an example where, in the calling POU (ST source file) shown in Figure 11, acquired by the acquisition unit 110, the call statement of one called POU in a simplified call is specified as the scope to be converted. Note that the call information of the calling POU in Figure 11 is as shown in Figure 12 and is stored in the storage unit 14. The argument information of the called POU is the same as in the case of Figure 9. As shown in Figure 13, the POU call management unit 112 receives the range to be converted and the argument format of the formal call conversion from the input unit 13 based on the user's operation. Based on the "argument specification" of the call information in Figure 12 and the "argument name" of the argument information in Figure 9, the POU call management unit 112 determines that the calling POU has the arguments "in", "Bits", "sign", "low", and "high". Based on the "definition order" of the argument information in Figure 9, the POU call management unit 112 completes the assignment operators for each of the arguments "in", "Bits", "sign", "low", and "high", and converts the calling POU into a formal call as shown in Figure 14.

[0030] The output unit 113 outputs and stores the ST source file of the calling POU, whose argument format has been converted by the POU call management unit 112, to the storage unit 14. Furthermore, if the output unit 113 obtains an ST source file from the PLC programming device 20, it may output the converted ST source file to the PLC programming device 20 as an external storage device.

[0031] <Conversion process of call format conversion system 1> Next, referring to Figure 15, the conversion process flow of the call format conversion system 1 will be explained. Figure 15 is a flowchart illustrating the conversion process of the call format conversion system 1.

[0032] In step S1, the acquisition unit 110 reads the ST source file before conversion from the storage unit 14.

[0033] In step S2, the ST source file parser unit 111 performs lexical analysis, syntactic analysis, and semantic analysis on the ST source file read in step S1.

[0034] In step S3, the ST source file parser unit 111 generates argument information from the variable definitions of the called POU based on the analysis results of step S2, and outputs the generated argument information to the POU call management unit 112.

[0035] In step S4, the ST source file parser unit 111 generates call information that calls the called POU from the calling POU's processing definition based on the analysis results in step S2, and outputs the generated call information to the POU call management unit 112.

[0036] In step S5, the POU call management unit 112 obtains the scope of conversion and the argument format after conversion of the ST source file (calling POU) obtained from the user in step S1 via the input unit 13.

[0037] In step S6, the POU call management unit 112 performs a call format conversion process based on the conversion target range and argument format obtained in step S5, and converts the argument description of the ST source file (calling side POU) within the conversion target range. The detailed flow of the call format conversion process will be described later.

[0038] In step S7, the output unit 113 outputs the converted ST source file to the storage unit 14 and stores it.

[0039] Figure 16 is a flowchart illustrating the detailed processing steps of the call format conversion process shown in step S6 in Figure 15.

[0040] In step S61, the POU call management unit 112 obtains call information from the storage unit 14 for the calling POU that calls one of the called POUs within the conversion range acquired in step S5.

[0041] In step S62, the POU call management unit 112 determines whether or not there is any call information for the calling POU obtained in step S61. If there is no call information for the calling POU, the call format conversion process in step S6 is terminated, and the process moves to step S7 in Figure 17. On the other hand, if there is call information for the calling POU, the process moves to step S63.

[0042] In step S63, the POU call management unit 112 obtains the argument information of the called POU from the storage unit 14 based on the "calling POU name" of the calling POU call information obtained in step S61.

[0043] In step S64, the POU call management unit 112 determines whether the argument format obtained in step S5 is a formal call or not. If the argument format is a formal call, the process moves to step S65. On the other hand, if the argument format is an abbreviated call, the process moves to step S66.

[0044] In step S65, the POU call management unit 112 completes the argument information by adding the argument name and assignment operator based on the argument specification in the call information, and converts the arguments of the call statement of the calling POU into a formal call.

[0045] In step S66, the POU call management unit 112 deletes the argument names and assignment operators based on the "argument specification" in the call information, and adds initial values ​​for the omitted arguments in the order of definition, thereby converting the arguments of the calling POU's call statement into a short-form call.

[0046] In step S67, the POU call management unit 112 obtains the call information of the calling POU that calls the next called POU in the call statement within the range to be converted. The process returns to step S62.

[0047] As described above, the call format conversion device 10 according to the first embodiment makes it easy to maintain the ST source file even when development is carried out in which two different types of descriptions, abbreviated calls and formal calls, are mixed in the ST source file created in the ST language as the method of calling functions and function blocks. Furthermore, the call format conversion device 10 automatically performs the task of unifying the argument format, thus saving time and avoiding errors. Furthermore, the call format conversion device 10 can prevent description errors by switching between two types of description methods, thereby reducing the burden on the user. In other words, the user can easily confirm whether the parameters are specified in the intended order in the abbreviated call, and can also easily confirm whether any arguments that should be specified in the formal call have been omitted. The first implementation form has now been explained.

[0048] <Second Embodiment> Next, a second embodiment will be described. In the first embodiment, the call format conversion device 10 receives the argument format and the conversion target (conversion target range), reads the ST source file before conversion, performs syntactic and semantic analysis on the read ST source file, outputs argument information and call information for the function definition and function block definition, converts the arguments of the ST source file to the accepted argument format of a formal call or abbreviated call based on the argument specification in the call information, and outputs the converted ST source file. In contrast, the second embodiment differs from the first embodiment in that the call format conversion device 10A accepts argument interpolation as well as formal calls and abbreviated calls as arguments after conversion. As a result, the call format conversion device 10A according to the second embodiment makes it easy to maintain the ST source file even when development is carried out in which two different types of descriptions, abbreviated and formal, are mixed in the ST source file created in the ST language, and programmers can easily check for any missing specifications by comparing the state before and after conversion. The second embodiment will be described below.

[0049] Figure 17 is a functional block diagram showing an example of the functional configuration of the call format conversion system according to the second embodiment. Elements having the same functions as those in the call format conversion system 1 of Figure 1 are denoted by the same reference numerals, and detailed explanations are omitted. As shown in Figure 17, the call format conversion system 1 according to the second embodiment includes a call format conversion device 10A and a PLC programming device 20. The PLC programming device 20 has the same functions as the PLC programming device 20 in the first embodiment.

[0050] The call format conversion device 10A includes a control unit 11a, a display unit 12, an input unit 13, and a storage unit 14. The control unit 11a includes an acquisition unit 110, an ST source file parser unit 111, a POU call management unit 112a, and an output unit 113. The display unit 12, input unit 13, and storage unit 14 have the same functions as the display unit 12, input unit 13, and storage unit 14 in the first embodiment.

[0051] <Control Unit 11a> The control unit 11a includes a CPU, ROM, RAM, CMOS memory, etc., which are configured to communicate with each other via a bus, and are known to those skilled in the art. The CPU is a processor that controls the entire call format conversion device 10A. The CPU reads the system program and application program stored in ROM via the bus and controls the entire call format conversion device 10A according to the system program and application program. As a result, as shown in Figure 17, the control unit 11a is configured to realize the functions of the acquisition unit 110, the ST source file parser unit 111, the POU call management unit 112a, and the output unit 113. The acquisition unit 110, the ST source file parser unit 111, and the output unit 113 have the same functions as the acquisition unit 110, the ST source file parser unit 111, and the output unit 113 in the first embodiment.

[0052] When the input unit 13 receives argument interpolation from the user in argument format, the POU call management unit 112a first converts the arguments of the ST source file before conversion to the abbreviated call argument format, and then converts the ST source file arguments converted to the abbreviated call argument format to the formal call argument format. Specifically, the POU call management unit 112a may, for example, as shown in Figure 18, allow the user to perform operations such as right-clicking with a mouse (not shown) on the display screen 40 of the calling POU in Figure 7, and accept "argument interpolation" as the argument format after conversion in the context menu 50 displayed on the specified conversion target range. When the POU call management unit 112a receives argument interpolation as the argument format, it first deletes the argument names and assignment operators from the call statement of the calling POU that calls the called POU in the range to be converted, based on the "argument specification" in the call information of Figure 8, similar to the case where the received argument format in the first embodiment is an abbreviated call. The POU call management unit 112a then interpolates the initial values ​​of the omitted arguments "sign" and "high" according to the "definition order" of the argument information of Figure 9, and converts the calling POU to an abbreviated call as shown in Figure 11. Next, the POU call management unit 112a, in the same way as in the case of a formal call in the first embodiment, converts the call statement of the calling POU, which has been converted to a shorthand call in Figure 11, to arguments such as "in" and assignment operators based on the "argument specification" in the call information in Figure 12 and the "argument name" in the argument information in Figure 9. The POU call management unit 112a converts the calling POU in Figure 7 to a formal call, as shown in Figure 14. By doing so, even if the calling POU in Figure 7 is standardized to either a formal or informal call, if variables in the called POU are added or changed, the user can check for any missing specifications by selecting "Argument Interpolation" and comparing the values ​​before and after the conversion.

[0053] <Conversion process of call format conversion system 1> The conversion process of the call format conversion system 1 is the same as in Figure 15, and therefore the explanation is omitted. However, the call format conversion process in step S6 is further modified by adding argument interpolation, as shown in Figure 19. The processes in steps S61 to S63 and steps S65 to S67 are the same as those in steps S61 to S63 and steps S65 to S67 in Figure 16, and therefore their explanation is omitted.

[0054] In step S64a, the POU call management unit 112a determines whether the argument format obtained in step S5 is a formal call or not. If the argument format is a formal call, the process moves to step S65. On the other hand, if the argument format is not a formal call, the process moves to step S68.

[0055] In step S68, it is determined whether the argument format obtained in step S5 is an abbreviated call or not. If the argument format is an abbreviated call, the process moves to step S66. On the other hand, if the argument format is argument interpolation, the process moves to step S69.

[0056] In step S69, the POU call management unit 112a first converts the arguments of the calling POU into the abbreviated call argument format, and then converts the arguments of the calling POU converted into the abbreviated call argument format back into the formal call argument format.

[0057] As described above, the call format conversion device 10A according to the second embodiment makes it easy to maintain the ST source file even when development is carried out in which two different types of descriptions, abbreviated calls and formal calls, are mixed in the ST source file created in the ST language as the method of calling functions and function blocks. Furthermore, the call format conversion device 10A automatically performs the task of unifying the argument format, thus saving time and avoiding errors. Furthermore, the call format conversion device 10A can prevent description errors by switching between two types of description methods, thereby reducing the burden on the user. In other words, the user can easily confirm whether the parameters are specified in the intended order in the abbreviated call, and can also easily confirm whether any arguments that should be specified in the formal call have been omitted. Furthermore, the call format conversion device 10A accepts "argument interpolation" and performs argument interpolation even if the calling POU is standardized to formal or abbreviated call format, or if variables in the called POU are added or changed. This allows the user to check for any missing specifications by comparing the format before and after conversion. The second implementation form has now been explained.

[0058] As described above, and as shown in the first and second embodiments, the call format conversion devices 10 and 10A of this disclosure make it easy to maintain the ST source file even when development is carried out in which two different types of descriptions, abbreviated calls and formal calls, are mixed in the ST source file created in the ST language as the method of calling functions and function blocks.

[0059] <Variation> In the first and second embodiments described above, the call format conversion devices 10 and 10A were separate devices from the PLC programming device 20, but the invention is not limited to this. For example, the call format conversion devices 10 and 10A may be included in the PLC programming device 20. Furthermore, a server may, for example, provide part or all of the control unit 11 of the call format conversion device 10, which includes the acquisition unit 110, the ST source file parser unit 111, the POU call management unit 112, and the output unit 113. Similarly, a server may, for example, provide part or all of the control unit 11 of the call format conversion device 10A, which includes the acquisition unit 110, the ST source file parser unit 111, the POU call management unit 112a, and the output unit 113. Alternatively, the functions of the call format conversion devices 10 and 10A may be implemented using virtual server functionality or the like on the cloud. Furthermore, the call format conversion devices 10 and 10A may be configured as a distributed processing system in which the functions of the call format conversion device 10 are appropriately distributed among multiple servers.

[0060] In the first and second embodiments, each function included in the call format conversion devices 10 and 10A can be implemented by hardware, software, or a combination thereof. Here, implementation by software means that it is implemented by a computer reading and executing a program.

[0061] Programs can be stored and supplied to a computer using various types of non-transitory computer-readable medium. Non-transitory computer-readable mediums include various types of tangible storage mediums. Examples of non-transitory computer-readable mediums include magnetic storage media (e.g., flexible disks, magnetic tapes, hard disk drives), magneto-optical storage media (e.g., magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs, CD-R / Ws, and semiconductor memory (e.g., mask ROMs, PROMs (Programmable ROMs), EPROMs (Erasable PROMs), flash ROMs, RAMs). Programs may also be supplied to a computer using various types of transient computer-readable mediums. Examples of transient computer-readable mediums include electrical signals, optical signals, and electromagnetic waves. Transitory computer-readable mediums can be supplied to a computer via wired communication channels such as electric wires and optical fibers, or via wireless communication channels.

[0062] The step of writing the program to be recorded on the recording medium includes not only processes that are performed chronologically in that order, but also processes that are not necessarily performed chronologically, but are executed in parallel or individually. Furthermore, the step of writing the program may be performed using cloud computing.

[0063] While this disclosure has been described in detail, it is not limited to the individual embodiments described above. These embodiments can be added, replaced, modified, partially deleted, etc., in any way that does not depart from the gist of this disclosure or from the spirit of this disclosure derived from the claims and their equivalents. Furthermore, these embodiments can be implemented in combination. For example, the order of operations and processes in the embodiments described above are given as examples only and are not limited thereto. The same applies when numerical values ​​or mathematical formulas are used in the description of the embodiments described above.

[0064] The following additional information is disclosed regarding the above embodiments and modifications. (Note 1) The call format conversion device (10) is a call format conversion device having an argument description format conversion function, and comprises an input unit (13) that accepts argument format and conversion target, an acquisition unit (110) that reads the ST source file before conversion, an ST source file parser unit (111) that has at least syntactic analysis and semantic analysis functions, a POU call management unit (112) that manages argument information and call information from function and function block definitions output by the ST source file parser unit (111), and an output unit (113) that outputs the converted ST source file. The ST source file parser unit (111) performs syntactic analysis and semantic analysis on the ST source file read by the acquisition unit (110), outputs argument information and call information of function definitions and function block definitions to the POU call management unit (112), the POU call management unit (112) converts the argument information to the argument format accepted by the input unit (13) based on the argument specification in the call information, and causes the output unit (113) to output the converted ST source file. (Note 2) In the call format conversion device (10) described in Appendix 1, the read destination of the acquisition unit (110) and the output destination of the output unit (113) are the storage unit (14) included in the call format conversion device (10) or an external storage device (20). (Note 3) The PLC programming device (20) includes a call format conversion device (10) as described in Appendix 1 or Appendix 2. (Note 4) In the call format conversion device (10A) described in Appendix 1 or Appendix 2, when the input unit (13) receives argument interpolation as argument format, the POU call management unit (112a) first converts the arguments of the ST source file before conversion to the abbreviated call argument format, and then converts the arguments of the ST source file converted to the abbreviated call argument format to the formal call argument format. (Note 5) The call format conversion program operates the computer as a call format conversion device (10) having an argument description format conversion function, and includes an input unit (13) that accepts the argument format and the target to be converted, an acquisition unit (110) that reads the ST source file before conversion, an ST source file parser unit (111) that has at least syntactic analysis and semantic analysis functions, a POU call management unit (112) that manages argument information and call information from the function and function block definitions output by the ST source file parser unit (111), and the converted ST file The output unit (113) outputs a source file, and the ST source file parser unit (111) functions as a POU call management unit (112). The POU call management unit (112) performs syntactic and semantic analysis on the ST source file read by the acquisition unit (110), and outputs argument information for function definitions and function block definitions, as well as function call information. The POU call management unit (112) converts the argument information into the argument format received from the input unit (13) based on the argument specifications in the call information, and outputs the converted ST source file to the output unit (113). (Note 6) The recording medium includes, in order to operate the computer as a call format conversion device (10) having an argument description format conversion function, an input unit (13) that accepts the argument format and the target to be converted, an acquisition unit (110) that reads the ST source file before conversion, an ST source file parser unit (111) that has at least syntactic analysis and semantic analysis functions, a POU call management unit (112) that manages argument information and call information from the function / function block definition output by the ST source file parser unit (111), and an output unit (113) that outputs the converted ST source file. A computer-readable recording medium that stores a call format conversion program, which functions as follows: the ST source file parser unit (111) performs syntactic and semantic analysis on the ST source file read by the acquisition unit (13), outputs argument information for function definitions and function block definitions and function call information to the POU call management unit (112), the POU call management unit (112) converts the argument information into the argument format received from the input unit (13) based on the argument specifications in the call information, and outputs the converted ST source file to the output unit (113). [Explanation of Symbols]

[0065] 1. Call format conversion system 10 Call format conversion device 11 Control Unit 110 Acquisition Department 111 ST Source File Parser Section 112 POU call management department 113 Output section 12 Display section 13 Input section 14 Storage section 20 PLC Programming Devices

Claims

1. A call format converter having an argument description format conversion function, An input section that accepts the argument format and the target to be converted, The acquisition unit reads the ST source file before conversion, An ST source file parser unit having at least syntactic and semantic analysis functions, The POU call management unit manages argument information and call information from the function and function block definitions output by the aforementioned ST source file parser unit, It comprises an output unit that outputs the converted ST source file, The ST source file parser unit performs syntactic and semantic analysis on the ST source file read by the acquisition unit, and outputs argument information and call information for the function definition and function block definition to the POU call management unit. The POU call management unit converts the argument specification in the call information into the argument format received from the input unit, and causes the output unit to output the converted ST source file. Call format conversion device.

2. The call format conversion device according to claim 1, wherein the read destination of the acquisition unit and the output destination of the output unit are a storage unit included in the call format conversion device or an external storage device.

3. The POU call management unit, when the input unit accepts argument interpolation in the argument format, first converts the arguments of the ST source file before conversion to the argument format of an abbreviated call, and then converts the arguments of the ST source file converted to the abbreviated call format to the argument format of a formal call, as described in claim 1 or claim 2.

4. A PLC programming device comprising a call format conversion device according to claim 1 or claim 2.

5. To operate a computer as a call format converter with argument description format conversion capabilities, An input section that accepts the argument format and the target to be converted, The acquisition unit reads the ST source file before conversion, An ST source file parser unit having at least syntactic and semantic analysis functions, The POU call management unit manages argument information and call information from the function and function block definitions output by the aforementioned ST source file parser unit, It functions as an output unit that outputs the converted ST source file, The ST source file parser unit performs syntactic and semantic analysis on the ST source file read by the acquisition unit, and outputs argument information for function definitions and function block definitions, and function call information to the POU call management unit. The POU call management unit converts the argument specification in the call information into the argument format received from the input unit, and causes the output unit to output the converted ST source file. A call format conversion program.

6. To operate a computer as a call format converter with argument description format conversion capabilities, An input section that accepts the argument format and the target to be converted, The acquisition unit reads the ST source file before conversion, An ST source file parser unit having at least syntactic and semantic analysis functions, The POU call management unit manages argument information and call information from the function and function block definitions output by the aforementioned ST source file parser unit, It functions as an output unit that outputs the converted ST source file, The ST source file parser unit performs syntactic and semantic analysis on the ST source file read by the acquisition unit, and outputs argument information for function definitions and function block definitions, and function call information to the POU call management unit. The POU call management unit converts the argument specification in the call information into the argument format received from the input unit, and causes the output unit to output the converted ST source file. A computer-readable recording medium containing a call format conversion program.

Images