JP2006202233A - Controller and program for same - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To batch update a plurality of control programs at run time. <P>SOLUTION: Control programs PG3' and PG9' that are update versions of control programs PG3 and PG9 are stored in a free area of a program memory 23. This can be done independently even while PG3 or PG9 is executed. The storage locations of PG3' and PG9' are stored in a program change request queue 22. During later scan end processing, by reference to the queue 22, a program information table 21 is updated sequentially about PG3 and PG9. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a method for updating a plurality of programs during operation of a programmable controller, particularly in updating a user program of a programmable controller.

  A programmable controller is a computer used for applications such as FA (Factory Automation), and there are many systems that are not desired to be stopped as much as possible, such as 24-hour operation, depending on user-specified specifications.

  However, the user program running in the system is required to be updated for various reasons such as a simple program mistake of the user, a change in operation specifications, and a change in setting value due to aging of the device.

In order to satisfy these conditions, some programmable controllers have a program update function (hereinafter referred to as RUN update) during operation of the controller.
Currently, the following three patterns can be considered for the update during RUN that is generally performed from the change range.

That is, instructions are replaced in units of one instruction (step) in the program.
・ Change all programs in the program.
・ Change multiple programs in one programmable controller at the same time.
It is.

  With the recent increase in memory capacity and processing speed of programmable controllers, the number of programs that can be handled simultaneously by a single controller has increased, and the necessity for the simultaneous update function during RUN of multiple programs is increasing.

  In order to solve such a problem of simultaneous updating of a plurality of programs during RUN, Patent Document 1 has two banks of program code on the controller, rewrite one of the program code memories, and store a program storage bank table. A method for simultaneously updating a plurality of programs by changing them has been proposed.

  However, even if a large-capacity memory is required due to an increase in program capacity, it is difficult to have memory that is not normally used only for the update function during RUN (the same size as the program memory). This is disadvantageous.

