JP3038279B2 - Programmable controller system - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a PC system comprising a plurality of programmable controllers (hereinafter abbreviated as PC), and more particularly, to a transfer system, a plant control, etc., which cannot be processed by a single CPU alone. When processing a large-scale system that cannot be controlled without processing using a CPU, each CPU uses an interlock or the like to process one large sequence program as a whole while affecting each other. The present invention relates to a PC system including a CPU of a PC and its programming device.

[0002]

2. Description of the Related Art In a conventional PC system using a plurality of CPUs, a system mainly using a link, that is, a so-called link system is used. This link system is a network for causing a programming device to communicate with a plurality of CPUs. FIG. 9 shows a flowchart of a link processing LINK in this network.

When the CPU link switching process is executed in block 9-1, the operation shifts to LINK. Block 9
When the network address of the communicating CPU is input by the programming device in -2, the network address is transferred to all CPUs in block 9-3. Blocks 9-4 and 9-5 with CP with that network address
The connection process with U is performed, and the communication is enabled.

However, in such a link system,
Since it is not possible to access the entire CPU at one time and only one-to-one communication can be performed at the same time, it is impossible to monitor programs of a plurality of CPUs at once, and monitor programs of other CPUs. Sometimes a certain CPU
A series of operations, such as performing link processing, replacing a communication cable, and reloading, must be repeated by the number of CPUs.

