JP2009245194A - Programmable controller, programmable controller support apparatus, and programmable controller system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To guarantee integrity by solving problems in "a data exchange method and a starting method" between embedded software and an application of a programmable controller, wherein in accessing the embedded software created by a user by means of a general purpose PC as an application software of the programmable controller, (a) the embedded software accessed from a plurality of positions such as sub-routines cannot be described, and (b) since the application software of the programmable controller and the embedded software are asynchronously operated, the timing of processing, start and completion of the embedded software cannot be grasped from the application of the programmable controller. <P>SOLUTION: Instance information to be added to the embedded software and instance information to be added to the application software are used to compare both of them, and the continuation of performing a program is determined on the basis of the right or wrong of the comparison. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a function block (hereinafter sometimes abbreviated as FB) of a programmable controller (hereinafter also abbreviated as PLC), and in particular, operation of embedded software created by a user and application software that handles the embedded software. Regarding warranty.

Conventionally, a programmable controller has been mainly provided with dedicated hardware (represented by Large Scale Integration, etc.) for causing sequence instructions to be executed at high speed. In these dedicated hardware, it was necessary to generate machine code by a support tool provided by the manufacturer of each controller.
However, there were also demerits that “dedicated hardware is expensive” and “development of system programs is relatively difficult with a dedicated machine language system”.
In recent years, with the spread of personal computers, portable terminals, and the like, technological innovation of commercially available general-purpose CPUs (Central Processing Units) has progressed, and it has become possible to obtain CPUs capable of high-speed execution at a very low cost. For this reason, even when a dedicated LSI is emulated and executed using a general-purpose CPU, it is possible to obtain a desired execution performance sufficiently.
Also, since it is general-purpose and firmware development tools can be procured from the market, programmable controllers using general-purpose CPUs are also being made.
In such a programmable controller based on a general-purpose CPU, the application development environment provided to the user is “a general-purpose programming language (C language, microcomputer compatible) in an embedded software development environment corresponding to the general-purpose CPU used in the programmable controller. "A method of executing the program after it is programmed using an assembler or the like, downloaded to a programmable controller" is attracting attention.

In fact, in recent years, a programmable controller that is based on a general-purpose CPU and operates exactly the same as that using a conventional dedicated LSI, or conversely, a C language controller that performs programming in an embedded software development environment without using a conventional support tool Etc. are also on sale.
In such a C language controller, a real-time operating system (hereinafter referred to as a real-time OS) is mounted in order to reduce a user's programming load. A real-time OS can execute a plurality of processing units called tasks in parallel, and has a communication function between tasks, and an effective control function such as task generation and activation. Since the time management of tasks is performed by the real-time OS, the user is freed from the scheduling load when programming.
By the way, the application software of the programmable controller uses a memory address system unique to the programmable controller system such as handling externally connected devices (for example, input / output modules) connected to the control network as memory in order to handle the programmable controller efficiently. keeping. Therefore, the memory management does not depend directly on the physical address of the general-purpose CPU. In addition, when the application software of the programmable controller is executed, it is registered as a task of the programmable controller, and these are started at a specified timing such as a fixed period or an event. It is not possible to be aware of the relationship between the application software task and the operation of the real-time OS running the system software.

Due to this, there are the following problems.
・ Embedded software called from multiple places such as subroutines cannot be described (for example, if a fixed address of the application memory of the programmable controller is explicitly described in the embedded software as a data exchange area, the data exchange area address is Each must be prepared separately, and it will be a separate program despite the same process).
-Since the application software of the programmable controller and the embedded software operate asynchronously, it is impossible to grasp the timing of processing, activation and completion of the embedded software from the application software of the programmable controller.
Thus, the “data exchange method and activation method” in the application software of the embedded software and the programmable controller becomes a problem.
Patent Literature 1 solves the problem of data exchange and activation by recognizing a user FB as a system FB provided by a manufacturer.
Patent Document 2 recognizes the previously downloaded embedded software user FB by downloading the embedded software user FB to the PLC first and issuing all the user FB numbers when compiling the application software using this. It is possible.

Both Patent Documents 1 and 2 use an FB number that can uniquely recognize the FB. Further, the invention focuses on the handling of the FB table for managing these.
Hereinafter, such a management method will be described.
First, the basic configuration will be described with reference to FIGS. Next, details of function blocks used in the programmable controller will be described with reference to FIGS. Next, a method for creating a function block of embedded software will be described with reference to FIGS. Finally, the FB table and its usage will be described with reference to FIGS.
FIG. 4 illustrates an example of the configuration of the programmable controller system. The personal computer 100 is a general personal computer, and the personal computer 100 stores a support tool (not shown) that supports the programmable controller. The personal computer 100 and the programmable controller 102 to be supported are connected by a cable 110. The programmable controllers 102 to 106 and the input / output module 108 to be controlled are connected by a control network 112. An example of the control network 112 is the SX bus used in the MICREX-SX series, which is the product of the applicant.
In the personal computer 100, programming is performed using function blocks and the like, and after execution, the execution file is downloaded to the programmable controller 102 via the cable 110 or the like (for this reason, the personal computer 100 may be called a loader).

