Patent Description:
A control device such as a PLC (Programmable Logic Controller) is introduced in various manufacturing sites. The control device is a kind of computer, and executes a user program such as a control program designed according to a manufacturing device or a manufacturing facility. The user program is created in a development environment prepared separately from the control device. A device that provides the development environment and provides a function of uploading the user program to the control device or downloading the user program to the control device is also referred to as a support device.

The support device provides an environment in which a user creates the user program such as the control program and a compiler (or also referred to as a builder) that converts a source code of the produced user program into a code, such as an intermediate code (or a pseudo code, an object code, and the like), which can be executed by the PLC. The support device transmits (downloads or uploads) the executable code to the PLC.

In the user program such as the control program, another program is called and used. For example, when an argument of the called program is changed, such a special countermeasure as a call-side program is changed according to the changed argument is taken.

For example, <CIT> (PTL <NUM>) discloses a program call between different OSs (operating systems) regarding transparent conversion of a program call in an interface as a method corresponding to a scene in which the program change is required. For example, <CIT> (PTL <NUM>) discloses a method for performing data access from an old version with respect to a change in data structure of a data processing system.

Moreover, a further prior art document is <CIT>, which discloses a method for making batch function callable. According to this prior art document, the various kinds of the information of a function definition in a source program are extracted and a function information table is prepared by a function information table generation processing. Similarly, by a calling information table generation processing, the information relating to function calling is extracted and a calling information table is generated. By a batch calling information table generation processing, the information relating to the batch function for processing the plural same function callings altogether is extracted from the calling information table and a batch function information table is generated. By a batch function generation processing, the batch function is generated in an intermediate word based on the batch function information table. Finally, by a batch calling conversion processing, based on the batch calling information table, the function calling in the intermediate word is converted into the batch function calling.

Furthermore, another prior art document is <CIT>, which discloses a programmable controller system, a development support device thereof and a target device. According to this prior art document, a development support device detects a specific command in a program following to processing for compiling a program (source code) and converting the program into a machine word object, then registers information indicating the specific command in a monitoring object code table. A target device determines whether or not a command which is executed currently is the specific command during execution of the machine word object, based on the monitoring object code table, then acquires and records storage data of a specific register (AX register) at a specific command execution timing.

For example, the user program including the control program of the PLC includes at least one POU (Program Organization Unit) that is a unit program performing input processing, control arithmetic processing, output processing, alarm processing, and the like. Many of the POUs can be provided as a library commonly used by the user programs. When the POU is called in the user program, data is exchanged between the program on the caller side and the called POU using an I/F (interface) including an argument and the like. In order to secure compatibility of the POU between the user programs or between control devices such as the PLC, the I/F of the POU created once can hardly be changed.

For this reason, in order to secure the compatibility, it is necessary for the user to create another POU even when the I/F is changed even for the POU that performs the same processing. Additionally, it is necessary for the user to properly use the POUs in consideration of the difference of the I/F during the creation of the user program including the control program. Additionally, because the similar POUs in which only the I/Fs are different is registered in the library, management of the library becomes complicated.

One object of the present disclosure is to provide a support device and a support program for achieving the compatibility of a callable unit program configuring the user program. This object is achieved by the subject-matters of claims <NUM> and <NUM>. Further advantageous modifications and embodiments of the invention are the subject-matter of the dependent claims. The invention is defined by claims <NUM> and <NUM>.

A support device, as defined by claim <NUM>, is for supporting development of a user program to be executed by a control device that controls a control target, the support device includes: a call detector configured to scan the user program and detect a call expression calling a callable unit program configuring the user program from the user program; and a code generator configured to generate a code having a format executable by the control device from the user program.

The code generator includes: a structure code generator configured to generate a creation instruction code creating a structure storing association information associating a name of an argument with a value set to the argument with respect to the call expression; a call code generator configured to convert the call expression into a call instruction code calling the unit program using an identifier of the structure; and a setting code generator configured to set the value of the association information to the argument when the association information corresponding to the name of the argument is stored in the structure with respect to each argument while the unit program includes at least one argument, and to generate a setting instruction code setting a predetermined value to the argument when the association information is not stored.

When the unit program called during the execution of the user program includes the arguments, the unit program can be executed with the value set to all the arguments. Thus, even when the I/F of the unit program is changed such that the number of arguments is increased or decreased, the user program can be executed without newly registering the unit program in which the I/F is changed in the library and the compatibility of the unit program is ensured.

Preferably the structure code generator generates the creation instruction code creating the structure each time the call detector detects the call expression of the unit program.

The call instruction code can be generated for all unit programs called in the user program by one-time scanning of the user program.

Preferably the structure code generator generates the creation instruction code creating the structure for each kind of the unit program called by the call expression detected by the call detector.

The structure is created for each kind of the unit program during the execution of the user program, so that an execution speed of the user program can be enhanced and the storage area where the structure is stored can be saved as compared with the case of creating the structure for each unit program.

Preferably the association information includes information indicating the name of the argument and information indicating the value, the information indicating the name of the argument includes an address of a storage area where the name of the argument is stored, and the information indicating the value includes an address of a storage area where the value is stored.

The association information stored in the structure can be set to the address. The address used to assign the storage area is generally a fixed length, so that the storage area where the structure is stored can be saved as compared with the case of using the argument name or the value itself having a variable data length.

Preferably the argument represents a variable used in the user program. The information indicating the value includes one of the address of the storage area where the value is stored and the value based on a type of a variable represented by the associated argument.

The information indicating the value of the association information can selectively be switched to the value itself or the address based on the type of the variable of the associated argument. Thus, when the association information includes not the address but the value itself, the address is directly acquired from the association information, so that the processing of reading the value from the storage area by specifying the address can be omitted.

Preferably the unit program includes a function determining a setting content of each argument of the unit program.

When the unit program is called during the execution of the user program, the setting content of each argument in the unit program can be determined by the executed function.

Preferably the call code generator converts the call expression into the call instruction code using, as the identifier of the structure, an address of an area where the structure is stored.

When the call instruction code is executed, the area of the structure can directly be assigned by the address used for the call instruction code, and the association information can be read and written.

Preferably the setting code generator generates an instruction code performing predetermined processing when the unit program does not include the argument.

When the unit program does not include the argument, the instruction code performing the predetermined processing can be generated as a code having an executable form.

