Programmable logic controller, control method, and program

Abstract

To efficiently switch a user program while a PLC is in operation.SOLUTION: The PLC may include a processor for repeatedly executing logic operations based on a user program, and a memory for storing values of variables accessed according to the user program executed in the processor. When the processor is executing a first user program, switching to a second user program that is an updated version of the first user program is instructed. Variable information is created for identifying a variable to be changed by updating from the first user program to the second user program, and a variable to be maintained. The address in which the value of the variable to be maintained is stored is maintained, and the address for the variable to be changed is reassigned after the logic operation is stopped at the division of the logic operation.SELECTED DRAWING: Figure 5

Description

[Technical Field]

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

[0002] In factory automation, programmable logic controllers (PLCs) are the core controllers that control industrial machinery. PLCs control industrial machinery by executing user programs such as ladder programs. When any corrections are found in a user program, they are changed or commands are added (Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2001-125608 Summary of the Invention [Problem to be solved by the invention]

[0004] However, switching a PLC user program from the old one to the new one requires stopping the PLC. This stops the production line controlled by the PLC, resulting in a decrease in the production line's operating rate. Alternatively, switching the user program can be done by temporarily stopping sequence control while the PLC is running. This reduces the downtime of the production line. However, if it takes a long time to establish the relationships between the many variables used by the user program and their storage areas, it becomes difficult to switch the user program while the PLC is running. In other words, the larger the user program, the more difficult it becomes to rewrite the user program quickly.

[0005] Therefore, an object of the present invention is to efficiently switch user programs while keeping the PLC running. [Means for solving the problem]

[0006] The present invention is, for example, a processor that repeatedly executes logic operations based on a user program; a data memory for storing values ​​of variables accessed in response to the user program executed by the processor; a memory management unit that, when receiving an instruction to switch to a second user program that is an updated version of a first user program while the processor is executing the first user program, maintains the addresses in the data memory where the values ​​of the variables to be maintained are stored, based on variable information that identifies variables that will be changed when the first user program is updated to the second user program and variables that will be maintained, and updates the values ​​of the variables in the data memory where the values ​​of the variables to be changed are stored, by stopping the logic operations at a break in the logic operations; The present invention provides a programmable logic controller comprising: [Effects of the Invention]

[0007] According to the present invention, it is possible to efficiently switch user programs while keeping the PLC running. [Brief explanation of the drawings]

[0008] [Figure 1] Diagram explaining a PLC system [Figure 2] Diagram explaining the PC (setting support device) [Figure 3] Diagram explaining the basic unit [Figure 4] A diagram explaining the transfer control unit [Figure 5] Flowchart explaining how to transfer a project [Figure 6]Flowchart explaining how to handle global variables [Figure 7] Diagram showing an example of array modification [Figure 8] An example of changing the structure type [Figure 9] Diagram explaining function block instantiation [Figure 10] A diagram showing an example of a storage area allocated in memory. [Figure 11] Diagram explaining instance storage area [Figure 12] Diagram illustrating definition information, call tree and instance IDs [Figure 13] Diagram illustrating definition information, call tree and instance IDs [Figure 14] Flowchart showing how to save values [Figure 15] Flowchart showing how to restore values DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the scope of the invention as claimed, and not all combinations of features described in the embodiments are necessarily essential to the invention. Two or more of the features described in the embodiments may be arbitrarily combined. Furthermore, the same reference numerals are used for the same or similar components, and redundant explanations will be omitted.

[0010] (1) PLC system FIG. 1 shows an example of the configuration of a programmable logic controller system (hereinafter referred to as PLC system 1) according to an embodiment of the present invention. As shown in FIG. 1, this PLC system 1 includes a PC 2, which is a setting support device for editing user programs such as ladder programs; a base unit 3, which is a PLC (Programmable Logic Controller) for comprehensively controlling various control devices installed in a factory or the like; and multiple expansion units 113-115. In the PLC system 1, one or more expansion units 113-115 are connected to the base unit 3 via an expansion bus 500. The base unit 3 is also sometimes called a CPU unit or a main unit. Examples of the expansion units 113-115 include various units such as a motion unit, an input unit, an output unit, an input / output unit (I / O unit), an analog conversion unit, and a communication unit. The motion control function, the analog conversion function, and the communication function connected to the expansion bus 500 may be recognized by the base unit 3 as expansion units built into the base unit 3. Furthermore, motor drivers 4a to 4c may be connected via an industrial network to the basic unit 3. The motor drivers 4a to 4c drive motors 10a, 10b, and 10c, respectively.

[0011] The user program created by PC2, which is a setting support device, may be created using a graphical programming language such as a ladder language or a flowchart-format motion program, or may be created using a high-level programming language such as ST language or C language.

[0012] The basic unit 3 has 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, etc. The display unit 5 may switch the display content depending on the operation content of the operation unit 6. The display unit 5 usually displays the current values ​​(device values) of devices in the PLC system 1 and error information (presence or absence of alarms or warnings) that has occurred in the PLC system 1. A device is a memory area provided for storing device values ​​(device data) and may also be called a device memory. A device value is information that indicates the input status from input devices, the output status to output devices, and the status of internal relays (auxiliary relays), timers, counters, data memory, etc. set in a user program. Device values ​​are classified into bit and word types. A bit device stores a 1-bit device value. A word device stores a 1-word device value.

[0013] The motor drivers 4a to 4c are provided to extend the functions of the PLC system 1. The 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 and the like in accordance with commands from the basic unit 3. The motors 10a to 10c are, for example, servo motors or stepping motors.

[0014] The PC2 is a computer that provides a development environment for the PLC system 1. The PC2 is, for example, a portable notebook or tablet personal computer, and is equipped with a display unit 7 and an operation unit 8. A ladder program, which is an example of a user program for controlling the PLC system 1, is created using the PC2. The created ladder program is converted into mnemonic code within the PC2. The PC2 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 program converted into mnemonic code to the basic unit 3. The basic unit 3 converts the ladder program into machine code and stores it in a memory provided in the basic unit 3. Note that, although the mnemonic code is transmitted to the basic unit 3 in this example, the present invention is not limited to this. For example, the PC2 may convert the mnemonic code into intermediate code and transmit the intermediate code to the basic unit 3, or may convert the mnemonic code into object code and transmit the object code to the basic unit. These may also be mixed.

[0015] Although not shown in FIG. 1, the operation unit 8 of the PC 2 may include a pointing device such as a mouse connected to the PC 2. The PC 2 may also be configured to be detachably connected to the basic unit 3 via a communication cable 9a other than USB. The PC 2 may also be connected to the basic unit 3 wirelessly, without using the communication cable 9a. In this case, the communication cable 9a may be understood to represent a wireless link.

[0016] The basic unit 3 and motor driver 4a are connected by a communication cable 9b, and can communicate with each other (e.g., cyclic communication, message communication) via the communication cable 9b. The motor drivers 4a and 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 drivers 4b and 4c are connected by a communication cable 9d, and can communicate with each other via the communication cable 9d. Furthermore, the motor driver 4c can communicate with the basic unit 3 via the communication cables 9b, 9c, and 9d.

[0017] In this example, motor drivers 4a to 4b are connected, but the number of motor drivers 4 may be one or more. The manufacturers of the motor drivers 4a to 4c may be different or the same. For ease of explanation, it is assumed here that the manufacturers of the motor drivers 4a to 4c are different.

[0018] In the following, when common matters are described for the motor drivers 4a to 4c, they will be referred to as the motor driver 4. Similarly, when common matters are described for the motors 10a to 10c, they will be referred to as the motor 10.

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

[0020] The PLC's basic unit 3 and each of the expansion units 113 to 115 each execute a repetitive process. The timing at which the basic unit 3 executes a program and the timing at which the expansion units 113 to 115 execute a repetitive process can be synchronized, and data exchange can be synchronized. This function may be called an "inter-unit synchronization function." The motion control function and sequence control function included in the basic unit 3 can also synchronize the execution timing of processes and synchronize data exchange using the "inter-unit synchronization function."

[0021] (2) Setting support device FIG. 2 is a block diagram for explaining the electrical configuration of PC 2. As shown in FIG. 2, PC 2 includes a CPU 11, a display unit 7, an operation unit 8, a storage device 12, and a communication unit 13. The display unit 7, the operation unit 8, the storage device 12, and the communication unit 13 are each electrically connected to CPU 11. The storage device 12 includes RAM, ROM, HDD, and SSD, and may further include a removable memory card. CPU is an abbreviation for central processing unit. ROM is an abbreviation for read-only memory. RAM is an abbreviation for random access memory. HDD is an abbreviation for hard disk drive. SSD is an abbreviation for solid state drive.

[0022] A user of the PC 2 causes the CPU 11 to execute the setting support program 21 stored in the storage device 12, and edits a project 22 and sets each motor driver 4 via the operation unit 8. The PC 2 may be called an engineering tool. The project 22 has one or more user programs (POUs 25a to 25c), global variables 23, and variable type information 24 defined by the user. POU is a general term for modules, function blocks, and functions. Modules are executed periodically or in response to specified events. Functions and function blocks are executed in response to calls. When describing matters common to multiple POUs 25a to 25c, the POUs 25a to 25c are referred to as POU25. The global variables 23 are variables (variable group) that can be commonly accessed from the POUs 25a to 25c. Each of the POUs 25a to 25c has a program 26, such as a ladder program, and local variables 27. A local variable 27 is a variable (group of variables) that can be accessed only from the program 26 in the POU 25 to which it belongs. For example, the local variable 27 of POU 25c can be accessed from the program 26 of POU 25c, but cannot be accessed from the program 26 of POU 25a.

[0023] Editing the project 22 includes creating a new project 22 and modifying (re-editing) the project 22. The user reads out the project 22 stored in the storage device 12 as needed and modifies the project 22 using the setting assistance program 21. In this way, the version of the project 22 is updated. Basically, the old version of the project 22 is overwritten with the new version of the project 22.

[0024] The communication unit 13 communicates with the basic unit 3 via the communication cable 9a. The CPU 11 transfers the project 22 to the basic 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 may communicate with the motor driver 4 via the communication cable.

[0025] (3) Basic unit FIG. 3 shows the hardware configuration of the basic unit 3. The CPU 31 writes information to and reads information from the memory 32. The memory 32 may include a ROM 36, a RAM 37, a hard disk drive (HDD), an SSD, or a removable memory card (not shown). The ROM 36 may be any memory capable of retaining information even when power to the basic unit 3 is cut off, such as a flash memory or an EEPROM. The ROM 36 includes a storage area for storing a project 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 that controls the execution of user programs, the transfer of user programs, and switching between user programs. The ROM 36 may store a first project 22, which is an old version of the project, and a second project 22, which is a new version of the project, or may store only the second project 22. The RAM 37 may be referred to as a data memory. Furthermore, the CPU 31 receives information input from the operation unit 6. The CPU 31 displays various information on the display unit 5.

[0026] The CPU 31 is connected to the PC 2 via the communication unit 33a, and is connected to the motor driver 4 via the communication unit 33b to perform communication. The communication unit 33a is a communication circuit compatible with, for example, 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, MECHATROLINK-III). The communication units 33a and 33b are capable of performing cyclic communication and message communication.

