Patent Description:
Factory automation (FA) techniques using control devices such as programmable logic controllers (PLCs) have been widespread at various production sites. Such a control device may indirectly control, in addition to directly controlling a control target, a control target through another device by providing a control command to the other device. Control systems including multiple dedicated devices are to integrate such devices into fewer control devices. For example, with the technique described in Patent Literature <NUM>, a central processing unit (CPU) module in a PLC executes a motion computation program and a user program in synchronization.

Patent Literature <NUM> describes a technique for performing control computations in accordance with multiple programs in different execution formats with a single control device. For example, this technique computes command values for a program in one format in which the program is entirely executed per control cycle and for a program in another format in which parts of the program are sequentially executed in accordance with intermediate codes generated through interpretation of each part of the program. The computed command values are output together per control cycle.

With a known technique, a common control target (e.g., a robot) may be controlled by one control device such as a PLC that executes a program in a format in which the program is entirely executed per control cycle and by another control device that executes a program in a format in which parts of the program are sequentially executed in accordance with intermediate codes generated through interpretation of each part of the program. However, the user is to manage which one of the control devices is controlling the control target and thus cannot build such a control system easily. Under insufficient management by the user, the control target may be controlled by both the control devices at a time and may behave in an unexpected manner.

Also, the known technique is not directed to controlling a control target commonly with different programs using a single control device that performs control computations in accordance with multiple programs in different execution formats. Such a control system is to be improved to reduce the load for building the system or increase safety in the control over a control target.

In response to the above issue, one or more aspects of the present invention are directed to a technique for easy building of a system that allows appropriate control over a control target.

In one or more aspects of the present invention, a single control device can execute multiple programs in different execution formats. In response to overlap between the execution times of different programs, the control device performs determination to execute one of the programs at a time. This structure allows determination of the execution states of different programs in real time and allows appropriate control over a control target. The present invention is defined by independent claim, and the advantageous embodiments are provided in the dependent claims.

More specifically, a control device according to the present invention is provided, as defined by independent claim <NUM>. The control device includes a first program in a first execution format in which an overall of the first program is executed per predetermined control cycle and a second program in a second execution format in which parts of the second program are sequentially executed by an interpreter. The device includes a first processor that executes the first program in the first execution format per predetermined control cycle to calculate a first command value for controlling a first control target and to control a second control target, a second processor that executes the second program in the second execution format to calculate a second command value for controlling the second control target per the predetermined control cycle in accordance with an intermediate code generated by the interpreter interpreting at least a part of the second program in the second execution format and calculates the second command value for controlling the second control target in response to the first processor executing the first program in the first execution format, an output unit that outputs the first command value and the second command value per the predetermined control cycle, and a permitter that permits, in response to overlap between a time to execute the first program in the first execution format and a time to execute the second program in the second execution format for controlling the second control target, execution of one of the first program or the second program issuing an occupation request to the second processor earlier than the other one of the first program or the second program per the predetermined control cycle.

The control device includes programs in different execution formats including the program in the first execution format and the program in the second execution format. In the first execution format, the overall program is executed per execution. In the second execution format, parts of the program are sequentially executed. These programs in different execution formats allow the user to appropriately select one program suitable for control over a control target and thus increase the convenience of the control device. The first processor executes the program in the first execution format per control cycle and calculates the first command value based on the program.

The second processor calculates a second command value based on the program in the second execution format per control cycle in accordance with an intermediate code generated through interpretation by an interpreter. The second processor can also calculate the second command value in response to execution of the program in the first execution format. For example, the second processor allows the user to control the same control target (second control target) with the program in the first execution format or the program in the second execution format. Thus, the control program for a control target can be flexibly designed to increase user convenience. The output unit outputs first and second command values. Thus, the command values based on the programs in different execution formats can be output in synchronization. This structure may cause the same control target to be controlled substantially by the two programs in the first and second execution formats. This may cause overlap between the control times.

