JP5849592B2 - Programmable controller system, programming device thereof, programmable controller, program, and debugging method - Google Patents

Description

  The present invention relates to a programmable controller system, and more particularly to a program debugging method.

  Conventionally, as a system related to a programmable controller (PLC), for example, a programmable controller main body (referred to as a PLC main body) and a program executed by the PLC main body (particularly control programs for various control target devices; hereinafter referred to as a PLC program) There is known a programmable controller system including a support device for assisting a user to arbitrarily create an image.

  In such a support device (programming device), the user creates an arbitrary PLC program using, for example, a mnemonic language or a graphic language program such as a ladder language or an FBD language. The created PLC program is compiled in the support device to generate a machine language object. The support apparatus downloads the machine language object to the PLC main body. The PLC main body stores the downloaded machine language object.

  Thereafter, the PLC main body executes this machine language object to control various devices to be controlled. Alternatively, there is a case where debugging (referred to as real machine debugging) is performed in which the machine language object is executed on the PLC main body side and the support apparatus side monitors the machine language object.

  In order to increase the speed of control processing and the like in the PLC main body, a method of performing optimization at the time of compiling the PLC program in the support apparatus has been proposed. However, an optimized machine language object (hereinafter referred to as an optimized machine language object) can be used to change the program execution order or delete unnecessary variables (including breakpoints) during optimization. Because it is done, it becomes difficult to debug on the source code.

Here, the above optimization will be described below.
Recently, with an increase in program size and system complexity, it has been desired to increase the speed of user applications, and not only hardware but also software (compiler) has been realized.

A specific example of such optimization compilation is shown below.
For example, if there is a source code in which “C = A + B” is first executed and subsequently “F = (A + B) × D” is executed, it is difficult to optimize “C = A + B” by compiling it. Therefore, normal compilation is performed and the following machine language object is generated.

LD A
ADD B
ST C
Next, with respect to “F = (A + B) × D”, optimization compilation is possible. As a result of the compilation, for example, the part (A + B) becomes “LDC”. For example, unnecessary variables and operations are deleted in this way. The machine language object (optimized machine language object) created in this way does not need to perform an operation related to A + B during execution, and only needs to load the value of the variable C. Can be achieved.

In the optimization compilation, if a breakpoint is set in the source code, it may be deleted.
Here, for example, the following conventional techniques are known for the problem that it is difficult to debug on the source code with the optimized machine language object as described above (so-called “source code level debugging / source code debugging”). ing.

  In other words, conventionally, the optimized machine language object is input, the optimized machine language object is decompiled, and a debugging source code for debugging with the source code is generated. There has been proposed a source code level debugging apparatus that is used for debugging on source code (see, for example, Patent Document 1).

  Moreover, the prior art described in Patent Document 2 is known.

JP-A-6-242942 JP 2002-99312 A

  However, in the conventional example described in Patent Document 1, it is necessary to decompile the optimized machine language object every time debugging is performed and to generate a source code for debugging, which makes the work complicated. There is a problem that debugging efficiency is not good.

  In the case of the mnemonic language, there is no problem, but in the case of the graphic language program such as the ladder language or the FBD language, the compiler determines in which order each graphic element is compiled at the time of compilation. The graphic elements are not necessarily expanded and compiled in the intended order.

  It is an object of the present invention to generate both a normal machine language object and an optimized machine language object by using two compilers for an arbitrary source code, and at the same time, match the expansion order of graphic elements by these two compilers. It is to provide a programmable controller system, a programming device thereof, a programmable controller, and the like that can perform source code level debugging without the need for decompilation or the like during debugging and without making the system operation unstable. .

  The PLC system of the present invention is a PLC system having a programming device and a programmable controller, and the programming device determines the source code of an arbitrary graphic language program and the order of expansion of each graphic element constituting the source code. While compiling in accordance with the expansion order to generate a first machine language object, at least first compiler means for storing the expansion order of each graphic element in the storage means, and the source code in the storage means A second compiler means for generating a second machine language object by referring to the expansion order of the stored graphic elements and compiling in accordance with the expansion order; the first machine language object; A machine language object is downloaded to the programmable controller. And an unload means.

  In the PLC system configured as described above, for example, one of the first machine language object and the second machine language object is a non-optimized machine language object generated by a normal compilation process. A machine language object, and the other is an optimized machine language object that is an optimized machine language object generated by an optimization compilation process.

  Two kinds of machine language objects are generated by two kinds of compiler means for the source code of an arbitrary figure language program, and the development order of each figure element at that time is made the same. The two generated machine language objects are downloaded to the programmable controller.

  On the programmable controller side, for example, the optimized machine language object is executed during normal times, and is switched to the non-optimized machine language object during debugging. As described above, since the expansion order of each graphic element is made the same at the time of compiling, there is no situation where the operation results differ between the two types of machine language objects, and the non-optimized machine language Switching to an object works fine.

  According to the programmable controller system, the supporting device, the programmable controller, etc. of the present invention, both a normal machine language object and an optimized machine language object are generated for two arbitrary compilers by two compilers. By matching the expansion order of the graphic elements with these two compilers, it becomes possible to perform source code level debugging without the need for decompilation or the like during debugging and without destabilizing the system operation.

This is a configuration example of a programmable controller system, particularly a configuration example of a programming device. It is a structural example of a programmable controller system, and is especially a block diagram of a programmable controller. It is a functional block diagram of a programmable controller system. It is a flowchart figure which shows an example of the assistance process in a programming device. It is an example of a menu screen. It is a flowchart figure which shows an example of the object expansion | deployment process in a programmable controller. It is a flowchart figure which shows an example of the debug control process in a programmable controller. It is a structural example of the machine language object transmitted. It is an example of the debug information transmitted at the time of debugging. It is a figure for demonstrating expansion | deployment of a machine language object and an address table. It is a figure which shows the expansion | deployment state of the address table at the time of debugging. 6 is a functional configuration example of a programmable controller system according to a second embodiment. FIG. 10 is a diagram illustrating an example of a processing operation of a compiler according to the second embodiment. It is a figure which shows the specific example of an expansion | deployment order corresponding table. (A)-(c) is a figure which shows the specific example of a graphic language program. (A) is a diagram showing the expanded state of the address table during normal operation, and (b) is a diagram showing the expanded state of the address table during debugging.