On the other hand, Patent Document 2 has an area for storing a program that is an execution code of an actual controller and a table indicating the start address of each program, and when an update program has been written to the program storage area A method for changing the address of the program address table is proposed.
Japanese Patent Laid-Open No. 10-207512 JP 2001-142510 A

  However, with the method of Patent Document 2, it is not considered to perform simultaneous updating of a plurality of programs during RUN (Although it can be performed in Patent Document 1, a problem arises that a large-capacity memory is required as described above). That is, in Patent Document 2, the POU address table is updated on the condition that the POU has been stored in the storage area, and only updating of one POU is considered. If a plurality of POUs are updated simultaneously (collectively), it is necessary to pass not only the POU but also some additional information (for example, a list of POUs to be updated collectively) to the controller side. Otherwise, the controller cannot determine when the POU address table can be replaced. Alternatively, as described above, the POU address table is updated when the POU has been stored in the storage area. For example, if an upgraded version of a POU is stored in the storage area during execution of this POU, a problem may occur. There is sex.

  Furthermore, in the method described in the above-mentioned Patent Document 2, in order to store the update program in the divided area as the free area of the program storage area is divided finely while the updating of the program during RUN is repeated. One program is divided into empty areas, and the divided individual programs are connected by inserting a jump instruction. Such a method is feasible, but if it is generated on the support tool side, it cannot be supported on other support tools. If it is realized on the controller side, it manages free space in the program storage area and generates jump instructions. The processing such as changing the jump destination address of the jump instruction existing in the original program becomes heavy, which is not realistic.

  An object of the present invention relates to updating during a RUN in a programmable controller, and enables a batch update of a plurality of programs without requiring a large-capacity memory (two-bank memory), or further divides an empty area in a program memory. It is an object of the present invention to provide a programmable controller that can be configured so that an updated program is added to the end of a stored program group.

  A programmable controller according to the present invention includes a program memory for storing a plurality of control programs, a table for storing a storage position of each control program stored in the program memory, a program change request queue having a read pointer and a write pointer, When an updated version of any control program stored in the program memory is sent from the outside, the updated version of the control program is stored in an empty area of the program memory, and the storage location information is Update program receiving means for storing in the program change request queue and advancing the write pointer, and updating the table during scan end processing, and the position of the read pointer does not match the position of the write pointer If there is an update request, Constant, and using the storage location information of the update program stored in the program change request queue and configured to have a program updating means for updating the table.

  When the programmable controller configured as described above receives the updated version of the control program, it stores it in the free space of the program memory, but does not immediately update the table, but temporarily sets the program storage location etc. in the program change request queue. Store it. Therefore, this process can be performed even while the control program is being executed. There may be a plurality of updated control programs. Then, the table is updated using the program change request queue during the scan end process. When there are a plurality of updated control programs, a plurality of storage location information can be stored in the program change request queue and updated at a time during the scan end process.

  In the programmable controller configured as described above, for example, the size of each control program is also stored in the table, and based on the storage position and size of each control program in the table, there is an empty area between the control programs. It is determined whether or not there is an empty area, and when there is an empty area, the program memory further includes an empty area adjusting means for pre-packing a control program stored immediately after the empty area. May be.

  In addition, regarding this configuration, the control program stored in the program memory is further provided with a save area for temporarily saving the control program stored in the program memory, and the free area adjusting means is stored immediately after the free area. May be realized by re-storing the saved control program from the beginning of the empty area after saving the program in the save area.

  According to the programmable controller of the present invention, it is possible to update a plurality of programs at once without requiring a large-capacity memory (two-bank memory) in connection with updating during RUN in the programmable controller. Alternatively, the free area on the program memory is not divided, and the updated version program can be added to the end of the stored program group. In other words, it is not necessary to perform processing such as dividing and storing the program in accordance with the finely divided free areas.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a schematic configuration diagram of a programmable controller system used in this example.

  In FIG. 1, a controller support device 10 stores an input device 12 on which a user performs input in order to create a desired control program, a display device 11 that displays the input contents, and a predetermined application program. Storage medium 13 or the like. The compiler 1 converts the control program created by the controller support device 10 into code that can be executed by the controller 3 (programmable controller main body or the like). In the figure, the compiler 1 and the controller support device 10 are separately shown, but they may be configured by the same hardware (for example, on a personal computer). The program code converted in this way is transferred to the controller 3 via the transmission device 2, and the controller 3 stores it. In the following description, the compiler 1 and the transmission device 2 will be omitted.

  Note that the controller support device 10 is realized by a computer such as a personal computer, and is not particularly shown in the figure. Of course, the controller support device 10 also has a CPU, a memory, a communication interface, and the like. By reading and executing a predetermined application program stored in the computer, the above control program (a program for controlling various control targets (not shown) executed by the controller 3) Etc.) and the process of transmitting this control program to the controller 3 side via the communication interface is executed.

  Similarly, the controller 3 includes a CPU / MPU, a storage device such as a memory, a communication interface, and the like, although not particularly illustrated. This storage device is, for example, a memory (RAM, flash memory, or the like) that stores program information tables 21 and 51 and a program change request queue 22 described later, a program memory 23 that stores a control program, a system temporary memory 52, or the like. The storage device also stores an application program for causing the CPU / MPU or the like to execute processes such as those shown in FIGS.

Next, a method for storing a control program in the controller 3 will be described.
The controller 3 includes a program information table 21 shown in FIG. 2A, a program change request queue 22 shown in FIG. 2B, and a program memory 23 shown in FIG.

  When the control program converted by the compiler of FIG. 1 and converted into a code executable by the controller 3 is loaded on the controller 3 side via the communication interface (not shown), it is stored in the program memory 23 of FIG. Be expanded. The control program placed on the program memory 23 is expanded in the order in which it is registered. The number of the control program developed in the program memory 23 and the start address of the storage location are stored in the program number 21a and the storage address 21b of the program information table 21 shown in FIG. Note that the program numbers are PG1 and PG3 shown in the figure, and hereinafter, each control program may be referred to as, for example, a program PG1 or the like using the program numbers.

  The program change request queue 22 has a configuration for realizing a function of updating a plurality of control programs at once during a RUN, and includes a read pointer 31 and a write pointer 32 shown in the figure. This will be described with reference to FIG.