[0027] The CPU 31 has a program execution unit 34 that executes the POU 25 included in the project 22, and a transfer control unit 35 that controls the transfer of the project 22 from the PC 2.

[0028] 4 shows details of the transfer control unit 35 and details of the information expanded in RAM 37. The transfer control unit 35 has a variable allocation unit 40 and a compilation unit 43. The variable allocation unit 40 further has a memory management unit 41 and an entity management unit 42. The variable allocation unit 40 allocates addresses in a storage area in RAM 37 to the global variables 23 and local variables 27 described in the project 22. The memory management unit 41 manages the allocation of addresses of the global variables 23 and local variables 27 stored in a common variable area 55. Common variable area 55 are referenced by both the new version program and the old version program. The entity management unit 42 assigns addresses in a first instance area 53 secured in the RAM 37 to instances of function blocks (FBs) and functions (FUNs) instantiated by being called by the first execution object deployed in the first execution object area 51. That is, each time a function block instance is defined in a POU 25, a function block instance is generated. The entity management unit 42 assigns addresses in a second instance area 54 secured in the RAM 37 to instances of function blocks instantiated by the second execution object deployed in the second execution object area 52. The first execution object is, for example, execution code generated by compiling the POU 25 included in the old version project 22 by the compilation unit 43. The second execution object is, for example, execution code generated by compiling the POU 25 included in the new version project 22 by the compilation unit 43. In this way, by storing the execution code of the new version and the execution code of the old version in the RAM 37, it is possible to update (switch) the execution code in a short time. For example, while the program execution unit 34 is executing the old version of the executable code, the compilation unit 43 can store the new version of the executable code in the second execution object area 52 .