Embodiments of the present invention will be described below with reference to the drawings.
1 and 2 are configuration examples of the programmable controller system of this example. In particular, FIG. 1 shows a detailed configuration example of the programming device, and FIG. 2 shows a detailed configuration example of the programmable controller.

  As shown in FIGS. 1 and 2, the programmable controller system of this example controls an arbitrary control device 300, and includes a programming device 100, a programmable controller (hereinafter referred to as PLC (programmable logic controller)). 200 etc. The programming device 100 and the PLC 200 are connected by a signal line 400. The PLC 200 is connected to a control device 300 that is various devices to be controlled. The PLC 200 controls the control device 300 by executing a sequence control program or the like.

  In general, the programming device 100 has a function for supporting a user to create an arbitrary sequence control program (its source code), a function for compiling a generated source code to generate a machine language object, A function of downloading the generated machine language object to the PLC 200 via the signal line 400 is provided.

  The sequence control program (source code) created by the user is usually created using, for example, a mnemonic language or a graphic language program such as a ladder language or FBD language. The function of the programming device 100 will be described later in detail.

  As an example of the hardware configuration of the programming device 100, for example, as shown in FIG. 1, a central processing unit (CPU) 101, an internal memory 104, a storage device 105, an input device 102 such as a mouse or a keyboard, a display or the like Device 103, input / output interface (I / O) 106, etc., which are connected to a common bus 107.

  The storage device 105 stores various data. The input device 102 notifies the CPU 101 of an input event from a mouse, a keyboard, or the like operated from the outside by an operator. The storage device 105 stores a predetermined application program in advance. The storage device 105 is, for example, a hard disk device.

  The display device 103 is composed of, for example, a liquid crystal display and displays various data and images according to, for example, an input event. The I / O 106 is connected to the signal line 400. The CPU 101 performs communication (data transmission / reception) with the PLC 200 via the I / O 106 and the signal line 400.

  The CPU 101 reads out and executes the application program stored in the storage device 105, for example, in the internal memory 104, thereby performing various processing functions (for example, processing functions of the user interface unit 11 and the compiler 12 in FIG. 3 described later; or For example, an interface function unit 61 and a processing function of the compiler 62 shown in FIG. These will be described later in detail with reference to FIG. 3 and FIG. 12, but the user interface unit 11 and the interface function unit 61 may basically be existing processing functions, and the user can select any sequence. This is a processing function that supports creation of a control program (source program). In this example, the source program is created using a mnemonic language or a graphic language such as a ladder language or FBD language as described above.

  Further, the CPU 101 compiles the sequence control program (source program) programmed by the user and converts it into an execution code (machine language object) that can be directly executed by the PLC 200 (CPU 211 in FIG. 2 described later). Also have. This processing function itself may be an existing process, but the compiler 12 and the compiler 62 further have a processing function described later. Details will be described later.

  In addition, the CPU 101 transmits an operation instruction (command / data, etc .; may include parameters, etc.) to the PLC 200 to the PLC 200 via the I / O 106 or the PLC 200 executes the sequence control program (machine language object). For example, a processing function for downloading to the PLC 200 via the I / O 106.

Note that the various processes may be executed while reading various data from the storage device 105 or writing various data to the storage device 105, for example.
The execution code (machine language object) of the sequence control program is downloaded to the PLC 200 via the I / O 106, whereby the CPU module 210 shown in FIG. 2 on the PLC 200 side is held in the user program memory 213 or the like. The execution code (old version or the like) of the sequence control program can be updated to the downloaded execution code (new version or the like).

A hardware configuration example of the PLC 200 includes a CPU module 210, an input / output module 222, and the like as shown in FIG.
In the example shown in FIG. 2, the CPU module 210 includes a CPU 211, a system program memory (FLASH) 212, a user program memory (RAM) 213, a PLC specific bus interface 214, a user data memory (RAM) 215, a system work memory (RAM 216, driver / receiver 217, etc., which are connected to the bus 218.

  The CPU module 210 is connected to the input / output module 222 via the PLC specific bus interface 214. The input / output module 222 is connected to the control device 300. The CPU 211 can communicate (data input / output) with the control device 300 via the PLC specific bus interface 214, the input / output module 222, and the like. The CPU 211 can communicate with the programming device 100 via the driver / receiver 217 or the like.

  The PLC 200 cyclically executes the sequence control program (execution code: machine language object) held in the user program memory 213 through system initialization after power-on or reset start, The control device 300 is configured to be controlled at a control cycle.

  The configuration shown in FIG. 2 is a general configuration of an existing PLC and will not be described in detail. For example, a user application memory 213 stores a predetermined application program in advance, and the CPU 211 By reading and executing this application program, for example, the processing of various functional units (object development unit 25, debug control unit 26, program execution unit 27, etc.) shown in FIG. 3 is realized. The address table 24 of FIG. 3 is stored in the user data memory 215, for example, but is not limited to this example.

FIG. 3 is a functional configuration diagram of the programmable controller system.
The programming device 100 (programming loader), as described above, supports a user to create an arbitrary program / source code (such as the source program of the sequence control program) by the user (the user interface unit 11 shown in the figure), A compiling function (the illustrated compiler 12) for converting to a machine language object is provided.

  The machine language object (execution code) generated by being compiled by the programming device 100 is downloaded to a target such as the PLC 200 (assuming that the download function is not shown).

  The user describes and creates an arbitrary sequence control program (source code) in the mnemonic language, or a graphical language such as a ladder language or FBD language, by the user interface unit 11. The user interface unit 11 passes the created source code to the compiler 12.

  The compiler 12 compiles the passed source code to generate and store two types of machine language objects. That is, the compiler 12 compiles the passed source code, generates and outputs an optimized machine language object 13, and also generates and outputs a non-optimized machine language object 15, which is stored in a storage area (not shown). Store. Thereafter, the optimized machine language object 13 and the non-optimized machine language object 15 are downloaded to the PLC 200 via the communication unit 14, respectively.

  The optimized machine language object 13 is as described in the above background art, and is formed by changing the execution order of programs, deleting unnecessary variables, and the like during optimization. On the other hand, the non-optimized machine language object 15 is a machine language object generated by normal compilation that is not optimized, and thus enables source code level debugging by actual machine debugging.

  A data packet (including a machine language object) downloaded to the PLC 200 includes an identification number 41, a type 42, and a machine language object (machine language object body) 43 as shown in FIG.

  The identification number 41 is, for example, an arbitrary number (for example, a serial number or the like) that the compiler 12 gives to the generated machine language object (the optimized machine language object 13 and the non-optimized machine language object 15). , An identifier for uniquely identifying the source code. For example, the optimized machine language object 13 and the non-optimized machine language object 15 generated from the same source code have the same identification number. Alternatively, the identification number is a unique ID unique to each source code (especially POU), which makes it non-optimal for machine language objects generated from any source code (even if it is optimized) It may be considered that the identification number of the source code of the generation source is given. Thus, for example, an example described later with reference to FIGS. 10 and 11 (details will be described later).

  The machine language object 43 is the machine language object itself generated by the compiler 12, and is the optimized machine language object 13 or the non-optimized machine language object 15.

  The type 42 is a type code indicating whether the machine language object 43 is the optimized machine language object 13 or the non-optimized machine language object 15. Here, the machine language object 43 is an optimized machine language object 13 when the type 42 = '1', and is a non-optimized machine language object 15 when the type 42 = '2'. .

  As shown in FIGS. 10 and 11 later, the data packet basically stores both the optimized machine language object 13 and the non-optimized machine language object 15 generated from the same source code. Is.

Communication between the programming device 100 and the PLC 200 is performed via the communication unit 14 and the communication unit 21 shown in the figure.
On the other hand, the PLC 200 has various functional units such as an object expansion unit 25, a debug control unit 26, and a program execution unit 27 shown in FIG.

  When the object expansion unit 25 receives the data packet transmitted from the programming device 100 by the communication unit 21, when the type 42 of the data packet is “1”, the object expansion unit 25 converts the machine language object 43 into the optimization machine language. The object 22 is stored in the user program memory 213. On the other hand, when the type 42 of the received data packet is “2”, the machine language object 43 is stored in the user program memory 213 as the non-optimized machine language object 23. Further, the object expansion unit 25 writes the storage address (such as the start address of the storage area) of the optimized machine language object 22 on the user program memory 213 into the address table 24 (details will be described later).

  The PLC 200 has a program execution unit 27 that sequentially executes machine language objects. The program execution unit 27 stores address data (usually the storage address of the optimized machine language object 22) stored in the address table 24. , The address data is indirectly addressed, and the machine language object held at the address destination is executed.

  The program execution unit 27 is cyclically controlled as described above by being called (called) by a program execution management unit (not shown) at predetermined intervals, for example, but is not limited to this example. As described above, since the storage address of the optimized machine language object 22 is written in the address table 24 during normal operation (PLC operation), the program execution unit 27 executes the optimized machine language object 22. become.

  On the other hand, during debugging, a debug start notification is transmitted from the programming device 100. The PLC 200 that has received the debug start notification rewrites the address data in the address table 24 to the storage address of the non-optimized machine language object 23 (such as the start address of the storage area) by the debug control unit 26. Therefore, at the time of debugging, when the program execution unit 27 executes the machine language object by referring to the address data in the address table 24 as described above, the non-optimized machine language object 23 is executed.

  Thereafter, at the end of debugging, a debugging completion notification is transmitted from the programming device 100. The PLC 200 that has received the debug completion notification rewrites the address data in the address table 24 to the storage address of the optimized machine language object 22 by the debug control unit 26. That is, the state is returned to the normal state (a state in which the optimized machine language object 22 is executed).

  In this way, the PLC 200 switches the machine language object to be executed between the normal time and the debug time. That is, an optimized machine language object is executed in normal times, and a machine language object that is not optimized (debuggable) is executed in debugging.

  That is, the storage address of the optimized machine language object 22 is registered in the address table 24 during normal time, and the storage address of the non-optimized machine language object 23 is registered in the address table 24 during debugging. The machine language object can be switched and executed. This makes it extremely easy to debug the PLC 200 that normally executes the optimized machine language object. Details will be described later.

Here, a specific processing example of the programming device 100 will be described.
FIG. 4 is a flowchart showing an example of support processing in the programming device.
Note that the processing in FIG. 4 will be described as being performed by the overall control unit (not shown) that is not shown in FIG.

  In the processing example shown in FIG. 4, the overall control unit first displays a predetermined processing menu (step S1). This may be displayed every time arbitrary source code is created, or may be displayed according to a user instruction.

FIG. 5 is an example of this processing menu.
On the processing menu screen in the example of FIG. 5, at least various command buttons such as a compile start button 31, a debug start button 32, an end button 33, and a debug end button 34 are arranged. A user can select / designate a desired command by operating the input device 102 such as a mouse or a keyboard and selecting any of these buttons 31 to 34.

  Then, the overall control unit determines whether or not the compile start button 31 has been selected (step S2). If the compile start button 31 is not selected (step S2, NO), it is subsequently determined whether or not the debug start button 32 is selected (step S6).

  When the compile start button 31 is selected (step S2, YES), the processes of steps S3 to S5 are executed. That is, first, the optimized machine language object 13 is generated by optimizing and compiling the source code (step S3). Also, compile the source code without optimization (perform normal compilation; it may be called non-optimized compilation), and de-optimize it as a normal (debuggable) machine language object A machine language object 15 is generated (step S4). Then, the generated optimized machine language object 13 and non-optimized machine language object 15 are downloaded to the PLC 200 via the communication unit 14 (step S5). Then, the process proceeds to step S6.

  Here, the compiler 12 in the programming device 100 may be regarded as comprising two compilers, for example, an optimization compiler and a non-optimization compiler. In this example, the optimization compiler operates in step S3, and the non-optimization compiler operates in step S4.

  Alternatively, the compiler 12 may be regarded as having two functions, for example, the optimized compilation function in step S3 and the non-optimized compilation function in step S4. In this example, of course, the compiler 12 generates the optimized machine language object 13 by performing the process of step S3 with the function to be optimized, and performs the process of step S4 with the function that is not optimized to perform the process of step S4. 15 will be generated. However, it can be considered that the one having such two functions is essentially the same as the one composed of the two compilers.

  In the example of the two functions, the overall control unit may switch the two functions (modes) by giving a predetermined parameter to the compiler 12, for example. That is, for example, the process of step S3 is executed by giving the parameter of the optimization mode to the compiler 12, and the process of step S4 is executed by giving the parameter of the non-optimization mode to the compiler 12.

  As described above, the optimized machine language object 13 and the non-optimized machine language object 15 are generated by using two compilers or by switching the mode of one compiler.

  The optimized machine language object 13 and the non-optimized machine language object 15 are given the identification numbers for uniquely identifying the source code, and the correspondence between the identification numbers and the source code is easily managed. As described above, a predetermined correspondence table (not shown) may be created at the time of compilation.

Next, the process after step S6 is demonstrated.
First, as described above, in step S6, it is determined whether or not the debug start button 32 has been selected.

  If the debug start button 32 is not selected (step S6, NO), the process proceeds to step S13 to determine whether or not to end the present process (support process). This determination is made, for example, to determine whether or not the end button 33 of the process menu in FIG. 5 has been selected. If the user selects the end button 33 (step S13, YES), this process is performed. Ends. On the other hand, if the end button 33 has not been operated yet (step S13, NO), the process returns to step S1.

On the other hand, if the debug start button 32 is selected by the user (step S6, YES), the processing of steps S7 to S12 is executed.
That is, first, “breakpoints” are set at locations where the PLC processing should be stopped at the time of debugging (which is arbitrarily determined by the user; usually, a plurality of locations) (step S7). This allows the user to set a desired “breakpoint” location on this screen, for example, by displaying a breakpoint setting screen (not shown).

  The setting of “breakpoint” will be described later. “Breakpoint” is a kind of marker (identifier) for temporarily suspending (pausing) program execution at a position corresponding to an arbitrary position in the source code. Therefore, the realization method may be in any form. In the following description, as an example, a method of inserting a breakpoint processing code (break instruction) is used.

  Subsequently, a debug start notification is transmitted to the PLC 200 (step S8). Note that, for example, debug information shown in FIG. 9 (information about a machine language object to be debugged and a “breakpoint” portion) to be described later is added to the debug start notification.

  Then, the process waits until the process completion notification is returned from the PLC 200 in response to the debug start notification. When the process completion notification is received (YES in step S9), the process proceeds to step S10. The process completion notification is a notification indicating that the breakpoint processing code insertion process (described later) has been completed on the PLC 200 side (preparation has been completed on the PLC 200 side).

  The process in step S10 is an existing process for “real machine debugging”, and is not described in detail here. For example, the state of the PLC 200 is displayed (for example, a status display when the PLC 200 breaks) or the like. It is a process for performing. The user performs a predetermined debugging work while referring to the status display for each breakpoint, for example, and operates the debug end button 34 in FIG. 5 when the debugging work is completed. Thereby, it is determined that the debugging process is finished (step S11, YES), and the process proceeds to step S12.

In the process of step S12, a debug completion notification is transmitted to the PLC 200 via the communication unit 14. And the determination process of said step S13 is performed.
On the other hand, the PLC 200 executes, for example, the processing shown in FIGS.

FIG. 6 is a flowchart showing an example of object expansion processing in the programmable controller.
FIG. 7 is a flowchart illustrating an example of debug control processing in the programmable controller.

  First, the process of FIG. 6 will be described. Note that the process of FIG. 6 may be regarded as the process of the object development unit 25. When the machine language object is downloaded from the programming device 100 side in the process of step S5, the process of FIG. 6 is executed.

  That is, first, it is determined whether or not the received machine language object is optimized (step S20). As already described, this is determined with reference to the received packet type 42. That is, when the type 42 is “1”, it is determined that the type 42 is optimized (step S20, YES), and the process proceeds to step S21. If the type 42 is “2”, it is determined that the type 42 is not optimized (NO in step S20), and the process proceeds to step S23.

  In step S21, the machine language object 43 of the received packet is stored in the user program memory 213 as the optimized machine language object 22. For example, the received machine language object 43 is transferred to an arbitrary storage area in an optimization machine language object storage area (not shown) in the user program memory 213 (predetermined; storage area α).・ It is to be stored. Further, the identification number 41 of the received packet and the transfer destination address (storage address; the start address of the storage area in the storage area α) of the machine language object 43 are associated with each other and stored in a backup area (not shown). May be.

  Following the processing of step S21, the transfer destination address (storage address; the top address of the storage area in the storage area α, etc.) of the machine language object 43, which is an optimized machine language object, is written into the address table 24 ( In step S22), the process is terminated.

  On the other hand, if the determination in step S20 is NO as described above, step S23 is executed. In step S23, the machine language object 43 of the received packet is stored in the user program memory 213 as the non-optimized machine language object 23. For example, the machine language object 43 is transferred to an arbitrary storage area in a non-optimized machine language object storage area (not shown) in the user program memory 213 (predetermined; storage area β). To store. Further, the identification number 41 of the received packet and the transfer destination address (storage address; the start address of the storage area in the storage area β) of the machine language object 43 are associated with each other and stored in a backup area (not shown). May be.

Next, the debug control process of FIG. 7 will be described below. Note that the process of FIG. 7 may be regarded as the process of the debug control unit 26.
The processing of FIG. 7 is a debug start notification (with debug information (an example shown in FIG. 9 is added) as described above) sent from the programming device 100 side in the processing of steps S7 and S8. Start by receiving. In the example shown in FIG. 9, the debug information includes an identification number 51 and a break position 52. The identification number 51 is the same as the identification number 41, but here means an ID indicating a machine language object corresponding to the source code to be debugged. The break position 52 is information indicating the position of the break point set in step S7, for example, and there may be a plurality of break positions.

  Based on the received debug information, the debug control unit 26 first refers to the backup area (not shown) to store the storage address (save area β) of the non-optimized machine language object 23 corresponding to the identification number 51. In the storage area within the storage area). Then, this storage address is overwritten on the address table 24 (step S30). As a result, the program execution unit 27 switches from a state in which the optimized machine language object 22 is executed to a state in which the non-optimized machine language object 23 is executed.

  Subsequently, the breakpoint position is recognized with reference to the break position 52, and a breakpoint processing code (break instruction) is inserted at the recognized position (step S31). Then, it is determined whether or not the insertion process has been completed (step S32). That is, since there may be a plurality of break positions 52, if there is an unprocessed break position 52, it is determined that the insertion process has not been completed (step S32, NO), and the process returns to step S31. The above breakpoint processing code is inserted.

  If the insertion process is completed for all break positions 52 (step S32, YES), the “processing completion notification” is transmitted to the programming device 100 via the communication unit 21 (step S33).

  Thereafter, although not shown or described in particular, in the PLC 200, the existing processing related to the debugging processing in the step S10 (execution of the non-optimized machine language object 23 by the program execution unit 27 and stop at the breakpoint and at that time) The status is transmitted to the programming device 100, etc.).

  On the other hand, the debug control unit 26 waits until the debug completion notification is sent from the programming device 100 (step S34). If the debug completion notification is received from the programming device 100 (YES in step S34), the stored content of the address table 24 is changed to the storage address of the optimized machine language object 22, and this process is terminated. .