FIG. 3 shows an example of a case where there are two program (PG3 and PG9) update requests during the RUN of the controller.
That is, first, on the controller support device 10 side, updated versions of the programs PG3 and PG9 (upgraded version, modified version, etc., which are hereinafter referred to as PG3 ′ and PG9 ′ in order to distinguish them from the old version) are created. The Then, the support apparatus 10 transmits the programs PG3 ′ and PG9 ′ to the controller 3 side together with the update request. The controller 3 that has received this needs to perform a process of replacing these updated control programs (PG3 ′, PG9 ′) with the old version control programs (PG3, PG9), that is, a program update process. Therefore, as shown in FIG. 3C, the updated control programs (PG3 ′, PG9 ′) are temporarily stored at the end of the program memory 23 (after the stored program area). During this storage process, the control process and the like are operated by the existing control program (PG3, PG9), so it is not particularly necessary to be aware of the write timing. The storage capacity of the program memory 23 needs to be “capacity that can store all control programs + 1 capacity that can store one or more updated programs”, but the memory capacity is small compared to the above-described two-bank configuration. That's it.

  When the storage of the updated control program (PG3 ′, PG9 ′) is completed, the program numbers (PG3, PG9) and the start addresses (ADR5, ADR6) of the storage locations in the program memory 23 are shown in FIG. As shown in (), the program change request queue 22 is written and the write pointer 32 is advanced (incremented). The program number is the same whether it is an old version or an updated version. The notations such as PG3 ', PG9', etc. are for easy understanding of the present description.

  Since this method realizes batch update of a plurality of programs, if the processing of FIG. 4 is started while writing to the queue is performed (before writing is completed for all of the plurality of programs). The update will be done incompletely. Therefore, in order to prevent this, for example, interrupts are prohibited until the writing to the queue is completed, or the priority of the writing processing to the queue is set to be equal to or higher than the processing of FIG. Therefore, it is desirable to prevent halfway updates.

  Next, this program change request is recognized, and the control program update process (that is, the update of the stored contents of the program information table 21) is performed. This is the timing when all the control programs are not executed. It is necessary to do in. The normal controller 3 performs a data input process to the program → execution of the program → result output process from the program as one scan, and the system program of the controller 3 performs a process between scans (hereinafter referred to as a scan end process). ). Therefore, the control program update process must be performed during the scan end process.

FIG. 4 is an RUN update process flow called from the scan end process.
Hereinafter, the process of FIG. 4 will be described with reference to FIGS.
In the process of FIG. 4, first, the read pointer 31 and the write pointer 32 in the program change request queue 22 are compared to determine whether or not the positions pointed to by both pointers match (step S11). If the positions of both pointers are the same (step S11, NO), there is no program change request, and the process ends.

On the other hand, if the positions indicated by the two pointers are different (step S11, YES), it means that there is a program change request, so the following processing is performed.
First, the program number stored in the address indicated by the read pointer 31 (initially PG3 in the example of FIG. 3B) is substituted into the variable I. Further, the head address of the program information table 21 (assumed to be Ptr_1 in the example of FIG. 3A) is substituted into the variable J (step S12).

  Then, it is determined whether or not the program number 21a stored at the address indicated by the variable J (initially the top address Ptr_1) is equal to the value of the variable I (step S13). If they do not match (step S13, NO), the value of the variable J is repeatedly advanced until they match (for example, when data is stored in units of 1 byte in the program information table 21). Is J = J + 1 (byte) or the like) (step S14).

  If the program number 21a at the position indicated by the variable J matches the value of the variable I (step S13, YES), the value of the storage address 21b corresponding to the program number 21a is set to the read pointer 31 of the program change request queue 22. Is updated with the value of the storage address 33 at the position indicated by (step S15). Since it is PG3 at first as described above, ADR2 is stored in the storage address 21b in FIG. 3A, but is changed to ADR5 as shown in FIG. 5A.

  After the change, the read pointer 31 is advanced by 1 (step S16). Then, the process returns to step S11 again, and the processes in steps S12 to S16 are repeatedly executed until the read pointer 31 and the write pointer 32 match (that is, until there is no change request). In the example of FIG. 3B, since there is PG9 other than the above PG3, the above processing is also executed for PG9, and when the state shown in FIGS. 5A and 5B is reached, the processing ends. .