[0029] The RAM 37 may further 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 stores information indicating which of the first execution code stored in the first execution object area 51 and the second execution code stored in the second execution object area 52 should be executed. The common variable area 55 stores global variables 23 and local variables 27 used by the first execution code and the second execution code. In this embodiment, the first execution code and the second execution code store variables and other data in the common variable area 55, which is a shared storage area. Therefore, when switching between execution codes, it is necessary to maintain, reallocate, or newly allocate addresses where variables are stored. For example, if there is a variable whose type remains unchanged between the first project 22 and the second project 22, the address assigned to that variable is maintained. This reduces the downtime of the execution code when switching between execution codes. If the type is changed or the size of the variable's storage area is expanded or reduced, the address assigned to that variable is changed. Furthermore, when a new variable is defined in the second project 22, a new address is assigned to that variable. The save area 56 is an area that temporarily stores values ​​stored in variables of the first project 22 when the values ​​stored in variables of the first project 22 are stored in variables of the second project 22. The variable update area 57 stores information (variable change information) that is useful for determining which variables will be maintained and which variables will be changed when updating from the first project 22 to the second project 22. The variable allocation area 58 is an area that stores information indicating the addresses (e.g., starting addresses) of storage areas assigned to each variable.

[0030] The variable allocation area 58 may 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 addresses of storage areas allocated to variables corresponding to the first project. The second variable allocation area 58b stores information indicating the addresses of storage areas allocated to variables corresponding to the second project.

[0031] The existence of multiple variable allocation areas 58a, 58b allows, for example, the memory management unit 41 to allocate addresses to variables corresponding to a new version of a project while the old version of the execution code is being executed by the program execution unit 34.

[0032] (4) How to update the program Generally, when the basic unit 3 is already executing an old version of the project 22, switching to a new version of the project 22 transferred from the PC 2 requires stopping the old version of the project 22. Stopping the project 22 stops the factory line controlled by the basic unit 3, preventing the factory from manufacturing products during that time. Therefore, downtime must be kept as short as possible. For example, one possible approach is to allocate separate variable areas in RAM 37 for storing the variables of the old version of the project 22 and the variables of the new version of the project 22, and copy the variables from one variable area to the other during downtime. However, of the many variables, only a small number are changed by updating the project 22. Therefore, downtime can be reduced by identifying the variables that actually require address changes, allocations, or value writing, and processing only those variables, rather than copying all of the many variables. For this reason, the common variable area 55 described above is employed. Because the shared variable area 55 is accessible by both the first and second execution codes, the addresses of variables whose types have not changed are maintained when switching between execution codes. The values ​​stored in those variables are also maintained. This significantly reduces the time required for tasks such as address allocation and value copying.

[0033] (4-1) Flowchart FIG. 5 shows how to switch from an older version of the project 22 to a newer version of the project 22 while the older version of the project 22 is running.

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

[0035] In S2, the CPU 31 (variable allocation unit 40) determines whether or not the types of all of one or more global variables 23 included in the new version of the project 22 have been changed, and, if necessary, reallocates addresses to the global variables 23. Details of S2 will be described later with reference to FIG.

[0036] In S3, the CPU 31 (variable allocation unit 40) determines whether or not one or more function blocks included in the new version of the project 22 have been changed, and reallocates addresses as necessary.

[0037] In S4, the CPU 31 (variable allocation unit 40) determines whether the types of all of one or more local variables 27 included in the new version of the project 22 have been changed, and, if necessary, reallocates addresses to the local variables 27. The details of S4 are the same as the details of S2.

[0038] In S5, the CPU 31 (compiler 43) recompiles all of one or more POUs 25 included in the new version of the project 22. The compiler 43 may recompile only the POUs 25 that have been edited by the user among all the POUs 25. The compiler 43 may also determine whether or not recompilation is necessary among all the POUs 25, and recompile only the POUs that are determined to require recompilation.

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

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

[0041] In S8, CPU 31 updates the values ​​stored in the variables. For example, CPU 31 updates the values ​​of the variables based on variable update information stored in variable update area 57. The variable update information includes, for example, the data type and address of the variable whose value is to be updated before the update, and the data type and address after the update, and an initial value. The variable update information may also include information indicating whether to retain or initialize the value for each variable. If the value of the variable is to be retained, CPU 31 reads the value of the variable from the address before the change, performs implicit type conversion as necessary, and writes it to the address after the change. If the value of the variable is to be initialized, CPU 31 writes the initial value to the address after the change.

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

[0043] (4-2) Details of change processing for global variables FIG. 6 shows in detail S2 (determining whether or not the types of all global variables 23 have been changed, and reallocating addresses to the global variables 23 as necessary).

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

[0045] In S11, the CPU 31 compares the old version of the project 22 with the new version of the project 22, and identifies all variables whose types, etc. have not changed. In other words, all variables whose allocated addresses do not need to be changed are identified.

[0046] In S12, the CPU 31 allocates the current address in the common variable area 55 to each variable identified in S11. That is, the address already allocated in the common variable area 55 is maintained.

[0047] In S13, the CPU 31 compares the old version of the project 22 with the new version of the project 22 to identify all deleted variables. Variables that exist in the old version of the project 22 but do not exist in the new version of the project 22 are identified. In other words, variables whose allocated addresses need to be changed to unused states are identified. Alternatively, addresses that should be changed from used states to unused states are identified.

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

[0049] In S15, the CPU 31 compares the old version of the project 22 with the new version of the project 22, identifies all the variables that have been changed, and selects one of the variables.

[0050] In S16, the CPU 31 determines whether the selected variable is a newly added variable. Here, a newly added variable is identified as a variable that does not exist in the old version of the project 22 but exists in the new version of the project 22. A variable that exists in both versions but whose type, etc. has been changed is determined to not be a newly added variable. If the selected variable is a newly added variable, the CPU 31 proceeds from S16 to S18. On the other hand, if the selected variable exists in both versions but whose type, etc. has been changed, the CPU 31 proceeds from S16 to S17.

[0051] In S17, the CPU 31 changes the old address allocated to the selected variable from a used state to an unused state (free state).Then, the CPU 31 proceeds from S17 to S18.

[0052] In S18, the CPU 31 allocates the variable selected in S15 to an empty address in the common variable area 55.

[0053] In S19, 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 for the variable selected in S15.

[0054] In S20, the CPU 31 determines whether any of the changed variables has not yet undergone address allocation processing. If any variable has not undergone address allocation processing, 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, if no variable has not undergone address allocation processing, the CPU 31 proceeds from S20 to S3 shown in FIG. 5.

[0055] (4-3) Change determination and reassignment of function block calls Here, the details of S3 will be explained. The CPU 31 compares the old version of the project 22 with the new version of the project 22 and determines whether there have been any changes to the function block calls. The function block calls may be defined as instances (memory areas). In the new version of the project 22, the CPU 31 allocates new memory areas to function block instances to which new function block calls have been added or whose consumed memory size has changed. The CPU 31 changes the memory areas allocated to the deleted function block instances to an unused state. For the function blocks whose addresses have been changed, the CPU 31 records information on variables included in the instances before the change in variable change information.

[0056] (4-4) Local variable change detection and reassignment The details of the processing in S4 are basically the same as the processing for the global variables 23. The CPU 31 compares the old version of the project 22 with the new version of the project 22 to determine whether any local variables 27 have been changed. If any local variables 27 have been changed, the CPU 31 allocates the same addresses as before the change to the local variables 27 that have not been changed. The CPU 31 allocates the local variables 27 that have been changed to vacant addresses. The reallocation procedure is as follows.