[0005] Incidentally, regarding such a conventional technique, 1
"Hitachi Review" published in July 989 (UDC: 658.
527.7'132), and the programmable controller H series described on pages 43 to 48.

In a PC system using a plurality of CPUs, each individual CPU operates independently.
The transmission and reception of the I / O information via the external wiring affect each other. However, in such a case, the monitor screen by the programming device
Unless the user has knowledge of the interrelationships in advance, there is no function to display the information, and it is impossible to understand unless the external wiring or the operation of the PC I / O is checked.

[0007]

As described above, when a plurality of CPUs each having an independent program form one large-scale control system while exerting influence on each other, a network using a link system requires a CPU. Since the mutual influence between them is not known, there is a problem that the usability is poor, and the program of each CPU cannot be monitored at the same time, so that the efficiency of user debugging is not good.

In other words, when debugging all programs constituted by each CPU, the state of the interlock signal from the other CPUs cannot be seen. Therefore, in order to analyze abnormal operation, peripheral devices are sequentially connected to each CPU. I had to debug while monitoring with.

In this regard, as a specific example, each CPU
Referring to FIG. 3 showing a ladder program in FIG. 3 and an interlock state between CPUs, in order to debug the program in FIG. 3, FIGS. 3 (a), (b) and
As shown in (c), monitor display and circuit correction must be performed separately for each CPU.

When the program must be monitored for each CPU as described above, when the CPU is monitored, it is intuitively understood that the signal X0 in FIG. 3B is the signal of the coil Y0 of the CPU. Absent. Moreover, the ON / OFF condition of the coil Y0 of the CPU at this time cannot be seen unless the connection with the programming device is switched from the CPU to the CPU and FIG. 3A is monitored.

Similarly, when the CPU is monitored, FIG.
It cannot be intuitively understood that the signal X1 of (c) is a signal of the coil Y1 of the CPU . Furthermore, ON / OFF condition of the coil Y1 of the CPU switches the connection between the programming device from the CPU to the CPU, it can not be seen unless the monitor to FIG 3 (b).

Further, when the CPU is monitored, FIG.
It cannot be intuitively understood that the signal X2 in (a) is a signal of the coil Y2 of the CPU. Further, the ON / OFF condition of the coil Y2 of the CPU is determined by switching the connection with the programming device from the CPU to the CPU, as shown in FIG.
Can not be seen unless you monitor.

Therefore, in the prior art, monitoring and debugging a plurality of ladder programs takes a very long time, and as the number of CPUs used increases, the time and effort increases, and the work efficiency becomes very poor. I was

In order to understand the overall operation when the ladder programs in a plurality of, for example, three CPUs are operated in combination, the ladder program is shown in FIG.
(b) and (c), it was very difficult.

SUMMARY OF THE INVENTION The present invention has been made to solve this problem, and an object of the present invention is to provide a large-scale control program in which the mutual relationship between a plurality of CPUs can be easily understood and debugged easily. An object of the present invention is to provide a PC system which can be used.

[0016]

SUMMARY OF THE INVENTION The object of the present invention is to make each CPU have an ID code and to know which function of the overall control system is responsible for each CPU.
This is achieved by creating a system in which the programs in U interact with each other and handle the entire control system.

Further, the present invention is attained by allowing one or more CPUs or programming devices to have a list of interlock signals in a data table so that the status of interlock signals between the CPUs can be grasped on a monitor screen. You. Specifically, the object of the present invention is to
User that stores the contents of the
User program memory and the above sequence program
CPU to read from user program memory and execute
To control the CPU, I / O and user programs
System memory with a program to control
I / O interface to input and output external signals for
With multiple programmable controllers connected by external wiring
Controller and sequence program creation and monitoring
Programming device with a programming device for performing
In the controller system, the above sequence program
CPU identification that is included in the
Separate information and I / O phase between each CPU by the external wiring
The interlock information indicating the interrelationship and each CPU
To recognize your position in the body system configuration
ID code of each of the CPUs.
Based on the PU information and the ID code, the CPU
-Sequence program is integrated into one ladder sequence
Displayed as an interlock program, and
From the ladder sequence program
To interlock between CPU sequence programs
Display to show the interaction
Is done.

[0018]

When a plurality of CPUs perform a program process having a mutual relationship by an interlock, each CPU has an ID code and knows its position in the entire control system. With the monitor function, a plurality of programs can be monitored in a linked form. In addition, the interlock relationship between the interlocks can be monitored simultaneously with the interlock signal list in the data table of one or more CPUs or programming devices. In addition, when creating, monitoring, and debugging a program, it can be performed efficiently with little effort. Also, since each CPU has an ID code and knows its position in the overall control system, one-to-many control by the programming device can be easily performed.

[0019]

DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, a PC system according to the present invention will be described.
This will be described in detail with reference to the illustrated embodiment. FIG. 1 shows a programming device 1-1 and a plurality of CPUs 1-4, 1-5, 1-6.
In this embodiment, the CPUs 1-4, 1-5, and 1-6 are connected by links (link modules) 1-13, 1-14, and 1-15, respectively. , Can communicate with each other.
Each of the CPUs 1-4, 1-5, and 1-6 has an independent program, and these programs are managed by the individual CPUs.

The CPUs 1-4, 1-5, 1-5
-6 each have an ID code, so that each CPU itself can recognize its own position in the entire control system even if it is operated by an independent program. On the other hand, programming device 1-
Numeral 1 manages program data 1-2 and monitor data 1-3 by an internal user program memory.

The program data 1-2 is stored in each CPU.
As shown in FIG. 2, the program to be processed is divided into an operand part 2-1 and an operation code part 2-2, and the operand part 2-1 has an I / O No. Information (interlock information indicating I / O interrelationship between CPUs) 2-3
However, the instruction information 2-4 is input to the operation code portion 2-2.

Further, the peripheral device information 2-5 is also input to the operation code portion 2-2 together with the instruction information. The peripheral device information 2-5 is provided with CPU identification information 2-6. The ID code which each CPU individually has is set in the identification information. Here, CPU knowledge
The separate information is information indicating the address of the CPU.
The ID code means that each CPU has the entire system configuration.
Code to confirm your position in
You.

FIG. 6 shows a hardware configuration of the programming device 1-1 and the CPU 1-4 in the embodiment of FIG. 1, and the CPUs 1-5 and 1-6 are omitted. As is apparent from FIG. 6, in this embodiment, C
The PUs 1-4, 1-5, and 1-6 are not actually a single CPU but also include other hardware.
When it is distinguished from a single PU, it is described as a CPU unit.

First, the hardware configuration of the programming device 1-1 includes a user program memory 6-3 in which a user program is written, a display 6-4 for displaying the user program and system information, and an input device for inputting. Keyboard 6-5, a communication I / F 6-6 for exchanging information with the CPU unit, and a system memory 6 in which a program for controlling the programming device is written.
-7, a CPU 6-8 for executing the program written in the system memory, and a floppy disk 6- for recording and storing the program and system information.
Consists of nine.

Next, the hardware configuration of the CPU unit 1-4 includes communication I / Fs 6-10 and 6-11 for exchanging information with other CPU units and programming devices.
An I / O 6-12 for connecting to an input / output device, and a user program memory 6- in which a user program is written
13, a system memory 6-14 in which a control program for the CPU is written, and a CPU 6-15 for executing the program written in the system memory. The same applies to the CPU units 1-5 and 1-6.

Next, the operation of this embodiment will be described. Program data 1-2 with CPU identification information
Is transmitted from the programming device 1-1 to the CPU (1-4), by comparing this information with the ID code of the CPU itself, it is determined whether the data is program data to be processed in the CPU. . If the program data is to be processed in the CPU, it is processed in the user memory 1-7 in the CPU.

If it is not the program data to be processed in the CPU, the program data is sent to the CPU (1-5) via the link 1-13. Therefore, this CPU performs the same processing as the processing performed by the CPU. By doing so, each program data is sent to the CPU to be processed and is processed by the user memory.

The use of the CPU identification information makes it possible to transfer program data from the programming device to the individual CPUs via the network.

Next, a description will be given of the operation of this embodiment for simultaneously monitoring the programs of the CPUs connected by the link by the programming device 1-1. Here, in order to facilitate understanding, as in the case of the prior art, a case where the PC system connected by a link is as shown in FIG. 3 will be described.

FIG. 7 shows the programming device 1 at this time.
Shows the status of the memory in the memory 7-1. The memory 7-1 has a program storage area designation CPU table 7-2.
And a program storage table 7-3. The program storage area designation CPU table 7-2 is linked to the interlock information table 7-4, and is a table corresponding thereto.

First, the user writes the names of the CPUs having the respective programs that the user wants to unify and monitor in a predetermined column of the program storage area designation CPU 7-2. FIG. 8 shows an input screen for that and an example of the input operation of the CPU name.

First, on the screen, C is read to read the program.
Ask the PU name (8-1). Therefore, when a necessary CPU name (here, CPU1) is input in response to this, the CPU1 is displayed on the screen, and the next CPU name is asked.
(8-2). Then, enter the CPU name again (here, CP
U3), CPU1 and CPU3 are displayed on the screen, and the next CPU name is asked (8-3).

Here, a CPU is provided between CPU 1 and CPU 3.
Key in the cursor "@" to insert 2. Then, the CPU 2 is inserted between the CPU 1 and the CPU 3 (8-4). When the CPU 2 is input, the CPU 1, the CPU 2, and the CPU 3 are displayed on the screen.
(8-5). At this time, the input CPU name is
At the same time, it is written in the column of the program storage area designation CPU 7-2 in FIG.

Then, the ID of the written CPU name
The code is written to the start address of each area in the program storage table 7-3, and a CPU having the same ID code as the ID code information is searched for, accessed there, and the program there is stored in the program storage table 7-3.
Load to 3. After the loading is completed, the ID code information at the head of the next area is checked, and the same processing is performed thereafter.
The program is loaded into each program storage table 7-3 from all the PUs.

Thereafter, processing is performed in the same manner as in the prior art. That is, using the program in the storage table, the monitor data of the program of the portion displayed on the screen of the programming device is extracted from the CPU to form the monitor screen. When the programs of a plurality of CPUs are displayed on the screen, the monitor data is taken out while switching the corresponding CPU to construct a monitor screen.

The feature of the PC system according to this embodiment is that the entire system is a series of large programs, and the programs in the respective CPUs operate while affecting each other. CPU
Therefore, when one CPU finishes the program processing and shifts the processing to the CPU that performs the next processing, a problem occurs in the transfer of the data. That is, since the CPU and the CPU and their programs are completely independent of each other, among the I / Os used in the program, the same I / O as the function is used.
However, when monitored, a completely different I / O N
o. This is because the following occurs.

An embodiment of the present invention will now be described in which the entire relationship can be understood even when the ladder program information of each CPU is monitored at one time. First,
FIG. 4 shows, in a system including three CPUs, a CPU and a CPU, a program independently provided for each CPU, which is displayed on a monitor as a series of ladder diagrams. Output data Y0 indicating that the processing has been completed, input data X0 for activating the CPU program by setting the Y0, similarly output data Y1 indicating that the CPU has completed the program processing, and Y1 There is input data X1 that activates the CPU program by the set.

Then, as a system, when the data Y0 is turned on (the program processing of the CPU is completed), the data X0 is turned on (starts the program of the CPU), and similarly, the data Y1 is turned on (the program processing of the CPU is completed). ), The data X1 turns ON (starts the CPU program).