In this example, since it is assumed that the existing control program is updated, it is not assumed that a completely new control program is added.
Note that the processing in step S11 is particularly significant in a two-chip controller. That is, conventionally, there is a two-chip controller having a first CPU that executes a control program and a second CPU that performs interface processing between support tools. In such a configuration, the first CPU can determine whether or not the program has been updated by performing the process of step S11.

  FIG. 5 shows the state of the program memory and the like when the above series of processing is completed. In the program information table 21 of FIG. 5A, the storage addresses 21b corresponding to PG3 and PG9 are updated to ADR5 and ADR6, respectively, and the program change request queue 22 of FIG. It coincides with the position of the pointer 32. Depending on the contents of the updated program information table 21, the areas 41 and 42 in which the old version programs PG3 and PG9 are stored in the program memory 23 of FIG. 5C are managed as free areas. Although not particularly illustrated, each pointer indicating the end of each stored program is prepared in the program memory 23. Therefore, in the program information table 21 in FIG. 5A, for example, only the start address (ADR1) of the storage area of the program PG1 is stored, but the program PG1 is stored in the storage areas ADR1 to ADR2 by the pointer. Is stored. However, the present invention is not limited to this example. For example, size information may be stored as in a program information table 51 described later.

  The process of FIG. 4 is a process that only updates the value of the storage address 21b of the program information table 21, and is a process that does not become a burden unless the number of update request programs is large.

  As described above, in this example, a plurality of programs can be updated at once. Further, the process itself of storing the updated version program in the program memory 23 can be performed even while the program to be updated is being executed.

  With the processing described above, the program update processing during RUN is completed, but the update program is added after the stored program area to invalidate the old program (update the program information table 21). As a result, vacant areas are inevitably distributed on the program memory 23 (see FIG. 5C).

In Patent Document 2, the program to be updated is divided in accordance with the free space, but the above-described problem occurs.
As a result, in this example, when a free area occurs, the control programs already stored in the program memory 23 are sequentially left-adjusted so that the free areas are not distributed (the last control). Propose a method to collect free space after the program.

  In this embodiment, for the sake of simplicity, an area is searched in order from the top of the program memory 23, and the control program next to the first free area is moved so as to start from the top of this free area. The process of filling the next control program in the same way for another free area is also shown. A part of this process can use the algorithm of FIG. Hereinafter, a detailed description will be given with reference to FIGS.

  First, in this example, as shown in FIG. 6A, the program information table 51 has a size 51c for storing the size of the control program in addition to the program number 51a and the storage address 51b. Thus, in the program storing / updating process, the process of storing the size of the control program stored in the program memory 23 in the size 51c is also performed. In this example, a system temporary memory 52 shown in FIG. The system temporary memory 52 is a memory for temporarily evacuating the control program whenever there is a control program whose storage location is to be moved among the plurality of control programs stored in the program memory 23. If the size of the vacant area is larger than the size of the control program to be moved, direct movement is possible, but the system temporary memory 52 is prepared because it is not necessarily large. The system temporary memory 52 secures the maximum size of a single program allowed by the controller 3. The system temporary memory 52 may use a part of the storage area of the program memory 23 (in this case, the storage capacity of the program memory 23 is increased accordingly).

  The configuration of the program change request queue 22 is not different from that described above, but the usage is different. That is, FIG. 6D shows a state in which the program PG8 is saved in the system temporary memory 52, and accordingly, the program change request queue 22 has a program number PG8 as shown in FIG. 6B. Is stored in association with the head address (ADR10) of the save destination. Furthermore, when the program PG8 is written back to a new storage location in the program memory 23, the start address of the new storage location is stored as shown in FIG.