Hereinafter, the programmable controller system of the present example will be described in more detail using specific examples.
In order to download a machine language object to the PLC 200 using the programming device 100, the user first uses a mnemonic language or a graphic language such as a ladder language or FBD language by the above function of the user interface unit 11 of the programming device 100. Create the source code of the control program described in. Next, the user compiles the created source code to generate a machine language object. This is realized, for example, by displaying the processing menu screen of FIG. 5 on the display 103 of the programming device 100 and selecting / instructing the compile start button 31. In response to this instruction, the compiler 12 compiles the source code to generate the optimized machine language object 13 and stores it in a storage area (not shown).

  The optimized machine language object 13 is a machine language object whose code size is reduced (that is, optimized) by changing the execution order of source code, effectively using registers, and the like. The optimized machine language object 13 is generated for each POU (Program Organization Unit), for example. The POU is a program constituent unit and is a language element of the PLC 200. Note that POU types include application programs and function blocks, and correspond to functions in the C language.

  The compiler 12 also generates a non-optimized machine language object 15 at the time of the above compilation, and stores it in a storage area (not shown). The non-optimized machine language object 15 is a machine language object that has not been optimized as described above (that is, a normal machine language object generated by a normal compile process. Real machine debugging is possible). A non-optimized machine language object 15 is also generated for each POU.

  When the above-described compiling process is completed, the programming device 100 downloads the generated two types of machine language objects (the optimized machine language object 13 and the non-optimized machine language object 15) to the PLC 200 via the communication unit 14. .

  At this time, as already described, for example, as shown in FIG. 8, the machine language object for each POU has the identification number 41 and the type 42 added to the machine language object (main body) 43. To be downloaded.

  The identification number 41 and the type 42 are as described above, and it may be considered that the identification number is given for each source code. Here, however, the source code is handled in POU units. Therefore, here, the identification number may be regarded as an identification ID unique to each POU. Thus, in this example, two machine language objects (optimized machine language object 13 and non-optimized machine language object 15) generated for any one POU have the same identification number (the identification number of that POU). ) Is given.

  When the PLC 200 receives a data packet (a packet in which the identification number 41 and the type 42 are added to the machine language object (main body) 43) from the programming device 100, the PLC 200 stores the machine language object 43 in the user program memory 213. At the same time, if it is an optimized machine language object, its storage address is registered in the address table 24.

  Here, for example, as shown in FIG. 10, it is assumed that the received data packet 55 includes four machine language objects (55a, 55b, 55c, 55d). As shown in FIG. 10, the identification number 41 and the type 42 are added to each of these four machine language objects (55a, 55b, 55c, 55d).

  Here, as shown in FIG. 10, the machine language objects 55a and 55b are of the type 42 = '1' (that is, the optimized machine language object), and the machine language objects 55c and 55d are of the type 42 = '2' ( That is, it is assumed that it is a non-optimized machine language object). The machine language objects 55a and 55c are generated from the same POU and are given the same identification number (identification number 1). Similarly, the machine language objects 55b and 55d are generated from the same POU and are given the same identification number (identification number 2).

  Here, the optimized machine language object storage area (storage area α) in the user program memory 213 is address 0 to 7FFF, and the non-optimized machine language object storage area (storage area β) is address 8000. It shall be after that.

  In the case of the above specific example, the PLC 200 that has received the data packet 55 first determines that the machine language objects 55a and 55b are optimized machine language objects as described above. Transfer / store in area (storage area α). This is stored in order of identification numbers (for example, in ascending order of numbers) with reference to the identification number 41, but is not limited to this example. Further, in this example, management is performed by dividing into 1000 addresses. Thus, for example, as shown in FIG. 10, the machine language object 55a is stored in the area of the start address = 0 address, and the machine language object 55b is stored in the area of the start address = 1000 address (and usually the free area is Will occur).

  Further, the top addresses (address 0 and address 1000) of these storage areas are registered in the address table 24 as shown. That is, “0000” is stored in the address field for the identification number 1 in the address table 24, and “1000” is stored in the address field for the identification number 2. The head addresses (address 0 and address 1000) of these storage areas are stored in a backup area (not shown) in association with the machine language object identification number stored in the storage area.

  On the other hand, since the machine language objects 55c and 55d are determined to be non-optimized machine language objects as described above, they are transferred and stored in the non-optimized machine language object storage area (storage area β). This is also stored in order of identification numbers (for example, in ascending order of numbers) with reference to the identification number 41, but is not limited to this example. Thus, for example, as shown in FIG. 10, the machine language object 55c is stored in the area of the start address = 8000, and the machine language object 55d is stored in the area of the start address = 9000.

  The head addresses (addresses 8000 and 9000) of each storage area are stored in a backup area (not shown) in association with the identification number of the machine language object stored in the storage area. However, since these are non-optimized machine language objects, they are not registered in the address table 24 (later registered temporarily in the debugging process).

  As shown in the figure, both machine language objects 55a and 55c have the identification number "1". This means that the machine language object 55a is generated by performing optimization compilation for the same POU, and the machine language object 55c is generated by performing non-optimization compilation. The same applies to the machine language objects 55b and 55d (both have an identification number “2”).

  As described above, the PLC 200 classifies the received plurality of machine language objects into optimized machine language objects and non-optimized machine language objects, and then assigns them to respective storage areas (α, β), for example, in the order of identification numbers. Store.

  Thereafter, the PLC 200 refers to the address table 24 and executes a control program (machine language object). That is, referring to the address table 24, the address data of the address table 24 is indirectly addressed and the machine language object is executed. Normally, the storage address of the optimized machine language object 22 (the start address of the storage area) is registered in the address table 24 as described above, so the PLC 200 executes the optimized machine language object 22. , Speeding up.

  On the other hand, when debugging, the user selects and designates the debug start button 32 on the menu screen of the programming device 100 as described above to start the debugging process. The user first sets a breakpoint in a desired source code. That is, a desired source code is opened, and breakpoints are set at arbitrary locations (lines, etc.) (may be set at a plurality of locations). However, this source code is not new, but is a source code of a program that has already been compiled and the machine language object has been downloaded to the PLC 200.

  The identification number is not limited to an example of an ID for identifying a source code. For example, when a machine language object is generated by compiling a source code, the identification number is generated and assigned to the machine language object. It may be a thing. However, even in this case, as already described, when a plurality of (two) machine language objects are generated from the same source code, the same identification number is assigned to the plurality of (two) machine language objects. Will be.

  Here, when compiling the source code, the programming device 100 associates the file name (source code name) with the machine language object identification number obtained by compiling the table (not shown; source code). An identification number correspondence table) is held in a storage area (not shown). Thus, the machine language object identification number corresponding to the source code name of the source code opened by the user can be obtained by referring to this source code identification number correspondence table.

  Then, based on the acquired identification number and the breakpoint setting content by the user, the debug information shown in FIG. 9 is generated. That is, the programming device 100 recognizes the position (line or the like) of the breakpoint designated by the user, sets this as the break position 52 of the debug information in FIG. 9, and uses the acquired identification number as the identification number 51. Debug information is generated. Then, this debug information is transmitted to the PLC 200.