[0057] (i) Allocation of Unchanged Local Variables 27. Allocation of addresses to unchanged local variables 27 is performed without changing the address offset from the beginning of the function block.

[0058] (ii) Allocation of changed local variables 27. The changed local variables 27 are allocated to free space. The processing details for the added variables may be added to an update list during online transfer of the project 22 from the PC 2 to the basic unit 3. For example, the added variables are initialized to their initial values. Changed variables retain their pre-change values ​​according to the changes. Information about the changed variables (address, data type, initial value) is recorded in the variable change information. In this way, the flowchart for determining whether a local variable 27 has been changed and reallocating it is equivalent to the flowchart shown in Figure 6, with the global variable 23 replaced with the local variable 27. The address is determined according to the offset within the memory area that can be allocated to the local variable 27. (4-5) Recompile the POU Here, the process of S5 will be described in detail. The compile unit 43 compiles the POU 25 of the new version of the project 22 to create new execution code (object) in the second execution object area 52. The RAM 37 contains the first execution object area 51 and the second execution object area 52, and the program execution unit 34 references one of the areas indicated by the information stored in the management area 59 and executes the execution code stored therein. If the management area 59 references the first execution object area 51, the compile unit 43 creates a new execution object in the second execution object area 52 that is not referenced by the management area 59.

[0059] The CPU 31 determines whether a change has been made to the POU 25 (program module (PROGRAM), function block (FB), or function (FUN)). The CPU 31 determines that a change has been made to the POU 25 if any of the following conditions is met: The program is being edited. Local variable 27 is being edited. Global variable 23 related to the POU has been edited. The structure to which the POU relates has been edited. The function or function block related to the POU has been edited.

[0060] A function or function block related to a POU is edited if, for example, the type of an argument to the function or function block is changed, or the type of a structure used in an argument is changed.

[0061] If there is a change in POU 25, the compilation unit 43 recompiles POU 25. If there is no change in POU, the compilation unit 43 copies the currently executed object held in the first execution object area 51 to the second execution object area 52 as is.

[0062] The allocation of variables and the compilation of programs are performed separately. Therefore, in step S5, the compilation unit 43 may compile all programs regardless of whether there are any changes. As an example, according to this embodiment, the compilation unit 43 performs compilation only on programs that have differences, and simply copies the execution code for programs that do not have differences. This reduces the compilation time. For this reason, the execution code is relocatable.

[0063] Here, S4 is executed for all POUs 25, and then S5 is executed for all POUs 25. However, this is just an example. For example, one POU 25 to be processed may be selected from multiple POUs 25, S4 and S5 may be executed, and then another POU 25 may be selected as the processing target, and S4 and S5 may be executed.

[0064] S2 to S5 are executed while the old version of project 22 is still running, thereby reducing the downtime caused by switching project 22.

[0065] (4-6) Details of variable changes The CPU 31 may determine whether a variable has been changed based on the name (variable name) given to the variable. For example, if a variable has the same name and the same variable type between the old version of the project 22 and the new version of the project 22, the CPU 31 retains the value stored in the variable as is. There may also be variables with the same name but whose type has changed. In this case, the CPU 31 retains the value stored in the variable if it is possible to track the value by applying implicit type conversion between the type before the change and the type after the change. If it is not possible to track the value, the CPU 31 initializes the variable with an initial value.

[0066] If no initial value is specified, CPU 31 assigns a value predetermined for that type as the initial value of that variable.

[0067] If the data type has been changed, the CPU 31 takes into consideration the data type before the change and the data type after the change, and performs implicit type conversion to follow the type change.

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

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

[0070] (iii) The maximum length of a character string may be changed. For example, if the maximum length of the new type is shorter than the maximum length of the old type, a character string stored in a variable of the old type cannot be stored in a variable of the new type. In this case, the CPU 31 may truncate the character string to fit the maximum length of the new type.

[0071] (iv) The data type of a string may be changed (e.g., from STRING to WSTRING). For example, the STRING type may be ASCII or a multibyte string (e.g., ShiftJIS). The WSTRING type may be a Unicode string (utf-16). In this case, the CPU 31 converts the character code so that the string is saved. If the string stored in a variable of the previous data type cannot be expressed in the changed data type, the CPU 31 may replace the string with a specific character.

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

[0073] (vi) If the types of both are an enumeration and an integer type, the CPU 31 performs an implicit type conversion.

[0074] (vii) The number of elements or the number of dimensions of an array may be changed. In this case, the CPU 31 retains the values ​​of the corresponding element numbers that existed before the change.

[0075] Figure 7 shows an example of an array change. In this example, variable varA is an array-type variable. The number of dimensions of variable varA is 2. In this example, the range of possible element numbers is changed from [0...1][0...2] to [0...2][0...1]. According to Figure 7, varA[0][0], varA[0][1], varA[1][0], and varA[1][1] exist before and after the change. Therefore, the values ​​stored in the variable before the change are carried over to the variable after the change. On the other hand, while varA[0][2] and varA[1][2] existed in the variable before the change, these do not exist in the variable definition after the change. Therefore, varA[0][2] and varA[1][2] are deleted along with their values. Furthermore, varA[2][0] and varA[2][1] have been added to the variable definition after the change. Therefore, a specified initial value (e.g., 0) is stored in varA[2][0] and varA[2][1], respectively. The predetermined initial value may be designated in advance by the user.

[0076] (viii) The type of a structure may be changed. If there are corresponding member names between the structure before and after the change, the above-mentioned change processes (i) to (vii) are executed between those members.

[0077] Figure 8 shows an example of changing the type of a structure. The structure STRUCT1 before the change has one-word unsigned integer variables mMem1 and mMem2, and a two-word signed integer variable mMem3 as member variables. stHoge is defined as a variable of this structure type. 2 is stored in stHoge.mMem1. 3 is stored in stHoge.mMem2. 2 is stored in stHoge.mMem3.

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

[0079] (ix) A function block instance may be added. In other words, a function block call is added to POU25. In this case, CPU31 initializes all variables included in the added function block instance to their initial values. A function block instance includes input variables (IN), output variables (OUT), and local variables.

[0080] (4-7) Function Block Details A function block generally consists of code (program) and data. The program of an individual function block may be called a "definition." The data may be called an "instance." The relationship between definition and instance allows the same program to be applied to multiple pieces of data.

[0081] Figure 9 suggests that three different instances are created for the same function block definition in POU25. A function block is called by specifying an instance. Note that the same instance may be called multiple times. The name of the function block is waveAnalyze. This function block has defined as input variables an array type aryWaveForm that holds waveform data and a variable waveLength that indicates the length of the waveform. As output variables, it has a variable Frequency that outputs the frequency of the waveform data, a Maxval that outputs the maximum value of the waveform amplitude, and a Minval that outputs the minimum value of the waveform amplitude.