A support program, as defined by claim <NUM>, is for constructing a support device supporting development of a user program to be executed by a control device that controls a control target is provided. The support program causing a computer to function as: a call detector configured to scan the user program and detect a call expression calling a callable unit program configuring the user program from the user program; and a code generator configured to generate a code having a format executable by the control device from the user program. The code generator includes: a structure code generator configured to generate a creation instruction code creating a structure storing association information associating a name of an argument with a value set to the argument with respect to the call expression; a call code generator configured to convert the call expression into a call instruction code calling the unit program using an identifier of the structure; and a setting code generator. The setting code generator sets the value of the association information to the argument when the association information corresponding to the name of the argument is stored in the structure with respect to each argument while the unit program includes at least one argument, and generates a setting instruction code setting a predetermined value to the argument when the association information is not stored.

According to an example of the present disclosure, the compatibility of the callable unit program configuring the user program can be provided.

An embodiment of the present invention will be described in detail with reference to the drawings. The same or equivalent portion in the drawings is denoted by the same reference numeral, and the description will not be repeated.

With reference to <FIG>, an example of a scene to which the present invention is applied will be described. <FIG> is a schematic diagram illustrating an example of an application scene of a support device <NUM> according to an embodiment. Support device <NUM> that supports development of a user program <NUM> to be executed by a control device that controls a control target is provided in the embodiment. For example, user program <NUM> can include a control program controlling the control target. For example, the control device can include a PLC <NUM>.

Support device <NUM> includes a program development unit <NUM> as a development support environment for user program <NUM>. Support device <NUM> uses a storage unit such as a RAM (Random Access Memory) <NUM> as an area where data related to compilation is stored and a work area. The storage unit is not limited to RAM <NUM>, but may include an HDD (Hard Disk Drive) and the like.