By the way, this system is controlled by an interlock, and after each CPU finishes its own program processing, it activates a CPU having an ID code for performing the next processing, and then re-starts itself. Start own program processing. However, this operation is only I /
O is operated by external wiring by an interlock connecting O, and therefore, all C
Even if the PU program (FIG. 4) is monitored, the interrelationship is not displayed on the monitor screen of FIG. 4, so that the interrelationship is checked unless a confirmation operation such as checking the external wiring is performed. In this state, the user cannot understand.

That is, in such a case, it is necessary to provide a monitor screen on which the interlock relationship between the CPUs can be understood.

In this embodiment, the monitor in the interlock state display mode shown in FIG. 5 can be used in place of the display shown in FIG. 4. CPU program data Y0 and CPU program data X0, CPU
Data Y1 of the CPU program, data X1 of the CPU program, and data Y2 of the CPU program
And the data X2 of the program of the CPU are drawn correspondingly also on the display surface. As shown in the figure, the display “Y2 CPU” is displayed below the display “X2”, and the display “X0” is displayed below the display “X0”. Indicates the display "Y0 CPU", and the display "Y1 CPU" will be displayed below the display "X1".

That is, in this embodiment, by using a list of interlock signals provided in a data table of one or more CPUs, programming devices, and the like, the interrelationship between these interlocks is displayed, for example, the CPU and the CPU. The CPU and the CPU can monitor the program together with the data indicating the interlocking relationship on one screen, and therefore, according to this embodiment, the related programs are displayed as a series of programs. In addition, a program monitor that is easy to understand as a whole, including their interrelationships, and that can be easily debugged by the user can be realized.