However, what has been described above is an example, and the identification number may be assigned in advance for each POU.
In the example shown in FIG. 11, the debug information has the identification number 51 = “2” and the break position 52 = “2”.

  Here, as a conventional technique, the compiler, for example, when the source code is a mnemonic language or the like (in other words, not a graphic language program), each line of the source code is compiled by compiling the source code. It records which position (which row; however, it is not necessarily a one-to-one relationship) of the machine language object. That is, it is possible to associate each line of the source code with each position (each line) of the machine language object.

  As a result, in the programming device 100, since the position (line) on the machine language object corresponding to the breakpoint setting position (line) by the user in the source code is known, this is set as the break position 52. Therefore, when the break position 52 = '2' as in the example of FIG. 11, the position on the machine language object corresponding to the breakpoint setting position on the source code is the second line. (Note that the breakpoint setting position on the source code is not understood even if only FIG. 11 is seen. For example, it may be the first line or the second line).

  Further, the above is not limited to the case where the source code is a mnemonic language or the like, but is substantially the same when the source code is a graphic language program. That is, when the user sets a breakpoint at an arbitrary position (graphic) on an arbitrary graphic language program (source code), the programming device 100 sets a position (line) on a machine language object corresponding to this position (graphic). Therefore, this is set as the break position 52. For example, an arbitrary graphic language program (source code) is temporarily converted into intermediate code. At this time, the graphic can be converted into intermediate code according to a certain rule. The compiler 12 can record the position (line) of the converted intermediate code. Therefore, when a breakpoint is set on the graphic language program (source code), the position (line) on the intermediate code corresponding to the breakpoint setting position (graphic) on the source code is also known.

  Therefore, if such a breakpoint position (line) on the intermediate code is recorded, after that, when this intermediate code is converted into a machine language object, in the same manner as in the case of the mnemonic language or the like, Since the break point position (line) on the machine language object is known, this is used as the break position 52 described above.

  When receiving the debug information as in this example, the PLC 200 first sets the address “1000” held in the address field for the identification number “2” in the address table 24 according to the identification number 51 = “2”. The non-optimized machine language object 55d, which is the non-optimized machine language object with the identification number = “2”, is updated to point to the stored address (that is, updated to “9000”). The address “9000” can be acquired by referring to the backup area (not shown). As described above, when the downloaded non-optimized machine language object is transferred / stored in the storage area β, the non-optimized machine language object is stored in the backup area (not shown) in association with its identification number. Since the address is stored, the storage address (here, “9000”) corresponding to the identification number = “2” can be acquired by referring to the address.

  After updating the address field for the identification number “2” in the address table 24 in this way, the PLC 200 subsequently updates the non-optimized machine language object 55d with the identification number “2” according to the break position 52 of the debug information. Insert breakpoint processing code (break instruction) at the indicated location (line). In the example shown in FIG. 11, since the break position 52 of the debug information is “2”, the breakpoint processing code is inserted in the second line of the non-optimized machine language object 55d. However, the number of break positions 52 is not limited to one, and a plurality of break positions 52 may be provided, and a breakpoint processing code is inserted into a corresponding place (line) for each.

