Programmable logic controller, control method, storage medium and program product

Abstract

The invention provides a programmable logic controller, a control method, a storage medium and a program product. A user program is efficiently switched while operating a PLC. The PLC may include a processor to repeatedly execute a user program-based logical operation and a memory to store a value of a variable accessed according to the user program executed by the processor. An instruction to switch to a second user program that is an updated version of the first user program is issued while the processor is executing the first user program. Variable information is created for identifying a variable to be maintained and a variable to be changed by updating from a first user program to a second user program. An address storing a value of a variable to be maintained is maintained, and an address storing a value of a variable to be changed is allocated at a discontinuity of a logical operation in a case where the logical operation is stopped.

Description

Technical Field

[0001] The present invention relates to a programmable logic controller and a control method. Background Art

[0002] In factory automation, a programmable logic controller (PLC) is a core controller used to control industrial machines. The PLC controls industrial machines by executing user programs such as ladder diagrams.

[0003] When a certain correction point is found, the user program is changed or a command is added (JP 2001-125608 A).

[0004] On the other hand, in order to switch the PLC user program from the pre-change user program to the post-change user program, it is necessary to stop the PLC. In this case, the production line controlled by the PLC is stopped, resulting in a reduction in the production line's operating rate. On the other hand, there is also a method of switching user programs by temporarily stopping sequence control while operating the PLC. In this case, the production line's stoppage time is shortened. However, since it takes a lot of time to establish the relationship between the large number of variables used by the user program and their storage areas, it is difficult to switch user programs while operating the PLC. In other words, the larger the user program, the more difficult it is to rewrite the user program at high speed. Summary of the Invention

[0005] Therefore, an object of the present invention is to efficiently switch user programs while operating a PLC.

[0006] For example, the present invention provides a programmable logic controller, comprising:

[0007] A processor for repeatedly executing logical operations based on user programs;

[0008] a data memory for storing values ​​of variables accessed according to a user program executed by the processor; and

[0009] a memory management unit for, when the processor receives an instruction to switch to a second user program that is an updated version of the first user program while the processor is executing the first user program, maintaining addresses in the data memory that store values ​​of variables to be maintained based on variable information for identifying variables to be maintained and variables to be changed by updating from the first user program to the second user program, and for stopping the logical operation and allocating addresses in the data memory that store values ​​of variables to be changed at interruptions in the logical operation.

[0010] According to the present invention, user programs can be efficiently switched while operating a PLC. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a diagram showing a PLC system;

[0012] Figure 2 is a diagram showing a PC (setting support device);

[0013] Figure 3 is a diagram showing a basic unit;

[0014] Figure 4 is a diagram showing a transmission control unit;

[0015] Figure 5 is a flow chart illustrating a method of transferring an item;

[0016] Figure 6 is a flowchart showing the handling of global variables;

[0017] Figure 7 is a diagram showing an example of a change in an array;

[0018] Figure 8 is a diagram showing an example of a change in structure type;

[0019] Figure 9 is a diagram showing an instantiation of a functional block;

[0020] Figure 10 is a diagram showing an example of a storage area secured in a memory;

[0021] Figure 11 is a diagram showing a storage area of ​​an example;

[0022] Figure 12 is a diagram showing definition information, call tree, and instance ID;

[0023] Figure 13 is a diagram showing definition information, call tree, and instance ID;

[0024] Figure 14 is a flow chart illustrating a method of saving a value; and

[0025] Figure 15 is a flow chart illustrating a method of restoring a value. DETAILED DESCRIPTION

[0026] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the invention according to the claims, and not all combinations of features described in the embodiments are essential to the present invention. Two or more of the multiple features described in the embodiments may be combined in any manner. In addition, identical or similar configurations are denoted by the same reference numerals, and redundant descriptions will be omitted.

[0027] (1) PLC system

[0028] Figure 1 1 shows a configuration example of a programmable logic controller system (hereinafter referred to as a PLC system 1) according to an embodiment of the present invention. Figure 1 As shown, a PLC system 1 includes a PC 2, a setup support device configured to edit user programs such as ladder diagrams; a base unit 3, a programmable logic controller (PLC) configured to perform integrated control of various control devices installed in a factory, etc.; and multiple expansion units 113 to 115. In the PLC system 1, one or more expansion units 113 to 115 are connected to the base unit 3 via an expansion bus 500. The base unit 3 is sometimes also referred to as a CPU unit or main unit. Examples of expansion units 113 to 115 include various units such as motion units, input units, output units, input / output units (I / O units), analog conversion units, and communication units. Note that the motion control function, analog conversion function, and communication function connected to the expansion bus 500 can be recognized by the base unit 3 as expansion units built into the base unit 3. Furthermore, motor drivers 4a to 4c can be connected to the base unit 3 via an industrial network. The multiple motor drivers 4a to 4c drive motors 10a, 10b, and 10c, respectively.

[0029] The user program created by the PC 2 as the setting support device may be created using a graphic programming language such as ladder language or flowchart format motion program, or may be created using a high-level programming language such as ST language or C language.

[0030] The base unit 3 includes a display unit 5 and an operation unit 6. The display unit 5 can display the operating status of the motor drivers 4a to 4c. The display unit 5 can switch the display content according to the operation content of the operation unit 6. The display unit 5 generally displays the current values ​​(device values) of the devices in the PLC system 1 and information related to errors occurring in the PLC system 1 (the presence or absence of alarms or warnings). The term "device" is used to indicate an area on the memory provided for storing device values ​​(device data) and can be referred to as device memory.

[0031] Device values ​​are information indicating the input status from input devices, the output status to output devices, or the status of internal relays (auxiliary relays), timers, counters, or data memory configured in the user program. Device value types include bit and word types. A bit device stores a 1-bit device value. A word device stores a word's device value.

[0032] Motor drivers 4a to 4c are provided to expand the functionality of the PLC system 1. Motors 10a to 10c are controlled by the motor drivers 4a to 4c, respectively. The motor drivers 4a to 4c supply power to the motors 10a to 10c and control the amount of rotation, etc., based on commands from the base unit 3. Examples of the motors 10a to 10c include servo motors and stepper motors.

[0033] PC 2 is a computer for providing a development environment for the PLC system 1. PC 2 is, for example, a portable notebook or tablet personal computer and includes a display unit 7 and an operating unit 8. A ladder diagram program is created using PC 2, which is an example of a user program configured to control the PLC system 1. The created ladder diagram program is converted into mnemonics in PC 2. PC 2 is connected to the basic unit 3 of the PLC system 1 via a communication cable 9a such as a universal serial bus (USB) and sends the ladder diagram program converted into mnemonics to the basic unit 3. The basic unit 3 converts the ladder diagram program into machine code and stores the machine code in a memory provided in the basic unit 3. Note that the mnemonics are transmitted to the basic unit 3 here, but the present invention is not limited to this. For example, PC 2 can convert the mnemonics into intermediate code and send the intermediate code to the basic unit 3, or can convert the mnemonics into object code and send the object code to the basic unit. In addition, these can be mixed.

[0034] Note that although Figure 1 Although not shown in the figure, the operating unit 8 of the PC 2 may include a pointing device such as a mouse connected to the PC 2. In addition, the PC 2 may be configured to be detachably connected to the base unit 3 via a communication cable 9a other than a USB. In addition, the PC 2 may be wirelessly connected to the base unit 3 without using the communication cable 9a. In this case, the communication cable 9a may be understood to represent a wireless link.

[0035] The basic unit 3 and the motor driver 4a are connected by a communication cable 9b, and can communicate with each other via the communication cable 9b (for example, periodic communication and message communication). The motor driver 4a and the motor driver 4b are connected by a communication cable 9c, and can communicate with each other via the communication cable 9c. The motor driver 4b can communicate with the basic unit 3 via the communication cables 9b and 9c. The motor driver 4b and the motor driver 4c are connected by a communication cable 9d, and can communicate with each other via the communication cable 9d. In addition, the motor driver 4c can communicate with the basic unit 3 via the communication cables 9b, 9c and 9d.