A compiler <NUM> included in program development unit <NUM> compiles user program <NUM> while accessing the storage unit such as RAM <NUM>. Compiler <NUM> includes a code generator <NUM> and a call detector <NUM>. The code generator <NUM> generates an intermediate code <NUM> as a code having a format executable by the control device from user program <NUM>. The call detector <NUM> detects a call expression calling a callable unit program (POU <NUM>) configuring user program <NUM> while scanning user program <NUM>. For example, the call expression includes a name (identifier) of the unit program and an argument name of at least one argument. For example, when the unit program is a function, the call expression is represented by a function name (the name of argument <NUM>, the name of argument <NUM>,. As illustrated in a modification described later, the number of arguments of the unit program may be zero. However, for convenience, the number of arguments of the unit program is at least one.

Code generator <NUM> includes a structure code generator <NUM>, a call code generator <NUM>, and a setting code generator <NUM>. The structure code generator <NUM> generates a creation instruction code creating a structure that stores association information associating the argument name with a value set in the argument with respect to each of at least one argument of the unit program included in the detected call expression. For example, the structure has an array type structure, and more specifically has an associative array type structure.

Call code generator <NUM> converts the call expression into a call instruction code calling the unit program in which at least one argument name of the unit program is changed to the identifier of the structure.

Setting code generator <NUM> generates a setting instruction code when a code having an executable format of the unit program is generated. The setting instruction code includes an instruction code in which, for each of at least one argument of the unit program, the value associated by the association information is set to the argument when the association information corresponding to the argument name of the argument is stored in the structure, and a predetermined value is set to the argument when the association information is not stored. Consequently, the intermediate code of the unit program includes the instruction code indicating an original processing content and the setting instruction code generated by setting code generator <NUM>.

When the setting instruction code is executed, the predetermined value set to the argument is a value that enables the execution of the unit program by treating the value of the argument as the omission, and the predetermined value can include a default value, a value indicating an error, and the like.

A transfer unit <NUM> included in support device <NUM> reads intermediate code <NUM> from the storage unit such as RAM <NUM> according to a user's operation content received through an input device, and transmits (downloads or uploads) read intermediate code <NUM> to the control device. Transfer unit <NUM> transmits intermediate code <NUM> to the control device through wired or wireless connection, or a recording medium such as a memory card.

When the control device executes the code having the executable format (hereinafter, referred to as an executable format code) from support device <NUM>, the unit program is called from a library of the control device by the call instruction code. A value associated by the association information about the structure or a predetermined value is set to each argument of the unit program called from the library using the setting instruction code. As described above, the unit program called during the execution of user program <NUM> by the control device is executed, with some values set to all arguments of the unit program.

Consequently, when the I/F is changed by changing the number of arguments, or the like, the unit program called during the execution of user program <NUM> can be executed to ensure the compatibility of the unit program without registering the changed unit program in the library as a "function expansion version". This also facilitates management of unit programs in the library, which results in maintainability of the library.

For example, user program <NUM> can include one or a combination of a plurality of sequence programs described in a ladder logic language. The program is not limited to the sequence program, but may be a motion program. The programming language is not also limited to the ladder logic language.

For example, the unit program includes a POU (Program Organization Unit) <NUM> that can be called in the user program <NUM>. POU <NUM> can include a kind of subroutine or function. The subroutine or function is called from another program (including another POU <NUM>) and executed, and returns an execution result to the program of a caller side. Support device <NUM> can also receive a user operation to create POU <NUM>, generate an executable format code for each created POU <NUM>, and send the executable code to the control device (PLC <NUM>).

POU <NUM> includes an I/F (interface) that calls POU <NUM>. The I/F includes at least one argument (variable) delivering a value such as a global variable and a local variable between programs including POU <NUM>.

Although intermediate code <NUM> is illustrated as the executable code, a pseudo code may be used. The control device (PLC <NUM>) can also convert intermediate code <NUM> received from support device <NUM> into the code suitable for the specifications of the control device, and execute the converted code. In this sense, in this application example, intermediate code <NUM> is used as being located between source code <NUM> of user program <NUM> and the code suitable for the specifications of the control device.

In the following description, the argument has two kinds, namely, a dummy argument and an actual argument. For example, when POU <NUM> (unit program) is a function, the dummy argument corresponds to a variable (parameter) in defining the function of POU <NUM>. For example, when POU <NUM> is a function, the actual argument corresponds to a value delivered to the function of POU <NUM> during the execution of POU <NUM> (the execution of an operation according to the function). As described above, during the execution of POU <NUM>, the value of the actual argument is substituted for the dummy argument, and the program is executed using the value of the substituted actual argument (for example, the operation of the function). In the present disclosure, an address can include both a physical address and a logical address.

Hereinafter, a more detailed configuration and processing of support device <NUM> of the embodiment will be described as a more specific application example of the present invention.

A configuration example of a PLC system <NUM> to which support device <NUM> of the embodiment can be applied will be described. <FIG> is a schematic diagram illustrating a configuration example of PLC system <NUM> to which support device <NUM> of the embodiment can be applied.

With reference to <FIG>, PLC system <NUM> includes a plurality of PLCs <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>,. (hereinafter, also collectively referred to as a "PLC <NUM>"). It is assumed that each of PLCs <NUM> is provided in a control system that controls a similar manufacturing device, and that the control programs executed in each of the PLCs <NUM> are substantially the same. Support device <NUM> of the embodiment develops a control program controlling the operation of each PLC <NUM>, and downloads (or uploads) the developed control program to each PLC. The number of PLCs provided in PLC system <NUM> is not limited to the plural number, but may be one or more.

Each of PLCs <NUM> is an example of the control device that controls the control target. PLC <NUM> typically includes a CPU unit <NUM> as a main body that executes various programs including the control program, a power supply unit <NUM> that supplies power to CPU unit <NUM> and the like, and an I/O (Input/Output) unit <NUM> that exchanges a signal from a field. I/O unit <NUM> is connected to CPU unit <NUM> through a system bus <NUM>.

Support device <NUM> supports the development of the control program to be executed by PLC <NUM> as the control device that controls the control target. Support device <NUM> has a function of providing the environment for the development of user program <NUM> including the control program to be executed by PLC <NUM>, a function of setting the control program and various pieces of information to PLC <NUM>, a function of acquiring a status value of operating PLC <NUM>, and the like. Support device <NUM> may have a debug function or a simulation function in order to assist the user in developing user program <NUM> including the control program.

Various functions described above are implemented by installing the support program, which is an application program stored in a recording medium <NUM>, in the support device <NUM>. Instead of recording medium <NUM>, the support program may be downloaded from an external server device or the like through a network. For example, support device <NUM> is connected to CPU unit <NUM> of PLC <NUM> through a connection cable. Support device <NUM> is typically constructed by a personal computer.

A hardware configuration example of PLC <NUM> will be described below. <FIG> is a schematic diagram illustrating the hardware configuration example of PLC <NUM> included in the PLC system in <FIG>.

With reference to <FIG>, PLC <NUM> implements the control of the control target by causing a processor to execute a previously installed program. More specifically, PLC <NUM> includes a processor <NUM> such as a CPU (Central Processing Unit) or an MPU (Micro-Processing Unit), a chip set <NUM>, a main memory <NUM>, a flash memory <NUM>, an external network controller <NUM>, a memory card interface <NUM>, an internal bus controller <NUM>, and a field bus controller <NUM>.

Processor <NUM> reads system program <NUM> and user program <NUM> stored in flash memory <NUM>, and expands system program <NUM> and user program <NUM> in main memory <NUM>, thereby implementing the control of the control target. User program <NUM> includes one or a plurality of POUs <NUM> that are registered in library <NUM>. Each POU <NUM> of library <NUM> is registered in the form of an executable form code (for example, the intermediate code).

System program <NUM> includes the instruction code providing such a basic function of PLC <NUM> as data input/output processing and execution timing control. User program <NUM> includes a kind of control program arbitrarily designed according to the control target. The control programs include a sequence program 600A executing sequence control and a motion program 600B executing motion control. User program <NUM> of PLC <NUM> can include user program <NUM> indicated by intermediate code <NUM> from support device <NUM>.

Chip set <NUM> performs processing of entire PLC <NUM> by controlling each component.

Internal bus controller <NUM> is an interface that exchanges the data between PLC <NUM> and I/O unit <NUM> connected to PLC <NUM> through an internal bus. Field bus controller <NUM> is an interface that exchanges the data between PLC <NUM> and an I/O unit <NUM> connected to PLC <NUM> through a field bus (not illustrated). Internal bus controller <NUM> and fieldbus controller <NUM> acquire the status values input to corresponding I/O units <NUM> and <NUM>, respectively, and output the operation result of the processor <NUM> as a command value from corresponding I/O units <NUM> and <NUM>.

External network controller <NUM> controls the data exchange through various wired and wireless networks. Memory card interface <NUM> is configured such that memory card <NUM> is detachable, and can write and read the data in and from memory card <NUM>.

Some or all of the functions provided by executing the program using PLC <NUM> may be implemented as a dedicated hardware circuit.

A hardware configuration example of support device <NUM> will be described below. <FIG> is a schematic diagram illustrating the hardware configuration example of support device <NUM> included in the PLC system in <FIG>. With reference to <FIG>, support device <NUM> is typically constructed with a general-purpose computer. In the manufacturing site where PLC <NUM> is disposed, support device <NUM> may be provided in the form of a notebook type personal computer having excellent portability.

Support device <NUM> includes a CPU <NUM> that executes various programs including an operating system (OS), a ROM (Read Only Memory) <NUM> that stores a BIOS (Basic Input Output System) and various data, RAM <NUM> that provides the work area storing the data necessary for the execution of the program in CPU <NUM>, and a hard disk (HDD) <NUM> that stores programs executed by CPU <NUM> in a nonvolatile manner.

Support device <NUM> further includes a keyboard <NUM> and a mouse <NUM> that receive an operation from a user and a display <NUM> that presents information to the user. Support device <NUM> includes a communication interface <NUM> that communicates with PLC <NUM> (CPU unit <NUM>) and the like.

Support device <NUM> includes a recording medium reader <NUM> that reads a support program stored in recording medium <NUM>. The support program can include a program constructing program development unit <NUM> having the compiler <NUM>.

With reference to <FIG> again, a program development environment provided by support device <NUM> will be described.

The user can change, update, and delete the programs in units of POU <NUM> using the editing function provided by a program editor <NUM> of the program development unit <NUM> in <FIG>. According to a user operation content received through an input device such as keyboard <NUM>, program editor <NUM> edits user program <NUM>, and converts edited user program <NUM> into a source code <NUM> of a predetermined program description language.

Variable programming can be performed on the control program to be executed by PLC <NUM>, and various pieces of processing can be executed using variable values associated with the field data defined in a global variable or a local variable table in PLC <NUM>. The value set to the argument of the above POU can include these variable values. Thus, the I/F of related POU <NUM> can be changed when the global variable or the local variable is changed due to a change in a field device (a device of the control target) or the like. For example, the number of arguments of the I/F can be changed.

Sometimes the function of compiler <NUM> for scanning user program <NUM> to generate intermediate code <NUM> is provided as a part of a builder included in the support device <NUM>. For example, the builder has both compiling and linking functions, thereby creating an executable file by linking a plurality of files of intermediate code <NUM> generated by compiling. Thus, compiler <NUM> can be provided as a part of the builder included in support device <NUM>. In this case, intermediate code <NUM> can be transferred to the control device (PLC <NUM>) as the executable file.

<FIG> is a view schematically illustrating an example of user program <NUM> according to the embodiment of the present invention. <FIG> is a view schematically illustrating an example of the conventional intermediate code on a caller side of the POU. <FIG> is a view schematically illustrating an example of the conventional intermediate code on a called side (POU). With reference to <FIG>, user program <NUM> is described in a range from START indicating start of the program to END indicating end of the program. User program <NUM> includes a declaration unit <NUM> such as the name (identifier) of POU <NUM> called in the program and the name and data type of each argument, and a PROGRAM unit <NUM> describing a program bar on the caller side of POU <NUM>. Hereinafter, it is assumed that POU <NUM> is a function in which the name is "foo".

With reference to <FIG>, in PROGRAM unit <NUM>, a call of POU <NUM> is described by a call expression <NUM>. Call expression <NUM> (foo (in1: = a + b, inout2: = c [idx], out3 → d)) has a POU name of "foo" and three arguments, the argument names are in1, inout3, and out3, and POU <NUM> is called by assigning a + b, c[idx], and d to the values of the arguments.

When user program <NUM> in <FIG> is compiled by a conventional method, for example, the intermediate code in <FIG> is generated for the program bar on the caller side. With reference to <FIG>, intermediate code <NUM> corresponding to the program bar includes a POU call code <NUM> corresponding to call expression <NUM> of POU <NUM>, a code <NUM> of another portion, and a code <NUM> setting a return value d. Code <NUM> includes an instruction code calculating (acquiring) the value of each argument of POU <NUM>. Consequently, when POU <NUM> is called from the program bar during the execution of user program <NUM>, the actual argument that is the value calculated (acquired) by the program bar is delivered to each argument (dummy argument) of the POU.

With reference to <FIG>, intermediate code <NUM> of POU <NUM> on the called side includes an instruction code <NUM> acquiring the value (the value of the actual argument) delivered to each argument, an instruction code <NUM> executing processing (such as an arithmetic processing) using the value of each delivered argument, and a code <NUM> setting a processing result as the return value.

Code generator <NUM> of the embodiment generates a creation instruction code instructing creation of an associative array that is an example of a structure in association with POU <NUM>. In the embodiment, the creation instruction code is provided by two methods, namely, an "associative array for each call" and an "associative array for each kind".

In the "associative array for each call", each time call detector <NUM> detects call expression <NUM> of the POU during the scanning of user program <NUM>, the structure code generator <NUM> generates the creation instruction code creating the associative array. On the other hand, in the "associative array for each kind", the creation instruction code creating the associative array for each kind of POU <NUM> called by call expression <NUM> detected by call detector <NUM> during the scanning of user program <NUM>.

Compiler <NUM> has both functions (modules) of the "associative array for each call" and the "associative array for each kind". Compiler <NUM> activates one of the functions (modules) based on the instruction received from the user through the input device.

The "associative array for each call" method will be described.

<FIG> and <FIG> are views schematically illustrating an example of the intermediate code generated according to the "associative array for each call" method of the embodiment of the present invention. Intermediate code in <FIG> illustrates an example of intermediate code <NUM> generated from the program bar in <FIG>, which is the caller side of the POU (foo), according to the "associative array for each call" method.

Intermediate code <NUM> includes code <NUM> of another portion similar to <FIG> and code <NUM> generated in association with the call of POU <NUM>. Code <NUM> includes a call instruction code <NUM> for POU <NUM>, a creation instruction code <NUM> for the associative array, and a release instruction code <NUM> instructing release of an area of the associative array.

Because code <NUM> is the same as that in <FIG>, the description thereof will not be repeated. Creation instruction code <NUM> includes an instruction code instructing the creation of the associative array storing the association information associating the argument name with the value (actual argument) set to the argument with respect to each of at least one argument included in call expression <NUM>. Specifically, creation instruction code <NUM> includes an instruction code <NUM> assuring the storage area of the associative array having a size based on the number of arguments (in1, inout2, out3) in association with the POU identifier (name foo) of call expression <NUM>, an instruction code <NUM> acquiring the address of the storage area where the value (actual argument) of each argument calculated (acquired) by the program bar that is the caller side of POU <NUM> is stored, and an instruction code <NUM> setting the address (that is, the address acquired by instruction code <NUM>) of the area where the value is stored to the associative array (storage area) in association with each argument name with respect to each argument of POU <NUM>.

Instruction code <NUM> represents an instruction code specifying the associative array identifier ("tmp7") to assure the area where the data (for example, NULL) indicating an area corresponding to the total number of arguments (in the case of foo, three arguments) and a termination (terminator) of the associative array is stored. At this point, for example, a head address (for example, "tmp7") of the area where the associative array is stored is assigned to the identifier of the associative array.

Call instruction code <NUM> represents an instruction code calling POU <NUM> in which at least one argument name is changed to the associative array identifier ("tmp7") using call expression <NUM>.

Release instruction code <NUM> represents a code instructing the release of the storage area used for the associative array when the processing of POU <NUM> is completed to return from POU <NUM> to the program bar that is the caller side. In the embodiment, the term "the release of the storage area" includes a change of the storage area from a used state to an unused state, namely, a free area.

In the "associative array for each call" method, each time user program <NUM> is scanned to detect call expression <NUM>, creation instruction code <NUM> creating the associative array is generated.

Intermediate code <NUM> in <FIG> illustrates an example of the intermediate code of POU <NUM> to be called. With reference to <FIG>, intermediate code <NUM> includes a setting instruction code <NUM> in addition to intermediate code <NUM> and intermediate code <NUM> in <FIG>. In <FIG>, setting instruction code <NUM> includes an instruction code instructing the acquisition (read) of the address at which the value (actual argument) corresponding to each argument name is stored from the associative array, and the setting of the value read from the area of the acquired address to the corresponding argument. When the value read from the address area is NULL, setting instruction code <NUM> includes an instruction code instructing the setting of a default value to the argument of the argument name.

Thus, when POU <NUM> is called during the execution of user program <NUM> in PLC <NUM>, the value (actual argument) acquired (calculated) by the program bar on the caller side or (when the value is not acquired) a predetermined value (for example, a default value) is set to each argument through the associative array before instruction code <NUM> of the original processing of POU <NUM> is executed. Consequently, when the processing of subsequent instruction code <NUM> is executed, an error caused by an indefinite value of the argument is prevented.

<FIG> is a flowchart illustrating an example of caller-side intermediate code generation processing according to the "associative array for each call" method of the embodiment of the present invention. <FIG> is a view schematically illustrating an example of contents of a temporary area <NUM> and an associative array <NUM> used in the processing of <FIG>. With reference to <FIG>, the processing of generating the intermediate code of the program bar that is an example of user program <NUM> on the caller side of POU <NUM> will be described. For example, temporary area <NUM> and associative array <NUM> are a storage area of PLC <NUM>, and typically correspond to a volatile storage area such as a RAM.

Call detector <NUM> determines whether to detect call expression <NUM> while scanning user program <NUM> (source code <NUM>) (step S1). When it is determined that that call expression <NUM> is detected (YES in step S1), the processing proceeds to steps from step S3. When it is determined that call expression <NUM> is not detected (NO in step S1), call detector <NUM> determines whether the scanning is performed up to the termination of user program <NUM> (step S12). When it is determined that the scanning is completed up to the termination of user program <NUM> (YES in step S12), call detector <NUM> ends the processing. When it is determined that the scanning is not completed up to the termination of user program <NUM> (NO in step S12), the processing returns to step S1 to continue the scanning of user program <NUM>.

When call detector <NUM> detects call expression <NUM> (YES in step S1), code generator <NUM> evaluates the actual argument of POU <NUM> and generates code <NUM> instructing the storage of the evaluation result in temporary area <NUM> (step S3). Code generator <NUM> generates an instruction code counting the number of arguments included in detected call expression <NUM> (step S3).

Specifically, with reference to <FIG>, code <NUM> generated in step S3 includes the instruction code instructing the storage of the value delivered to the variable of each dummy argument, namely, the evaluation value of the variable of the actual argument in temporary area <NUM> in <FIG>. Specifically, code <NUM> includes the instruction code instructing the storage of the addresses of an area T1 (that is, the operation result (a + b) value of the program bar on the caller side of POU <NUM>) where the evaluation value of the actual argument to input variable inl that is the first dummy argument is stored, an area T2 (that is, the address (the address of c[i]) of the variable to delivered to inout2) where the evaluation value of the actual argument to the input and output variable inout2, that is the second dummy argument is stored, and an area T3 (that is, empty (secured as an area where the value of the processing result of the POU is stored in out3) where the evaluation value of the actual argument is stored in the output variable out3 that is the third dummy argument. For example, temporary area <NUM> is a kind of stack area, and is set so as not to overlap the storage area where values of other variables and the like are stored.

The evaluation values stored in corresponding area T1 to T3 differ from each other for each kind of the variable represented by the argument. In the embodiment, for example, the kinds of the variables represented by the arguments that can be included in the I/F of POU <NUM> include three kinds of the input variable, the input and output variable, and the output variable. The kinds of evaluation values stored in areas T1 to T3 vary according to the kinds of the variables.

Subsequently, structure code generator <NUM> generates instruction code <NUM> instructing the security of the area of associative array <NUM> having the number of entries based on the total number of dummy arguments counted in step S3 (step S5). In step S5, the number of entries of associative array <NUM> is set to a number obtained by adding one representing the termination to the total number of dummy arguments such that the termination of the associative array can easily be determined in, for example, step S13 (to be described below).

Structure code generator <NUM> generates instruction codes <NUM> and <NUM> (step S7). Instruction codes <NUM> and <NUM> are an instruction code storing association information <NUM> associating the argument name and the value (actual argument) set to the argument with each other in each entry (an entry for each of at least one argument included in the call expression) of associative array <NUM>.

Association information <NUM> about each entry of associative array <NUM> includes information indicating the argument name and information indicating the value (actual argument). More specifically, the information indicating the argument name includes an address <NUM> of the storage area where the argument name is stored. The information indicating the value includes an address <NUM> of the storage area where the value is stored.

Call code generator <NUM> generates call instruction code <NUM> calling POU <NUM> in which at least one argument name is changed to the identifier of associative array <NUM> with respect to call expression <NUM> (step S9). At this point, in call instruction code <NUM>, information (such as "tmp7") indicating the head address of the storage area of associative array <NUM> is used as the identifier of associative array <NUM>.

Code generator <NUM> generates code <NUM> of the processing of reading, from area T3 of temporary area <NUM> through the associative array, the value (that is, the value stored in area T3) delivered to the dummy argument (output variable out3) in returning to the processing of the original program bar from POU <NUM>, and release instruction code <NUM> releasing temporary area <NUM> (that is, releasing the area of the associative array) (step S11). Thereafter, the processing transfers to step S12.

As described above, compiler <NUM> generates the intermediate code including codes <NUM>, <NUM> to <NUM> creating the associative array having entries corresponding to the number of dummy arguments of the POU and call instruction code <NUM> calling the POU from the library using the associative array for each POU called in user program <NUM> on the caller side of POU <NUM>.

Not the argument name or the value (actual argument), but the address of the area where the argument name or the value (actual argument) is stored during execution of the program is set as association information <NUM> to each entry of associative array <NUM> generated by the execution of instruction codes <NUM>, <NUM>. As the background of the present invention, because an address length accessing the storage area is generally fixed, as compared with the case of storing the argument name or the value (actual argument) in which a data length may vary, the storage of the address of the area can save the storage area required for associative array <NUM>.

In the call instruction code <NUM>, because the head address of the storage area of associative array <NUM> is used as the identifier of associative array <NUM>, a direct addressing by using the head address can be realized, and a search (reading and writing) of associative array <NUM> is facilitated as compared with a method for attaching a unique name to associative array <NUM>.

<FIG> is a flowchart illustrating an example of called-side intermediate code generation processing according to the "associative array for each call" method of the embodiment of the present invention. With reference to <FIG>, the processing of generating the intermediate code associated with POU <NUM> called from library <NUM> by the program bar or the like will be described.

Setting code generator <NUM> generates setting instruction code <NUM> in the pieces of processing in steps S13 to S19 when compiler <NUM> compiles the POU. Setting instruction code <NUM> is an instruction code that is executed before the execution of instruction code <NUM> indicating the processing of POU <NUM>, and is executed, for example, immediately after the start of the processing of the POU.

Specifically, setting code generator <NUM> generates setting instruction code <NUM> in which, for each of at least one argument of POU <NUM>, the value (actual argument) of the association information is set to the argument when association information <NUM> corresponding to the argument name of the argument is stored in associative array <NUM>, and a predetermined value is set to the argument when association information <NUM> is not stored.

Setting instruction code <NUM> includes an instruction code searching associative array <NUM> by the number (for example, N) of dummy arguments of the POU using the dummy argument name (variable name) as a key (step S15, (i < N) holds in step S13) and setting the value read from the area assigned by address <NUM> of the specified entry to the variable of the dummy argument (step S17) when the entry matched with the argument name stored in the area of address <NUM> in the entries can be specified (YES in step S15). Setting instruction code <NUM> includes an instruction code instructing omission of the variable value of the dummy argument (step S19) when a determination that the value read from the area of address <NUM> is NULL is made (NO in step S15). For example, an instruction code setting a default value to the variable of the dummy argument or an instruction code outputting an error can be generated in step S19. When a series of processing is performed by the number (for example, N) of dummy arguments of the POU (that is, when (i ≥ N) is satisfied in step S13), the processing in <FIG> ends.

Setting instruction code <NUM> generated in step S17 includes an instruction code changing the value set to the dummy argument according to the kind of the variable corresponding to the dummy argument. For example, setting instruction code <NUM> includes an instruction code acquiring the value from the area of address <NUM> when the kind of the variable is the input variable, an instruction code acquiring the address of the area where the value of the variable is stored when the kind of the variable is the input and output variable, or an instruction code acquiring the address of the area where the output (return value) from POU <NUM> is stored when the kind of the variable is the output variable.

In this way, when PLC <NUM> executes call instruction code <NUM> of user program <NUM> to call POU <NUM> from library <NUM>, the value (the actual argument value, the default value, and the like) can be set to all the variables (arguments) necessary for the processing before instruction code <NUM> that is the original processing of POU <NUM> is executed. Consequently, a runtime error caused by setting no value to the dummy argument during the execution of instruction code <NUM> can be avoided.

<FIG> is a flowchart illustrating another example of the caller-side intermediate code generation processing according to the "associative array for each call" method of the embodiment of the present invention. <FIG> is a view schematically illustrating an example of contents of temporary area <NUM> and associative array <NUM> used in the processing of <FIG>. <FIG> is a flowchart illustrating another example of the called-side intermediate code generation processing according to the "associative array for each call" method of the embodiment of the present invention.

In the processing of <FIG>, because other pieces of processing are the same as those in <FIG> although step S7a is different from step S7 in <FIG>, the description except for step S7a will not be repeated.

In step S7a of <FIG>, structure code generator <NUM> generates an instruction code setting address <NUM> and an address <NUM> of the area where the actual argument evaluation value is stored to each entry of associative array <NUM>. In step S7a, the instruction code setting the address of the storage area where the value is stored or the value itself is generated as address <NUM> based on the type of the variable represented by the associated argument.

Specifically, structure code generator <NUM> generates an instruction code storing not the address but the value of the input variable in1 itself in address <NUM> when the type of the input variable is a type falling within the area less than or equal to a width of address <NUM> of associative array <NUM> for the dummy argument corresponding to the input variable, and structure code generator <NUM> generates an instruction code storing the address in evaluation value storage area T1 when the type of the input variable is not the type falling within the area less than or equal to the width of address <NUM> of associative array <NUM>.

When the dummy argument corresponds to the input and output variable, structure code generator <NUM> generates an instruction code storing the address (address of c[i]) storing the value of input and output variable inout2 in corresponding address <NUM>. When the dummy argument corresponds to the output variable, structure code generator <NUM> generates an instruction code storing the address of the area where the output from POU <NUM> is stored.

With reference to <FIG>, the processing on the called side will be described below. In the processing of <FIG>, because other pieces of processing are the same as those in <FIG> although step S17a is different from step S17 in <FIG>, the description except for step S17a will not be repeated. In step S17a of <FIG>, setting code generator <NUM> generates an instruction code changing the treatment of the value acquired from associative array <NUM> with the change of the content stored in the entry of associative array <NUM> according to the kind of the variable in step S7a described above.

Setting instruction code <NUM> generated in step S17a includes an instruction code changing the value set to the dummy argument according to the kind of the variable corresponding to the dummy argument. For example, for the input variable, the value is acquired from the entry when the type of the input variable is the type falling within the area less than or equal to the address width, otherwise, the value is treated as the address to area T1 where the evaluation value is stored, and setting instruction code <NUM> includes an instruction code acquiring the value from area T1. For the input and output variable, setting instruction code <NUM> includes an instruction code acquiring the address of the area where the value of the variable is stored. For the output variable, setting instruction code <NUM> includes an instruction code acquiring the address of area T3 where the output (return value) from POU <NUM> is stored.

In the modifications of <FIG>, <FIG>, and <FIG>, the content stored as the data of the actual argument in association information <NUM> of the entry of the associative array (or obtained from association information <NUM> of the entry) can be varied by the kind and type of the variable of the dummy argument of called POU <NUM>.

A method for securing the area of the associative array for each kind of POU <NUM> called in user program <NUM> will be described. <FIG> is a flowchart schematically illustrating an example of the intermediate code generation processing according to the "associative array for each kind" method of the embodiment of the present invention.

With reference to <FIG>, compiler <NUM> scans user program <NUM> (source code <NUM>) twice. Hereinafter, first-time scan is referred to as pass <NUM>, and second-time scan is referred to as pass <NUM>.

In pass <NUM>, call detector <NUM> of compiler <NUM> determines whether call expression <NUM> is detected (step S23) while scanning user program <NUM> from, for example, the head (step S21). When call detector <NUM> does not detect call expression <NUM> (NO in step S23), the processing proceeds to step S29 (to be described later).

When call detector <NUM> detects call expression <NUM> (YES in step S23), compiler <NUM> identifies the kind of POU <NUM> from detected call expression <NUM> (step S25). The type of POU <NUM> is based on the POU name and the like included in call expression <NUM>.

Compiler <NUM> determines the maximum number of dummy arguments included in POU <NUM> for each kind of POU identified from call expression <NUM> (step S27). Thereafter, call detector <NUM> determines whether the scanning is performed up to the termination of user program <NUM> (step S29). When it is determinated that the scanning is not performed up to the termination (NO in step S29), the processing returns to step S21 to continue the scanning.

When call detector <NUM> determines that user program <NUM> is scanned up to the termination (YES in step S29), compiler <NUM> decides the maximum number of dummy arguments for each kind of POU <NUM>.

Structure code generator <NUM> generates an instruction code <NUM> securing the area where associative array <NUM> is stored for each kind of POU <NUM> (step S31). Specifically, structure code generator <NUM> generates an instruction code securing the area of the associative array including the entries for the maximum number of dummy arguments of POU <NUM> belonging to the kind and the entry indicating the termination with respect to the associative array for each kind of POU <NUM>. Consequently, pass <NUM> ends.

Compiler <NUM> executes pass <NUM>. In pass <NUM>, user program <NUM> is scanned, and code generator <NUM> generates the intermediate code for each POU <NUM> according to the "associative array for each call" method using associative array <NUM> corresponding to the kind of POU <NUM> secured in pass <NUM> (step S33). Consequently, pass <NUM> ends.

<FIG> is a view schematically illustrating an example of the associative array generated according to the "associative array for each kind" method of the embodiment of the present invention. With reference to <FIG>, when three kinds of POU <NUM> of pou1, pou2, and pou3 are detected by scanning user program <NUM> (source code <NUM>) by pass <NUM>, structure code generator <NUM> generates a creation instruction code creating associative arrays <NUM>, <NUM>, and <NUM> corresponding to each kind. Each associative array has the number of entries corresponding to the maximum number of dummy arguments of POU <NUM> belonging to the corresponding kind.

With reference to <FIG>, in the generation of the intermediate code in pass <NUM>, structure code generator <NUM> generates an instruction code setting the value to the associative array every time the POU is called. The generated instruction code is the same as that of the "associative array for each call" method. Call code generator <NUM> generates the call code using the associative array corresponding to each POU <NUM>. Even in this case, the call code in which the head address of the storage area of the associative array is used is generated similarly to the "associative array for each call" method.

When returning from the processing of POU <NUM>, code generator <NUM> generates an instruction command initializing (clearing) the contents of the storage areas of associative arrays <NUM>, <NUM> and <NUM>. For example, the instruction code initializing the associative array includes an instruction code instructing the setting of the terminator or the like to the first entry of associative arrays <NUM>, <NUM>, and <NUM>.

In this way, the instruction code performing the setting and initialization of association information <NUM> of the associative array is generated each time POU <NUM> belonging to the kind is called. Consequently, the same associative array can be repeatedly used with respect to each POU <NUM> belonging to the same kind.

<FIG> is a view schematically illustrating an example of the intermediate code generated according to the "associative array for each kind" method of the embodiment of the present invention. The intermediate code in <FIG> illustrates an example of an intermediate code <NUM> generated from the program bar in <FIG>, which is the caller side of the POU (foo), according to the "associative array for each kind" method of the code generator <NUM>.

Intermediate code <NUM> includes an instruction code <NUM> securing the storage area of the associative array including the entries for the maximum number of dummy arguments of POU <NUM>, code <NUM> of another portion similar to <FIG>, and a code <NUM> generated in association with the call of POU <NUM>. Code <NUM> includes a call instruction code <NUM> for POU <NUM>, an associative array creation instruction code <NUM>, and an instruction code <NUM> instructing the initialization of the associative array area. Associative array creation instruction code <NUM> includes instruction code <NUM> and instruction code <NUM> in <FIG>, which are the instruction setting the association information to each entry of the associative array ("foo_arg_area"). Instruction code <NUM> is an instruction code instructing the storage of the association information in the associative array. Although the identifier of the associative array is varied, instruction code <NUM> is the same as instruction code <NUM> in <FIG>, so that the overlapping description will be omitted.

Instruction code <NUM> is an instruction assigning the associative array identifier ("foo_arg_area"), and securing the area where data (for example, NULL) indicating the area (entry) for the maximum number (for example, <NUM>) of arguments and the termination (terminator) of the array (terminator) is stored.

Call instruction code <NUM> represents an instruction calling POU <NUM> using the associative array identifier ("foo_arg_area").

Instruction code <NUM> represents an instruction initializing the storage area of the associative array when the processing of POU <NUM> ends.

In this way, each time the processing of called POU <NUM> is completed, the intermediate code according to the "associative array for each kind" method includes instruction code <NUM> initializing the associative array corresponding to the kind of the POU, which allows the associative array to be shared by the plurality of POUs <NUM> of the same kind. Thus, as in the intermediate code of the "associative array for each call", the processing of securing the area of the associative array for each call of the POU and the processing of releasing the storage area of the associative array each time the processing of POU <NUM> ends can be omitted.

In the embodiment, the intermediate code generated by the "associative array for each kind" may include an instruction code securing the storage area of the associative array in a static storage area of PLC <NUM> in a build unit (generally, a unit in which the file of intermediate code <NUM> is linked). The static storage area is a storage area where the intermediate code of user program <NUM> in the build unit is retained until the intermediate code is deleted since the intermediate code is loaded into PLC <NUM>. Thus, in the same build unit, the number of execution times of pass <NUM> can be decreased to one.

The intermediate code generated by the "associative array for each kind" may include an instruction code permitting the storage area of the associative array to be referred to (or the reading and writing of the data) only from the inside of the build unit, and prohibiting the storage area of the associative array from being referred to (or the reading and writing of the data) from outside of the build unit. Consequently, even when the associative array is held in the static storage area, the data is not read or written from the outside of the build unit, so that an unexpected or unintended change of the data in the associative array can be prevented.

The intermediate code generated by the "associative array for each kind" may include an instruction code performing exclusive control on the associative array used by the same kind of POU <NUM>. By performing the exclusive control on the "associative array for each kind", the same kind of POU <NUM> can be called in the build unit and executed in parallel.

The intermediate code generated in the "associative array for each kind" may include an instruction code performing the processing of evacuating and returning the content (association information <NUM>) of the associative array and an instruction code calling recursively the same kind of POU <NUM>. Consequently, the same kind of POU can be recursively called while evacuating and returning the content of the associative array.

<FIG> is a view schematically illustrating an example of the format and the content of the call of an intrinsic function <NUM> according to the embodiment of the present invention.

In the embodiment, the user can describe intrinsic function <NUM> (the function name is isArgSpecified) of <FIG> in POU <NUM> using program creation unit <NUM>.

As described above, because the default value or the value indicating the error is set to the argument (see step S19) when the actual argument is omitted, although called POU <NUM> can determine that the omission is performed from the setting value, this determination method depends on the content of setting instruction code <NUM> (setting code generator <NUM>). On the other hand, in the determination method in which intrinsic function <NUM> is used, POU <NUM> can determine the setting content whether the actual argument is set (or omitted) by performing intrinsic function <NUM> without depending on the content of setting instruction code <NUM> (setting code generator <NUM>).

Thus, the user describes intrinsic function <NUM> in POU <NUM>, which allows the user to execute programming performing the explicit processing during the omission of the actual argument based on the determination result (return value) of intrinsic function <NUM> without depending on the content of setting instruction code <NUM> (setting code generator <NUM>). In the case where the default value is set when the actual argument is omitted, the setting content indicating whether the actual argument is actually omitted or whether the default value is set to the actual argument (without omitting the actual argument) can be determined using intrinsic function <NUM>.

A support program performing the processing of compiler <NUM> including the processing of each flowchart described in the embodiment is stored in the storage unit (ROM <NUM>, RAM <NUM>, HDD <NUM>, recording medium <NUM>, and the like) of support device <NUM>. CPU <NUM> reads the support program from the storage unit, and executes the support program, whereby compiler <NUM> including the code generator <NUM> described in the embodiment can be constructed.

The support program is recorded in a computer-readable recording medium such as a flexible disk, a CD-ROM (Compact Disk-Read Only Memory), a ROM, a RAM, and recording medium <NUM> attached to support device <NUM>, and can also be provided as a product. Alternatively, the program can be provided by being recorded in a recording medium such as HDD <NUM> incorporated in support device <NUM>. The program can be provided by being downloaded from a network (not illustrated) through a communication interface.

In the above embodiment, structure code generator <NUM> can generate creation instruction codes <NUM>, <NUM> even when the argument does not exist in call expression <NUM>. In this case, creation instruction codes <NUM>, <NUM> include an instruction code instructing the creation of associative array <NUM> storing only association information <NUM> having terminator data (for example, NULL) as address <NUM> of the dummy argument name and the value of N/A as address <NUM> of the corresponding set value. Setting code generator <NUM> generates an instruction code performing the processing according to a predetermined specification for associative array <NUM> storing only association information <NUM> of the termination data. When the number of arguments of called POU <NUM> is zero, for example, setting code generator <NUM> generates an instruction code performing the processing according to a predetermined specification.

In the embodiment, user program <NUM> (that is, the executable code (intermediate code <NUM>)) can be copied and used between different PLCs <NUM>, namely, binary compatibility of user program <NUM> can be secured without depending on the kind of POU <NUM> stored in library <NUM> of each PLC <NUM>.

Code generator <NUM> can generate the executable format code (intermediate code <NUM>) having backward compatibility from user program <NUM>. That is, when a change in version upgrade is generated in a processor that executes user program <NUM> or a program execution environment such as an OS (Operating System) in the control device (for example, the change in the argument of the POU called by the control device), PLC <NUM> can execute the original executable code (intermediate code <NUM>) under the changed processor or the OS even when the original executable code is not changed to the version corresponding to the changed execution environment.

The compatibility will further be described. <FIG> is a view schematically illustrating an example of advantages obtained by the present embodiment. With reference to <FIG>, when a POU <NUM>-<NUM> in which input arguments are variables in1 to in3 is registered in library <NUM> and user program <NUM> includes a call expression <NUM>-<NUM>, because POU <NUM>-<NUM> is matched with call expression <NUM>-<NUM> in the number of arguments and the argument name as illustrated in <FIG>, POU601-<NUM> is called during the execution of user program <NUM> to execute the unit program as in the conventional case when call instruction code <NUM> or <NUM> is executed.

On the other hand, when a POU <NUM>-<NUM> in which the input arguments are variables in1 to in4 are registered in library <NUM> and user program <NUM> includes call expression <NUM>-<NUM>, POU <NUM>-<NUM> is not matched with call expression <NUM>-<NUM> in the number of arguments and the argument name of the argument of input variable in4 as illustrated in <FIG>. Thus, because the actual argument corresponding to the dummy argument of input variable in4 does not exist when call instruction code <NUM> or <NUM> converted from call expression <NUM>-<NUM> is executed, for example, the default value is set (for example, the instruction codes of step S15 and step S19 in <FIG> are executed) on the assumption that the value (the actual argument) to be set to the dummy argument is omitted.

With reference to <FIG>, when POU <NUM>-<NUM> in which the input arguments are variables in1 to in4 is registered in library <NUM> and user program <NUM> includes a call expression <NUM>-<NUM>, because POU <NUM>-<NUM> is matched with call expression <NUM>-<NUM> in the number of arguments and the argument name as illustrated in <FIG>, POU <NUM>-<NUM> is called during the execution of user program <NUM> to execute the unit program as in the conventional case when call instruction code <NUM> or <NUM> converted from call expression <NUM>-<NUM> is executed.

On the other hand, when a POU <NUM>-<NUM> in which the input arguments are variables in1 to in3 are registered in library <NUM> and user program <NUM> includes call expression <NUM>-<NUM>, POU <NUM>-<NUM> is not matched with call expression <NUM>-<NUM> in the number of arguments and the argument name of the argument of input variable in4 as illustrated in <FIG>. Thus, when call instruction code <NUM> or <NUM> converted from call expression <NUM>-<NUM> is executed during the execution of user program <NUM>, the actual argument corresponding to the dummy argument of input variable in4 is ignored.

As illustrated in <FIG>, PLC <NUM> can execute user program <NUM> while calling POU <NUM> without depending on the number of arguments and argument names of the dummy arguments included in call expression <NUM> described in user program <NUM>, and without depending on the number of arguments and argument names of POU <NUM> registered in library <NUM>. Consequently, in the embodiment, the binary compatibility that is the compatibility of the executable format code of user program <NUM> and POU compatibility can be provided.

This also facilitates version control of the executable code of each PLC <NUM>. The user can develop user program <NUM> in support device <NUM> without being conscious of whether POU <NUM> registered in library <NUM> of PLC <NUM> is a usable version.

It should be considered that the disclosed embodiments are an example. The scope of the present invention is defined by the claims, and modifications of the invention are encompassed as long as covered by the scope of the claims.

Claim 1:
A support device (<NUM>) supporting development of a user program (<NUM>) to be executed by a control device (<NUM>) that controls a control target, wherein the control device (<NUM>) comprises a library (<NUM>) that stores a callable unit program (<NUM>) called by the user program, the support device comprising:
a call detector (<NUM>) configured to scan the user program and detect a call expression (<NUM>) calling the callable unit program (<NUM>) and
a code generator (<NUM>) configured to generate a code (<NUM>) having a format executable by the control device from the user program,
wherein the code generator includes:
a structure code generator (<NUM>) configured to generate a creation instruction code creating a structure (<NUM>) storing association information (<NUM>) associating a name of an argument with a value set to the argument with respect to each argument of the unit program included in the detected call expression;
a call code generator (<NUM>) configured to convert the call expression into a call instruction code (<NUM>, <NUM>) calling the unit program from the library (<NUM>) using an identifier of the structure; and
a setting code generator (<NUM>) configured to generate a setting instruction code to, for each argument of the callable unit program,
in response to association information corresponding to a name of the argument of the callable unit program being stored in the structure, set a value of the argument of the callable unit program to be the value associated with the name of the argument stored in the structure, and
in response to no association information corresponding to the name of the argument of the callable unit program being stored in the structure, set the value of the argument of the callable unit program to be a predetermined default value.