Hereinafter, the program storage location rearrangement processing using the above configuration will be described.
In this program rearrangement process, the storage state of each control program (whether or not there is an empty area before the control program) is checked by referring to the program information table 51 in ascending order of the storage address 51b. If there is an area, the process of moving the control program (to the front) is sequentially executed. In the illustrated example, since the storage address is ADR1 <ADR3 <ADR5 <ADR6, the processing described below is performed for each control program in the order of PG1, PG8, PG3, and PG9.

  First, it is determined whether “the value of the storage address 51b + the value of the size 51c” of the control program immediately before the control program to be processed matches the value of the storage address 51b of the process target program. This is to check whether there is a free area by checking whether “start address + size” of each control program is the start address of the next control program. However, since only the first PG1 has no previous control program, another process is performed. That is, it is determined whether or not the value of the storage address 51b of PG1 matches the head address of the program memory 23. Since they match in the example shown in the figure, PG1 ends the process without being moved, and PG8 is subsequently processed.

  With respect to PG8, it is checked whether or not the “start address ADR1 + size 51c” of the immediately preceding control program PG1 matches the start address ADR3 of the program PG8, as shown in FIG. Since “start address + size” of PG1 = ADR2, since they do not match, it can be seen that there is an empty area before the program PG8.

  If it is determined that they do not coincide with each other, the program PG 8 is subsequently moved to a position where the start address is ADR 2. For this purpose, the program PG 8 is temporarily stored in the system temporary memory 52 as described above. Evacuate (copy) automatically. Then, the program number (PG8) of the saved control program and the save destination head address (ADR10) are stored in the program change request queue 22, and the write pointer 32 is incremented. As a result, the program change request queue 22 is in the state shown in FIG.

  Next, the process shown in FIG. 4 is called. As a result, the program information table 51 is in the state shown in FIG. That is, the storage address 51b corresponding to PG8 is updated from ADR3 to ADR10. Further, since the read pointer 31 is advanced by one in step S16, the program change request queue 22 is in the state shown in FIG. That is, the position of the read pointer 31 and the position of the write pointer 32 coincide with each other. Further, according to the contents of the program information table 51 shown in FIG. 7A, the program memory 23 has the empty area 61 shown in FIG. 7C (the area where the program PG8 was present is also an empty area). ing).

  Subsequently, a process of writing back the program PG 8 from the system temporary memory 52 to the head of the empty area 61 is executed. That is, as shown in FIG. 8C, the program PG8 is copied by setting the start address of the copy destination of the program PG8 saved in the system temporary memory 52 as "start address of PG1 + size = ADR2". . When the copying is completed, as shown in FIG. 8B, the program change request queue 22 is set with the program number PG8 written in the program memory and its start address ADR2, and the write pointer 32 is incremented.

  Then, by calling and executing the processing of FIG. 4 again, the program information table 51 is in the state shown in FIG. That is, the storage address 51b corresponding to PG8 is updated from ADR10 to ADR2.

  The processing described above is executed in the same manner for other control programs. That is, since the check is performed in the order of PG1, PG8, PG3, and PG9 as described above, the process for PG3 is executed in the same manner as in the case of PG8. The same applies to PG9. If a certain control program is moved, basically all subsequent control programs are moved, so that the check process may be omitted and the movement process may be performed immediately.

  When the processing for PG9 is completed, the storage state of the program memory 23 is a state in which an empty area exists collectively after the stored program. Therefore, when a program update is performed thereafter, the updated version program is stored in this empty area, and therefore it is not necessary to divide and store the updated version program.

  The example of the embodiment of the present invention has been described above, but the present invention is not limited to such an example. For example, in the above-described example, the program change request queue 22 used for the program update process by the user request is also used (shared) for the program storage location relocation process by the system. May be used separately. In this way, the program change request queue by the user request and the queue used by the system are prepared in order to speed up the program relocation by preferentially processing the system request, This is because program rearrangement can be executed regardless of whether or not scanning is in progress. This is because the program storage location rearrangement process according to the system request moves the same program, and does not affect the operation regardless of whether the program before the movement or the program after the movement is executed. However, overwriting another program in the system temporary memory 52 during execution of the program stored in the system temporary memory 52 is not a problem.

  Alternatively, in addition to the method using the above two queues, for example, only one queue is shared, but bit information for determining whether the request is from the system or the user is provided in the program change request queue. May be. This modification will be described below with reference to FIGS. 9 and 10. In this modification, generally, as shown in FIG. 9B, first, the program change request queue 70 is managed using not only the read pointer 31 and the write pointer 32 but also the system read pointer 71. ing. In addition, the program change request queue 70 stores not only the program number 73 and the storage address 74 but also bit information 72. If the bit information 72 is “1”, it means that the stored data is based on the program storage location relocation process (by a request from the system), and if the bit information 72 is “0”, This means that the stored data is related to the update process during RUN (according to a user request). That is, when data is stored in the program change request queue 70 during the program storage location rearrangement processing described with reference to FIGS. 6 to 8, “1” is stored in the bit information 72. On the other hand, when the updated version program is stored in the program memory 23 as described with reference to FIG. 3, “0” is stored in the bit information 72 when the data is stored in the program change request queue 70. Note that “by user request” means that the update request is sent from the support apparatus 10.

  In the example shown in FIG. 9, a program PG3 ′, which is an updated version of the program PG3, is sent in response to a user request and stored in the program memory 23, and then corresponds to PG3 in the program information table 51 by update processing during RUN. The storage address to be changed is changed to ADR 5, and then PG 8 is saved in the system temporary memory 52 by the above-described rearrangement processing of the program storage location, and this storage location is stored in the program change request queue 70. In this case, the bit information 72 is “1” as illustrated. In this state, a program PG 9 ′, which is an updated version of the program PG 9, is sent in response to a user request, which is stored in the program memory 23 and its storage position data is stored in the program change request queue 70. In this case, the bit information 72 is “0” as illustrated.

  As described above, the data storage states of the program information table 51, the program change request queue 70, the program memory 23, and the system temporary memory 52 are as shown in FIGS.