According to this embodiment, even when an error occurs, it is possible to easily cope with the error as described below. First, in order to facilitate understanding, as an example at the time of occurrence of an error, when the phenomenon that the data X0 in FIG. 3B does not turn on occurs, the cause is divided into a software type and a hardware type. I will consider it.

Now, the I / O No. At the time of input, when the user erroneously inputs the contact X0 of FIG. 3B as X100 and the interlock signal does not operate properly, the interlock state display mode of FIG. Since the Y0 CPU is not displayed below, the I / O No. Soft bugs such as typographical errors can be found easily and reliably at a glance.

3 (a) and 3 (b), it is assumed that an interlock line connecting the relay Y0 and the contact X0 is broken between the CPUs, thereby causing an abnormal operation. Then, at this time, if the interlock state display mode shown in FIG. 5 is used, the data X0 (Y0 CPU) must be always turned on when the data Y0 is turned on, but the data X0 (Y0 CPU) is not turned on. The user can easily understand at a glance, and as a result, if there is an abnormality in the interlock line, this can be easily inferred.

Therefore, according to this embodiment, as in the case of the conventional debugging, a series of processings such as monitoring the program and checking the state of the I / O by reconnecting the communication cable for each CPU and each CPU are performed. This saves time and makes it easy to find hard bugs such as disconnections at a glance.

Next, the means for monitoring the programs of a plurality of CPUs linked by a link by a programming device and the means for displaying the interlock status on a monitor screen according to the present embodiment will be described. This will be described with reference to a flowchart.

FIGS. 10, 11, and 12 show a user program memory 6-13 of the CPU, a user program memory 6-3 of the programming device, and a system memory 6-7 of the programming device, respectively, according to an embodiment of the present invention. Shows the data stored in the. First, as shown in FIG. 10, an ID code 10-1 and a user program 10-2 (here, fixed length) are stored in a program memory 6-13, and as shown in FIG. Has ID codes 11-1, 11-3,
11-5 and user programs 11-2, 11-4, 11-
6 (again, fixed length) is provided as a set of program management tables. That is, one set is provided for each CPU, and the programming device is provided as necessary using an external memory or the like.

Next, as shown in FIG. 12, the system memory 6-7 of the programming device 1-1 stores a program management table use number storage unit 12-1 for recording the use number of the program management table. A table 12-8 for storing the ID code of the CPU to be read at the time of reading, a pointer 12-2 of the table, and a counter 12-6 for the pointer, and a table for storing the ID code of the transfer destination CPU at the time of program transfer. 12-
9, pointer 12-3 of the table, counter 12-7 of the pointer, pointer 12-5 for the ID code of the user program memory of the programming device, forced output information storage table 12-10 for checking interlock information, And its pointer 12-4.