[0082] In the first call, the waveform data stored in the variable arrayWave1 is input to the aryWaveForm of intance1, and the value stored in the variable arrayLen1 of intance1 is output to waveLength. The input and output variables can be omitted. If the input variable is omitted, the instance variable will retain its value.

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

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

[0085] In this way, function blocks are used by creating instances. An instance is a memory entity, and may be understood to be the same as an entity of a structure of the data type "function block." Function block instances can also include global function blocks and local function blocks. Local function blocks are defined as local variables 27. Instances may also be defined within function blocks as local variables 27. Function block instances are nested via local variables 27.

[0086] (4-8) Function Block Details Program modules (PROGRAM) and function block instances may be added, changed, or deleted, which requires the allocation of storage space for the associated local variables 27.

[0087] The CPU 31 allocates the storage area for global variables 23 and the storage area for local variables 27 of program modules and function blocks in consecutive storage areas. When a module or function block instance is added, deleted, or changed (the number of variables used changes), the CPU 31 allocates new consecutive storage area in an available storage area. When an instance is deleted or changed, the storage area used by that instance is changed to an unused state. For the added or changed instance, consecutive storage area is allocated within the unused storage area and the instance is allocated there. This makes it possible to maintain the addresses allocated to the variables of unchanged modules and function blocks.

[0088] FIG. 10 shows two examples i and ii of storage areas reserved in RAM 37. In example i, before the change, six function block instances I1 to I6 are stored consecutively in storage areas. In FIG. 10, "unused" indicates free storage areas. After the change, the size of instance I4 has been increased. Therefore, the storage area for instance I4 is reserved in the free area.

[0089] In Example ii, before the change, six function block instances I1 to I6 were stored consecutively in the memory area. After the change, instances I1 and I3 were deleted. Therefore, the memory areas for instances I1 and I3 were changed to unused states.

[0090] Although function block instances are described here, program modules and storage areas for global variables 23 are treated similarly.

[0091] It may be wasteful to allocate storage space to unused areas every time the number of variables used in a program module or function block is changed. Specifically, even for small changes, all values ​​of local variables 27 in the module or function block must be moved when the project 22 is transferred online. As a result, the program downtime during online transfer increases.

[0092] Therefore, extra unused storage areas may be allocated to global variables 23, modules, function blocks, and instances, i.e., storage areas of a size larger than the size required to store them may be allocated to them.

[0093] As shown in example iii of Figure 10, for example, the size required to store instance I1 of a function block before the change is Size1, but in reality, a larger memory area of ​​Size2 is allocated. 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 assumed to be smaller than Size2. In this case, the CPU 31 does not change the memory area allocated to the instance. This makes it possible to reduce downtime.

[0094] It should be noted that the size of instance I1 may be reduced to Size4, which is smaller than the original size, Size1. In this case, CPU 31 may also maintain the memory area of ​​Size2 allocated to instance I1. This reduces downtime.

[0095] The unused area written on the right side is also necessary in the case of Example iii. This is because when a new module or function block is added, its instance must be allocated in the unused area on the right side. It is also possible that adding variables within an individual storage area will result in insufficient storage space, making it impossible to add or change new variables. In this case, the CPU 31 may move the storage area for POU 25 to the entire unused area. Alternatively, the CPU 31 may display an error notice to the user on the display unit 5 or 7 and cause the online transfer of project 22 to fail.

[0096] The CPU 31 reserves an entire unused area and unused areas (excess areas) for individual modules and function block instances in the RAM 37. The size of each of these areas may be designated in advance by the user.

[0097] (4-9) Function Block Details Within a program module (PROGRAM) or function block instance there are one or more variables. The allocation of addresses to each of these variables is explained below.

[0098] In order to shorten the downtime of program execution during online transfer, the allocation method of example iii may be adopted for allocating storage space to instances. When variables are added, deleted, or changed during online transfer, the variables are allocated as follows: (i) The added variable is newly allocated to an unused memory area. (ii) The storage area allocated to the deleted variable is changed to unused. (iii) For the modified variables, the originally allocated storage area is changed to unused, and the new storage area is allocated within the unused area. In other words, the change is processed as a combination of deletion and addition. As a result, the addresses of variables whose types have not been changed are maintained.

[0099] Figure 11 shows the storage area of ​​function block instance I1, which consists of variables a to e. Before the change, variables a, b, and c were of type DINT. Variable d was of type UINT. Variable e was of type array (e.g., ARRAY[0...3]).

[0100] In this example, the type of variable b has been changed from DINT to LREAL, so the LREAL variable b cannot be stored in the original storage area where the DINT type was stored. Therefore, the storage area for the LREAL variable b is allocated to the unused area that was reserved. In this case, the variable update information for variable b does not include information about the address, data type, or initial value, but instead describes the initialization method as "implicit type conversion."

[0101] (4-10) Managing modules and function block instances A function block is called by specifying an instance from a function block call command. To call a function block, the caller needs the following two pieces of information about the function block: (A) Address of function block execution code (object) (B) Address of local variable of function block instance The address of A is linked to the definition of the function block. When any program changes are made through online transfer, the address of A changes. This is not limited to changes to the function block in question, but may also occur in conjunction with changes to other function blocks. Function block definitions and calls may also be added.

[0102] The address of B is linked to the instance of the function block. When an instance of the function block is added by online transfer, the address of B is added. If the number of local variables 27 used in the function block changes due to online transfer, and new storage space is required, the address of the work area also changes.

[0103] Instance information and instance IDs are used so that the calling program does not need to be recompiled even if the addresses of A and B change due to online transfer. Instance information is information that associates and stores the instance ID, the address of the object, and the address of the local variable 27. The instance ID is identification information for the function block entity.

[0104] The calling program (POU 25) or function block embeds the instance ID of the function block it calls into the execution code (object code), and references the instance information at runtime using the instance ID as an index. This allows the address of the object and the address of the local variable 27 to be obtained. An example of instance information is as follows: ┌─────────┬─────────────┬─────────────┐ │Instance ID │Object address │Local variable address │ ├─────────┼─────────────┼─────────────┤ │ 1 │ 0x80003020 │ 0xC0000570 │ ├─────────┼─────────────┼─────────────┤ │ 2 │ 0x80003020 │ 0xC000A200 │ ├─────────┼─────────────┼─────────────┤ │ 3 │ 0x80003020 │ 0xC000CAF0 │ ├─────────┼─────────────┼─────────────┤ │ 4 │ 0x80003B00 │ 0xC0007200 │ ├─────────┼─────────────┼─────────────┤ │ : │ : │ : │ ├─────────┼─────────────┼─────────────┤ │ : │ : │ : │ In this example, the function blocks with instance IDs 1, 2, and 3 have the same definition. That is, the object addresses of instance IDs 1, 2, and 3 are the same, and the execution programs are the same.