Then, when the breakpoint processing code is inserted in all the corresponding portions, the processing completion notification is transmitted to the programming device 100.
Thereafter, the program execution unit 27 of the PLC 200 executes the non-optimized machine language object 23 (here, 55d) for the POU with the identification number “2”. Then, when the breakpoint processing code (inserted in the second line in the above example) is executed while the object 55d is being executed, the execution of the object 55d is stopped and a standby state is entered. Then, for example, the program breaks (stops) and predetermined data (for example, the register value of the CPU 211 and the input / output data of the input / output module 222) are transmitted to the programming device 100.

  As described above, the non-optimized machine language object 23 is executed only for the POU with the identification number “2”, and the optimized machine language object 22 is continuously executed for the other POUs. .

  After receiving the processing completion notification from the PLC 200, for example, the programming device 100 waits for reception of the predetermined data transmitted from the PLC 200 at the time of the break, and every time the predetermined data is received, By displaying this data (the register value, the input / output data, etc.) on the display unit 103, the break state is notified to the user (debugging process). The user selects and operates the debug end button 34 at the end of the debug operation, and accordingly, the programming device 100 transmits the debug completion notification to the PLC 200.

  The PLC 200 that has received the debug completion notification switches the content stored in the address table 24 from the debug time to the normal time. That is, the address “9000” held in the address field for the identification number “2” in the address table 24 is returned to the original address “1000”. Thus, the state returns to the state in which the optimized machine language object 22 (55b) is executed for the POU with the identification number “2”. The PLC 200 further deletes the breakpoint processing code inserted in the non-optimized machine language object 23 (55d) having the identification number “2”. In the above example, the breakpoint processing code inserted in the second line of the non-optimized machine language object 55d is deleted. In this way, the PLC 200 returns from the debug state to the operation state (normal time). In this example, the execution of the optimized machine language object 22 is resumed for the POU with the identification number “2”, and the optimized machine language object 22 is continuously executed for the other POUs.

  Note that the PLC 200 is usually configured with machine language objects corresponding to a plurality of POUs, and the plurality of machine language objects operate in cooperation to execute predetermined control processing. When the address data is registered in the address table 24 at the time of switching from the operating state to the debug state and the address data is registered in the address table 24 at the time of returning from the debug state to the operating state, the PLC 200 controls the control device 300. It is desirable to execute in synchronization with the control cycle for controlling.

The embodiment described above is referred to as Example 1.
Here, as in the first embodiment, two types of machine language objects of optimization and non-optimization are generated and downloaded to the PLC side by two compilers on one source code on the programming device side, and downloaded to the PLC side. In the case of a configuration in which both of these two types of machine language objects are executed (with different execution times), the execution logic (calculation results) of these two types of machine language objects must be the same. If the operation results of two types of machine language objects related to the same source code are different, if these two types of machine language objects are switched and executed, the operation of the system may become unstable and may give the presence to the user. .

  However, if the source code is written in a mnemonic language, a PLC program (a program in which a plurality of graphic elements are arranged at arbitrary positions) is created using a graphic language such as a ladder language or FBD language. In the case of the configuration using two compilers as described above, the calculation results of two types of machine language objects related to the same source code may be different. In other words, there is a possibility that the expansion order of the graphic elements at the time of compilation affects the calculation result (the calculation results differ if the expansion order of the graphic elements is different).

  The reason for this is that in the case of graphic languages, the basic rules for the expansion order of graphic elements are from top to bottom and from left to right. Since it can be arranged in the size and position, and the combination of connections between graphic elements can be freely set, the expansion order cannot be uniquely determined only by basic rules. Because there exists.

  As described above, the two machine language objects generated by compiling the same source code separately with two compilers have different calculation results mainly due to the difference in the expansion order of the graphic elements. There is a possibility. In the second embodiment, such a problem is prevented from occurring in the configuration of the first embodiment.

Hereinafter, Example 2 will be described in detail.
FIG. 12 is a functional configuration example of the programmable controller system according to the second embodiment.
The illustrated programmable controller system includes a development support device (loader) 60, a PLC (target) 80, and the like.