FIG. 13 is a flow chart of the unified program read, transfer and monitor processing in one embodiment of the present invention. When the program MAIN is started, first, at a block 13-1, input from the keyboard is performed. Read. At block 13-2, the input is determined, and the processing is shifted to the corresponding processing routine. Input is “TNYM”, “FK
“YM”, “TNTN”, “FKTN”, and “END”. If “TNNYM”, the program is read out by a single CPU. If “FKYM”, the program is read out by a plurality of CPUs. In this case, the processing is transferred to the transfer processing of the program of a single CPU, in the case of "FKTN", to the transfer processing of the program of a plurality of CPUs, and in the case of "END", to the monitor processing.

First, in the case of a program reading process of a single CPU, a program reading table setting TBLY is performed in a block 13-3, and a single CPU program reading TNYM is performed in a block 13-4. Multiple C
In the case of the PU program read processing, the program read table setting TBLY is executed in block 13-5.
Is performed, and a multiple CPU program read FKYM is performed in block 13-6.

In the case of a program transfer process of a single CPU, a program transfer table setting TBLT is performed in block 13-7, and a single CPU program transfer TNTN is performed in block 13-8.

Then, in the case of a program transfer process of a plurality of CPUs, a program transfer table setting TBLT is performed in block 13-9, and a plurality of CPU program transfer FKTN is performed in block 13-10. On the other hand, when the process proceeds to the monitor process, it is determined whether or not the monitor process is performed in block 13-11.
At 12, the monitor processing execution means MNT is performed.

FIG. 14 is a flowchart of the processing in blocks 13-3 and 13-5, that is, the flowchart of the program reading table setting means TBLY. When this processing TBLY is started, first, the I which has already been set in the block 14-1 is set.
It is determined whether or not to change the D code. If the change is not to be made, the process of TBLY is finished. On the other hand, if it is to be changed, the data read from the key is checked in block 14-2, and if it is “TNYM”, In block 14-3, 1 is written to the program management table storage unit 12-1 and
In the case of "FKYM", the user inputs the number of used tables to the program management table storage unit 12-1.
Then, in a block 14-5, a read CPU ID code input process YMNY is executed.

FIG. 15 is a flowchart showing block 14-5, that is, a read CPU ID code input process YMNY. When this process YMNY is started, first, in block 15-1, a read table pointer 12-2 and a read pointer counter 12-6 are read. Is initialized, and the block 15-2 initializes the ID code pointer 12-5.

In block 15-3, the read CPU I
The user inputs the D code and stores it in the program memory in block 15-4. In block 15-5, the read table pointer 12-2 and the ID code pointer 1
2-5 is updated, and the read pointer counter 12-6 is updated in block 15-6. In block 15-7, the management table usage number 12-1 and the read pointer counter 12-6
If are different values, the process returns to block 15-3 again to continue the process, and if the values are the same, the process ends.

FIG. 16 is a flowchart showing the processing in the blocks 13-7 and 13-9, that is, the processing in the program transfer table setting means TBLT. When this processing TBLY is started, first, the processing is already set in the block 16-1. I
It is determined whether or not to change the D code, and if not, the TBLT processing ends. On the other hand, if it is to be changed, the key read data is checked in block 16-2, and if it is "TNTN", 1 is written to the program management table storage unit 12-1 in block 16-3, and "FKT"
If "N", the user inputs the number of tables used in the program management table storage unit 12-1. Then, the block 16-5 executes the ID code input processing TNNY of the transfer CPU.

FIG. 17 is a flowchart showing block 16-5, that is, the transfer CPU ID code input process TNNY. When this process TNNY starts, first, in block 17-1, the transfer table pointer 12-3 and the transfer pointer counter 12-7 are started. Initialize and block 17-2
Then, the ID code pointer 12-5 is initialized. In block 17-3, the user inputs the ID code of the transfer CPU. In block 17-4, the transfer table pointer 12-3 and the ID code pointer 12-
5 and the transfer pointer counter 12-7 is updated at block 17-5. Then, in block 17-6, if the management table usage count 12-1 and the transfer pointer counter 12-7 have different values, the process returns to block 17-3 again to continue the processing, and if the values are the same, the processing is terminated.

FIG. 18 is a flowchart showing the block 13-4, that is, the single CPU program reading TNYM. When the TNYM process is started, first, the memory allocation is read in the block 18-1, and the block 18-2 is read.
Search for the final circuit. Then, the program is read in block 18-3, and it is determined whether or not the read circuit is the final circuit. If the read circuit is not the final circuit, the process returns to block 18-3 to continue the processing.