[0105] When project 22 is transferred online, the addresses of the objects and local variables 27 change. Therefore, it is necessary to update the instance information when the program is changed. However, if the changed instance information is prepared in advance, it can be referenced and the storage area can be switched. This will shorten the downtime of sequence control.

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

[0107] In this embodiment, instance IDs are used as identification IDs for managing addresses, including programs (modules) and functions. However, this is just one example. Instance IDs may also be used exclusively for function blocks. Instance IDs are obtained by analyzing calls.

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

[0109] Program Prog1 calls FBDef1 and FBDef2. FBDef1 is called once, creating an instance inst1. FBDef2 is called twice, creating an instance inst2 and an instance inst3.

[0110] Program Prog2 calls FBDef3, which is called once and an instance inst1 is created.

[0111] FBDef1 calls FBDef3 twice, which creates the instances inst1 and inst2.

[0112] FBDef2 calls FBDef3 once, which creates the instance inst1.

[0113] The call tree and instance IDs are shown at the bottom of Figure 12. Program Prog1 has been assigned an instance ID of 1. Program Prog2 has been assigned an instance ID of 2.

[0114] The function block FBDef1 called from program Prog1 is assigned an instance ID of 3. The function block FBDef3 called twice from this function block FBDef1 is assigned instance IDs of 4 and 5, respectively. The function block FBDef2 called twice from program Prog1 is assigned instance IDs of 6 and 8. The function block FBDef3 called from the function block FBDef2 called the first time is assigned an instance ID of 7. The function block FBDef3 called from the function block FBDef2 called the second time is assigned an instance ID of 9.

[0115] The function block FBDef3 called from the program Prog2 is assigned an instance ID of 10.

[0116] Figure 13 shows that inst2 of program Prog1 has been deleted from the old version of project 22 shown in Figure 12, and a new version of project 22 has been created. Furthermore, inst2 (FBDef3) has been added to FBDef2.

[0117] When a module is added or deleted, or when the instance definition of a function block is changed, the CPU 31 reconstructs the call (instance) tree and changes the instance ID of the deleted instance to an unused state. Furthermore, the CPU 31 assigns an instance ID to the added instance.

[0118] As shown in FIG. 13, since inst2 of Prog1 has been deleted, the instance of FBDef2 with instance ID=6 and the instance of FBDef3 with instance ID=7 have been deleted in the call tree.

[0119] From the FBDef2 instance with instance ID = 8, FBDef3 is called twice due to a change in the definition of FBDef2. Here, the first call of FBDef3 existed before the change, so the instance ID for the first call of FBDef3 remains 9. The second call of FBDef3 was added, so the instance ID for the second call of FBDef3 is 11.

[0120] In this way, the instance ID does not change for function blocks whose calling relationships have not changed. As a result, if the function block it calls has not changed, the instance ID does not change and recompilation is not required.

[0121] In this embodiment, the instance ID serves as an index for the instance information array. Therefore, unused instance IDs may be reused. For example, when FBDef3 is called for the second time, 6 or 7 may be reused as the instance ID.

[0122] (4-11) Update values (4-11-1) Saving values 14 shows a method for saving values ​​stored in variables used in the old version of project 22 during the update process in S8. Saving and restoring values ​​is performed while sequence control is stopped.

[0123] In step S31, the CPU 31 saves the value stored in the global variable 23 in the save area 56.

[0124] S32-S34 are processes related to the module in POU 25. Hereinafter, for convenience, the module may be referred to as module 25.

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

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

[0127] In S34, the CPU 31 determines whether or not there are any modules 25 remaining that have not been evacuated. If there are any modules 25 remaining that have not been evacuated, the CPU 31 returns from S34 to S32 and selects the next module 25. Thereafter, the CPU 31 repeats S32 to S34. When there are no more modules 25 remaining that have not been evacuated, the CPU 31 proceeds from S34 to S35.

[0128] S35-S39 are processes related to the function blocks of the POU.

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

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

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

[0132] In S38, the CPU 31 determines whether any unsaved instances remain. If any unsaved instances remain, the CPU 31 returns from S38 to S36 and selects the next instance. Thereafter, the CPU 31 repeats S36 to S38. If no unsaved instances remain, the CPU 31 proceeds from S38 to S39.

[0133] In S39, the CPU 31 determines whether or not there are any unsaved function blocks remaining in the old version of the project 22. If there are any unsaved function blocks remaining, the CPU 31 returns from S39 to S35 and selects the next function block. Thereafter, the CPU 31 repeats S35 to S39. If there are no unsaved function blocks remaining, the CPU 31 ends the save process.

[0134] (4-11-2) Returning values 15 shows a method of restoring values ​​from the save area 56 to variables to be used in the new version of the project 22, part of the update process in S8. If the address assigned to the variable in the old version of the project 22 matches the address to be assigned to the variable in the new version of the project 22, there is no need to restore the value. If the address assigned to the variable in the old version of the project 22 does not match the address to be assigned to the variable in the new version of the project 22, the value is restored.

[0135] In step S41, the CPU 31 restores the value stored in the save area 56 to the global variable 23. S42-S44 are module-related processes.

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

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

[0138] In S44, the CPU 31 determines whether or not there are any modules 25 remaining that have not yet been restored. If there are any modules 25 remaining that have not yet been restored, the CPU 31 returns from S44 to S42 and selects the next module 25. Thereafter, the CPU 31 repeats S42 to S44. When there are no more modules 25 remaining that have not yet been restored, the CPU 31 proceeds from S44 to S45.

[0139] S45-S49 are processing related to function blocks.

[0140] In S45, the CPU 31 selects function blocks that have not yet been restored from among all function blocks defined in the new version of the project 22. Note that for function blocks that have been newly added to the new version of the project 22, initial values ​​are stored.

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

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

[0143] In S48, the CPU 31 determines whether any unrestored instances remain. If any unrestored instances remain, the CPU 31 returns from S48 to S46 and selects the next instance. Thereafter, the CPU 31 repeats S46 to S48. If no unrestored instances remain, the CPU 31 proceeds from S48 to S49.

[0144] In S49, the CPU 31 determines whether or not there are any unrestored function blocks remaining in the new version of the project 22. If there are any unrestored function blocks remaining, the CPU 31 returns from S49 to S45 and selects the next function block. Thereafter, the CPU 31 repeats S45 to S49. If there are no unrestored function blocks remaining, the CPU 31 ends the restoration process.

[0145] If the common variable area 55 has a sufficient memory size, the edited or added variable may be allocated to a previously unused address. For example, the value of the edited variable may be moved from the memory area before the change to the memory area after the change.