In response to overlap between the times to execute the programs, the permitter in the control device permits execution of one program alone based on the state of access to the second processor, or more specifically, permits one program alone that has accessed earlier to control the control target. Thus, while one program is already being executed, the permitter does not permit execution of another program despite any request for executing another program. In other words, in response to overlap between the times to execute programs on the same control target, the permitter exclusively permits execution of one of the programs based on the state of access to the second processor.

The control device with this structure appropriately prevents a control target from being controlled with different programs at a time. The control device also allows flexible program design for control over the control target to increase user convenience. The control device can thus appropriately control the control target. The system can be built without the user' efforts to avoid overlap of control programs during programming. This reduces a load in programming and allows easy building of the system.

In the control device, in response to an end of control over the second control target performed by one of the first program or the second program accessing the second processor earlier than the other one of the first program or the second program, the first program in the first execution format and the second program in the second execution format may become executable upon being permitted by the permitter. Such a control device allows exclusive execution of one of the programs continuously on the same control target.

In the control device, in response to permitting execution of one of the first program or the second program, the permitter may provide an error notification for the other one of the first program or the second program for which execution is not permitted by the permitter. This structure allows the program for which execution is not permitted to perform a predetermined substitute process based on the error notification.

The technique according to the above aspects allows easy building of a system that appropriately controls a control target.

An example use of a control device according to an embodiment will now be described with reference to <FIG> and <FIG>. <FIG> is a schematic diagram of a control system <NUM> including control devices <NUM>. <FIG> is a functional block diagram of each control device <NUM>, describing its functions.

Each control device <NUM> corresponds to an industrial controller that controls a control target including various facilities or devices. The control device <NUM> is a computer that performs control computations described later. The control device <NUM> may be connected to various field devices through a field network <NUM>. The field devices include an actuator that physically acts on a production device or a production line (hereafter collectively referred to as a field) and an input-output device that exchanges information with the field. In the example shown in <FIG>, the field devices include robots <NUM>, servo drivers <NUM>, and motors <NUM>. Each servo driver <NUM> drives the corresponding motor <NUM> in accordance with output data (for example, position commands or speed commands) from the corresponding control device <NUM>. Examples of the robot <NUM> include a parallel robot, a selective compliance assembly robot arm (SCARA) robot, and an articulated robot. The control device <NUM> can thus integrally control the robots <NUM>, the servo drivers <NUM>, and the motors <NUM>. The control device <NUM> will be described in detail below.

The control device <NUM> exchanges data with one or more field devices through, for example, the field network <NUM>. The field network is generally referred to as a field bus, but is referred to as a field network herein for simplicity of explanation. The control device <NUM> collects data (hereafter referred to as input data) collected or generated by various field devices (input process), generates data (hereafter referred to as output data) including commands to the field devices (computation process), and transmits the generated output data to the corresponding field devices (output process).

The field network <NUM> may be a bus or a network that allows pre-timed communications for guaranteed data arrival time. For example, EtherCAT (registered trademark) is known as an example of such a bus or network that allows pre-timed communications. Data exchanged between the control device <NUM> and a field device through the field network <NUM> is updated in very short cycles of the order of several hundred microseconds to several ten milliseconds. Such update of exchanged data is also referred to as an input-output refresh.

The control device <NUM> is also connected to another device through a host network <NUM>. The host network <NUM> may be Ethernet (registered trademark) or EtherNet/IP (registered trademark), which is a typical network protocol. More specifically, one or more servers <NUM> may be connected to the host network <NUM>. Examples of the servers <NUM> include a database system and a manufacturing execution system (MES). The MES obtains information from a production device or a facility as a control target to monitor and manage the entire production. The MES can also handle information such as order information, quality information, or shipping information. Instead of a server, a device that provides information services may be connected to the host network <NUM>.