FIG. 19 is a flowchart showing block 13-8, that is, a single CPU program transfer TNTN.
Reads memory allocation at -1 and returns C at block 19-2.
Clear all PU program management tables. Then, the parameters are written in block 19-3, the ladder program is written in block 19-4, and the process is completed.

FIG. 20 is a flowchart showing the block 13-6, that is, the multiple CPU program read FKYM. When this processing FKYM is started, first, the block 20-1 initializes the read table pointer 12-2, and then executes the block 20-2. With the ID code pointer 12-
5 is initialized. In block 20-3, the read table pointer 12-2 and the ID code pointer 12-5
It is determined whether both are pointing to the same ID code. If they are different, the ID code pointer 12-5 is updated in block 20-4, and the processing is continued from block 20-3 again.

On the other hand, if they are the same, block 20-5
Retrieves the CPU having the ID code indicated by the ID code pointer 12-5, and reads out the single CPU program TNYM in block 20-6. Then, in block 20-7, the read table pointer 12-2 is updated. In block 20-8, it is determined whether or not the ID code exists at the position of the read table pointer 12-2. Then, the process returns to step 4 and the processing is continued again.

FIG. 21 is a flow chart showing block 13-10, that is, a multiple CPU program transfer FKTN.
At 1-1, the transfer table pointer 12-3 is initialized, and at block 21-2, the ID code pointer 12-5 is initialized. In block 21-3, it is determined whether the read table pointer 12-3 and the ID code pointer 12-5 both indicate the same ID code,
If they are different, the ID code pointer 12-5 is updated in block 21-4, and the processing is continued from block 21-3 again.

On the other hand, if they are the same, block 21-5
Search for the CPU having the ID code indicated by the ID code pointer 12-5, and execute the single CPU program transfer TNTN at block 21-6. And block 21
-7, the transfer table pointer 12-3 is updated, and in block 21-8, the position of the transfer table pointer 12-3 is
It is determined whether or not the D code exists. If the D code exists, the process returns to block 21-4 to continue the process again. If the D code does not exist, the process ends.

FIG. 22 is a block 13-12, that is, a flowchart showing the monitor processing execution means MNT. When this MNT processing is started, first, in a block 22-1, the value of the program management table use number storage section 12-1 is checked. If it is 1, the single program monitor execution means TNMNT is executed in block 22-2, and if it is not 1, the plural program monitor execution means FKM is executed in block 22-3.
Execute NT. When the processing of the singular program monitor execution means TNMNT is finished in block 22-2, block 2
At 2-4, it is determined whether or not the monitoring process is to be completed. If not, the process is restarted from block 22-1.

On the other hand, when the processing of the plural program monitor execution means FKMNT is completed in block 22-3, it is determined in block 22-5 whether or not interlock information is to be displayed. On the other hand, if it is to be displayed, the interlock information display processing INTL is executed in block 22-6, and the block 22-
The process starts from Step 4.

FIG. 23 is a flowchart showing the block 22-2, that is, the singular program monitor execution means TNMNT. When the processing TNMNT is started, first, a monitor start address is set in a block 23-1, and then a block 23-2 is set. Set the number of steps in block 23-
In step 3, the monitor data is received, and the process ends.

FIG. 24 is a flowchart showing the block 22-3, that is, the plural program monitor execution means FKMNT. When the processing FKMNT is started, first, the program displayed on the screen in the block 24-1 is changed to 1CP.
It is determined whether or not the program is for U. If the program is for one CPU, the ID code of the program being displayed is checked in block 24-2, and the CPU having the checked ID code is searched in block 24-3. Then, in a block 24-4, a single program monitor execution means TNMNT
Is executed, and the process is ended here.

On the other hand, if the program is not a program for one CPU, the block I-5 of the program at the top of the screen is
The D code is checked, and the CPU having the ID code checked in block 24-6 is searched for, and the block 24-7 is searched.
Executes the single program monitor execution means TNMNT. Then, it is determined whether or not a program of another CPU exists below the program checked in block 24-8. If it does not exist, the process is terminated. If it exists, the ID code of the program is changed in block 24-9. The check is made, and the processing is continued from block 24-6.