[0146] (5) Technical concepts derived from the embodiments [Point 1] For example, while the program execution unit 34 is executing a first user program, the CPU 31 (memory management unit 41) may receive an instruction to switch to a second user program, which is an updated version of the first user program. In this case, the memory management unit 41 may create variable information that identifies variables that will be changed when the first user program is updated to the second user program and variables that will be maintained, and store the information in the RAM 37 (e.g., the variable update area 57). The memory management unit 41h may maintain addresses in the RAM 37 where the values ​​of the maintained variables are stored, based on the variable information, and may assign addresses in the RAM 37 where the values ​​of the changed variables are stored, by stopping the logic operation performed by the program execution unit 34 at a break in the logic operation. Here, the logic operation refers to, for example, the execution of the first user program (e.g., a ladder program) by the program execution unit 34.

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

[0148] [Point 2] The memory management unit 41 maintains the address in the variable storage area where the value of the variable to be maintained is stored, based on the variable information. The variable information may be, for example, type information 24 indicating the type of each variable, variable update information stored in the variable update area 57, or instance information managing instance IDs, etc. The memory management unit 41 assigns addresses in the variable storage area where the values ​​of the variables to be changed are stored, stores the second user program in the second execution object area 52, and changes the information stored in the third storage area (management area 59) from information indicating that the first user program will be executed to information indicating that the second user program will be executed. Furthermore, the memory management unit 41 writes predetermined values ​​to the variables whose addresses have been changed at the end of the logic operation. This will reduce the downtime of the user program.

[0149] [Point 3] A variable that is changed may be one whose type or size is changed. When the type or size is changed, not only the allocated storage area (address) but also the storage contents (value) often change. Therefore, for variables whose type or size is changed, address reallocation is performed. Conversely, for variables whose type and size are maintained, the value is also maintained. In other words, address reallocation is not necessary. This will reduce the pause time of the user program.

[0150] [Point 4] 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, or the type or size of the member included in the structure is changed.

[0151] [Point 5] The variable to be changed may be a variable whose storage address is changed.

[0152] [Point 6] The variables may include a first global variable and a second global variable. The first global variable is a variable that is maintained, and the second global variable is a variable that is changed. In this case, the memory manager 41 may maintain the address of the first global variable and assign the second global variable to an available address (an unused address) in the data memory.

[0153] [Point 7] The variables may include a first local variable and a second local variable. The first local variable is a variable that is maintained and the second local variable is a variable that is changed. The memory manager 41 may maintain the address of the first local variable and allocate the second local variable to an available address in the data memory.

[0154] [Point 8] 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 addresses of the first local variable and the second local variable using address offsets from the starting address of the function block.

[0155] [Point 9] The first storage area (e.g., first execution object area 51) is an area for storing execution objects of a first user program. The second storage area (e.g., second execution object area 52) is an area for storing execution objects of a second user program. After the allocation of addresses in the variable storage area for the variables to be changed is completed, the compilation unit 43 may compile the second user program to generate execution objects.

[0156] [Point 10] The user program may include multiple POUs 25. The compilation unit 43 may recompile only those POUs 25 determined to require recompilation among the multiple POUs 25 to regenerate executable objects. The compilation unit 43 may copy executable objects of POUs 25 not determined to require recompilation from the first user program to the second user program. This may shorten the downtime. Note that POUs not determined to require recompilation may be referred to as POUs determined not to require recompilation.

[0157] Recompilation may also be required if the variables or structure definitions used by POU25 are changed. [Before change] struct ST_A { mem1: UINT; mem2: UINT; } END_STRUCT [After change] TYPE ST_A STRUCT mem1: ARRAY[0..9] OF UINT; mem2: UINT; END_STRUCT; END_TYPE [POU (No Edit)] VAR var1: ST_A; END_VAR; var1.mem2 := 10; In this case, the offset from the beginning of the var1.mem2 structure changes from 2 bytes to 20 bytes due to the change. Therefore, it is determined that POU25 needs to be recompiled.

[0158] [Point 11] The retained variable may be a variable for which both the name and type of the variable are retained. The memory management unit 41 may retain the value stored in the retained variable when the first user program was stopped, and allow the second user program to use the value as is.

[0159] [Point 12] The variables may include array-type variables with two or more dimensions. There may be cases where the name of an array-type variable in the first user program matches the name of the array-type variable in the second user program, the number of dimensions of the array-type variable in the first user program matches the number of dimensions of the array-type variable in the second user program, and the range of possible element numbers of the array-type variable in the first user program differs from the range of possible element numbers of the array-type variable in the first user program. In this case, when a variable in the first user program has the same element number as the element number of an array-type variable in the second 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. If there is no array-type variable in the first user program with the same element number as the element number of an array-type variable in the second 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.

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

[0161] [Point 14] A user program including multiple function blocks may be updated from a first user program to a second user program. In this case, entity information identifying the first function block entity (instance) that is maintained by the update and the second function block entity that is changed by the update may be stored in the RAM 37. This entity information (instance information) may be part of the type information 24. Based on the entity information, the CPU 31 (entity management unit 42) maintains, in the second user program, entity identification information (e.g., instance ID) of the first function block entity in the first user program, and also maintains the address of the first function block entity. The entity management unit 42 may change the entity identification information of the second function block entity and assign an available address to the second function block entity.

[0162] [Point 15] A second function block may exist in both the first user program and the second user program, but a variable included in the second function block may be changed. In this case, the entity management unit 42 changes the address assigned to the entity of the second function block in the first user program to an unused state. Furthermore, the entity management unit 42 may assign a free address to the entity of the second function block in the second user program. When a variable is changed, the size of the function block instance often changes as well. Therefore, the storage area for such an instance may be released, and the instance may be allocated to an unused area.

[0163] [Point 16] In some cases, the second function block does not exist in the first user program but is added to the second user program. The entity management unit 42 may allocate an available address to the entity of the second function block in the second user program.

[0164] [Point 17] In some cases, the second function block exists in the first user program but is deleted from the second user program. In this case, the entity management unit 42 may change the address where the entity of the second function block in the first user program was stored to an unused state.

[0165] [Point 18] 11, the first function block entity and the second function block entity in the first user program may be stored in a memory area larger than the size of the entity before online transfer. In this case, the second function block entity in the second user program may be allocated a memory area within the range of the memory area allocated to the second function block entity in the first user program. The size and address of the memory area may be predetermined or fixed.

[0166] [Point 19] When a variable is added to the second function block, a storage area for the added variable may be allocated within the range of the storage area.

[0167] [Point of View 20] When a variable is deleted in the second function block, the storage area for the deleted variable may be changed to an unused state within the range of the storage area.

[0168] [Point of View 21] A user program (for example, POU25) may use the entity identification information to obtain the address of the object for each entity of the function block and the addresses of the variables used within the function block.