Referring now to <FIG>, the structure of each control device <NUM> will be described. The control device <NUM> is a computer that performs predetermined control computations as described above, and includes a processor and a memory for the control computations. The processor includes a central processing unit (CPU), a micro processing unit (MPU), and a graphics processing unit (GPU). The processor may include multiple cores, or the computer may include multiple processors. Examples of the memory include a volatile storage such as a dynamic random access memory (DRAM) or a static random access memory (SRAM) and a nonvolatile storage such as a hard disk drive (HDD) or a solid state drive (SSD). The processor reads various programs from the memory and executes the programs to perform appropriate control or various other processes (described later) on a control target. In addition to the system program for implementing basic functions, the memory stores user programs (an IEC program <NUM> and an application program <NUM>) designed in accordance with a production device or a facility as a control target.

In one or more embodiments of the present disclosure, the overall IEC program <NUM> is scanned per execution for calculating one or more command values per execution. The IEC program <NUM> typically contains a program including one or more commands described in accordance with the international standard IEC61131-<NUM> defined by the International Electrotechnical Commission (IEC). The IEC program <NUM> contains commands for sequence control and motion control. The IEC program <NUM> is in an execution format in which the overall program is executed (scanned) per control cycle, and is suitable for instantaneous and speedy control. The application program <NUM> in one or more embodiments of the present disclosure is a control program for performing specific processing or a specific operation with a robot, and contains a program including one or more commands for implementing a control application with the robot. The application program <NUM> is basically distinguished from the IEC program <NUM>. In one example, the application program <NUM> for robot control is an interpreter described in a robot language executed sequentially line by line.

As shown in <FIG>, the control device <NUM> includes an IEC program processor <NUM>, a subordinate network interface <NUM>, a host network interface <NUM>, and a control application processor <NUM>. The subordinate network interface <NUM> mediates, through the field network <NUM>, data exchange between the IEC program processor <NUM> and the connected field devices and between the control application processor <NUM> and the field devices. The host network interface <NUM> mediates, through the host network <NUM>, data exchange between the IEC program processor <NUM> and the connected the server <NUM> and between the control application processor <NUM> and the server <NUM>. For example, the control device <NUM> receives a command such as a production start or a production end from the server <NUM> connected through the host network <NUM>. The server <NUM> may transmit information such as recipe information (information including parameters appropriate for production) and an application program for running the control application to the control device <NUM>.

The IEC program processor <NUM> executes (scans) the IEC program <NUM> per predetermined control cycle and calculates one or more command values. More specifically, the IEC program processor <NUM> calculates command values per control cycle in accordance with the IEC program <NUM>. In one or more embodiments of the present disclosure, the IEC program <NUM> is executed to control a predetermined device including the motor <NUM>. A motion processor <NUM> calculates command values per control cycle in accordance with a motion command contained in the IEC program <NUM>. More specifically, the motion command contained in the IEC program <NUM> includes a command indicating the behavior over multiple control cycles (for example, a command instructing a predetermined device including the motor <NUM> to have an output for drawing a certain locus). When the motion command is executed, the motion processor <NUM> calculates command values per control cycle in accordance with the instruction in the executed motion command. In other words, the motion processor <NUM> outputs command values per control cycle to the predetermined device to implement the behavior instructed by the motion command.

The control application processor <NUM> calculates command values for controlling the control application based on, for example, the application program <NUM> and the recipe information. In one or more embodiments of the present disclosure, the control application processor <NUM> executes the application program <NUM> to control the robot <NUM>. The control application processor <NUM> calculates and outputs command values for the control application in synchronization with the IEC program processor <NUM> calculating and outputting the command values. In other words, the control application processor <NUM> calculates the command values in synchronization with the IEC program processor <NUM>. The synchronous processes of the IEC program processor <NUM> and the control application processor <NUM> will be described later. To calculate the command values in synchronization with the IEC program processor <NUM>, the control application processor <NUM> includes a motion processor <NUM>, a buffer <NUM>, and an interpreter <NUM>.