Here, as an example of the programmable controller system, a configuration of one personal computer 100, a plurality of programmable controllers 102 to 106, and a plurality of input / output modules 108 is shown, but this does not limit the invention. , Each may be configured by an arbitrary number. The support target of the personal computer 100 may be any one or all of the programmable controllers 102 to 106.
Here, the personal computer 100 and the programmable controllers 102 to 106 to be supported are connected by the cable 110, but the present invention is not limited to this, and a wireless LAN may be used, and information may be transmitted via an arbitrary medium. You can exchange it.
FIG. 5 illustrates a schematic hardware configuration of the programmable controller. The programmable controller 120 includes a CPU 124 that executes a system program and / or a user program. The CPU 124 exchanges programs, instructions, various data, and the like via an internal bus 134. Here, in order to save the system program and / or the user program even when the power is turned off, the flash memory 128 is provided as a nonvolatile rewrite memory. In general, a flash memory operates at a lower speed than an SRAM or the like, so that even if it is suitable for storing a program, it is not suitable for execution. Therefore, a program memory 130 is provided as an SRAM that expands and executes a system program and / or a user program from the flash memory 128. Further, a data memory 132 is also provided as a memory area (SRAM) for managing and storing information read / written by the system program and / or the user program.

On the other hand, the programmable controller 120 roughly has two communication functions with external devices. One is a driver / receiver 122 that is an interface function for exchanging user instructions, programming, execution files, and the like with the CPU 124 from a programmable controller support device 140 described later. The other is a bus controller 126 that performs arbitration of a bus, which is a dedicated line, when communicating with a control target device such as an input / output module.
The flash memory 128, the program memory 130, and the data memory 132 are divided into a plurality of units from the viewpoint of data storage / management and execution, but sufficient capacity, speed performance, and data guarantee at the time of power interruption are ensured. When possible, for example, one memory may be used.
FIG. 6 illustrates a schematic hardware configuration of the programmable controller support device. The programmable controller support device 140 includes an input device 146 for inputting a user to create a desired control program, a display device 148 for displaying the input contents, a storage device 150 for storing a predetermined program, a connection A communication I / F 144 that communicates with the target programmable controller via a line or an external network. The CPU 142 stores the program created from the input device 146 via the internal bus 152 in the storage device 150 as necessary, and creates an execution file by a compiling function of a support tool (not shown), and creates the execution file as a communication I / F 144. Is sent (downloaded) to the target programmable controller. Also, an FB number described later is transmitted as necessary.

The user performs programming using a support tool in the programmable controller support apparatus 140, and often uses function blocks. The function block defined in the description language standard IEC61131-3 has a processing structure in which a processing code and data (instance) used for processing are integrated.
FIG. 7 illustrates an example of an input / output outline of the function block. In the example of FIG. 7A, an input terminal 162 is disposed on the left side and an output terminal 164 is disposed on the right side with respect to the function block main body 160 displayed in a rectangular portion. Here, the CTU described in the upper center of the function block main body 160 represents a function block name, and CU, R, PV, Q, and CV represent terminal names. Further, the information (BOOT, INT) described in the input terminal 162 and the output terminal 164 represents the data type of the terminal.
Similarly, in the example of FIG. 7B, an input terminal 172 is disposed on the left side and an output terminal 174 is disposed on the right side of the function block main body 170 displayed in a rectangular portion. Here, UFB described in the upper center of the function block main body 170 represents a function block name, and IN1, IN2, OUT1, and OUT2 represent terminal names. Information (INT) described in the input terminal 172 and the output terminal 174 represents the data type of the terminal.

FIG. 8 illustrates an example of the configuration of an instance of a function block. The minimum rectangle in FIG. 8A represents the bit amount. The fact that CU, R and Q are composed of one rectangle indicates that the data type is BOOT (see FIG. 7A), and PV and CV are composed of 16 rectangles. Indicates that the data type is INT (see FIG. 7A). Further, the hatched portion in FIG. 8A represents an unused area. Similarly, IN1, IN2, OUT1, and OUT2 in FIG. 8B are composed of 16 rectangles, and indicate that the data type is INT (see FIG. 7B).
Although a schematic display is shown here, memory allocation is actually performed as a continuous area. In FIG. 5, addresses are allocated to the data memory 132 in these units, and managed as instance areas. The program code of the function block at the time of execution is arranged in the program memory 130, and the instance information is arranged in the data memory 132. The function block functions by executing these pieces of information in cooperation.
By the way, the function blocks are roughly classified into two according to their properties. Here, these are called a user function block (hereinafter abbreviated as user FB) and a system function block (hereinafter abbreviated as system FB), respectively.