[0036] Although the motor drivers 4a to 4b are connected in this example, the number of motor drivers 4 may be one or more. The manufacturers of the motor drivers 4a to 4c may be different from or the same as each other. Here, for convenience of description, it is assumed that the motor drivers 4a to 4c are manufactured by different manufacturers.

[0037] Hereinafter, when describing common matters, the motor drivers 4a to 4c are represented as the motor driver 4. Similarly, when describing common matters, the motors 10a to 10c are represented as the motor 10.

[0038] The base unit 3 has the function of executing a sequence control program written in ladder diagram (LD) or ST. In addition, the base unit 3 of this embodiment may also have a communication function and a motion control function. The communication function and motion control function of the base unit 3 are treated as an expansion unit built into the base unit 3.

[0039] The PLC's base unit 3 and each expansion unit 113 to 115 each execute an iterative process. The timing of program execution by the base unit 3 can be aligned with the timing of iterative processing by the expansion units 113 to 115, or data exchange can be performed synchronously. This function is referred to as an "inter-unit synchronization function." The motion control function and sequence control function included in the base unit 3 can also be aligned in process execution timing and data exchange can be performed synchronously through the "inter-unit synchronization function."

[0040] (2) Set up support equipment

[0041] Figure 2 2 is a block diagram showing the electrical configuration of PC 2. Figure 2 As shown, PC 2 includes a CPU 11, a display unit 7, an operating unit 8, a storage device 12, and a communication unit 13. Display unit 7, operating unit 8, storage device 12, and communication unit 13 are electrically connected to CPU 11. Storage device 12 includes RAM, ROM, HDD, and SSD, and may also include a removable memory card. CPU is the abbreviation for central processing unit. ROM is the abbreviation for read-only memory. RAM is the abbreviation for random access memory. HDD is the abbreviation for hard disk drive. SSD is the abbreviation for solid-state drive.

[0042] The user of PC 2 causes CPU 11 to execute a setup support program 21 stored in storage device 12, edits a project 22 via operating unit 8, and performs setup for each motor driver 4. PC 2 can also be referred to as an engineering tool. Project 22 includes one or more user programs (POUs 25a to 25c), global variables 23, and type information 24 of user-defined variables. POU is a general term for modules, function blocks, and functions. Modules are executed periodically or in response to assigned events. Functions and function blocks are each executed in response to a call. When describing common items between POUs 25a to 25c, POUs 25a to 25c are represented as POU 25. Global variables 23 are variables (variable groups) that can be accessed from POUs 25a to 25c. Each POU in POUs 25a to 25c has a program 26, such as a ladder diagram program, and local variables 27. The local variables 27 are variables (variable groups) accessible only from the program 26 in the POU 25 to which they belong. For example, the local variables 27 of the POU 25c are accessible from the program 26 of the POU 25c but not from the program 26 of the POU 25a.

[0043] Editing a project 22 includes creation and change (re-editing) of the project 22 .

[0044] The user reads the project 22 stored in the storage device 12 as needed and changes the project 22 using the setting support program 21. In this way, the version of the project 22 is continuously updated. Basically, the old version of the project 22 is overwritten by the new version of the project 22.

[0045] The communication unit 13 communicates with the base unit 3 via the communication cable 9a. The CPU 11 transmits the item 22 to the base unit 3 via the communication unit 13. The communication unit 13 includes a communication circuit capable of performing communication compliant with the USB standard, a communication circuit for performing wired LAN communication, and a communication circuit for performing wireless LAN communication. The communication unit 13 can communicate with the motor driver 4 via the communication cable.

[0046] (3) Basic unit

[0047] Figure 3The hardware configuration of the base unit 3 is shown. The CPU 31 writes information to the memory 32 and reads information from the memory 32. In addition to the ROM 36 and RAM 37, the memory 32 may also include an HDD or SSD (not shown) and a removable memory card. The ROM 36 may be any memory such as flash memory or EEPROM that can retain information even when the power to the base unit 3 is cut off. The ROM 36 includes a storage area for storing projects 22 created and transferred by the PC 2 and a storage area for storing a control program 38. The control program 38 is a program used to control the execution of user programs, the transfer of user programs, and the switching of user programs. The ROM 36 may store a first project 22 as an old version project and a second project 22 as a new version project, or may store only the second project 22. The RAM 37 may be referred to as a data memory. The CPU 31 also receives information input from the operating unit 6. The CPU 31 displays various types of information on the display unit 5.

[0048] The CPU 31 is connected to the PC 2 via the communication unit 33a and to the motor driver 4 via the communication unit 33b for communication. Furthermore, the communication unit 33a is, for example, a communication circuit compatible with USB or Ethernet. The communication unit 33b is a communication circuit capable of performing communication compatible with industrial Ethernet protocols (e.g., EtherCAT, EtherNet / IP, PROFINET, and MECHATROLINK-III). Furthermore, the communication units 33a and 33b can perform periodic communication and message communication.

[0049] The CPU 31 includes a program execution unit 34 for executing the POU 25 included in the project 22 and a transmission control unit 35 for controlling transmission of the project 22 from the PC 2 .

[0050] Figure 4Details of the transmission control unit 35 and the information expanded in the RAM 37 are shown. The transmission control unit 35 includes a variable allocation unit 40 and a compile unit 43. The variable allocation unit 40 also includes a memory management unit 41 and an entity management unit 42. The variable allocation unit 40 allocates the address of a storage area in the RAM 37 to each of the global variables 23 and local variables 27 described in item 22. The memory management unit 41 manages the allocation of addresses for each of the global variables 23 and local variables 27 to be stored in the common variable area 55. The common variable area 55 is referenced by both the new version program and the old version program. The entity management unit 42 allocates the address of the first instance area 53 secured in the RAM 37 to an instance of a function block (FB) or function (FUN) instantiated by calling the first execution object expanded in the first execution object area 51. In other words, each time a function block instance is defined in the POU 25, a function block instance is generated. The entity management unit 42 allocates the address in the second instance area 54 secured in the RAM 37 to the instance of the function block instantiated by the second execution object expanded in the second execution object area 52. Note that the first execution object is, for example, the execution code generated by the compilation unit 43 compiling the POU 25 included in the old version project 22. The second execution object is, for example, the execution code generated by the compilation unit 43 compiling the POU 25 included in the new version project 22. In this way, the new version execution code and the old version execution code are stored in the RAM 37, making it possible to update (switch) the execution code in a short time. For example, the compilation unit 43 can also store the new version execution code in the second execution object area 52 while the program execution unit 34 is executing the old version execution code.

[0051] RAM 37 may also include a management area 59, a common variable area 55, a save area 56, a variable update area 57, and a variable allocation area 58. The management area 59 is an area for storing information indicating which of the first execution code stored in the first execution target area 51 and the second execution code stored in the second execution target area 52 is to be executed. The common variable area 55 is an area for storing global variables 23 and local variables 27 used by the first and second execution codes. In this embodiment, since variables and the like are stored in the common variable area 55, which serves as a common storage area for the first and second execution codes, it is necessary to maintain, reallocate, or newly allocate the addresses storing the variables for switching execution codes. For example, if there is a variable whose type has not changed between the first and second projects 22, the address assigned to the variable is maintained. As a result, the execution code stoppage time associated with switching execution codes is reduced. When the type changes or the size of the variable's storage area expands or shrinks, the address assigned to the variable is changed. Furthermore, when a new variable is defined in the second project 22, a new address is allocated to the variable. The save area 56 is an area for temporarily storing the values ​​stored in the variables of the first project 22 when the values ​​stored in the variables of the second project 22 are stored in the variables. The variable update area 57 stores information (variable change information) for determining which variables are to be maintained and which variables are to be changed when the first project 22 is updated to the second project 22. The variable allocation area 58 is an area for storing information indicating the addresses (e.g., the starting addresses) of the storage areas allocated to the respective variables.

[0052] The variable allocation area 58 can be divided into a first variable allocation area 58a and a second variable allocation area 58b. The first variable allocation area 58a stores information indicating the address of the storage area allocated to the variable corresponding to the first item. The second variable allocation area 58b stores information indicating the address of the storage area allocated to the variable corresponding to the second item.