FIG. 25 is a flowchart showing block 22-6, that is, the interlock information display processing INTL. When this processing FKMNT is started, first, block 2-6 is executed.
At 5-1, the ID code pointer 12-5 is initialized, and at block 25-2, the CPU having the ID code indicated by the ID code pointer 12-5 is searched. Then, the program searched in block 25-3 is checked in circuit order, and its output is searched. Here, the forced output execution means KYST is executed in block 25-4, and further, block 2 is executed.
In step 5-5, an I / O information storage process INTKKN in the interlock table is executed. Next, it is checked at block 25-6 whether all outputs in the program have been detected.

If all outputs have not been detected, the next output is detected in block 25-7, and the processing is performed again from block 25-4. On the other hand, if all the outputs have been detected, the ID code pointer 12-
5 is updated and a check is made at block 25-9 whether the ID code is present. If it exists, the processing is performed again from block 25-2, and if it does not exist, block 2 is executed.
5-10 Interlock information screen display processing INTHYJ
Is executed, and the process ends.

FIG. 26 is a flowchart showing the block 25-4, that is, the forced output execution means KYSY. When the process KYSY is started, first, at a block 25-1, C
It is determined whether or not the PU is in the STOP state, and if not, the process is terminated. If it is in the STOP state, the I / O code is set in block 26-2, and the I / O No. is set in block 26-3. Is set, and block 26-
The forced output data is set in step 4, the forced output data set is performed in block 26-5, and the process is completed.

FIG. 27 is a block 25-5, that is, a process of storing I / O information in an interlock table INTKK.
In the flowchart showing N, when this process INTKKN is activated, first, in block 27-1, the forced output information storage table 12-10 is reset, and in block 27-2, the forced output table pointer 12-4 is initialized.
Then, I / O turned ON by forced output in block 27-3
O is stored in the forced output information storage table 12-10.
In block 27-4, the forced output table pointer 12-4
It is determined whether or not the CPU identification information 2-6 of the I / O pointed to by the CPU is the same as the CPU identification information 2-6 of the checked output, and if they are the same, the block 27-5 outputs the information to the interlock information table 7-4. The I / O that has been turned on is stored, and the forced output table pointer 12-4 is updated in block 27-6.

On the other hand, if they are different, the block 27-5 is bypassed, and the processing is performed from the next block 27-6. Then, at the point indicated by the pointer updated in block 27-7, I
It is determined whether or not / O is stored. If it is stored, the process is performed again from block 27-4, and if it is not stored, the process ends.

FIG. 28 is a flowchart showing block 25-10, that is, the interlock information screen display processing INTHYJ. When this processing INTHYJ is started, first, in block 28-1, the head of the designated CPU of the interlock information table 7-4 is started. Check the CPU name. Next, in block 28-2, the specified CPU name is added to the I / O,
Displayed on the / O symbol. Then, in block 28-3, it is determined whether or not I / O still remains in the interlock information table 7-4.
Start processing more. If not, block 28-4
To determine whether or not the designated CPU still exists in the interlock information table 7-4. If there is no remaining CPU, the process is terminated.
The PU is checked, and the processing is executed again from block 28-2.

According to this embodiment, the program information (operation timing, interlock, etc.) of each CPU can be centrally managed by one programming device. Further, according to this embodiment, a network system using a large number of CPUs can be managed as a single control system, so that the efficiency of program creation and debugging by the user is improved.

Incidentally, as apparent from the above description, the present invention can be implemented in the following modes.

Embodiment 1 In the first aspect of the present invention, each sequence program has CPU identification information, and one or more CPUs have interlock information and ID codes.
C system.

Embodiment 2 The PC system according to claim 1, wherein one or more CPUs have an ID code, and a programming device has CPU identification information and interlock information.

Embodiment 3 The PC system according to claim 1, wherein one or more CPUs have the interlock information and the ID code, and each sequence program has the CPU identification information.

Embodiment 4 The PC system according to claim 1, wherein one or more CPUs have an ID code, a programming device has interlock information, and each sequence program has CPU identification information.

[0082]

According to the present invention, one-to-many communication control can be performed for a plurality of CPUs by a programming device. Therefore, even when operating each CPU, it is necessary to always individually access each CPU. This eliminates the need for troublesome operations, and has the effect of improving operability by the user.

According to the present invention, each CPU
Can be simultaneously monitored by the programming device, and the interlock state can be displayed on the monitor screen, thereby improving the debugging efficiency by the user.

[Brief description of the drawings]