The user FB is programmed by the user including the contents of the function block (processing itself), and the user FB itself is compiled by the programmable controller support apparatus and then downloaded to the programmable controller.
On the other hand, the system FB is a function block provided by the manufacturer of the programmable controller. Therefore, the function is included in the system program of the programmable controller main body in advance, and the user can use the function only by writing a code for calling the system FB in the application of the programmable controller.
In addition, in the system FB, the optimum design for the microcomputer or dedicated LSI used in the programmable controller is made by the manufacturer, but the user cannot modify the system FB and is only allowed to refer to it. It is common.
In addition, since the function block by the built-in software created by the user is originally the user FB, it is generally handled as the user FB in the programmable controller, but a method of registering as a system FB in the programmable controller may be used.

FIGS. 7A and 8A described so far show examples of the system FB, and FIGS. 7B and 8B show examples of the user FB.
FIG. 9 illustrates an example of a program when FB is called from an application of a programmable controller. In FIG. 9A, the CTU which is the function block of FIG. 7A is called from the program PG0. An instance 180 represents that it is a CTU instance in PG0. Even in the same function block, processing is different if the instant name is different. Therefore, there is a target data area corresponding to each instant name, and here, the instance name is CTU # 1. The variable 182 is defined in PG 0 but is passed as an input value of the instance 180. Similarly, the variable 184 is defined in PG0, but the output value that is the execution result of the instance 180 is passed.
The same applies to FIG. 9B, and UFB, which is the function block of FIG. 7B, is called from the program PG1. An instance 190 represents a UFB instance in PG1. Here, the instance name is UFB # 1.
The variable 192 is defined in PG1, but is passed as an input value of the instance 192. Similarly, the variable 194 is defined in PG1, but the output value that is the execution result of the instance 190 is passed.

  FIG. 10 illustrates pseudo program code of PG0. Codes 200 and 210 are tags indicating the start and end of the program, and are substantially unprocessed codes. The code 202 corresponds to the variable 182 in FIG. On the code, A, CTU # 1. Although it is represented as CU, in reality, the address of the data memory of the programmable controller is allocated to these variables (or instance areas). Here, CTU # 1 is the start address of the instance area, CTU # 1. A CU is assigned an address of a CU that is a component (property) of the CU. CTU # 1. R and CTU_1. The same applies to PV. Here, ATU, B, and C are input values, and CTU # 1 is CTU # 1. CU, CTU # 1. R, CTU # 1. Store in PV. A code 204 is a PUSH instruction, which is an instruction for storing the address of the instance area in a stack or the like. Code 206 is a CAL instruction that calls the program code of the function block CTU. The code 208 corresponds to the variable 184 in FIG. After the processing of the function block CTU called by the code 206 is completed, the execution result is used as an output value, and CTU # 1 is stored in the CTU # 1. Q, CTU # 1. A value is extracted from CV and stored in D and E.

FIG. 11 illustrates the pseudo program code of PG1, and the processing is the same as that in FIG. Codes 220 and 230 are tags indicating the start and end of the program, a value to be passed to the instance area of UFB_1 at code 222, a PUSH instruction at code 224, a UFB at code 226, and the execution result at instance area in code 228 Take from.
FIG. 12 is a schematic flowchart illustrating an example of processing of the system FB in the programmable controller. Here, an outline of how the system FB (CTU) in PG0 is processed when PG0 is executed as one of the processes of the application of the programmable controller is shown.
As is apparent from the figure, in the process of PG0 (flow F100), the CAL process (flow F102) is called, and then the entity of the CTU is processed (flow F104), returning to the flow F100 and completing the process.
To explain step by step, during the execution of PG0, a CAL process pre-installed in the programmable controller is called (step S100). In addition, as preprocessing in step S100, the address of the instance (CTU_1) of the system FB (CTU) is stacked on the data memory and stored in the instant area. In the CAL process, first, the return address after the system FB (CTU) process is stored (step S102). Then, the address of the instance area stored in the stack is taken out (step S104), the system FB number of the system FB (CTU) to be called is retrieved from the system FB table (see FIG. 17) described later, Address information is extracted (step S106). The address of the instance area is set as a parameter, and the process jumps to system FB (CTU) processing (step S108). After the processing of the system FB (CTU) is completed, after jumping to the return address stored in step S102, the processing of PG0 is continued.