Then, in this state, the scan end process is started, and a processing routine for executing the RUN update process shown in FIG. 10 is called during this process.
The processing shown in FIG. 10 is basically the same as the processing shown in FIG. 4 except that the data having bit information 72 of “1” is first used using the system read pointer 71. The update processing during RUN as the processing target is executed, and then the update processing during RUN is executed using the read pointer 31 for the data whose bit information 72 is “0”.

  In the process shown in FIG. 10, first, it is determined whether or not the position of the system read pointer 71 is the same as the position of the write pointer 32 (step S21). The processing proceeds to step S28 without executing the processing after S22.

  If the position of the system read pointer 71 is different from the position of the write pointer (step S21, YES), it is further determined whether or not the bit information 72 of the data pointed to by the system read pointer 71 is “1” ( If the bit information 72 is '0' (step S22, NO), the process proceeds to step S27 without executing the processes after step S23, and advances (increments) the system read pointer 71. ), The process returns to step S21.

  On the other hand, if the bit information 72 is “1” (step S22, YES), the process proceeds to step S23 and subsequent steps. The processing of steps S23 to S27 is substantially the same as the processing of steps S12 to S16 shown in FIG. 4 and will not be described here.

  The system read pointer 71 and the read pointer 31 are initially in the same position, and even if the system read pointer 71 is advanced by the above processing, the read pointer 31 is not advanced.

  When the above processing is executed for the example of FIG. 9 above, first, the system read pointer 71 indicates the position of the data related to PG9 first, and its bit information 72 is “0”. The determination in S22 is NO, and the system read pointer 71 is advanced by 1 in step S27. This time, the position of the data relating to PG8 is obtained, and the bit information 72 is “1”. Therefore, the processing in steps S23 to S26 is performed. Will be executed. As a result, in the program information table 51, in the state shown in FIG. 9A, the storage address corresponding to PG8 is ADR3, but this is updated to ADR10. Then, when the system read pointer 71 is advanced by 1 again in step S27, the position of the pointer 71 becomes the same as the position of the write pointer 32. Therefore, the determination in step S21 is NO, and the process proceeds to step S28.

  In step S28, it is determined whether or not the position of the read pointer 31 is the same as the position of the write pointer 32. If the position is the same (NO in step S28), the process after step S29 is not executed, The process ends. On the other hand, if they are not the same (step S28, YES), it is determined whether or not the bit information 72 of the data pointed to by the read pointer 31 is “0” (step S29), and the bit information 72 is “1”. If so (step S29, NO), the process proceeds to step S34, the read pointer 31 is advanced, and then the process returns to step S28.

  On the other hand, if the bit information 72 is “0” (step S29, YES), the process proceeds to step S30 and subsequent steps. The processing of steps S30 to S34 is substantially the same as the processing of steps S12 to S16 shown in FIG. 4 and will not be described here. However, when this processing is executed for the example of FIG. In the state shown in FIG. 9A, the storage address corresponding to PG9 is ADR4, but this is updated to ADR6.

  The present invention is not limited to the example of the embodiment described above. For example, instead of using the program change request queue 22, when downloading an updated program from the support apparatus 10 to the controller 3, a "list of programs to be updated at once" and an update request command are passed together. It may be.