[0053] For example, due to the presence of the plurality of variable allocation areas 58 a and 58 b , the memory management unit 41 can allocate addresses to variables corresponding to new version items while the program execution unit 34 is executing the old version execution code.

[0054] (4) Method of updating the program

[0055] Typically, when the base unit 3 is already executing an old version of a project 22, switching to the new version of the project 22 transmitted from the PC 2 requires stopping the old version of the project 22. When the project 22 is stopped, the factory line controlled by the base unit 3 stops, and during this time, the factory cannot manufacture products. Therefore, the downtime should be as short as possible. For example, a technique is conceivable in which RAM 37 separately reserves a variable area for storing variables of the old version of the project 22 and a variable area for storing variables of the new version of the project 22, and during the downtime, the variables are copied from one variable area to the other. However, among the large number of variables that change with the update of the project 22, only a small number are affected. Therefore, if only the variables that actually require address changes, assignments, or value writes are specified and only those variables are processed, rather than copying all the variables, the downtime can be reduced. Therefore, the common variable area 55 described above is employed. Since the common variable area 55 can be accessed by both the first and second execution codes, the addresses of variables whose types, etc. have not changed, are maintained unchanged when the execution code is switched. Furthermore, the values ​​stored in the variables are also maintained. As a result, the time for operations such as address allocation and value copying is significantly reduced.

[0056] (4-1) Flowchart

[0057] Figure 5 A method of switching an old version project 22 to a new version project 22 during execution of the old version project 22 is shown.

[0058] In S1 , the CPU 31 (transmission control unit 35 ) communicates with the PC 2 , receives the new version item 22 from the PC 2 , and writes the new version item 22 into the ROM 36 .

[0059] In S2, the CPU 31 (variable allocation unit 40) determines the changes in the types and the like of all one or more global variables 23 included in the new version project 22, and reallocates addresses to the global variables 23 as needed. Figure 6 Describe the details of S2.

[0060] In S3 , the CPU 31 (variable allocation unit 40 ) determines changes in all one or more function blocks included in the new version project 22 and reallocates addresses as necessary.

[0061] In S4, the CPU 31 (variable allocation unit 40) determines changes in the types and the like of all one or more local variables 27 included in the new version project 22, and reallocates addresses to the local variables 27 as necessary. Details of S4 are similar to those of S2.

[0062] In S5, the CPU 31 (compiling unit 43) recompiles all of the one or more POUs 25 included in the new version project 22. Note that the compiling unit 43 may recompile only the POUs 25 edited by the user among all the POUs 25. Furthermore, the compiling unit 43 may determine whether recompiling is necessary for all the POUs 25, and recompile only the POUs determined to be necessary to recompile.

[0063] In S6, the CPU 31 (program execution unit 34) stops the sequence control. That is, the program execution unit 34 stops the execution of the old version project 22. Note that the CPU 31 disables interrupts so that the execution of the interrupt program is not newly started.

[0064] In S7, the CPU 31 switches the execution code. Specifically, the CPU 31 rewrites the information indicating the execution code (e.g., the starting address of the storage area storing the execution code) stored in the management area 59 from the old version execution code to the new version execution code. In other words, the target area referenced by the program execution unit 34 is switched from the first execution target area 51 to the second execution target area 52.

[0065] In S8, the CPU 31 updates the values ​​stored in the variables. For example, the CPU 31 updates the values ​​of the variables based on the variable update information stored in the variable update area 57. The variable update information includes, for example, the data type and address of the variable whose value needs to be updated before the update, as well as the data type, address, and initial value after the update. In addition, the variable update information may include information indicating whether the value of each variable is to be maintained or initialized. When the value of the variable is to be maintained, the CPU 31 reads the value of the variable from the address before the change, performs implicit type conversion as needed, and writes the value to the address after the change. When the value of the variable is to be initialized, the CPU 31 writes the initial value to the address after the change.

[0066] In S9 , the CPU 31 (program execution unit 34 ) starts sequence control. That is, the program execution unit 34 executes the new version execution code stored in the second execution target area 52 .

[0067] (4-2) Details of change processing related to global variables

[0068] Figure 6 S2 (determination of changes in the types and the like of all global variables 23 and reallocation of addresses of the global variables 23 as necessary) is shown in detail.

[0069] In S10 , the CPU 31 clears the allocation information stored in the variable allocation area 58 for all the global variables 23 .

[0070] In S11, the CPU 31 compares the old version item 22 with the new version item 22 and specifies all variables that have not changed in type, etc. That is, all variables whose assigned addresses do not need to be changed are specified.

[0071] In S12, the CPU 31 assigns the current address in the common variable area 55 to each variable specified in S 11. That is, the address already assigned in the common variable area 55 is maintained.

[0072] In S13, the CPU 31 compares the old version project 22 with the new version project 22 and specifies all variables to be deleted. Variables that existed in the old version project 22 but not in the new version project 22 are specified. In other words, variables whose assigned addresses need to be changed to an unused state are specified. Alternatively, addresses that are to be changed from a used state to an unused state are specified.

[0073] In S14 , the CPU 31 changes the old address used by the deleted variable in the common variable area 55 to an unused state (free state).

[0074] In S15 , the CPU 31 compares the old version project 22 with the new version project 22 , specifies all the variables that are changed, and selects one of the variables.

[0075] In S16, CPU 31 determines whether the selected variable is a newly added variable. A newly added variable is a variable that does not exist in the old version of project 22 but exists in the new version of project 22. A variable that exists in both versions but has a different type, etc., is not considered a newly added variable. If the selected variable is a newly added variable, CPU 31 proceeds from S16 to S18. On the other hand, if the selected variable exists in both versions but has a different type, etc., CPU 31 proceeds from S16 to S17.

[0076] In S17, the CPU 31 changes the old address assigned to the selected variable from the used state to the unused state (idle state). Thereafter, the CPU 31 proceeds from S17 to S18.

[0077] In S18 , the CPU 31 assigns the variable selected in S15 to an address in a free state in the common variable area 55 .

[0078] In S19 , regarding the variable selected in S15 , the CPU 31 records the data type and address of the variable before the change and the data type, address, and initial value of the variable after the change in the variable update information held in the variable update area 57 .

[0079] In S20, the CPU 31 determines whether there is a variable for which the address assignment process has not yet been completed among the changed variables. When there is a variable for which the address assignment process has not yet been completed, the CPU 31 returns from S20 to S15 and selects the next variable. Thereafter, the CPU 31 repeats S16 to S20. On the other hand, when there is no variable for which the address assignment process has not yet been completed, the CPU 31 proceeds from S20 to S16. Figure 5 S3 shown.

[0080] (4-3) Judgment and reallocation of function block call changes

[0081] Here, the details of S3 will be described. CPU 31 compares the old version project 22 with the new version project 22 and determines whether there is a change related to the call of the function block. The call of the function block can be defined as an instance (memory area). In the new version project 22, CPU 31 newly allocates a memory area to the instance of the function block to which the call of the function block has been newly added or the memory size consumed has changed. CPU 31 changes the storage area allocated to the deleted function block instance to an unused state. With respect to the function block whose address has changed, CPU 31 records the information of the variables included in the instance before the change in the variable change information.

[0082] (4-4) Judgment and reallocation of changes in local variables

[0083] The details of the processing according to S4 are basically the same as those involving the global variables 23. The CPU 31 compares the old version item 22 with the new version item 22 and determines whether there is a change related to the local variables 27. When any of the local variables 27 has changed, the CPU 31 assigns the same address as before the change to the local variable 27 that has not changed. The CPU 31 assigns the changed local variable 27 to a free address. The reallocation process is as follows.

[0084] (i) Allocation of unchanged local variables 27. Addresses are allocated to unchanged local variables 27 without changing the address offset from the head of the function block.