FIG. 13 is a schematic flowchart illustrating an example of processing of the user FB in the programmable controller. This is basically the same as the processing of the system FB in FIG. Here, an outline of how the user FB (UFB) in PG1 is processed when PG1 is executed as one of the processes of the application of the programmable controller is shown.
As is apparent from the figure, in the process of PG1 (flow F110), the CAL process (flow F114) is called, and then the UFB entity is processed (flow F112), and the process returns to the flow F110 to complete the process.
To explain step by step, during the execution of PG1, a CAL process pre-installed in the programmable controller is called (step S110). In addition, as preprocessing in step S110, the address of the instance (UFB_1) of the user FB (UFB) is stacked on the data memory and stored in the instant area. In the CAL process, first, the return address after the user FB (UFB) process is stored (step S112). Then, the address of the instance area stored in the stack is taken out (step S114), the user FB number of the user FB (UFB) to be called is retrieved from the user FB table (see FIG. 18) described later, Address information is extracted (step S116). The address of the instance area is set as a parameter, and the process jumps to the process of the user FB (UFB) (step S118). After the processing of the user FB (UFB) is completed, after jumping to the return address stored in step S112, the processing of PG1 is continued.

The difference between the processes in FIG. 13 and FIG. 14 is that the actual process of the system FB and the user FB is executed in the PLC application or in the system program.
Up to this point, the basic configuration and its processing have been described. Hereinafter, specific methods related to a method for creating an FB (hereinafter referred to as an embedded software FB) in embedded software (see FIGS. 14 to 16) and a process for expanding the embedded software FB to a programmable controller (FIGS. 17 to 20). Explain the work.
FIG. 14 illustrates a screen for selecting a POU (Program Organization Unit) to be created. This screen is an example of a user interface in a support tool (not shown) in the programmable controller support device 140 of FIG.
This menu screen indicates that the creation of the embedded software FB is supported in addition to the conventional program, function block, and function.
FIG. 15 illustrates an example of the editing screen of the embedded software FB. Here, the name of the function block and the variable name, data type, and type of each variable are input. The function block name is not limited in input rules, but it should not be duplicated with already registered names. There are no restrictions on the input rules for variable names, but they should not be duplicated in the same function block. As the data type, an INT type, a BOOT type, or the like, which is a variable type, can be specified, and is reflected in the configuration of the function block instance (see FIG. 8). The type is either INPUT or OUTPUT, and specifies whether the variable is on the input side or output side of the function block.

FIG. 16 illustrates an example of a template of the embedded software FB. An example in which a template of embedded software using C language is created using the variables set in FIG. The code 240 is a structure description method, and corresponds to an instance in a function block. The code 242 is a place where variables are transferred from the structure and the actual processing is entered, and in particular, the user can input an arithmetic expression and control contents after the portion of “/ * where the processing is entered * /”. It describes in. Here, for the sake of explanation, an example in which information such as variables is input in FIG. 15 and a template is created in FIG. 16 is shown here, but the corresponding parts such as variables of code 240 and code 242 from the information in FIG. May be automatically reflected, or the codes 240 and 242 may be directly input by the user. The created code is compiled in an embedded software development environment, and an object file (object code of embedded software FB) is generated.
With the processing so far, the embedded software FB is created as the system FB or the user FB, and preparations for storing it in the programmable controller are completed. 17 and 19 show a method of incorporating the embedded software FB as the system FB of the programmable controller, and FIGS. 18 and 20 show a method of incorporating the embedded software FB as the user FB of the programmable controller. Here, the storage method as the system FB / user FB will be described separately for the sake of explanation, but these may be used together.

First, each FB table will be described.
FIG. 17 illustrates an example of the system FB table. In the program memory, 99 object codes of the system FB and one embedded software FB created by the user are stored. A system FB number that uniquely identifies these is assigned to the object code of each system FB. This enables the programmable controller to quickly call the system FB designated by the system FB number. Here, a system FB table is used as a method of managing these system FB numbers.
The system FB table includes a list of system FB numbers and storage addresses of object codes of the system FB. In the example of FIG. 17, the system FB table is stored in the data memory, and by specifying each system FB number in the system FB table, it is possible to specify the start address of each object code in the program memory. Show. As an example, when the system FB number is “1”, the address stored in the system FB1 of the system FB table is referred to, and it can be seen here that the system FB number is stored in the address 50 of the program memory.

This system FB table is composed of a basic part and an extended part. The system FB1 to 99 (basic part) specified by the manufacturer is fixed, and the embedded software FB and an arbitrary user FB are installed in the subsequent systems FB100 to n (extended part). sign up. As shown in the figure, an empty area (reserve) may be prepared in the extended portion according to the presence or absence of registration.
The address designation method generally uses the start address of the object code storage destination. However, the start address, the end address, and the address length for storing the object code may be designated. The address information may be registered as an absolute address in the program memory or may be a relative address.
Further, the structure of the system FB table itself is structured, for example, the address of the system FB number 1 in the fourth byte from the head of the system FB table, the address of the system FB number 2 in the eighth byte,... If the address of the system FB number n is stored in the 4nth byte, it may be constituted by a simple list of addresses.
Here, as an example, it is assumed that there are n systems FB, and n systems FB are actually stored. However, the number of systems FB to be managed is allowed if the capacity of data memory, program memory, or the like allows. It does not matter if the number is not fixed to n, there may be an unused number, and the system FB need not be a serial number. However, management according to the system FB to be actually executed is preferable in terms of memory resources and response.