[0169] [Point of View 22] There may be provided a method for controlling a programmable logic controller having a processor that repeatedly executes logic operations based on a user program, and a data memory that stores values ​​of variables accessed in response to the user program executed by the processor, the method comprising: receiving an instruction to switch to a second user program that is an updated version of a first user program while the processor is executing the first user program; maintaining an address in a data memory at which a value of a variable to be maintained is stored based on variable information that identifies a variable that is changed by updating from the first user program to the second user program and a variable that is to be maintained; updating the value of the variable in the data memory in which the value of the variable to be changed is stored, by stopping the logic operation at a break in the logic operation; It has.

[0170] [Point of View 23] The control program 38 stored in the ROM 36 may cause the programmable logic controller to execute the programmable logic controller control method described in item 21.

[0171] The invention is not limited to the above-described embodiment, and various modifications and variations are possible within the scope of the gist of the invention.

Claims

1. a processor that repeatedly executes logic operations based on a user program; a data memory for storing values ​​of variables accessed in response to the user program executed by the processor; a memory management unit that, when receiving an instruction to switch to a second user program that is an updated version of a first user program while the processor is executing the first user program, maintains the addresses in the data memory where the values ​​of the variables to be maintained are stored, based on variable information that identifies variables that will be changed when the first user program is updated to the second user program and variables that will be maintained, and updates the values ​​of the variables in the data memory where the values ​​of the variables to be changed are stored, by stopping the logic operations at a break in the logic operations; A programmable logic controller comprising:

2. further comprising a program memory for storing a user program; The program memory includes: a first storage area for storing the first user program; a second storage area for storing the second user program; a third storage area for storing information indicating whether a user program stored in the first storage area or the second storage area is to be executed, a variable storage area of ​​the data memory that stores the values ​​of the variables is a storage area shared by the first user program and the second user program; The memory management unit maintaining an address in the variable storage area where the value of the variable to be maintained is stored based on the variable information, and performing an address allocation in the variable storage area where the value of the variable to be changed is stored; 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; At the breakpoint of the logic operation, a predetermined value is written to the variable whose address has been changed.

2. The programmable logic controller of claim 1.

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

4. 2. The programmable logic controller according to claim 1, wherein, when the variable is a variable of a structure type, the variable to be changed is a variable in which a member included in the structure is added or deleted, and a type or size of the member included in the structure is changed.

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

6. the variables include a first global variable and a second global variable, the first global variable being the variable to be maintained and the second global variable being the variable to be changed; 2. The programmable logic controller of claim 1, wherein the memory manager maintains the address of the first global variable and allocates the second global variable to an available address in the data memory.

7. the variables include a first local variable and a second local variable, the first local variable being the maintained variable and the second local variable being the changed variable; 2. The programmable logic controller of claim 1, wherein the memory manager maintains the address of the first local variable and allocates the second local variable to an available address in the data memory.

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

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

10. The user program is made up of a plurality of POUs, 2. The programmable logic controller of claim 1, wherein, of the plurality of POUs, only those POUs determined to require recompilation are recompiled to regenerate execution objects, and execution objects of those POUs not determined to require recompilation are copied from the first user program to the second user program.

11. the maintained variable is a variable for which both the name of the variable and the type of the variable are maintained; 2. The programmable logic controller according to claim 1, wherein the memory management unit maintains the values ​​stored in the maintained variables when the first user program is stopped, and allows the second user program to use the values ​​as they are.

12. The variables include array-type variables having two or more dimensions, If the name of the array type variable in the first user program and the name of the array type variable in the second user program match, and the number of dimensions of the array type variable in the first user program and the number of dimensions of the array type variable in the second user program match, and the range of possible element numbers of the array type variable in the first user program and the range of possible element numbers of the array type variable in the first user program are different, The memory management unit When a variable having the same element number as the element number of the array-type variable in the second user program exists in the array-type variable in the first user program, the value of the array-type variable in the first user program identified by the element number is maintained as the value of the array-type variable in the second user program identified by the element number, If there is no array-type variable in the first user program having an element number identical to that of the array-type variable 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.

2. The programmable logic controller of claim 1.

13. 13. The programmable logic controller of 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. 2. The programmable logic controller according to claim 1, further comprising an entity management unit that, when the user program including a plurality of function blocks is updated from the first user program to the second user program, maintains in the second user program entity identification information of the first function block entity in the first user program based on entity information that identifies the first function block entity maintained by the update and the second function block entity changed by the update, maintains addresses of the first function block entity, changes the entity identification information of the second function block entity, and assigns vacant addresses to the second function block entity.

15. When the second function block exists in both the first user program and the second user program, but a variable included in the second function block is changed, The entity management unit changing an address assigned to the entity of the second function block in the first user program to an unused state; 15. The programmable logic controller according to claim 14, wherein a vacant address is assigned to the entity of the second function block in the second user program.

16. the second function block is a function block that does not exist in the first user program and is to be added to the second user program; 15. The programmable logic controller according to claim 14, wherein the entity management unit allocates an available address to the entity of the second function block in the second user program.

17. the second function block is present in the first user program but is a function block to be deleted from the second user program; 15. The programmable logic controller according to claim 14, wherein the entity management unit changes the address at which the entity of the second function block in the first user program was stored to an unused state.

18. the entity of the first function block and the entity of the second function block in the first user program are stored in advance in a storage area larger than the size of the entity at the time of online transfer, 15. The programmable logic controller of claim 14, wherein the second function block entity in the second user program is allocated a memory area within the range of the memory area allocated to the second function block entity in the first user program.

19. 19. The programmable logic controller according to claim 18, wherein when a variable is added in the second function block, a storage area for the added variable is allocated within the range of the storage area.

20. 19. The programmable logic controller according to claim 18, wherein when a variable is deleted in the second function block, the storage area of ​​the deleted variable within the storage area is changed to an unused state.

21. 15. The programmable logic controller according to claim 14, wherein the user program uses the entity identification information to obtain the address of an object for each entity of a function block and the address of a variable used within the function block.

22. A method for controlling a programmable logic controller having a processor that repeatedly executes logic operations based on a user program, and a data memory that stores values ​​of variables accessed in accordance with the user program executed by the processor, the method comprising: receiving an instruction to switch to a second user program that is an updated version of a first user program while the processor is executing the first user program; maintaining an address in the data memory at which a value of a variable to be maintained is stored, based on variable information that identifies a variable that is changed by updating from the first user program to the second user program and a variable that is to be maintained; updating the value of the variable in the data memory in which the value of the variable to be changed is stored, by stopping the logic operation at a break in the logic operation; 1. A method for controlling a programmable logic controller, comprising:

23. A program that causes a programmable logic controller to execute the programmable logic controller control method according to claim 22.

Images