[0085] (ii) Allocation of the changed local variable 27. The changed local variable 27 is allocated to the free area. The processing content related to the variable added here can be added to the update list at the time of online transmission of the project 22 from the PC 2 to the basic unit 3. For example, the added variable is initialized with an initial value. The changed variable maintains the value before the change in response to the change. The information (address, data type and initial value) of the changed variable is recorded in the variable change information. In this way, the flowchart of the judgment and reallocation of the change of the local variable 27 is equivalent to that obtained by Figure 6The flowchart shown in the description is a flowchart obtained by replacing the global variable 23 with the local variable 27. Note that the address of the local variable 27 is determined based on the offset in the storage area to which the local variable 27 can be allocated.

[0086] (4-5) Recompile POU

[0087] Here, the details of the processing according to S5 will be described. Compiler 43 compiles POU 25 of the new version project 22 and creates new code (object) for execution in second execution target area 52. Both first execution target area 51 and second execution target area 52 exist in RAM 37, and program execution unit 34 refers to one of the two execution target areas indicated by the information stored in management area 59 and executes the execution code stored therein. When management area 59 refers to first execution target area 51, compiler 43 creates a new execution object in second execution target area 52, which is not referred to by management area 59.

[0088] The CPU 31 determines whether there is a change in the POU 25 (a program module (PROGRAM), a function block (FB), or a function (FUN)). The CPU 31 determines that there is a change in the POU 25 when any of the following items applies.

[0089] ●The program has been edited.

[0090] ●Local variable 27 has been edited.

[0091] ●Global variable 23 associated with the POU has been edited.

[0092] ●The structure associated with the POU has been edited.

[0093] ●The function or function block associated with the POU has been edited.

[0094] The expression “a function or a function block related to a POU has been edited” indicates a case where, for example, the type of an argument of a function or a function block has been changed or the type of a structure used in the argument has been changed.

[0095] When there is a change in the POU 25, the compiling unit 43 recompiles the POU 25. When there is no change in the POU, the compiling unit 43 copies the objects being executed and held in the first execution target area 51 to the second execution target area 52 without change.

[0096] Variable allocation and program compilation are performed separately. Therefore, in step S5, compilation unit 43 can compile all programs, regardless of whether any changes have been made. As an example, according to this embodiment, compilation unit 43 compiles only programs with differences and copies the execution code only for programs without differences. As a result, compilation time is shortened. Therefore, the execution code is relocatable code.

[0097] Here, S4 is executed for all POUs 25, and then S5 is collectively executed for all POUs 25. However, this is merely an example. For example, S4 and S5 may be executed by selecting one POU 25 as a processing target from among a plurality of POUs 25, and then S4 and S5 may be executed by selecting another POU 25 as a processing target.

[0098] Note that S2 to S5 are executed while the old version project 22 is being executed. As a result, the stop time accompanying the switching of the project 22 is reduced.

[0099] (4-6) Details of variable changes

[0100] The CPU 31 can determine whether a variable has changed based on the name (variable name) given to the variable. For example, when a variable has the same name and the same variable type between the old version project 22 and the new version project 22, the CPU 31 maintains the value stored in the variable without any change. There may be a variable with the same name but a changed type. In this case, if the value stored in the variable can be tracked by applying implicit type conversion between the type before the change and the type after the change, the CPU 31 maintains the value. If tracking is not possible, the CPU 31 initializes the variable with an initial value.

[0101] When no initial value is assigned, the CPU 31 substitutes a value determined in advance for the corresponding type as the initial value of the variable.

[0102] When the data type has changed, the CPU 31 performs implicit type conversion in consideration of the data type before the change and the data type after the change to track the type change.

[0103] (i) When the type before the change is an integer type and the type after the change is also an integer type, the CPU 31 performs implicit type conversion. When the changed type cannot represent the original value, the CPU 31 can saturate the value of the variable to the upper or lower limit.

[0104] (ii) When the type before the change is an integer type and the type after the change is a floating point type, the CPU 31 performs implicit type conversion. When the changed type cannot represent the original value, the CPU 31 saturates the value of the variable to the upper limit or lower limit.

[0105] (iii) There is a case where the maximum length of a string changes. For example, when the maximum length of the changed type is shorter than the maximum length of the type before the change, the string stored in the variable of the type before the change cannot be stored in the variable of the changed type. In this case, the CPU 31 may truncate the string to accommodate the maximum length of the changed type.

[0106] (iv) There is a case where the data type of a string is changed (such as from STRING to WSTRING, etc.). For example, the STRING type can be an ASCII or multi-byte string (such as ShiftJIS, etc.). The WSTRING type can be a unicode string (utf-16). In this case, CPU 31 converts the character code to store the string. When the string stored in the variable of the data type before the change cannot be represented by the data type after the change, CPU 31 can replace the string with a specific character.

[0107] (v) When both types are BOOL type and integer type, the CPU 31 performs implicit type conversion. Specifically, TRUE is converted to 1 and FALSE is converted to 0.

[0108] (vi) In the case where both types are an enumeration type and an integer type, the CPU 31 performs implicit type conversion.

[0109] (vii) There is a case where the number of elements and the dimension of the array are changed. In this case, the CPU 31 maintains the value of the corresponding element number that existed before the change.

[0110] Figure 7 An example of a change in an array is shown. In this example, the variable varA is an array type variable.

[0111] The dimension of the variable varA is 2. In this example, the possible range of element numbers has changed from [0...1][0...2] to [0...2][0...1]. Figure 7, varA[0][0], varA[0][1], varA[1][0], and varA[1][1] exist before and after the change. Thus, the values ​​stored in the variables before the change are taken over by the variables after the change. On the other hand, varA[0][2] and varA[1][2] exist in the variables before the change, but these cannot exist according to the variable definition after the change. Thus, varA[0][2] and varA[1][2] are deleted together with their values. Furthermore, according to the variable definition after the change, varA[2][0] and varA[2][1] are added. Thus, a predetermined initial value (e.g., 0) is stored in each of varA[2][0] and varA[2][1]. The predetermined initial value can be pre-assigned by the user.

[0112] (viii) When there is a change in structure type: If there are member names corresponding to each other between the structure before the change and the structure after the change, the change processing (i) to (vii) above is performed between the members.

[0113] Figure 8 This example shows a structure type change. Before the change, the structure STRUCT1 has member variables mMem1 and mMem2, both unsigned integers of one word length, and mMem3, a signed integer of two words length. "stHoge" is defined as a variable of this structure type. 2 is stored in "stHoge.mMem1." 3 is stored in "stHoge.mMem2." 5 is stored in "stHoge.mMem3."

[0114] like Figure 8 As shown in the example, the definition of the structure has changed. In this example, the name of the member variable "mMem2" of the UINT type has been changed to "mPiyo". Therefore, "stHoge.mPiyo", which is the member variable in the changed "stHogeb", is initialized with the initial value. The type of the member variable mMem1 has changed from UINT type to LREAL type (double-precision floating-point type). Therefore, implicit type conversion is applied, and the value of the member variable stHoge.mMem1 is converted from 2 to 2.0.

[0115] (ix) A function block instance is added. That is, a function block call is added to the POU 25. In this case, the CPU 31 initializes all variables included in the added function block instance with initial values. A function block instance includes input variables (IN), output variables (OUT), and local variables.

[0116] (4-7) Details of function blocks

[0117] Generally, a function block includes code (program) and data. The program of each function block can be called a "definition". The data can be called an "instance". Due to the relationship between definitions and instances, the same program can be applied to multiple data.

[0118] Figure 9 This implies that three different instances are generated for the same function block definition in POU 25. The function block is called by assigning instances. Note that the same instance can be called multiple times. The name of the function block is "waveAnalyze". In this function block, "aryWaveForm", an array type for holding waveform data, and "waveLength", a variable for indicating the length of the waveform, are defined as input variables. As output variables, there are "Frequency", a variable for outputting the frequency of the waveform data, "Maxval", which outputs the maximum value of the amplitude of the waveform, and "Minval", which outputs the minimum value of the amplitude of the waveform.

[0119] In the first call, the waveform data stored in the variable "arrayWave1" is input to "aryWaveForm" in "Instance1," and the value stored in the variable "arrayLen1" in "Instance1" is output to "waveLength." Input and output variables can be omitted. If an input variable is omitted, the instance variable retains its value.