In any case, if the system FB number is known, the address of the object code of the system FB in the program memory to be executed is also uniquely determined.
FIG. 18 illustrates an example of the user FB table. Since the structure is basically the same as the system FB table of FIG. 17, the difference will be described. In the application software created by the user, the user FB number generated at the time of compiling is used as the user FB table, so that basically no free space like the system FB is generated (not necessary). Further, since the user FB number is issued based on the optimization routine of the compilation process, the number of the embedded software FB number is not fixed. In the case of FIG. 18, since the number of the embedded software FB is assigned to the user FB number 99, the storage location is 300 addresses in the program memory.
Next, how processing is performed in the programmable controller support device and the programmable controller will be described.
FIG. 19 is a schematic flowchart for explaining the processing of the embedded software FB (system FB) in the conventional programmable controller system. Here, what kind of processing is performed on the programmable controller support device side and the programmable controller side is shown mainly on the information to be transferred.

As is clear from the figure, on the programmable controller support device side, the user creates embedded software FB, develops application software using the software (flow F10), and generates execution code from the embedded software FB ( Flow F12) is performed. On the other hand, on the programmable controller side, processing for storing the embedded software FB (flow F14) and processing for storing application software (flow F16) are performed.
To explain step by step, the user creates the embedded software FB using a support tool in the programmable controller support apparatus. As an example, the input / output relationship of the embedded software FB is mainly defined by the interfaces as shown in FIGS. As a result, the template 10 of the embedded software FB is generated, and the system FB number 14 that identifies the embedded software FB is issued (step S10).
Next, the user programs specific processing contents of the embedded software FB (step S20). As a result, the support tool compiles the program code of the embedded software FB and generates the object code 16 of the embedded software FB in the execution format (step S22).

Then, the support tool transmits (downloads) the system FB number 14 and the object code 16 of the embedded software FB to the programmable controller to be operated (step S12).
Subsequently, the user generates application software using the embedded software FB (step S14). Thereafter, the application software is compiled to generate application software 18 in an executable format (step S16). Then, this application software 18 is transmitted (downloaded) to the programmable controller to be operated (step S18).
When the programmable controller receives the system FB number 14 and the object code 16 of the embedded software FB, it stores them in a vacant part of the program memory 130 (step S24). Subsequently, the system FB number 14 assigned to the object code 16 of the embedded software FB is registered in the system FB table of the data memory 132 (step S26). An example of a method of registering in the system FB table is as described above with reference to FIG.
On the other hand, when the application software 18 is received, it is stored in a vacant part of the program memory 130 (step S30).

By such processing, the programmable controller enters the standby state, and the application software 18 is executed at an arbitrary timing, and the object code 16 of the embedded software FB is called and executed during the processing.
FIG. 20 is a schematic flowchart for explaining the processing of the embedded software FB (user FB) in the conventional programmable controller system. Here too, as in the case of the system FB, what kind of processing is being performed on the programmable controller support device side and the programmable controller side is mainly shown in the transferred information.
As apparent from the figure, on the programmable controller support device side, the user creates the embedded software FB, develops application software using the embedded software FB (flow F20), and generates the execution code from the embedded software FB ( Flow F22) is performed. On the other hand, on the programmable controller side, processing for storing the embedded software FB (flow F24) and processing for storing application software (flow F26) are performed.
To explain step by step, the user creates the embedded software FB using a support tool in the programmable controller support apparatus. As an example, the input / output relationship of the embedded software FB is mainly defined by the interfaces as shown in FIGS. Thereby, the template 20 of the embedded software FB is generated (step S50).

Next, the user programs specific processing contents of the embedded software FB (step S62). As a result, the support tool compiles the program code of the embedded software FB to generate the object code 26 of the embedded software FB in the executable format (step S64).
Then, the support tool transmits (downloads) the object code 26 of the embedded software FB to the programmable controller to be operated (step S52).
Subsequently, the user generates application software using the embedded software FB (step S54). Thereafter, the application software is compiled to generate application software 28 in an executable format (step S56). At the time of compiling, the user FB number 30 for specifying the embedded software FB to be called from the application software 28 is issued (step S58). Then, the application software 28 and the user FB number 30 are transmitted (downloaded) to the programmable controller to be operated (step S60).
When the programmable controller receives the object code 26 of the embedded software FB, it stores it in a vacant part of the program memory 130 (step S66).