The development support device 60 has substantially the same function as the programming device 100, and further has the function (function for solving the above problem) in the second embodiment.
The development support apparatus 60 includes various function units such as an interface function unit 61, a compiler 62, and a communication function unit 63. The development support device 60 also includes a screen (display) 64, an input device 65, and the like.

  The interface function unit 61 and the communication function unit 63 may be the same as the user interface unit 11 and the communication unit 14 in FIG. 1, and the description thereof will be omitted, but the user can perform desired control depending on the function of the user interface unit 11. The source code 66 of the program is created.

  The basic function of the compiler 62 may be the same as that of the compiler 12 of FIG. That is, the compiler 62 is composed of, for example, two compilers, and an arbitrary source code 66 is input, and a machine language object corresponding to the source code 66 is generated by each of the two compilers. Thus, the compiler 62 generates two types of machine language objects (optimized machine language object 67 and debuggable machine language object 68).

  The optimized machine language object 67 and the debuggable machine language object 68 may be basically the same as the optimized machine language object 13 and the non-optimized machine language object 15 shown in FIG. That is, the optimized machine language object 67 is generated by optimizing and compiling the source code, like the optimized machine language object 13. Similar to the non-optimized machine language object 15, the debuggable machine language object 68 is generated by performing normal compilation on the source code.

  However, from the above, there may be a case where the calculation result is different between the optimized machine language object 13 and the non-optimized machine language object 15 (the development order of the graphic elements at the time of generation is different). The calculation results are always the same between the object 67 and the debuggable machine language object 68 (the development order of the graphic elements at the time of generation is the same), and there is no possibility that the calculation results are different.

  In order to realize this, the compiler 62 generates an expansion order correspondence table 69 indicating the graphic element expansion order, for example, when the optimized machine language object 67 is generated. Then, the compiling process can be executed in the same expansion order as in the case of the optimized machine language object 67 by referring to the expansion order correspondence table 69 in the compiling process for generating the debuggable machine language object 68.

  In addition, the compiler 62 naturally performs memory address allocation processing of each variable (general processing and description thereof is omitted) when the optimized machine language object 67 is generated. Address information may be stored in the variable address correspondence table 70. In this case, the compiler 62 refers to the variable address correspondence table 70 at the time of the compilation process for generating the debuggable machine language object 68, so that the variable machine optimization object 67 can be obtained for each variable. The same memory address can be assigned.

  Note that the illustrated source code identification number correspondence table 71 may be regarded as the same as the “source code identification number correspondence table” described in the first embodiment, and is not particularly described here, but is described in the first embodiment. As described above, for example, the source code file name and the identification number of the source code (or the identification number assigned to the machine language object generated from the source code) are stored in association with each other.

  The two generated machine language objects (optimized machine language object 67 and debuggable machine language object 68) are downloaded to the PLC 80. The data packet configuration at the time of downloading may be the same as that in the first embodiment (shown in FIG. 8).

Here, the function of the illustrated PLC 80 may be the same as that of the PLC 200 (although it may be considered to be substantially the same even if the name and format are somewhat changed).
That is, the PLC 80 includes processing function units such as a program execution management function unit 81, an address table 82, and a communication function unit 83. The address table 82 and the communication function unit 83 may be regarded as the same as the address table 24 and the communication unit 21 in FIG. 1, and a description thereof is omitted here. The program execution management function unit 81 may be regarded as including all the functions of the object development unit 25, the debug control unit 26, and the program execution unit 27 of FIG. Therefore, although the description of the processing function of the PLC 80 is omitted here, the PLC 80 converts the downloaded optimized machine language object 67 and debuggable machine language object 68 into the optimized machine language object 84 shown in FIG. It is stored as a machine language object 85.

FIG. 13 shows an example of the processing operation of the compiler 62.
The example shown in FIG. 13 is an example in which intermediate code (intermediate language) is once generated from the source code and then a machine language object is generated from the intermediate code at the time of compilation processing. It is not limited. The machine language object may be generated directly from the source code without generating the intermediate code. The intermediate code (intermediate language) is, for example, C language, but is not limited to this example.

  In Patent Document 2, a control program (source file) described in a sequence processing language such as an instruction list is converted into a high-level programming language such as C language, and a program file of this C language expression is converted into a program file. There is a disclosure that an executable code can be obtained by compiling and generating an object file. In this way, using an intermediate language such as C language is an existing technology and will not be described further here.

  In the example shown in FIG. 13, the compiler 62 is composed of two compilers (compilers 62a and 62b). These two compilers are assumed to be of a type that once generates intermediate code as described above.

  The compiler 62a performs normal compilation processing to generate the debuggable machine language object 68. The compiler 62b performs optimization compilation processing to generate the optimized machine language object 67. In this example, the compilers 62a and 62b respectively generate intermediate code (intermediate code 1 and intermediate code 2) by front-end processing, and then generate machine language objects (68 and 67) by back-end processing.

  Conventionally, the intermediate code 1 and the intermediate code 2 may be different in the expansion order of the graphic elements at the time of generation. As described above, if the development order is different, there is a problem because the calculation result differs between when the optimized machine language object 84 is executed on the PLC 80 side and when the debuggable machine language object 85 is executed.

  On the other hand, in the compiler 62 of this example, when the compiler 62a first generates the intermediate code 1 by compiling the source code 66 (front-end processing), for example, a graphic according to a unique rule different from that of the compiler 62b. Although the element expansion order may be determined, this expansion order is stored in the expansion order correspondence table 69.

  Note that the optimization processing in the compiler 62b may be realized, for example, in back-end processing. For example, the compiler 62b has, for example, a C language compiler (not shown), and the C language compiler executes the back-end processing of the compiler 62b. The C language compiler is an existing general compiler for C language that has a function of generating a machine language by compiling a C language program, and also includes a processing function for the optimization. The configuration example shown in FIG. 13 has an advantage that optimization can be realized by using the optimization function of such an existing C language compiler, particularly when the intermediate language is C language.

FIG. 14 shows a specific example of the development order correspondence table 69.
In the illustrated example, in the development order correspondence table 69, an execution order (development order) 92 indicating the development order of each graphic element is registered in association with the graphic ID 91 which is an ID for identifying each graphic element. In the illustrated example, the expansion order (execution order) of the three graphic elements of graphic ID 91 = '1', '2', '3' is in the order of '1' → '3' → '2'.

  Then, after the compiling process is completed in the compiler 62a and the debuggable machine language object 68 is generated, the compiling process of the compiler 62b is started (or after the intermediate code 1 is generated). Then, it may be after the creation of the development order correspondence table 69 is completed). For example, when the compiler 62a completes its own compiling process, the compiler 62b may start the compiling process by passing the source code 66 to the compiler 62b. Alternatively, when the compiler 62a notifies the compiler 62b of the completion of processing, the compiler 62b may acquire the source code 66 and start the compilation process.

  Then, the compiler 62b executes compilation processing while referring to the expansion order correspondence table 69. As a result, also in the compiler 62b, the expansion order of the graphic elements is the same as in the compiler 62a. For example, in the example of FIG. 14, the expansion order of the graphic elements in the compiler 62 a is “1” → “3” → “2”, and the compiler 62 b performs compiling processing in the same expansion order. The intermediate code 2 is generated.

  Conventionally, the compiler 62b determines the expansion order according to its own rule (graphic element code generation rule), so the expansion order of graphic elements is, for example, “1” → “2” → “3”. Although there is a possibility, this method does not cause such a problem.

  As is well known, in the process of compiling the PLC control program, a process of allocating an arbitrary memory address to each variable (existing process) is also performed. In this method, the compiler 62 a The address information assigned to each variable at the time of generating one may be stored in the variable address correspondence table 70. In this case, the compiler 62b can also refer to the variable address correspondence table 70 to make the memory address assignment to each variable the same as the compiler 62a.

Although a specific example of the variable address correspondence table 70 is not particularly shown, for example, a memory address assigned to the variable is stored in association with the identification ID of each variable.
As described above, in this method, the two compilers 62a and 62b can make the expansion order of the graphic elements and the contents of the memory address assigned to each variable the same. Although a specific example of the variable address correspondence table 70 is not particularly shown, for example, information on the address assigned to the variable in association with the identification ID of each variable (for example, the start address and size of the assigned memory area). Is registered.

  The compiler 62a converts the intermediate code 1 into a machine language object by back-end processing, and generates a debuggable machine language object 68. The compiler 62b converts the intermediate code 2 into a machine language object by back-end processing, and generates an optimized machine language object 67. Here, as described above, the intermediate code 1 and the intermediate code 2 have the same expansion order of the graphic elements at the time of generation. Therefore, when the machine language objects (debuggable machine language object and optimized machine language object) of the intermediate code 1 and the intermediate code 2 are executed on the PLC 80 side, the above-described problem does not occur. That is, there is no concern that the operation results of the two types of machine language objects related to the same source code are different from each other, thereby causing a problem that the system operation becomes unstable.

  Needless to say, the debuggable machine language object 68 and the optimized machine language object 67 are downloaded to the PLC 80 and stored as the debuggable machine language object 85 and the optimized machine language object 84. In the PLC 80, the optimized machine language object 84 is executed in normal times, and is switched to the debuggable machine language object 85 in debugging. In the second embodiment, after the switching, the operation before the switching is calculated. There will be no situation such as different results, and system operation will not become unstable.

  FIG. 13 shows an example and is not limited to this example. For example, the compiler 62b may be executed first and then the compiler 62a may be executed. Of course, in this case, the compiler 62b generates the expansion order correspondence table 69 and the variable address correspondence table 70, and then the compiler 62a executes the compilation process with reference to the correspondence tables 69 and 70. As a result, the expansion order of the graphic elements is the same as that of the compiler 62b, and the memory address assigned to each variable is also the same as that of the compiler 62b.

  In this way, either one of the two compilers 62a and 62b (basically, the one that executes the process first) generates the expansion order correspondence table 69 and the variable address correspondence table 70, and the other is the correspondence table thereof. By executing the compiling process with reference to 69 and 70, the operation result differs between the debuggable machine language object 68 (85) and the optimized machine language object 67 (84) related to the same source code. This is avoided.

  Alternatively, FIG. 13 shows a case where the present technique is applied to a type of compiler that generates intermediate code. However, the present invention is not limited to such an example. This method can also be applied without problems to compilers that generate machine language objects.