[0120] In the second call, the waveform data stored in the variable "arrayWave2" is input to "aryWaveForm" of "Instance2", and the value stored in the variable "arrayLen2" of "Instance2" is output to "waveLength".

[0121] In the third call, the waveform data stored in the variable "arrayWave3" is input to "aryWaveForm" of "Instance3", and the value stored in the variable "arrayLen3" of "Instance3" is output to "waveLength".

[0122] As described above, a function block is used by generating an instance. An instance is a memory entity and can be understood as being the same as an entity of the structure of the data type "function block". Within a function block instance, global function blocks and local function blocks can exist. A local function block is defined as a local variable 27. An instance can also be defined as a local variable 27 within a function block. Function block instances are nested via the local variable 27 nest.

[0123] (4-8) Details of function blocks

[0124] There are cases where addition, modification or deletion is made to a program module (PROGRAM) or a function block instance. In this case, allocation of a storage area for the relevant local variables 27 is required.

[0125] The CPU 31 allocates the storage area of ​​the global variables 23 and the storage area of ​​the local variables 27 of the program module or function block to the continuous storage area. When there is an addition, deletion or change in the module or function block instance (the number of variables used has changed), the CPU 31 ensures a new continuous storage area in the free storage area. When an instance is deleted or changed, the storage area used by the instance is changed to an unused state. For the added or changed instance, a continuous storage area is ensured in the unused storage area, and the instance is allocated to the continuous storage area. As a result, the addresses of the variables allocated to the unchanged module or function block can be maintained.

[0126] Figure 10 Two examples i and ii are shown regarding the storage area secured in the RAM 37. In example i, six instances I1 to I6 of the function block are continuously stored in the storage area before the change. Figure 10 In [1], "unused" indicates a storage area in an idle state. After the change, the size of instance I4 has increased. Therefore, the storage area for instance I4 is secured in the idle area.

[0127] In Example ii, before the change, the six instances I1 to I6 of the function block were continuously stored in the storage area. After the change, instances I1 and I3 were deleted. Therefore, the storage area of ​​instances I1 and I3 was changed to an unused state.

[0128] Although a function block example is described here, a program module or a storage area of ​​the global variable 23 is also handled in a similar manner.

[0129] Each time the number of variables used in a program module or function block changes, the memory area is allocated to an unused area, which can be extremely wasteful. Specifically, even if there is a small change, all the values ​​of the local variables 27 of the module or function block need to be moved during the online transfer of the project 22. As a result, the program downtime during the online transfer increases.

[0130] Therefore, an additional unused storage area can be allocated to the global variables 23, modules, function blocks and instances. That is, a storage area with a size larger than the size required to store these can be allocated to these.

[0131] For example, Figure 10As shown in Example iii, the size required to store the function block instance I1 before the change is Size1, but a memory area of ​​Size2 (Size2) larger than Size1 is actually allocated. Suppose that after the change, the number of variables used in the function block increases, and the size required to store the instance is Size3, which is smaller than Size2. In this case, CPU 31 does not change the memory area allocated to the instance. This makes it possible to reduce downtime.

[0132] Note that there is a case where the size of instance I1 is reduced to Size4 (Size 4), which is smaller than the original size of Size1. In this case as well, the CPU 31 can maintain the memory area of ​​Size2 allocated to instance I1 without any change. This reduces the stop time.

[0133] Furthermore, in the case of Example iii, the unused area depicted at the right end is necessary. This is because when a new module or function block is added, its instance must be secured in the unused area at the right end. Furthermore, it is assumed that the storage area becomes insufficient as variables are added to the various storage areas, making it difficult to add or change new variables. In this case, the CPU 31 can move the storage area of ​​the POU 25 to the entire unused area. Alternatively, the CPU 31 can display an error notification to the user on the display unit 5 or 7 and cause the online transfer of the project 22 to fail.

[0134] The CPU 31 reserves an entire unused area and unused areas (extra areas) for individual modules or function block instances in the RAM 37. The sizes of these can be specified in advance by the user.

[0135] (4-9) Details of function blocks

[0136] There are one or more variables in a program module (PROGRAM) or function block instance. The address assignment of these variables will be described below.

[0137] To shorten the downtime of program execution during online transfer, you can use the allocation method in Example iii to allocate memory areas to instances. When adding, deleting, or changing variables during online transfer, allocate the variables as follows.

[0138] (i) The added variables are newly allocated to an unused memory area.

[0139] (ii) The memory area allocated to the deleted variable is changed to "unused".

[0140] (iii) For changed variables, the originally allocated storage area is changed to "unused," and the changed variable is allocated to a newly secured storage area within the unused area. In other words, the change is handled as a combination of deletion and addition. As a result, the addresses of variables whose types and other features have not changed are maintained without any changes.

[0141] Figure 11 The memory area of ​​the function block instance I1 including variables a to e is shown. Before the change, the types of variables a, b, and c are DINT types. The type of variable d is UINT type. The type of variable e is array type (e.g., ARRAY[0...3]).

[0142] In this example, the type of variable b has been changed from DINT to LREAL. LREAL variable b cannot be stored in the original storage area of ​​DINT variable b. Therefore, the storage area of ​​LREAL variable b is allocated to the reserved additional unused area. In this case, the variable update information for variable b does not contain information about the address, data type, and initial value, and "implicit type conversion" is specified for the initialization method.

[0143] (4-10) Management of modules and function block instances

[0144] The function block is called by assigning an instance from the function block call command. In order to call a function block, the following two pieces of information related to the function block are required on the calling side.

[0145] (A) Address of the function block execution code (object)

[0146] (B) Address of local variables of function block instance

[0147] The address of A is associated with the definition of a function block. When a program is modified through online transfer, the address of A changes. This is not limited to changes in function blocks and can occur with changes to other function blocks. In addition, function block definitions and calls can be added.

[0148] The address of B is associated with the function block instance. When a function block instance is added by online transfer, the address of B is added. When a new storage area is required due to a change in the number of local variables 27 used in the function block due to online transfer, the address of the working area is also changed.

[0149] Using instance information and instance IDs eliminates the need to recompile the caller program even when the addresses of A and B change due to online transfer. Instance information associates and stores the instance ID, the address of the object, and the address of the local variable 27. The instance ID is information identifying the entity of the function block.

[0150] The caller's program (POU 25) or function block embeds the instance ID of the function block to be called in its execution code (object code), and references the instance information using the instance ID as an index during execution. As a result, the address of the object and the address of the local variable 27 are obtained. An example of instance information is as follows.

[0151]

[0152] In this example, the function blocks of instance IDs 1, 2, and 3 have the same definition. That is, the addresses of the objects of instance IDs 1, 2, and 3 are common, and the execution procedures are common.

[0153] When project 22 is transferred online, the addresses of objects and local variables 27 change. Therefore, it is necessary to update instance information as the program changes. However, by preparing the changed instance information in advance, the referenced storage area can be switched. This reduces the time it takes to stop sequence control.

[0154] The instance ID is an integer value assigned in association with an instance of a function block. The instance ID does not change during the online transfer of the associated instance. When the instance is deleted, the CPU 31 changes the instance ID to an unused state.

[0155] Note that in this embodiment, the instance ID is used as an identification ID for managing addresses including PROGRAM (module) and function. However, this is just an example. The instance ID can be used only for function blocks. Note that the instance ID is obtained by analyzing the call.

[0156] Figure 12 Definition information, a call tree, and an instance ID are shown. In this example, two programs Prog1 and Prog2 and three function blocks FBDef1, FBDef2, and FBDef3 are defined.

[0157] Program Prog1 calls FBDef1 and FBDef2. FBDef1 is called once and creates instance inst1. FBDef2 is called twice and creates instances inst2 and inst3.

[0158] Program Prog2 calls FBDef3. FBDef3 is called once and creates an instance inst1.

[0159] FBDef1 calls FBDef3 twice. As a result, instances inst1 and inst2 are created.