On the other hand, when the application software 28 and the user FB number 30 are received, the application software 28 is stored in a vacant part of the program memory 130 (step S70). Subsequently, the user FB number 30 assigned to the object code 26 of the embedded software FB is registered in the user FB table of the data memory 132 (step S72).
By such processing, the programmable controller enters a standby state, the application software 28 is executed at an arbitrary timing, and the object code 26 of the embedded software FB is called and executed during the processing.
In the description of FIGS. 19 and 20 described above, the processing is shown for the system FB number / user FB number of the embedded software FB. In actual processing, the system FB number / user FB number other than the embedded software FB is also given and programmable. Sent (downloaded) to the controller and reflected. As a result, each FB table as shown in FIGS. 17 and 18 is constructed and held.
Japanese Patent Application 2007-171535 Japanese Patent Application No. 2007-083871

Even after the introduction of the programmable controller system, depending on the field environment, detailed maintenance items will occur on a daily basis due to the need for software updates and customer needs. At this time, for example, there are cases where only the embedded software is improved, and application software using the embedded software is not modified. On the other hand, memory management changes with the expansion of embedded software, so application software may be modified.
In either case, from the viewpoint of the amount of software change, the program is rarely changed in the area of partial change.
By the way, in the above-mentioned Patent Documents 1 and 2, in any case of the system FB and the user FB, activation of embedded software and data exchange are performed by these calls. The data exchanged here exists in the instance memory of the created embedded software FB. If an incorrect FB is called due to the above-described program change, the relative position in the instance of the data to be accessed and the size of the instance are different, so that the calculation may end abnormally.
In addition, since the name of the FB of the embedded software that is called from the application software does not change, it is difficult to identify the cause such as whether there is a cause in the call source or the call destination or in the call relationship.

As described above, in the above-described Patent Documents 1 and 2, since the management system depends only on the FB number, there arises a problem that cannot cope with such program change.
In view of such problems, the present invention has an object to provide a programmable controller, a programmable controller support device, and a programmable controller system that guarantee operations in embedded software created by a user and application software that calls them. To do.

As means for solving the above problems, the present invention is configured as follows.
First, a programmable controller according to the present invention includes a first storage means for storing an object code of a function block of embedded software and first additional information given to the object code, and a function block of the embedded software. Second storage means for storing application software using the software and second additional information given to the application software, and execution means for interpreting and executing the information stored in the first and second storage means The execution means includes the first additional information and the second additional information when the application software has a function block calling process of the embedded software when the application software is executed. And continue processing if there is no difference Configured to.
Second, in the programmable controller, the first additional information and the second additional information are configured to be instance format information of a function block of the embedded software.
Thirdly, in the programmable controller, the first additional information and the second additional information are configured so as to be version number information or time stamp information capable of specifying a function block of the embedded software.

Fourth, the programmable controller support device of the present invention includes a first programming means for programming a function block of embedded software, a second programming means for programming application software using the function block of the embedded software, Compile means for compiling the function block and the application software, first transmission means for transmitting the object code of the function block of the embedded software, and first additional information for specifying the object code, the application software, And second additional information for specifying an object code of a function block of the embedded software included in the application software. Configured to include a second transmission means for signals.
Fifth, in the programmable controller support device, the first additional information and the second additional information are instance format information of a function block of the embedded software.
Sixth, in the programmable controller support device, the first additional information and the second additional information are version number information or time stamp information that can specify a function block of the embedded software. Programmable controller support device.

  Seventh, in a programmable controller system comprising a programmable controller and a programmable controller support device, the programmable controller support device uses a first programming means for programming a function block of the embedded software and the function block of the embedded software. Second programming means for programming the application software, compiling means for compiling the function block and the application software, object code of the function block of the embedded software, and first additional information for specifying the object code; First transmission means for transmitting the application software, the application software, and the application Second transmission means for transmitting second additional information for specifying the object code of the function block of the embedded software included in the software, and the programmable controller has been transmitted by the first transmission means The first storage means for storing the object code of the function block of the embedded software and the first additional information given to the object code, and the embedded software transmitted by the second transmission means Second storage means for storing the application software using the function block and the second additional information given to the application software; and interpreting and executing the information stored in the first and second storage means Executing means, wherein the executing means When executing the application, if the application has a function block calling process of the embedded software, the first additional information is compared with the second additional information, and the process is continued if there is no difference. Configure as follows.

According to the present invention, since the consistency between the embedded software created by the user and the application software that calls them is checked by the programmable controller, the operation is guaranteed.
Also, by simplifying the instance format information that is the source of confirmation, it is possible to reduce the burden (load) on the user and the system.