FIG. 15 shows a specific example of the graphic language program.
FIG. 15A shows graphic elements of a graphic language program such as a ladder diagram and a function block diagram.

FIGS. 15B and 15C show specific examples of program description using function block diagrams.
The example of FIGS. 15A and 15B is not particularly described, but in the example of FIG. 15B, three graphic elements are arranged at arbitrary positions.

Hereinafter, the example of FIG. 15C will be described.
In this example, a graphic element 95 for calculating C = A + B and a graphic element 96 for calculating F = C + D are shown. Depending on which of the graphic elements 95 and 96 is executed first, the calculation result may differ. However, in the example shown in FIG. 15C, it is not clear which one of the graphic element 95 and the graphic element 96 is executed first.

  In other words, as described above, the order from left to right and top to bottom is the basic rule, but in the case of FIG. 15C, if the “left to right” rule is prioritized, the graphic element 95 is executed first. However, if the “top to bottom” rule is prioritized, the graphic element 96 may be executed first. Alternatively, in the case of FIG. 15C, it is unclear which of the graphic elements 95 and 96 is on the “from top to bottom” rule.

For example, suppose that the current memory holding values for the variables A, B, C, D, and F are A = 1, B = 2, C = 100, D = 10, and F = 0.
In this example, if the graphic element 95 is executed in the order of the graphic element 96, first, C = A + B = 1 + 2 = 3 and the value of C is updated from 100 to 3, and then F = C + D = 3 + 10 = 13. Therefore, the calculation results (memory holding values related to the variables A, B, C, D, and F after the calculation) are A = 1, B = 2, C = 3, D = 10, and F = 13.

  On the other hand, when the graphic element 96 is executed in the order of the graphic element 95 in the above example, first, F = C + D = 100 + 10 = 110 and the value of F is updated from 0 to 110, and then C = A + B = 1 + 2 = 3. Therefore, the calculation results (memory holding values related to the variables A, B, C, D, and F after the calculation) are A = 1, B = 2, C = 3, D = 10, and F = 110. As described above, the calculation results are different between the case where the graphic element 95 is executed in the order of the graphic element 96 and the case where the graphic element 96 is executed in the order of the graphic element 95.

  FIG. 16A is a diagram illustrating a specific example of the expanded state of the address table 82 during normal time, and FIG. 16B is a diagram illustrating the expanded state of the address table 82 during debugging. As shown in the figure, these contents are substantially the same as those shown in FIGS. 10 and 11, and the names in FIG. 12 are different from those in FIG. 3 (non-optimized machine language object → debuggable machine language object). For example, as shown in FIGS. 16 (a) and 16 (b).

  Accordingly, FIGS. 16A and 16B are not particularly described in detail here, but in the same way as in the first embodiment, in the second embodiment, two types of machine language objects are generated for each POU. In addition to downloading, it is possible to instruct execution of debugging (execution of debuggable machine language object) in units of POUs. Therefore, for example, in the entire control program, only the part (POU) required by the user can be switched to a debuggable machine language object and executed, thereby shortening the debugging work time and the work load. Can be achieved.

  The hardware configuration example of the development support device 60 and the PLC 80 according to the second embodiment may be the same as the programming device 100 and the PLC 200 according to the first embodiment. That is, it may be considered that the hardware configuration example of the development support apparatus 60 is as shown in FIG. 1, and the hardware configuration example of the PLC 80 is as shown in FIG. However, the present invention is not limited to this example.

  Further, the processing functions (reference numerals 61, 62, etc.) of the development support device 60 shown in FIG. It is realized by. Similarly, the processing functions (reference numeral 81 and the like) of the PLC 80 shown in FIG. 12 are realized by the CPU 211 executing, for example, an application program stored in advance in the user program memory 213, as in the case of the PLC 200. The debuggable machine language object 85 and the optimized machine language object 84 are stored in the user program memory 213.

  In the second embodiment, basically, in the specific examples of FIGS. 4 to 9 in the first embodiment, the processes in steps S3 and S4 may be slightly changed. That is, in the process of step S3, a process for generating the expansion order correspondence table 69 and the variable address correspondence table 70 is added. Further, in the process of step S4, for example, instead of determining the development order of the graphic elements according to a unique rule, by referring to the development order correspondence table 69, in the same order as the development order of the graphic elements in the process of step S3, Compile processing is realized by expanding graphic elements. In the process of step S4, the memory address assigned to each variable of the source code is further made the same as in the process of step S3 by referring to the variable address correspondence table 70. Except for these, it may be substantially the same as that of the first embodiment, so that it will not be described here.

  From the above, although not particularly illustrated, the development support device 60 (programming device) and the PLC 80 (programmable controller) of the second embodiment may be considered to have the following processing functions, for example.

First, the programming device (development support device 60) may be regarded as having a first compiler, a second compiler, and a download unit.
The first compiler compiles the source code of an arbitrary graphic language program according to the expansion order while determining the expansion order of each graphic element constituting the source code, and generates a first machine language object. At least the expansion order of the graphic elements is stored in a predetermined storage area (storage unit).

  The second compiler refers to the expansion order of each graphic element stored in the storage unit and compiles the source code according to the expansion order to generate a second machine language object.

The download unit downloads the first machine language object and the second machine language object to the programmable controller.
For example, one of the first machine language object and the second machine language object is a non-optimized machine language object that is a machine language object that can be debugged and generated by a normal compilation process. The other is an optimized machine language object that is an optimized machine language object generated by the optimization compilation process.

  On the other hand, the programmable controller (PLC 80) has a program execution unit that executes the optimized machine language object during normal operation and switches to the non-optimized machine language object during execution for debugging.

  Further, for example, the first compiler generates the first machine language object from the intermediate language after the intermediate language is once generated from the source code when the first machine language object is generated. Therefore, when the intermediate language is generated, the graphic elements are determined in the order of expansion and stored in the storage unit.

  In addition, for example, the second compiler generates the second machine language object from the intermediate language after generating the intermediate language from the source code once when generating the second machine language object. Then, the intermediate language is generated with reference to the expansion order of the graphic elements stored in the storage unit when the intermediate language is generated.

  Further, for example, the first compiler further stores, in the storage unit, information on a memory address assigned to each variable of the source code at the time of the compilation. On the other hand, the second compiler further allocates the same memory address as that of the first compiler to each of the variables by referring to the stored memory address information during the compilation.

For example, the programmable controller may further have the following configuration.
That is, the programmable controller is
A first storage area for holding the optimized machine language object; a second storage area for holding the non-optimized machine language object; and a storage address of the optimized machine language object or the non-optimized machine language object And an address table for registering the storage addresses.

  The program execution unit executes, for example, one of the optimized machine language object and the non-optimized machine language object in accordance with the storage address registered in the address table.

  In addition, the programmable controller, for example, by registering the storage address of the optimized machine language object in the address table, causing the program execution unit to execute the optimized machine language object, A debug control unit that causes the program execution unit to execute the non-optimized machine language object by registering a storage address of the non-optimized machine language object in the address table in accordance with a debug instruction from the programming device; It has further.

  Further, when the optimized machine language object and the non-optimized machine language object are downloaded from the programming device, the programmable controller stores the received optimized machine language object in the first storage area. The start address of the storage area is registered in the table, and the received non-optimized machine language object further includes an object transfer unit for storing in the second storage area.

  In addition, for example, the programming device transmits the debug instruction to the programmable controller, and accordingly, break position information indicating a stop position of execution of the non-optimized machine language object set arbitrarily is also described above. It further has a debug instruction unit for transmitting to the programmable controller.

  In the programmable controller, for example, when the debug control unit receives the break position information together with the debug instruction, in the non-optimized machine language object, the machine language object is placed at a predetermined position according to the break position information. Insert a break instruction to stop execution of.

  In addition, during execution of the non-optimized machine language object, the program execution unit stops execution of the non-optimized machine language object and transmits the stop state to the programming device along with execution of the break instruction. To do.

  Alternatively, the upper optimized machine language object is held in the first storage area in POU units, the non-optimized machine language object is also held in the second storage area in POU units, and the program execution unit is At the time of debugging, only the arbitrary POU is switched to the non-optimized machine language object and executed. This is because, for example, the debug information of FIG. 9 including the identification number is sent to the PLC side only for the POU specified by the user on the programming device side, and the non-optimized machine language only for this POU on the PLC side. Switch to the object and execute it.

  As described above, in the programmable controller system of the second embodiment, in the programming device (development support device; loader), both the normal machine language object and the optimized machine language object are generated by the two compilers. In addition, by making these two compilers match the development order of the graphic elements, it is possible to perform source code level debugging without decompilation or the like during debugging and without destabilizing the system operation.