[0160] FBDef2 calls FBDef3 once, resulting in the creation of an instance called inst1.

[0161] Figure 12 The call tree and instance IDs are shown in the lower part of . Instance ID 1 is given to program Prog1. Instance ID 2 is given to program Prog2.

[0162] Instance ID 3 is assigned to function block FBDef1, which is called from program Prog1. Instance IDs 4 and 5 are assigned to function block FBDef3, which is called twice from function block FBDef1. Instance IDs 6 and 8 are assigned to function block FBDef2, which is called twice from program Prog1. Instance ID 7 is assigned to function block FBDef3, which is called from function block FBDef2 called the first time. Instance ID 9 is assigned to function block FBDef3, which is called from function block FBDef2 called the second time.

[0163] The instance ID 10 is given to the function block FBDef3 called from the program Prog2.

[0164] Figure 13 Shows that it has passed Figure 12 In the old version project 22 shown, inst2 of the program Prog1 is deleted and a new version project 22 is created. In addition, inst2 (FBDef3) is added to FBDef2.

[0165] When adding or deleting a module or changing the definition of an instance of a function block, the CPU 31 rebuilds the call (instance) tree and changes the instance ID of the deleted instance to an unused state. In addition, the CPU 31 assigns the instance ID to the added instance.

[0166] like Figure 13 As shown, since inst2 of Prog1 is deleted, the instance of FBDef2 with instance ID=6 and the instance of FBDef3 with instance ID=7 are deleted in the call tree.

[0167] As the definition of FBDef2 changes, FBDef3 is called twice from the instance of FBDef2 with instance ID = 8. Here, since the first call of FBDef3 pre-existed before the change, the instance ID 9 is maintained without any change for the first call of FBDef3. Since the second call of FBDef3 has been added, the instance ID 11 is given to the second call of FBDef3.

[0168] In this way, in the function block whose calling relationship has not changed, the instance ID does not change. As a result, when there is no change in the function block to be called, the instance ID does not change, and recompiling is also unnecessary.

[0169] In this embodiment, the instance ID is an index into the instance information array. Therefore, unused instance IDs can be reused. For example, for the second call of FBDef3, 6 or 7 can be reused as the instance ID.

[0170] (4-11) Value Update

[0171] (4-11-1) Saving values

[0172] Figure 14 The following describes a method for saving the values ​​stored in the variables used in the old version project 22 during the update process of S8. While the sequence control is stopped, the values ​​are saved and restored.

[0173] In S31 , the CPU 31 saves the value stored in the global variable 23 in the storage area 56 .

[0174] S32 to S34 are processes related to the module of the POU 25. Hereinafter, the module is sometimes referred to as the module 25 for convenience.

[0175] In S32 , the CPU 31 selects a module 25 to which the save process has not been applied from among all the modules 25 included in the old version project 22 .

[0176] In S33 , the CPU 31 saves all the values ​​stored in the local variables 27 of the selected module 25 in the save area 56 .

[0177] In S34, the CPU 31 determines whether a module 25 that has not yet been saved remains. If a module 25 that has not yet been saved remains, the CPU 31 returns from S34 to S32 and selects the next module 25. Thereafter, the CPU 31 repeats S32 to S34. If no module 25 that has not yet been saved remains, the CPU 31 proceeds from S34 to S35.

[0178] Steps S35 to S39 are processes related to the functional blocks of the POU.

[0179] In S35 , the CPU 31 selects a function block that has not yet been saved from among all the function blocks defined in the old version project 22 .

[0180] In S36 , the CPU 31 selects an instance that has not yet been saved from all instances generated based on the selected function block.

[0181] In S37 , the CPU 31 saves the values ​​of all local variables 27 associated with instances that have not yet been subjected to save processing in the save area 56 .

[0182] In S38, the CPU 31 determines whether any instances remain that have not yet been saved. If any instances remain that have not yet been saved, the CPU 31 returns from S38 to S36 and selects the next instance. Thereafter, the CPU 31 repeats S36 to S38. If no instances remain that have not yet been saved, the CPU 31 proceeds from S38 to S39.

[0183] In S39, the CPU 31 determines whether any function blocks that have not yet been saved remain in the old version project 22. If any function blocks that have not yet been saved remain, the CPU 31 returns from S39 to S35 and selects the next function block. Thereafter, the CPU 31 repeats S35 to S39. If no function blocks that have not yet been saved remain, the CPU 31 terminates the saving process.

[0184] (4-11-2) Value Recovery

[0185] Figure 15 The following describes a method for restoring values ​​from the storage area 56 to variables to be used in the new version project 22 during the update process in S8. If the address assigned to the variable in the old version project 22 matches the address to be assigned to the variable in the new version project 22, there is no need to restore the value. If the address assigned to the variable in the old version project 22 does not match the address to be assigned to the variable in the new version project 22, the value is restored.

[0186] In S41 , the CPU 31 restores the value stored in the save area 56 to the global variable 23 .

[0187] S42 to S44 are module-related processes.

[0188] In S42, the CPU 31 selects a module 25 to which the restoration process has not been applied from all the modules 25 included in the new version project 22. Note that for the added module 25, an initial value is stored.

[0189] In S43 , the CPU 31 restores the values ​​from the save area 56 to all the local variables 27 for the selected module 25 .

[0190] In S44, the CPU 31 determines whether a module 25 that has not yet been restored remains. If a module 25 that has not yet been restored remains, the CPU 31 returns from S44 to S42 and selects the next module 25. Thereafter, the CPU 31 repeats S42 to S44. If no module 25 that has not yet been restored remains, the CPU 31 proceeds from S44 to S45.

[0191] Steps S45 to S49 are processes related to the functional blocks.

[0192] In S45, the CPU 31 selects a function block that has not yet been restored from among all the function blocks defined in the new version project 22. Note that for a function block newly added in the new version project 22, an initial value is stored.

[0193] In S46 , the CPU 31 selects an instance that has not yet been restored from all instances generated based on the selected function block.

[0194] In S47 , the CPU 31 restores the values ​​of all local variables 27 associated with the instance that has not yet been restored from the save area 56 .

[0195] In S48, the CPU 31 determines whether any instances that have not yet been restored remain. If any instances that have not yet been restored remain, the CPU 31 returns from S48 to S46 and selects the next instance. Thereafter, the CPU 31 repeats S46 to S48. If no instances that have not yet been restored remain, the CPU 31 proceeds from S48 to S49.

[0196] In S49, the CPU 31 determines whether any function blocks that have not yet been restored remain in the new version project 22. If any function blocks that have not yet been restored remain, the CPU 31 returns from S49 to S45 and selects the next function block. Thereafter, the CPU 31 repeats S45 to S49. If no function blocks that have not yet been restored remain, the CPU 31 terminates the restoration process.

[0197] Note that if the common variable area 55 has sufficient memory size, the edited or added variables can be allocated to unused addresses in advance. For example, the value of the edited variable can be moved from the storage area before the change to the storage area after the change.

[0198] (5) Technical ideas derived from the examples

[0199] [Viewpoint 1]

[0200] For example, there is a case where the CPU 31 (memory management unit 41) receives an instruction to switch to a second user program, which is an updated version of the first user program, while the program execution unit 34 is executing the first user program. In this case, the memory management unit 41 can create variable information for identifying variables to be maintained and variables to be changed by updating from the first user program to the second user program, and store this variable information in the RAM 37 (e.g., the variable update area 57). Based on this variable information, the memory management unit 41 can maintain the addresses in the RAM 37 storing the values ​​of the variables to be maintained, and can also stop the logical operations of the program execution unit 34 and, at the interruption of the logical operations, allocate the addresses in the RAM 37 storing the values ​​of the variables to be changed. Here, the logical operations refer to, for example, the execution of the first user program (e.g., a ladder program) by the program execution unit 34.