The best mode for carrying out the present invention will be described below with reference to the drawings.
FIG. 1 is a schematic flowchart showing processing of the embedded software FB (system FB) in the programmable controller system of the present invention. FIG. 2 is a schematic flowchart showing the processing of the embedded software FB (user FB) in the programmable controller system of the present invention. The parts corresponding to those of the conventional example shown in FIGS. 19 and 20 are denoted by the same reference numerals. Hereinafter, the description of the same reference numerals will be omitted, and the features of the present invention will be described.
In FIG. 1, the user creates the embedded software FB using the support tool in the programmable controller support device. At this time, in addition to the numbering process of the embedded software FB template 10 and the system FB number 14, instance format information 12 (see FIG. 3) described later is generated (step S10a). The instance format information 12 is also transmitted to the programmable controller when the system FB number 14 and the object code 16 of the embedded software FB are transmitted (downloaded) to the operation target programmable controller (step S12a). Also, when the application software 18 is transmitted (downloaded) to the programmable controller to be operated, the instance format information 12 is transmitted to the programmable controller (step S18a).

On the other hand, in the programmable controller, when the system FB number 14, the object code 16 of the embedded software FB, and the instance format information 12 are received, the received instance format information 12 is converted into the embedded software following the processing of step S24 and step S26. Store in association with the FB. For example, the instance format information 12 is stored in an empty part of the data memory 132, and the system FB number 14 is registered as index information of the instance format information 12. Thus, if the embedded software FB is designated, the corresponding instance format information 12 can be browsed (step S28).
When the application software 18 and the instance format information 12 are received, the received instance format information 12 is stored in association with the application software 18 following the process of step S30. For example, the instance format information 12 is stored in a vacant part of the data memory 132, and information specifying the application software 18 is registered as index information of the instance format information 12. Thus, if the application software 18 is designated, the corresponding instance format information 12 can be browsed (step S32).

By such processing, the programmable controller enters the standby state, and the application software 18 is executed at an arbitrary timing (step S34), and stored in the memory at the timing when the object code 16 of the embedded software FB is called during the processing. The “instance format information 12 corresponding to the embedded software FB” and the “instance format information 12 corresponding to the application software 18” are compared. If the contents match, the process is continued. If the contents are different, a message such as abnormality is presented to the user, and the process ends (step S36).
In FIG. 2, the user creates the embedded software FB using the support tool in the programmable controller support device. At this time, in addition to the generation of the template 20 of the embedded software FB, the instance format information 22 (see FIG. 3) is generated (step S50a). This instance format information 22 is also transmitted to the programmable controller when the object code 26 of the embedded software FB is transmitted (downloaded) to the programmable controller to be operated (step S52a). Also, when the application software 28 and the user FB number 30 are transmitted (downloaded) to the operation target programmable controller, the instance format information 22 is also transmitted to the programmable controller (step S60a).

On the other hand, when the programmable controller receives the object code 26 of the embedded software FB, the received instance format information 22 is stored in association with the embedded software FB following the process of step S66. For example, the instance format information 22 is stored in an empty part of the data memory 132, and information for specifying the embedded software FB is registered in the instance format information 22. Thus, if the embedded software FB is designated, the corresponding instance format information 22 can be browsed (step S68).
When the application software 28, the user FB number 30, and the instance format information 22 are received, the received instance format information 22 is stored in association with the application software 28 following the processing of step S70 and step S72. For example, the instance format information 22 is stored in a vacant part of the data memory 132, and information specifying the application software 28 is registered as index information of the instance format information 22. Thus, when the application software 28 is designated, the corresponding instance format information 22 can be browsed (step S74).

By such processing, the programmable controller enters the standby state, and the application software 28 is executed at an arbitrary timing (step S76), and stored in the memory at the timing when the object code 26 of the embedded software FB is called during the processing. The “instance format information 22 corresponding to the embedded software FB” and the “instance format information 22 corresponding to the application software 28” are compared. If the contents match, the process is continued. If the contents are different, a message such as abnormality is presented to the user, and the process ends (step S78).
FIG. 3 shows an example of the instance format information. Here, as a simple example, a list of attribute information and size information of instance variables is used. The attribute information indicates VAR, VAR_INPUT, and VAR_OUTPUT and means input or output information. The size information indicates OOL and INT, and indicates the memory occupation size according to the data type (see FIG. 8). Since the embedded software FB can be extracted mechanically from the variable structure of the embedded software FB during the generation of the embedded software FB using the support tool of the programmable controller support device, it is not necessary for the user to consciously prepare them.
As another example of the instance format information, for example, the creation time (time stamp) of the embedded software FB may be used. Alternatively, the user may directly prepare and input version number information. By substituting with such simple information, priority may be given to the reduction of the processing time of the comparison in the programmable controller in steps S36 and S78.

In the description of FIGS. 1 and 2, the method of saving the instance format information in the program memory 130 has been described. However, a method of directly embedding in the object code 16 and 26 and the application software 18 and 28 of the embedded software FB may be used. .
As described above, by using the configuration described above, it is possible to avoid abnormality or the like when calling from the application software while using the embedded software FB by the user in the general-purpose controller.