It is a schematic block diagram of a programmable controller system. (A) is an example of a program information table, (b) is an example of a program change request queue, and (c) is an example of a program memory. FIG. 3 is an example of data storage when there are two program update requests during RUN based on the example of FIG. It is a RUN update process flowchart. It is a figure which shows a data storage state when the process of FIG. 4 is performed based on the example of FIG. FIG. 10 is a diagram (part 1) for explaining a program storage position rearrangement process; FIG. 10 is a diagram (part 2) for explaining the program storage position rearrangement process; FIG. 10 is a diagram (No. 3) for explaining the program storage position rearrangement process; It is a specific example for demonstrating a modification. It is a RUN update process flowchart according to a modification.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Compiler 2 Transmission apparatus 3 Controller 10 Controller support apparatus 11 Display apparatus 12 Input apparatus 13 Recording medium 21 Program information table 21a Program number 21b Storage address 22 Program change request queue 23 Program memory 31 Read pointer 32 Write pointer 33 Storage address 41, 42 Area 51 Program information table 51a Program number 51b Storage address 51c Size 52 System temporary memory 61 Free area

Claims (4)

A program memory for storing a plurality of control programs;
A table for storing the storage position of each control program stored in the program memory;
A program change request queue having a read pointer and a write pointer;
When an updated version of any control program stored in the program memory is sent from the outside, the updated version of the control program is stored in an empty area of the program memory, and the storage location information is Updated version program receiving means for storing the program change request queue and advancing the write pointer;
If the table is updated during the scan end process and the position of the read pointer does not match the position of the write pointer, it is determined that there is an update request and is stored in the program change request queue. Program update means for updating the table using storage location information of the updated version program;
The controller characterized by having. The table also stores the size of each control program,
Based on the storage position and size of each control program in the table, it is determined whether or not there is a free area between the control programs. If there is a free area, the free space in the program memory 2. The controller according to claim 1, further comprising an empty area adjusting means for pre-packing a control program stored immediately thereafter. A storage area for temporarily storing the control program stored in the program memory;
The empty area adjusting means saves the control program stored immediately after the empty area to the save area, and then stores the saved control program from the beginning of the empty area to re-fill the front end. The controller according to claim 2, wherein: On the computer,
Using a program memory for storing a plurality of control programs, a table for storing the storage position of each control program stored in the program memory, and a program change request queue having a read pointer and a write pointer,
When an updated version of one of the control programs stored in the program memory is sent from the outside, the updated version of the control program is stored in an empty area of the program memory, and the storage location is set in the program A function to store the change request queue and advance the write pointer;
During the scan end process, if the position of the read pointer and the position of the write pointer do not match, it is determined that there is an update request, and depending on the storage position of the updated version program stored in the program change request queue, A function of updating the storage position of the table;
A program to realize

Images