[0201] RAM 37 may also include a program memory (e.g., a first execution target area 51 and a second execution target area 52) for storing user programs. The program memory may include the first execution target area 51 for storing the first user program (the execution code (object code) generated by compiling the old version POU 25 by the compiling unit 43) and the second execution target area 52 for storing the second user program (the execution code (object code) generated by compiling the new version POU 25 by the compiling unit 43). RAM 37 may also include a third storage area (management area 59) for storing information indicating whether the first user program stored in the first execution target area 51 or the second user program stored in the second execution target area 52 is to be executed. In RAM 37, the variable storage areas for storing variable values ​​(e.g., the first instance area 53, the second instance area 54, and the common variable area 55) may be shared by the first and second user programs. Here, the first instance area 53 stores instances generated by calling function blocks using the execution code stored in the first execution target area 51. The second instance area 54 stores instances generated by calling function blocks using the execution code stored in the second execution target area 52. The common variable area 55 stores variables (e.g., global variables 23, local variables 27) to be used by the execution code stored in the first execution target area 51 and variables (e.g., global variables 23, local variables 27) to be used by the execution code stored in the second execution target area 52. This makes it possible to efficiently switch user programs while operating the PLC.

[0202] [Viewpoint 2]

[0203] The memory management unit 41 maintains the addresses of the variables to be maintained in the variable storage area based on the variable information. The variable information may be, for example, type information 24 indicating the type of each variable, variable update information to be stored in the variable update area 57, or instance information for managing instance IDs, etc. The memory management unit 41 allocates addresses in the variable storage area storing the values ​​of the variables to be changed, stores the second user program in the second execution target area 52, and changes the information stored in the third storage area (management area 59) from information indicating that the first user program is to be executed to information indicating that the second user program is to be executed. Furthermore, the memory management unit 41 writes predetermined values ​​to the variables whose addresses have changed at the intervals between logical operations. This reduces the downtime of the user programs.

[0204] [Viewpoint 3]

[0205] Variables to be changed may have their type or size changed. When the type or size changes, not only does the allocated storage area (address) often change, but the stored contents (value) also often change. Therefore, address reallocation is performed for variables whose type or size changes. Conversely, for variables whose type and size remain unchanged, the value is also maintained. This eliminates the need for address reallocation, reducing user program downtime.

[0206] [Viewpoint 4]

[0207] The variable may be a variable of a structure type. In this case, the variable to be changed may be a variable in which a member included in the structure is added or deleted and the type or size of the member included in the structure is changed.

[0208] [Viewpoint 5]

[0209] The variable to be changed may be a variable whose address for storing the variable is changed.

[0210] [Viewpoint 6]

[0211] The variables may include a first global variable and a second global variable. The first global variable is a variable to be maintained, and the second global variable is a variable to be changed. In this case, the memory management unit 41 may maintain the address of the first global variable and allocate the second global variable to an idle address (an address in an unused state) in the data memory.

[0212] [Viewpoint 7]

[0213] The variables may include a first local variable and a second local variable. The first local variable is a variable to be maintained, and the second local variable is a variable to be changed. The memory management unit 41 may maintain the address of the first local variable and allocate the second local variable to a free address in the data memory.

[0214] [Viewpoint 8]

[0215] The first local variable and the second local variable may be local variables included in the function block. The memory management unit 41 may manage the address of the first local variable and the address of the second local variable using an address offset from a head address of the function block.

[0216] [Viewpoint 9]

[0217] The first storage area (e.g., first execution target area 51) is an area for storing execution targets of the first user program. The second storage area (e.g., second execution target area 52) is an area for storing execution targets of the second user program. After the address allocation in the variable storage area for the variable to be changed is completed, the compilation unit 43 can compile the second user program to generate the execution target.

[0218] [Viewpoint 10]

[0219] A user program may include multiple POUs 25. The compiling unit 43 may recompile only the POUs 25 determined to be necessary to reproduce the execution target. The compiling unit 43 may copy the execution targets of the POUs 25 determined not to be necessary to recompile from the first user program to the second user program. As a result, the downtime can be shortened. Note that the POUs determined not to be necessary to recompile may be referred to as POUs determined not to require recompilation.

[0220] There are cases where recompilation is necessary even when the variable or structure definition used by the POU 25 is changed.

[0221] [Before change]

[0222] struct ST_A{

[0223] mem1: UINT;

[0224] mem2: UINT;

[0225] }END_STRUCT

[0226] [After]

[0227] TYPE ST_A

[0228] STRUCT

[0229] mem1: ARRAY[0..9] OF UINT;

[0230] mem2: UINT;

[0231] END_STRUCT;

[0232] END_TYPE

[0233] [POU (no edit)]

[0234] VAR

[0235] var1:ST_A;

[0236] END_VAR;

[0237] var1.mem2:=10;

[0238] In this case, the offset from the beginning of the structure of var1.mem2 changes from 2 bytes to 20 bytes due to this change. Therefore, it is determined that recompiling of the POU 25 is necessary.

[0239] [Viewpoint 11]

[0240] The variable to be maintained may be a variable whose name and type are both maintained. The memory management unit 41 may maintain the value stored in the variable to be maintained when the first user program stops, and allow the second user program to use the value without any change.

[0241] [Viewpoint 12]

[0242] The variable may include an array type variable having two or more dimensions. There is a situation where the name of the array type variable in the first user program is consistent with the name of the array type variable in the second user program, the dimension of the array type variable in the first user program is consistent with the dimension of the array type variable in the second user program, and the possible range of the element number of the array type variable in the first user program is different from the possible range of the element number of the array type variable in the second user program. In this case, when a variable having the same element number as the variable in the array type variable in the second user program exists in the array type variable in the first user program, the memory management unit 41 may maintain the value of the array type variable in the first user program identified by the element number as the value of the array type variable in the second user program identified by the element number. When a variable having the same element number as the variable in the array type variable in the second user program does not exist in the array type variable in the first user program, the memory management unit 41 may store a predetermined value (e.g., an initial value) in the array type variable in the second user program identified by the element number.

[0243] [Viewpoint 13]

[0244] There are cases where the type of a variable of an array type in a first user program identified by element number is different from the type of a variable of an array type in a second user program identified by element number, and implicit type conversion is possible. In this case, the value can be maintained by implicit type conversion.

[0245] [Viewpoint 14]

[0246] There is a case where a user program including multiple function blocks is updated from a first user program to a second user program. In this case, entity information for identifying the entity (instance) of the first function block to be maintained by the update and the entity of the second function block to be changed by the update can be stored in the RAM 37. This entity information (instance information) can be part of the type information 24. Based on the entity information, the CPU 31 (entity management unit 42) maintains the entity identification information (e.g., instance ID) of the entity of the first function block in the first user program in the second user program, and maintains the address of the entity of the first function block. The entity management unit 42 can change the entity identification information of the entity of the second function block and allocate a free address to the entity of the second function block.

[0247] [Viewpoint 15]

[0248] There is a situation where the second function block exists in both the first user program and the second user program, but the variables included in the second function block have changed. In this case, the entity management unit 42 changes the address of the entity of the second function block in the first user program to an unused state. In addition, the entity management unit 42 can allocate a free address to the entity of the second function block in the second user program. When the variables change, in many cases, the size of the instance of the function block also changes. Therefore, the storage area of ​​such an instance can be released, and the instance can be allocated to the unused area.

[0249] [Viewpoint 16]

[0250] There is a case where the second function block is a function block that does not exist in the first user program but is added to the second user program. The entity management unit 42 may allocate a free address to the entity of the second function block in the second user program.

[0251] [Viewpoint 17]

[0252] There is a case where the second function block is a function block that existed in the first user program but was deleted from the second user program. In this case, the entity management unit 42 may change the address of the entity storing the second function block in the first user program to an unused state.

[0253] [Viewpoint 18]

[0254] like Figure 11 As shown, each of the entities of the first functional block in the first user program and the entities of the second functional block can be pre-stored in a storage area larger than the entity size during online transmission. In this case, a storage area can be allocated to the entity of the second functional block in the second user program within the range of the storage area allocated to the entity of the second functional block in the first user program. The size and address of the storage area can be predetermined or fixed.

[0255] [Viewpoint 19]

[0256] When a variable has been added to the second function block, a storage area for the added variable can be allocated within the range of the storage area.