FIG. 1 is a block diagram showing one embodiment of a programmable controller system according to the present invention.

FIG. 2 is an explanatory diagram showing details of program data information in one embodiment of the present invention.

FIG. 3 is an explanatory diagram showing a screen in which a ladder program of each CPU is monitored as it is in the prior art.

FIG. 4 is an explanatory diagram showing a screen in which a ladder program of each CPU is monitored in a state of a series of programs according to an embodiment of the present invention.

FIG. 5 is an explanatory diagram showing a screen that monitors a series of ladder programs displaying a mutual relationship between the CPUs according to an embodiment of the present invention.

FIG. 6 is a block diagram illustrating a hardware configuration of a CPU and a programming device according to an embodiment of the present invention.

FIG. 7 is an explanatory diagram showing a usage state of a user program memory in a programming device according to an embodiment of the present invention.

FIG. 8 shows a program reading C according to an embodiment of the present invention.
It is an explanatory view showing an example of a PU name input screen.

FIG. 9 is a flowchart showing a link process in the related art.

FIG. 10 is an explanatory diagram showing a usage state of a user program memory of a CPU according to an embodiment of the present invention.

FIG. 11 is an explanatory diagram showing a usage state of a user program memory of the programming device according to the embodiment of the present invention.

FIG. 12 is an explanatory diagram showing a usage state of a system memory of the programming device according to the embodiment of the present invention.

FIG. 13 is a flowchart showing a main processing program in one embodiment of the present invention.

FIG. 14 is a flowchart showing a program reading table setting means in one embodiment of the present invention.

FIG. 15 shows a read CPUI in one embodiment of the present invention.
It is a flowchart which shows a D code input process.

FIG. 16 is a flowchart showing a program transfer table setting means in one embodiment of the present invention.

FIG. 17 is a flowchart showing a transfer CPU ID code input process in one embodiment of the present invention.

FIG. 18 is a flowchart showing reading of a single CPU program in one embodiment of the present invention.

FIG. 19 is a flowchart showing a single CPU program transfer in one embodiment of the present invention.

FIG. 20 is a flowchart showing reading of a multiple CPU program in one embodiment of the present invention.

FIG. 21 is a flowchart showing a multiple CPU program transfer in one embodiment of the present invention.

FIG. 22 is a flowchart showing a monitor processing execution unit according to one embodiment of the present invention.

FIG. 23 is a flowchart showing a singular program monitor executing means in one embodiment of the present invention.

FIG. 24 is a flowchart showing a plurality of program monitor executing means in one embodiment of the present invention.

FIG. 25 is a flowchart showing an interlock information display process in one embodiment of the present invention.

FIG. 26 is a flowchart showing a forced output execution unit according to one embodiment of the present invention.

FIG. 27 is a flowchart showing processing for storing I / O information in an interlock table according to an embodiment of the present invention.

FIG. 28 is a flowchart showing an interlock information screen display process in one embodiment of the present invention.

[Explanation of symbols]

 1-21 Programming device 1-4 to 1-6 CPU 1-2 Program data stored in memory 1-3 Monitor data stored in memory 1-7 to 1-9 User memory 1-10 to 1-12 I / O

──────────────────────────────────────────────────続 き Continuation of the front page (56) References JP-A-60-41102 (JP, A) JP-A-61-84707 (JP, A) JP-A-61-195408 (JP, A) 167602 (JP, A) JP-A-58-8305 (JP, A) (58) Fields investigated (Int. Cl. ⁷ , DB name) G05B 19/04-19/05

Claims (1)

(57) [Claims] 1. A user program memory for storing the contents of sequence control as a sequence program, a CPU for reading and executing the sequence program from the user program memory, and controlling the CPU, I / O, and the user program as a whole. A plurality of programmable controllers having a system memory having a program, an input / output interface unit for inputting / outputting an external signal for control and connected by external wiring, and a programming device for creating and monitoring a sequence program In a programmable controller system comprising: a CPU identification information that is included in the sequence program and indicates an address of each of the CPUs; CPU An ID code for recognizing their positioning within the overall system configuration, the respective CPU
, And a plurality of CPs are obtained by the CPU information and the ID code.
And unifying the U sequence program displayed as ladder sequence program one system, by the interlock information, the ladder sequence flop
Program display of multiple CPUs
Display indicating the interrelationship between
A programmable controller system, characterized in that the programmable controller system is configured to be added .