Processing flowchart of embedded software FB (system FB) in programmable controller system of the present invention Processing flowchart of embedded software FB (user FB) in programmable controller system of the present invention Explanatory drawing showing an example of instance format information Explanatory drawing which shows an example of a structure of a programmable controller system Explanatory diagram showing the schematic hardware configuration of the programmable controller Explanatory drawing which shows schematic hardware structure of a programmable controller assistance apparatus Explanatory drawing showing an example of input / output outline of function block An explanatory diagram showing an example of the configuration of an instance of a function block Explanatory drawing which shows an example of the program which calls FB Explanatory drawing which shows the pseudo program code of the program (PG0) shown to Fig.9 (a) Explanatory drawing which shows the pseudo program code of the program (PG1) shown in FIG.9 (b). Outline flowchart showing an example of processing of system FB Schematic flowchart showing an example of processing of user FB Explanatory drawing showing the POU selection screen of the support tool An explanatory diagram showing an example of the editing screen of the embedded software FB An explanatory diagram showing an example of the template of the embedded software FB Explanatory drawing which shows an example of a system FB table Explanatory drawing which shows an example of a user FB table Processing flowchart of embedded software FB (system FB) in a conventional programmable controller system Processing flowchart of embedded software FB (user FB) in a conventional programmable controller system

Explanation of symbols

10, 20 ... Embedded software FB template 12, 22 ... Instance format information 14 ... Embedded software FB system FB number 16, 26 ... Embedded software FB object code 18, 28 ... Application software 30 ... Embedded software FB user FB number DESCRIPTION OF SYMBOLS 100 ... Personal computer 102, 104, 106, 120 ... Programmable controller 108 ... Input / output module 110 ... Cable 112 ... Control network 122 ... Driver / receiver 124 ... CPU
DESCRIPTION OF SYMBOLS 126 ... Bus controller 128 ... Flash memory 130 ... Program memory 132 ... Data memory 134 ... Internal bus 140 ... Programmable controller support apparatus 142 ... CPU
144 ... Communication I / F
146: Input device 148: Display device 150 ... Storage device 152 ... Internal bus 160, 170 ... Function block main body 162, 172 ... Input terminal 164, 174 ... Output terminal 180, 190 ... Instance 182, 184, 192, 194 ... Variable 200 ~ 210, 220 ~ 230, 240 ~ 242 ... code

Claims (7)

First storage means for storing an object code of a function block of embedded software and first additional information given to the object code;
Second storage means for storing application software using the function block of the embedded software and second additional information given to the application software;
Execution means for interpreting and executing the information stored in the first and second storage means,
The execution means, when executing the application software, if the application software has a function block call process of the embedded software, compares the first additional information and the second additional information, A programmable controller characterized in that the processing is continued when there is no difference. The programmable controller according to claim 1,
The programmable controller, wherein the first additional information and the second additional information are instance format information of a function block of the embedded software. The programmable controller according to claim 1,
The programmable controller, wherein the first additional information and the second additional information are version number information or time stamp information that can specify a function block of the embedded software. A first programming means for programming function blocks of the embedded software;
A second programming means for programming application software using the function block of the embedded software;
Compiling means for compiling the function block and the application software;
First transmission means for transmitting an object code of a function block of the embedded software and first additional information for specifying the object code;
A programmable controller support device comprising: the application software; and second transmission means for transmitting second additional information for specifying an object code of a function block of the embedded software included in the application software. The programmable controller support device according to claim 4,
The programmable controller support apparatus, wherein the first additional information and the second additional information are function block instance format information of the embedded software. The programmable controller support device according to claim 4,
The programmable controller support apparatus, wherein the first additional information and the second additional information are version number information or time stamp information that can specify a function block of the embedded software. In a programmable controller system comprising a programmable controller and a programmable controller support device,
The programmable controller support device is
A first programming means for programming function blocks of the embedded software;
A second programming means for programming application software using the function block of the embedded software;
Compiling means for compiling the function block and the application software;
First transmission means for transmitting an object code of a function block of the embedded software and first additional information for specifying the object code;
Second transmission means for transmitting the application software and second additional information for specifying an object code of a function block of the embedded software included in the application software;
The programmable controller is:
First storage means for storing an object code of the function block of the embedded software transmitted by the first transmission means and the first additional information given to the object code;
Second storage means for storing application software using function blocks of the embedded software transmitted by the second transmission means and the second additional information given to the application software;
An execution means for interpreting and executing the information stored in the first and second storage means;
When executing the application, the execution means compares the first additional information with the second additional information when the application has a function block calling process of the embedded software, and there is no difference. A programmable controller system characterized in that the processing is continued in some cases.

Images