[0257] [Viewpoint 20]

[0258] When the variable has been deleted from the second function block, the storage area of ​​the deleted variable may be changed to an unused state within the range of the storage area.

[0259] [Viewpoint 21]

[0260] The user program (eg, the POU 25 ) can use the entity identification information to acquire the addresses of objects for each entity of the function block and the addresses of variables used in the function block.

[0261] [Viewpoint 22]

[0262] A control method for a programmable logic controller may be provided, the programmable logic controller comprising: a processor for repeatedly executing logic operations based on a user program; and a data memory for storing values ​​of variables accessed according to the user program executed by the processor. The control method comprises:

[0263] While the processor is executing the first user program, receiving an instruction to switch to a second user program that is an updated version of the first user program;

[0264] maintaining addresses storing values ​​of variables to be maintained in the data memory based on variable information identifying the variables to be maintained and the variables to be changed by updating from the first user program to the second user program; and

[0265] Stop the logic operation and allocate the address of the variable to be changed in the data memory at the break of the logic operation.

[0266] [Viewpoint 23]

[0267] The control program 38 stored in the ROM 36 can cause the programmable logic controller to execute the control method of the programmable logic controller described in viewpoint 22 .

[0268] The present invention is not limited to the above-described embodiments, and various modifications and changes can be made within the scope of the gist of the present invention.

Claims

1. A programmable logic controller comprising: a processor configured to repeatedly perform logic operations based on a user program; a data memory configured to store values ​​of variables accessed according to a user program executed by the processor; as well as A memory management unit configured to, when the processor receives an instruction to switch to a second user program that is an updated version of the first user program while the processor is executing the first user program, maintain addresses in the data memory storing values ​​of variables to be maintained based on variable information for identifying variables to be maintained and variables to be changed by updating from the first user program to the second user program, and to stop the logical operation and allocate addresses in the data memory storing values ​​of variables to be changed at interruptions of the logical operation.

2. The programmable logic controller according to claim 1, further comprising a program memory configured to store the user program, in, The program memory includes: a first storage area, configured to store the first user program; a second storage area, for storing the second user program; and The third storage area is used to store information indicating whether to execute the first user program stored in the first storage area or the second user program stored in the second storage area. A variable storage area in the data memory that stores variable values ​​is a storage area shared by the first user program and the second user program, and The memory management unit: Based on the variable information, an address in the variable storage area storing the value of the variable to be maintained is maintained, and an address in the variable storage area storing the value of the variable to be changed is allocated, storing the second user program in the second storage area, changing the information stored in the third storage area to information for executing the second user program, and At the interruption of the logic operation, a predetermined value is written into the variable whose address is changed.

3. The programmable logic controller according to claim 1, wherein: The variable to be changed is a variable whose type or size is changed.

4. The programmable logic controller according to claim 1, wherein: In the case where the variable is a variable of a structure type, the variable to be changed is a variable in which members included in the structure are added or deleted and the types or sizes of the members included in the structure are changed.

5. The programmable logic controller according to claim 1, wherein: The variable to be changed is a variable whose address for storing the variable is changed.

6. The programmable logic controller according to claim 1, wherein: The variables include a first global variable and a second global variable, the first global variable is the variable to be maintained, and the second global variable is the variable to be changed, and The memory management unit maintains the address of the first global variable and allocates the second global variable to a free address in the data memory.

7. The programmable logic controller according to claim 1, wherein: The variables include a first local variable and a second local variable, the first local variable being the variable to be maintained, and the second local variable being the variable to be changed, and The memory management unit maintains the address of the first local variable and allocates the second local variable to a free address in the data memory.

8. The programmable logic controller according to claim 7, wherein: The first local variable and the second local variable are local variables included in a function block, and The memory management unit manages the address of the first local variable and the address of the second local variable using an address offset from a head address of the function block.

9. The programmable logic controller according to claim 2, wherein: The first storage area is an area for storing an execution target of the first user program, and the second storage area is an area for storing an execution target of the second user program, and The execution target of the second user program is generated by compiling the second user program after address allocation in the variable storage area for the variable to be changed is completed.

10. The programmable logic controller according to claim 1, wherein: The user program includes a plurality of POUs, and Only the POUs determined to be necessary to be recompiled among the plurality of POUs are recompiled to reproduce the execution object, and the execution object of the POUs determined not to be necessary to be recompiled among the plurality of POUs is copied from the first user program to the second user program.

11. The programmable logic controller according to claim 1, wherein: The variable to be maintained is a variable in which both the variable name and the variable type are maintained, and The memory management unit maintains the value stored in the variable to be maintained when the first user program is stopped, and causes the second user program to use the value without any change.

12. The programmable logic controller according to claim 1, wherein: The variables include variables of array type having two or more dimensions, In the case where the name of the array-type variable in the first user program is consistent with the name of the array-type variable in the second user program, the dimension of the array-type variable in the first user program is consistent with the dimension of the array-type variable in the second user program, and the possible range of the element number of the array-type variable in the first user program is different from the possible range of the element number of the array-type variable in the second user program, The memory management unit: When there is a variable of the array type in the first user program whose element number is the same as the element number of the variable of the array type in the second user program, the value of the variable of the array type in the first user program identified by the element number is maintained as the value of the variable of the array type in the second user program identified by the element number, and When there is no variable in the array type in the first user program whose element number is the same as the element number of the variable in the array type in the second user program, a predetermined value is stored in the array type variable in the second user program identified by the element number.

13. The programmable logic controller according to claim 12, wherein: When the type of the array-type variable in the first user program identified by the element number is different from the type of the array-type variable in the second user program identified by the element number and implicit type conversion is possible, the value is maintained by the implicit type conversion.

14. The programmable logic controller according to claim 1 further includes an entity management unit, which is configured to, when a user program including multiple function blocks is updated from the first user program to the second user program, based on entity information for identifying the entity of the first function block to be maintained by the update and the entity of the second function block to be changed by the update, maintain the entity identification information of the entity of the first function block in the first user program in the second user program, maintain the address of the entity of the first function block, change the entity identification information of the entity of the second function block, and allocate a free address to the entity of the second function block.

15. The programmable logic controller according to claim 14, wherein: In the case where the second function block exists in both the first user program and the second user program, but variables included in the second function block are changed, The entity management unit: changing the address of the entity allocated to the second function block in the first user program to an unused state, and A free address is allocated to an entity of a second function block in the second user program.

16. The programmable logic controller according to claim 14, wherein: In the case where the second function block does not exist in the first user program but is added to the second user program, The entity management unit allocates a free address to an entity of a second function block in the second user program.

17. The programmable logic controller according to claim 14, wherein: In the case where the second function block exists in the first user program but is deleted from the second user program, The entity management unit changes an address of an entity storing a second function block in the first user program to an unused state.

18. The programmable logic controller according to claim 14, wherein: Each of the entity of the first function block and the entity of the second function block in the first user program is pre-stored in a storage area larger than the size of the entity when online transmission is performed, and A memory area is allocated to the entity of the second function block in the second user program within the range of the memory area allocated to the entity of the second function block in the first user program.

19. The programmable logic controller according to claim 14, wherein: The user program uses the entity identification information to acquire the address of an object for each entity of a function block and the address of a variable used in the function block.

20. A control method for a programmable logic controller, the programmable logic controller comprising a processor and a data memory, the processor being configured to repeatedly execute logic operations based on a user program, the data memory being configured to store values ​​of variables accessed according to the user program executed by the processor, the control method comprising: When the processor is executing a first user program, receiving an instruction to switch to a second user program that is an updated version of the first user program; maintaining, in the data memory, addresses storing values ​​of the variables to be maintained based on variable information identifying the variables to be maintained and the variables to be changed by updating from the first user program to the second user program; as well as The logic operation is stopped, and the address storing the value of the variable to be changed in the data memory is allocated at the interruption of the logic operation. 21 . A computer-readable storage medium storing a program for causing the programmable logic controller to execute the control method according to claim 20 . 22 . A computer program product comprising a program for causing the programmable logic controller to execute the control method according to claim 20 .

Images