The interpreter <NUM> sequentially interprets at least a part of the application program <NUM>, and generates an intermediate code. The interpreter <NUM> includes the buffer <NUM> to store the generated intermediate code. In one or more embodiments of the present disclosure, the intermediate code contains a command for calculating command values per control cycle, and may contain one or more commands or one or more functions. The motion processor <NUM> calculates command values per control cycle in accordance with intermediate codes pre-generated by the interpreter <NUM> and stored in the buffer <NUM>. Typically, commands (codes) described in the application program <NUM> are executed sequentially. Thus, the calculation cycle of command values is not guaranteed. However, in one or more embodiments of the present disclosure, the use of the intermediate codes allows the motion processor <NUM> to calculate command values per control cycle. Commands described in the intermediate codes may include a coordinate system corresponding to each control application.

A shared memory <NUM> allows data sharing between the IEC program processor <NUM> and the control application processor <NUM>. In one or more embodiments of the present disclosure, the shared memory <NUM> stores a part or all of the results of the processing performed by the control application processor <NUM>. The IEC program processor <NUM> can access data stored in the shared memory <NUM> in the control application processor <NUM>. The IEC program processor <NUM> may write data into the shared memory <NUM> in the control application processor <NUM>. Such data written by the IEC program processor <NUM> is accessible by the interpreter <NUM> and the motion processor <NUM>.

As described above, the motion processor <NUM> controls the robot <NUM> with the intermediate codes generated by the interpreter <NUM>. In another example, the motion processor <NUM> may control the robot <NUM> in response to execution of the IEC program <NUM>. In this case, the IEC program <NUM> contains a control command (motion command) for the robot <NUM>. Upon the IEC program processor <NUM> executing the IEC program <NUM>, the control command for the robot <NUM> contained in the IEC program <NUM> is provided to the motion processor <NUM>. The motion processor <NUM> controls the robot <NUM> based on the control command.

The control device <NUM> thus controls the robot <NUM> in accordance with both the IEC program <NUM> and the application program <NUM> in different execution formats. Thus, the control system <NUM> for implementing a user request can be flexibly built based on the characteristics of each program. In this structure, the robot <NUM> can be controlled with different programs. This structure can cause overlap between the times to execute the two programs for robot control, thus possibly causing the robot <NUM> to operate in an unexpected manner. To avoid such an unexpected operation of the robot <NUM>, the user is to appropriately manage the correlation between the times to execute the two programs. This can be a burden on the user.

The control device <NUM> includes a permitter <NUM> that permits, in response to overlap between the times to execute the IEC program <NUM> and the application program <NUM> for robot control, alternative execution to permit execution of one of the programs without permitting execution of the other program. The permitter <NUM> in the control device <NUM> limits the program for controlling the robot <NUM> to either the IEC program <NUM> or the application program <NUM>. This structure can avoid the robot <NUM> operating unintentionally in response to overlap between the times to execute the IEC program <NUM> and the application program <NUM>.

The control device <NUM> implements synchronous execution of the IEC program <NUM> and the application program <NUM>. The interpreter <NUM> in the control application processor <NUM> sequentially executes parts of the application program <NUM> per cycle longer than the control cycle, for example, per cycle twice as long as the control cycle. The motion processor <NUM> in the IEC program processor <NUM> and the motion processor <NUM> in the control application processor <NUM> calculate command values per same control cycle. Thus, command values are output from the control device <NUM> in synchronization in the predetermined control cycle. As described above, the IEC program processor <NUM> and the control application processor <NUM> each include a motion processor for continuously controlling the movement of the actuator. These motion processors calculate command values in synchronization. This allows the control in accordance with the IEC program <NUM> and the control in accordance with the application program <NUM> to be performed in synchronization with the control cycle. Thus, precise control per control cycle can be performed.

The times to execute the IEC program <NUM> and the application program <NUM> in the control device <NUM> will now be described in detail with reference to <FIG> is a diagram describing example times to execute the programs in the control device <NUM>. The control device <NUM> has high-priority tasks (upper process in <FIG>) with a high priority and a low-priority task (lower process in <FIG>) with a low priority, which are set based on the processor resource. More specifically, the execution of the subordinate network interface <NUM>, the execution of the IEC program processor <NUM>, the execution of the motion processor <NUM>, and the execution of the motion processor <NUM> in the control application processor <NUM> are set as high-priority tasks, and the execution of the interpreter <NUM> in the control application processor <NUM> is set as a low-priority task.