DESCRIPTION OF SYMBOLS 11 User interface part 12 Compiler 13 Optimization machine language object 14 Communication part 15 Non-optimization machine language object 21 Communication part 22 Optimization machine language object 23 Non-optimization machine language object 24 Address table 25 Object expansion part 26 Debug control part 27 Program execution unit 31 Compile start button 32 Debug start button 33 End button 34 Debug end button 41 Identification number 42 Type 43 Machine language object (machine language object body)
51 Identification number 52 Break position 55 Data packet 55a, 55b, 55c, 55d Machine language object 60 Development support device (loader)
61 Interface Function Unit 62 Compiler 62a Compiler (Normal)
62b Compiler (optimization)
63 Communication function section 64 Screen (display)
65 Input device 66 Source code 67 Optimized machine language object 68 Debuggable machine language object 69 Expansion order correspondence table 70 Variable address correspondence table 71 Source code identification number correspondence table 80 PLC
81 Program Execution Management Function Unit 82 Address Table 83 Communication Function Unit 84 Optimization Machine Language Object 85 Debuggable Machine Language Object 91 Graphic ID
92 Execution order 95, 96 Graphic element 100 Programming device 101 Central processing unit (CPU)
102 Input Device 103 Display 104 Internal Memory 105 Storage Device 106 Input / Output Interface (I / O)
107 Common bus 200 Programmable controller (PLC)
210 CPU module 211 CPU
212 System program memory (FLASH)
213 User program memory (RAM)
214 PLC specific bus interface 215 User data memory (RAM)
216 System work memory (RAM)
217 Driver / receiver 218 Bus 222 Input / output module 300 Control device 400 Signal line

Claims (11)

A PLC system having a programming device and a programmable controller,
The programming device is:
The source code of an arbitrary graphic language program is compiled in accordance with the expansion order while determining the expansion order of the graphic elements constituting the source code to generate a first machine language object, and at least each of the graphic elements First compiler means for storing the expansion order in the storage means;
Second compiler means for generating a second machine language object by referring to the expansion order of the graphic elements stored in the storage means and compiling the source code according to the expansion order;
Download means for downloading the first machine language object and the second machine language object to the programmable controller ;
Either the first machine language object or the second machine language object is a non-optimized machine language object that is a machine language object that can be debugged and generated by a normal compilation process, and the other is an optimal A PLC system, which is an optimized machine language object, which is an optimized machine language object generated by an integrated compilation process . The programmable controller is
PLC system according to claim 1, wherein the normal running the optimization machine language objects, at the time of debugging have a program execution means for executing switching to the non-optimized machine language object. The first compiler means generates the first machine language object from the intermediate language after the intermediate language is once generated from the source code when the first machine language object is generated. When the intermediate language is generated, the graphic elements are determined in order of expansion and stored in the storage means,
The second compiler means generates the second machine language object from the intermediate language after the intermediate language is once generated from the source code when the second machine language object is generated. 3. The PLC system according to claim 1, wherein the intermediate language is generated with reference to the expansion order of the graphic elements stored in the storage means when the intermediate language is generated. The first compiler means further stores, in the storage means, information on a memory address assigned to each variable of the source code during the compilation,
The second compiler means further assigns the same memory address as that of the first compiler means to each variable by referring to the stored memory address information during the compilation. Item 4. The PLC system according to any one of Items 1 to 3 . The programmable controller is
A first storage area for holding the optimized machine language object;
A second storage area for holding the non-optimized machine language object;
An address table for registering a storage address of the optimized machine language object or a storage address of the non-optimized machine language object;
The program execution means for executing one of the optimized machine language object and the non-optimized machine language object according to a storage address registered in the address table;
Optimized machine language object execution means for causing the program execution means to execute the optimized machine language object by registering a storage address of the optimized machine language object in the address table;
Debugging control means for causing the program execution means to execute the non-optimized machine language object by registering a storage address of the non-optimized machine language object in the address table in accordance with a debug instruction from the programming device;
PLC system according to any one of claims 1 to 4, further comprising a. The programmable controller is
When the optimized machine language object and the non-optimized machine language object are downloaded from the programming device, the received optimized machine language object is stored in the first storage area and the storage address is stored in the address table. 6. The PLC system according to claim 5 , further comprising object transfer means for storing the non-optimized machine language object registered and received in the second storage area. The programming device transmits the debug instruction to the programmable controller, and accordingly, also transmits break position information indicating a stop position of execution of the non-optimized machine language object set arbitrarily to the programmable controller. A debug instruction means for performing
In the programmable controller,
When the debug control means receives the break position information together with the debug instruction, in the non-optimized machine language object, a break instruction for stopping execution of the machine language object at a predetermined position according to the break position information Insert
The program execution means stops execution of the non-optimized machine language object and transmits the stop state to the programming device along with execution of the break instruction during execution of the non-optimized machine language object. The PLC system according to claim 5 or 6, wherein The optimized machine language object is held in the first storage area in POU units,
The non-optimized machine language object is also held in the second storage area in POU units,
The PLC system according to any one of claims 5 to 7 , wherein the program execution means switches to the non-optimized machine language object only for an arbitrary POU at the time of debugging. A programming device in a PLC system having a programming device and a programmable controller, comprising:
The source code of an arbitrary graphic language program is compiled in accordance with the expansion order while determining the expansion order of each graphic element constituting the source code, and a first machine language object is generated. First compiler means for storing the expansion order in the storage means;
Second compiler means for generating a second machine language object by referring to the expansion order of the graphic elements stored in the storage means and compiling the source code according to the expansion order;
Download means for downloading the first machine language object and the second machine language object to the programmable controller ;
Either the first machine language object or the second machine language object is a non-optimized machine language object that is a machine language object that can be debugged and generated by a normal compilation process, and the other is an optimal A programming device for a PLC system, which is an optimized machine language object that is an optimized machine language object generated by an integrated compilation process . A computer of said programming device in a PLC system having a programming device and a programmable controller,
The source code of an arbitrary graphic language program is compiled in accordance with the expansion order while determining the expansion order of each graphic element constituting the source code, and a first machine language object is generated. First compiler means for storing the expansion order in the storage means;
Second compiler means for generating a second machine language object by referring to the expansion order of the graphic elements stored in the storage means and compiling the source code according to the expansion order;
Either the first machine language object or the second machine language object is a non-optimized machine language object that is a machine language object that can be debugged and generated by a normal compilation process, and the other is an optimal An optimization machine language object that is an optimized machine language object generated by the compile processing, and download means for downloading the non-optimized machine language object and the optimized machine language object to the programmable controller;
Program to function as. A debugging method in the programming device of a PLC system having a programming device and a programmable controller,
The source code of an arbitrary graphic language program is compiled in accordance with the expansion order while determining the expansion order of each graphic element constituting the source code, and a first machine language object is generated. Store the deployment order in the storage means,
The source code is compiled according to the expansion order with reference to the expansion order of the graphic elements stored in the storage means to generate a second machine language object,
Either the first machine language object or the second machine language object is a non-optimized machine language object that is a machine language object that can be debugged and generated by a normal compilation process, and the other is an optimal A debugging method characterized by being an optimized machine language object that is an optimized machine language object generated by an integrated compilation process .