More specifically, tasks executed as high-priority tasks include input-output refresh B60 performed by the subordinate network interface <NUM>, execution B40 of the IEC program <NUM>, computation B42 of a command value performed by the motion processor <NUM> in accordance with the IEC program <NUM>, computation B32 of a command value performed by the motion processor <NUM> in accordance with the application program <NUM>, and computation B32' of a command value performed by the motion processor <NUM> in response to execution of the IEC program <NUM>. Sequential interpretation B34 of the application program <NUM> is executed as a low-priority task. In the high-priority tasks in one control cycle T1, the permitter <NUM> described above permits execution of either the computation B32 or the computation B32'.

The high-priority tasks are repeatedly executed per predetermined control cycle T1. The low-priority task is executed in each control cycle while the high-priority tasks are not being executed. More specifically, the time to execute the high-priority tasks is allocated to each control cycle, and the low-priority task is executed at a time other than the time to execute the high-priority tasks.

The high-priority tasks will first be described. In each control cycle, the input-output refresh B60 is executed, and then the IEC program processor <NUM> executes (scans) the overall IEC program <NUM> to calculate one or more command values for sequence control (execution B40). The motion processor <NUM> performs a motion process for the motion command contained in the IEC program <NUM> to calculate one or more command values of the motion command (execution B42). The motion processor <NUM> in the control application processor <NUM> prepares a motion command for controlling the robot <NUM> in accordance with the intermediate code stored in the buffer <NUM> (execution B32), or prepares a motion command for controlling the robot <NUM> included in the IEC program <NUM> (execution B32'). The permission from the permitter <NUM> determines whether to perform the execution B32 or the execution B32'. The permission process will be described in detail later. The same processes are repeated per control cycle. The motion processor <NUM> may read an intermediate code from the buffer <NUM> at the time other than every control cycle. The read intermediate code may include commands for calculating command values over multiple control cycles T1. In this case, the intermediate code can be read at a time over the multiple control cycles T1.

In this manner, the high-priority tasks in a control cycle are executed to generate a set of command values. The command values include a command value for the sequence control over, for example, the motor <NUM>, a command value for the motion control over, for example, the motor <NUM>, and a command value for the control application of the robot <NUM>. These command values are basically reflected on the field in the subsequent control cycle. In other words, the IEC program processor <NUM> and the control application processor <NUM> calculate command values corresponding to input data in the same control cycle, and can thus provide outputs synchronized with the inputs.

For the low-priority task, the interpreter <NUM> in the control application processor <NUM> sequentially executes parts of the application program <NUM>. More specifically, the interpreter <NUM> reads and analyzes the application program <NUM> with a low priority. The intermediate codes generated by the interpreter <NUM> analyzing the application program <NUM> are sequentially stored in the buffer <NUM> based on the capacity of the buffer <NUM>. The intermediate codes stored in the buffer <NUM> are sequentially referred to by the motion processor <NUM> in the control application processor <NUM>, and used to generate command values in the computation B32. In this case, the interpreter <NUM> pre-generates extra intermediate codes corresponding to an integral multiple of the control cycle as the computation cycle of the high-priority tasks, and thus can calculate the command values for the control application per control cycle without affecting the process performed by the motion processor <NUM>.

Before each predetermined control application synchronization cycle (integral multiple of the control cycle), the interpreter <NUM> temporarily stops interpretation of the application program <NUM>. At the time of temporary stop, the IEC program processor <NUM> and the control application processor <NUM> perform data synchronization with each other to share data consistent for the two processors. The interpreter <NUM> thus updates data shared with the IEC program processor <NUM> per synchronization cycle. In addition to updating shared data, the interpreter <NUM> may also update (synchronize) input data and output data obtained from the field. This allows the control application processor <NUM> to control the robot <NUM> using data obtained by the IEC program processor <NUM>. The control application synchronization cycle may have any length corresponding to an integral multiple of the control cycle. The control application synchronization cycle is appropriately set in accordance with, for example, the precision of control intended in the control application.

The process performed on the field devices (the robot <NUM> and the motor <NUM>) as controlled by the control device <NUM> will now be described with reference to <FIG>. <FIG> is a flowchart of the process for the above high-priority tasks, <FIG> is a flowchart of a detailed robot execution performed for the high-priority tasks, and <FIG> is a flowchart of the process for the low-priority task described above.

The process for the high-priority tasks will first be described. In each control cycle T1, the subordinate network interface <NUM> performs the input-output refresh (process in S101). This process allows output of the command values (command values from, for example, the processes B40, B42, and B32 or B32') calculated in the previous control cycle T1 to, for example, the actuator in each field device and input of data from each field device. Subsequently, in S102, the determination is performed as to whether the current control cycle matches the data synchronization time. In response to an affirmative determination result obtained in S102, data synchronization is performed between the IEC program processor <NUM> and the control application processor <NUM> (process in S103). In response to a negative determination result obtained in S102, the processing advances to S104.

The execution B40 is performed in S104, and then the execution B42 is performed in S105. After S105, the robot execution is performed in S106 for preparing a motion command for controlling the robot <NUM>.

The robot execution will now be described with reference to <FIG>. In S201, the determination is performed as to whether any occupation request is issued as a request for occupying the robot <NUM> in the period of controlling the robot <NUM>. The occupation request is issued to the control application processor <NUM> from the IEC program <NUM> and the application program <NUM> containing control commands to instruct the robot <NUM> to perform a predetermined series of control operations before the instructed control is started. In response to the issued occupation request being permitted in occupation permission determination in S203 or S206 described later, the robot <NUM> is occupied by either program for control until the occupation is canceled in S211 (described later). In response to an affirmative determination result obtained in S201, the processing advances to S202. In response to a negative determination result obtained in S201, the processing advances to S220.

In S202, the determination is performed as to whether the application program <NUM> or the IEC program <NUM> has issued the occupation request. In response to the request issued from the application program <NUM>, the processing advances to S203. In response to the request issued from the IEC program <NUM>, the processing advances to S206. In S203, the determination is performed as to whether the occupation request issued by the application program <NUM> is to be permitted by the permitter <NUM>. In this determination, unless the robot <NUM> is occupied by the other program or the IEC program <NUM> for control, the occupation request issued by the application program <NUM> is permitted (the determination result is affirmative in S203). In response to the robot <NUM> being occupied by the IEC program <NUM> for control, the occupation request is not permitted (the determination result is negative in S203). In response to an affirmative determination result obtained in S203, the processing advances to S204. In response to a negative determination result obtained in S203, the processing advances to S208.

In S204, the motion processor <NUM> reads the intermediate code from the buffer <NUM>. In the subsequent step S205, the motion processor <NUM> calculates a motion command for controlling the robot <NUM> in the current control cycle T1 in accordance with the read intermediate code. The motion command is prepared for synchronous control (processing corresponding to the computation B32).

In S206, the determination is performed as to whether the occupation request issued by the IEC program <NUM> is permitted by the permitter <NUM>. In this determination, unless the robot <NUM> is occupied by the other program or the application program <NUM> for control, the occupation request issued by the IEC program <NUM> is permitted (the determination result is affirmative in S206). In response to the robot <NUM> being occupied by the application program <NUM> for control, the occupation request is not permitted (the determination result is negative in S206). In response to an affirmative determination result obtained in S206, the processing advances to S207. In response to a negative determination result obtained in S206, the processing advances to S208.

In S207, the motion command included in the IEC program <NUM> for controlling the robot <NUM> is prepared for synchronous control (processing corresponding to the computation B32').

In response to a negative determination result obtained in S203 or S206, the processing advances to S208, in which the permitter <NUM> provides an error notification. The error notification indicates that the occupation request output from one program is not permitted while the robot <NUM> is being occupied by the other program for control. Subsequently, in S209, a motion command for controlling the robot <NUM> is prepared for synchronous control in accordance with the program currently occupying the robot <NUM>. More specifically, in response to the robot <NUM> being occupied by the application program <NUM>, processing corresponding to the processing in S204 and S205 is performed. In response to the robot <NUM> being occupied by the IEC program <NUM>, processing corresponding to the processing in S207 is performed.

After S205, S207, or S209, the processing advances to S210. In S210, the determination is performed as to whether the series of control operations on the robot <NUM> in accordance with the corresponding program is ended. The control is determined to be ended or not ended based on, for example, a control end command output from each program. In response to an affirmative determination result obtained in S210, the robot <NUM> is released from being occupied in the subsequent step S211. After S211, the robot <NUM> is unoccupied by any of the programs for control. In response to a negative determination result obtained in S210, the robot <NUM> remains occupied.

In response to a negative determination result obtained in S201, the processing advances to S220. In S220, in response to no occupation request being issued (the determination result is negative in S201), the determination is performed as to whether the robot <NUM> is occupied by any program for control. In response to an affirmative determination result obtained in S220, the processing advances to S209. A motion command for controlling the robot <NUM> is prepared for synchronous control in accordance with the program currently occupying the robot <NUM>. In response to a negative determination result obtained in S220, the robot execution ends. In this case, no motion command is prepared for controlling the robot <NUM>.

The command value calculated and prepared in the series of processes of the high-priority tasks shown in <FIG> and <FIG> is output to the field in the subsequent control cycle T1. After the series of processes and before the subsequent control cycle T1, the low-priority task is performed as shown in <FIG>.

The process of the low-priority task will now be described with reference to <FIG>. The low-priority task is performed for the interpreter <NUM> to interpret the application program <NUM>. In S301, the control application processor <NUM> determines whether any intermediate code remains in the buffer <NUM> to avoid generation of intermediate codes exceeding the capacity of the buffer <NUM>. In response to an affirmative determination result obtained in S301, the low-priority task ends. In response to a negative determination result obtained in S301, the processing advances to S302. In S302, the interpreter <NUM> reads a part of the application program <NUM>. For example, the interpreter <NUM> reads a line of the code included in the application program <NUM>. In S303, the interpreter <NUM> interprets the read code to generate an intermediate code. The generated intermediate code is stored in the buffer <NUM> in S304. In response to no application program being available for execution, the processing in S302 to S304 is not performed, and thus no intermediate code is stored in the buffer <NUM>. The low-priority task undergoing the above series of processes is repeated during a period allocated to the low-priority task to execute the program.

Claim 1:
A control device (<NUM>) including a first program (<NUM>) in a first execution format in which an overall of the first program (<NUM>) is executed per predetermined control cycle, and a second program (<NUM>) in a second execution format in which parts of the second program (<NUM>) are sequentially executed by an interpreter (<NUM>), the device comprising:
a first processor (<NUM>) configured to execute the first program (<NUM>) in the first execution format per the predetermined control cycle to calculate a first command value for controlling a first control target (<NUM>) and to control a second control target (<NUM>);
a second processor (<NUM>) configured to execute the second program (<NUM>) in the second execution format to calculate a second command value for controlling the second control target (<NUM>) per the predetermined control cycle in accordance with an intermediate code generated by the interpreter (<NUM>) interpreting at least a part of the second program in the second execution format, and to calculate the second command value for controlling the second control target (<NUM>) in response to the first processor (<NUM>) executing
the first program (<NUM>) in the first execution format;
an output unit (<NUM>) configured to output the first command value and the second command value per the predetermined control cycle; and
a permitter (<NUM>) configured to permit, in response to overlap between a time to execute the first program (<NUM>) in the first execution format and a time to execute the second program (<NUM>) in the second execution format for controlling the second control target (<NUM>), execution of one of the first program (<NUM>) or the second program (<NUM>) issuing an occupation request to the second processor (<NUM>) earlier than the other one of the first program (<NUM>) or the second program (<NUM>) per the predetermined control cycle.