Control device

To cause multiple field devices to operate together in coordination in accordance with a predetermined program through a network allowing periodic communication, a control device includes an estimator that calculates, based on a position of a first field device in a first cycle, a position of the first field device operable in accordance with a first program in a second cycle following the first cycle, and a processor that determines, based on the first program, a first command value to cause the first field device to operate, transmits the first command value to the first field device through an interface allowing communication with the field devices, determines, based on the estimated position and a second program, a second command value to cause a second field device to operate in coordination with the first field device, and transmits the second command value to the second field device through the interface.

FIELD

The present invention relates to a control device for controlling multiple control targets.

BACKGROUND

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 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 1, a central processing unit (CPU) module in a PLC executes a motion computation program and a user program in synchronization.

Patent Literature 2 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 overall program is executed in every control cycle and for a program in another format in which parts of the program are executed successively in accordance with intermediate codes generated through interpretation of each part of the program. The computed command values are output together in every control cycle.

Patent Literature 3 describes a control device for synchronizing multiple signals that are periodically generated by different clocks. The control device with this technique includes a first processor that obtains a synchronization signal generated in every first cycle, and a second processor that generates second cycles each having a length obtained by dividing the first cycle by n (n≥1), generates, using a timer, a control signal in every third cycle having a length obtained by dividing the second cycle by m (m≥2), and performs predetermined processing at timing based on the control signal. At least one of multiple control signals generated in first cycles is to be synchronized with the synchronization signal. Upon detecting an error in timing between the synchronization signal and the control signal to be synchronized with the synchronization signal, the second processor temporarily changes the timer interval for subsequent cycles to correct the error.

CITATION LIST

Patent Literature

Patent Literature 1: Japanese Unexamined Patent Application Publication No. 2012-194662Patent Literature 2: Japanese Unexamined Patent Application Publication No. 2019-36043Patent Literature 3: Japanese Unexamined Patent Application Publication No. 2019-101480

SUMMARY

Technical Problem

For example, a known system may synchronize master-slave operations with a master operation using a rotational shaft in an apparatus that transports containers and a slave operation using a nozzle filling the containers with any filler. Another known system may synchronize master-slave operations with a master operation using a conveyor that transports workpieces and a slave operation using a robot that performs an operation on the workpieces. Such systems involve a user correcting delays in master-slave operations resulting from communication cycles.

In response to the above issue, one or more aspects of the present invention are directed to a technique for easy synchronous control of operations of field devices.

Solution to Problem

A control device according to an aspect of the present invention causes a plurality of field devices to operate in coordination with one another in accordance with a predetermined program through a network allowing periodic communication. The control device includes an estimator that calculates, based on a position of a first field device in a first cycle, a position of the first field device operable in accordance with a first program in a second cycle following the first cycle, and a processor that determines, based on the first program, a first command value to cause the first field device to operate, transmits the first command value to the first field device through an interface allowing communication with the plurality of field devices, determines, based on the position calculated by the estimator and a second program, a second command value to cause a second field device to operate in coordination with the first field device, and transmits the second command value to the second field device through the interface.

When a field device is controlled through a network that allows periodic communication, a delay of cycles taken for processing and communication may occur before the field device receives a command value and performs the operation. In the above control device, the estimator calculates the position of the first field device in a subsequent cycle (second cycle), and the processor determines, based on the calculated position, a command value for an operation of the second field device to operate in coordination with the first field device. In other words, an instruction for the operation of the second field device, which uses the position of the first field device in the subsequent cycle as a target, can accommodate a delay between transmission of the command value and reception of the command value in the second field device. The technique allows easy synchronous control of operations of field devices.

The estimator may calculate the position of the first field device in the second cycle by adding, to the position of the first field device in the first cycle, a value determined by multiplying an operating speed of the first field device by a predetermined correction coefficient. The position of the first field device in the second cycle can be estimated through, for example, the calculation above.

One of the first program or the second program may be in a first execution format in which an overall program is executed at every execution, and another one of the first program or the second program may be in a second execution format in which parts of the program are executed successively. The predetermined correction coefficient may be determined in accordance with a combination of types of the first field device and the second field device, and the combination may include a device operable in accordance with the program in the first execution format and a device operable in accordance with the program in the second execution format. The first execution format is a format in which the overall program is executed at every execution of the program. Examples of such a program include an International Electrotechnical Commission (IEC) program containing instructions for sequence control and motion control. The second execution format is a format in which parts of the program are executed successively. Examples of such a program include an application program for mainly controlling a robot. In this case, the delay varies depending on, for example, whether each of the first field device serving as a reference for coordinated operations and the second field device that operates in coordination with the first field device is a device that operates in the first execution format or a device that operates in the second execution format. Thus, the correction coefficient may be determined in accordance with a combination of the types of first field device and second field device, thus allowing appropriate estimation.

The processor may include a first processor that executes the program in the first execution format in every control cycle in the periodic communication and computes a command value to control one of the plurality of field devices, and a second processor that executes the program in the second execution format and computes a command value to control another of the plurality of field devices in every control cycle in accordance with an intermediate code generated by an interpreter interpreting at least a part of the program in the second program, and also computes the command value to control the other of the plurality of field devices in response to the first processor executing the program in the first execution format. The first processor and the second processor may each transmit the computed command value in every control cycle through the interface.

The first processor and the second processor each transmit a calculated command value in every control cycle in the periodic communication described above, thus allowing integrated control of, for example, a motion shaft and a robot and easy synchronous control of their operations.

The position of the first field device in the first cycle may be a feedback value fed back from the first field device or a command value transmitted to the first field device. The predetermined correction coefficient may be determined in accordance with one of the feedback value or the transmitted command value to be used as the position of the first field device in the first cycle. More specifically, either of the values described above may be used to indicate the position of the first field device in the first cycle. The delay differs for each of the two values. The correction coefficient may thus be determined with one of the two values to be used, thus allowing appropriate estimation.

The periodic communication may include communication in accordance with an EtherCAT (registered trademark) standard. Such a standard allows a field network to perform the processing described above.

Advantageous Effects

The technique according to the above aspects allows easy synchronous control of operations of field devices.

DETAILED DESCRIPTION

Example Use

An example use of a control device according to an embodiment will now be described with reference toFIGS.1and2.FIG.1is a schematic diagram of a control system1including control devices100.FIG.2is a functional block diagram of a control device100including functional units.

The control device100corresponds to an industrial controller that controls targets such as various pieces of equipment and apparatuses. The control device100is a computer that performs control computations described later. The control device100may be connected to field devices with a field network2. The field devices include, for example, an actuator and an input-output device. The actuator physically acts on a manufacturing apparatus or at a production line (hereafter collectively referred to as a field). The input-output device exchanges information with the field. InFIG.1, robots210, servo drivers220, and motors222are examples of the field devices. Each servo driver220drives the corresponding motor222in accordance with output data (e.g., a command value such as a position command and a speed command) from the corresponding control device100. Examples of the robots210include a parallel robot, a selective compliance assembly robot arm (SCARA) robot, and an articulated robot. The control device100can control the corresponding robot210, servo driver220, and motor222in an integrated manner as described in detail later.

The control device100exchanges data with one or more field devices through, for example, the field network2. Afield network is generally referred to as a fieldbus, but is referred to as a field network herein for simplicity of explanation. The control device100collects 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 network2herein may be a bus or a network that allows periodic communication for on-time arrival of data. Known buses or networks for such periodic communication include Ethernet for Control Automation Technology (EtherCAT) (registered trademark). Data exchanged between the control device100and the field devices through the field network2is updated in short cycles in the order of several hundreds of microseconds to several tens of milliseconds. Such updating of exchanged data may be referred to as input-output refresh.

The control device100is also connected to other devices with an upper network6. The upper network6may use a common network protocol such as Ethernet (registered trademark) and EtherNet/IP (registered trademark). More specifically, one or more servers10may be connected to the upper network6. The server10may be, for example, a database system or a manufacturing execution system (MES). The MES obtains information from a control target, such as a manufacturing apparatus or equipment, to monitor and manage the overall production. The MES may also manage other information such as order information, quality information, and shipping information. Devices connected to the upper network6are not limited to the above. A device that provides information services may also be connected to the upper network6.

The structure of the control device100will now be described with reference toFIG.2. As described above, the control device100is a computer that performs predetermined control computations. The control device100includes a processor and a memory for the control computations. The processor includes, for example, a central processing unit (CPU), a microprocessing unit (MPU), and a graphics processing unit (GPU). The processor may include multiple cores. The control device100may include multiple processors. The memory may be, for example, a volatile storage such as a dynamic random-access memory (DRAM) or a static random-access memory (SRAM), or a nonvolatile storage such as a hard disk drive (HDD) or a solid-state drive (SSD). The processor reads various programs stored in the memory and executes the programs to implement control for the control target and various types of processing described later. The memory stores system programs for implementing basic functions and user programs (an IEC program51and an application program52) created specifically for control targets, such as a manufacturing apparatus or a piece of equipment.

In one or more embodiments of the present disclosure, the overall IEC program51is scanned at every execution of the program for computing one or more command values at every execution of the program. The IEC program51typically includes a program containing one or more instructions written in accordance with the international standard IEC 61131-3 defined by the International Electrotechnical Commission (IEC). The IEC program51contains instructions for sequence control and motion control. The IEC program51is in an execution format in which the overall program is executed (scanned) in every control cycle, and is thus suitable for control to be performed immediately at high speed. In contrast, the application program52in one or more embodiments of the present invention is a control program for a specific process or operation using a robot. The application program52includes a program containing one or more instructions to implement a control application using a robot. The application program52is basically distinguished from the IEC program51. In one example, the application program52for controlling a robot is an interpreter written in a robot language executed successively line by line.

As shown inFIG.2, the control device100includes an IEC program processor40, a lower network interface60, an upper network interface20, a control application processor30, an estimator70, and a shared memory71. The lower network interface60mediates, through the field network2, data exchange between the IEC program processor40and the connected field devices and between the control application processor30and the field devices. The upper network interface20mediates, through the upper network6, data exchange between the IEC program processor40and the connected server10and between the control application processor30and the server10. For example, the control device100receives an instruction to start or end production from the server10connected with the upper network6. The server10may also transmit, to the control device100, for example, an application program for operating a control application and recipe information (information about parameters suitable for production).

The IEC program processor40executes (scans) the IEC program51in every predetermined control cycle and computes one or more command values. In other words, the IEC program processor40computes one or more command values in accordance with the IEC program51in every control cycle. In one or more embodiments of the present disclosure, the IEC program51is executed to control a predetermined apparatus including the motor222. A motion processor42computes a command value in accordance with a motion instruction included in the IEC program51in every control cycle. More specifically, the motion instruction included in the IEC program51includes an instruction for a motion to continue for multiple control cycles (e.g., an instruction to cause an output from the predetermined apparatus including the motor222to indicate a predetermined path). In response to the motion instruction being implemented, the motion processor42computes a command value in every control cycle in accordance with the executed motion instruction. In other words, the motion processor42outputs a command value to the above predetermined apparatus in every control cycle to cause the motion specified by the motion instruction. The motion processor42corresponds to a first processor in an aspect of the present invention.

The control application processor30computes a command value for controlling the control application based on, for example, the application program52and recipe information. In one or more embodiments of the present disclosure, the control application processor30executes the application program52to control the robot210. In synchronization with the computation and output of a command value by the IEC program processor40, the control application processor30computes a command value for the control application and outputs the command value. In other words, the control application processor30computes a command value in synchronization with computation performed by the IEC program processor40. Synchronization of the IEC program processor40and the control application processor30will be described later. To compute a command value in synchronization with the computation of a command value by the IEC program processor40, the control application processor30includes a motion processor32, a buffer33, and an interpreter34.

The interpreter34successively interprets at least a part of the application program52and generates an intermediate code. The interpreter34includes the buffer33that stores the generated intermediate code. The intermediate code in one or more embodiments of the present disclosure includes an instruction for computing a command value in every control cycle, and may include one or more instructions or one or more functions. The motion processor32computes a command value in every control cycle in accordance with an intermediate code pre-generated by the interpreter34and stored in the buffer33. An instruction (code) written in the application program52is typically executed successively. Thus, the command value may not be computed in cycles. In one or more embodiments of the present disclosure, the intermediate code allows the motion processor32to compute the command value in every control cycle. The instruction written in the intermediate code may use a coordinate system in accordance with the control application. The motion processor32corresponds to a second processor in an aspect of the present invention. The motion processor32and the motion processor42each correspond to a processor in an aspect of the present invention.

The control device100includes the shared memory71for data sharing between the IEC program processor40and the control application processor30. In one or more embodiments of the present disclosure, the shared memory71stores a part or all of the results of processing performed by the control application processor30. The IEC program processor40can refer to data stored in the shared memory71. The IEC program processor40may also write data to the shared memory71. Such data written by the IEC program processor40can be referred to by the interpreter34and the motion processor32. The estimator70may also write and read data to and from the shared memory71.

As described above, the motion processor32uses the intermediate code generated by the interpreter34to control the robot210. In another embodiment, the motion processor32may control the robot210in response to execution of the IEC program51. In this case, the IEC program51contains a control command (motion command) for the robot210. In response to the IEC program processor40executing the IEC program51, the control command for the robot210contained in the IEC program51is output to the motion processor32, which then controls the robot210based on the control command.

As described above, the control device100can control the robot210in accordance with both the IEC program51and the application program52in different execution formats. The control system1can thus have a flexible structure to implement a user request based on the characteristics of each program.

The estimator70performs estimation for correcting a delay in operations of multiple field devices that are to operate in coordination. For example, based on a value representing the current position or posture of a field device serving as a reference for operations (also referred to as an operation master device), a command value is calculated for an operation of another field device (also referred to as an operation slave device) that is to operate in coordination with the operation master device. At a time point at which the operation slave device performs the operation in accordance with a control command containing the command value, the operation master device may have moved further or may have changed the posture. This delay in an operation can result from a difference in communication cycles or from the time taken for data processing. The estimator70thus estimates the position or posture of the operation master device at the time point at which the operation slave device performs the operation. The motion processor32and the motion processor42transmit, to the operation slave device, command values based on an estimated value. In this manner, the estimator70performs lead angle correction to cause the operation slave device to operate earlier than the operation master device. This allows the user of the control device100to easily perform synchronous control of operations. The control device100controls the master device and the slave device in an integrated manner. More specifically, the control device100controls the field devices in accordance with both the IEC program51and the application program52, and thus can control the master device and the slave device in different execution formats in an integrated manner.

Synchronous Execution of Programs

The control device100synchronously executes the IEC program51and the application program52. The interpreter34in the control application processor30successively executes parts of the application program52in cycles longer than control cycles, or for example, in every cycle (control application synchronization cycle T2) with a length twice the length of the control cycle. Each of the motion processor42in the IEC program processor40and the motion processor32in the control application processor30computes a command value in every control cycle with the same length. Command values are thus synchronously output from the control device100in predetermined control cycles. As described above, each of the IEC program processor40and the control application processor30includes a motion processor for continuously controlling the operation of an actuator. These motion processors synchronously compute command values to perform both control in accordance with the IEC program51and control in accordance with the application program52in cycles synchronized with control cycles. This allows accurate control in control cycles.

The execution timing of the IEC program51and the application program52in the control device100will now be described in detail with reference toFIG.3.FIG.3is a diagram showing the example timing at which the control device100executes programs. For the control device100, high-priority tasks with a higher priority (tasks in an upper portion ofFIG.3) and a low-priority task with a lower priority (task in a lower portion ofFIG.3) are defined based on processor resources. More specifically, tasks involving the lower network interface60, execution by the IEC program processor40and the motion processor42, and execution by the motion processor32in the control application processor30are defined as high-priority tasks, and tasks involving execution by the interpreter34in the control application processor30are defined as low-priority tasks.

More specifically, high-priority tasks include input-output refresh B60associated with the lower network interface60, execution B40of the IEC program51, computation B42of a command value performed by the motion processor42in accordance with the IEC program51, computation B32of a command value performed by the motion processor32in accordance with the application program52, and computation B32′ of a command value performed by the motion processor32in response to the IEC program51. Low-priority tasks include successive interpretation B34of the application program52. The high-priority tasks performed in one control cycle T1include either the computation B32or the computation B32′.

The high-priority tasks are performed in every predetermined control cycle T1. The low-priority task is performed while the high-priority tasks are not being performed in each control cycle. More specifically, each high-priority task has an allotted time to be performed in every control cycle, whereas the low-priority task is performed at a time other than a time at which any high-priority task is performed.

The high-priority tasks will be described first. At the start of each control cycle, the input-output refresh B60is performed. The IEC program processor40then executes (scans) the overall IEC program51to compute one or more command values for sequence control (execution B40). The motion processor42also performs motion processing for a motion instruction contained in the IEC program51to compute one or more command values for the motion instruction (execution B42). The motion processor32in the control application processor30then prepares a motion command for controlling the robot210in accordance with an intermediate code stored in the buffer33(execution B32), or prepares a motion command for controlling the robot210contained in the IEC program51(execution B32′). Either the execution B32or the execution B32′ is selected based on a predetermined criterion. The same processing is thereafter performed in every control cycle. The motion processor32may read the intermediate code from the buffer33at any timing that may not be in every control cycle. When the read intermediate code contains an instruction to compute command values for multiple control cycles T1, the intermediate code for the multiple control cycles T1can be read once.

In this manner, the high-priority tasks are performed in one control cycle, followed by preparation of a set of a command value for sequence control for, for example, the motor222, a command value for motion control for, for example, the motor222, and a command value for the control application for the robot210. These command values are normally output to the field at the start of the next control cycle. More specifically, the IEC program processor40and the control application processor30compute command values in accordance with input data in the same control cycles. This allows output synchronized with input.

For the low-priority task, the interpreter34in the control application processor30successively executes parts of the application program52. More specifically, the interpreter34reads and analyzes the application program52with a lower priority. The interpreter34analyzes the application program52to generate intermediate codes, which is successively stored into the buffer33based on the capacity of the buffer33. The intermediate codes stored in the buffer33are sequentially referred to by the motion processor32in the control application processor30to generate a command value in the computation B32. In this case, the interpreter34pre-generates extra intermediate codes corresponding to an integral multiple of the control cycle as the computation cycle of the high-priority tasks. This allows computation of a command value for the control application in every control cycle without affecting the processing performed by the motion processor32.

The interpreter34temporarily stops interpreting the application program52before the start of a cycle with a predetermined control application synchronization cycle (an integer multiple of the control cycle). At the temporary stop, data synchronization is performed between the IEC program processor40and the control application processor30to have the two processors sharing consistent data. In this manner, the interpreter34updates data shared with the IEC program processor40in every synchronization cycle. At the same time with the update of the shared data, input data obtained from the field and output data may also be updated (synchronized). This allows the control application processor30to control the robot210by using data obtained by the IEC program processor40. The control application synchronization cycle may have any length that is an integer multiple of the control cycle. The length of the control application synchronization cycle may be set as appropriate depending on, for example, the control accuracy for the control application.

Synchronous Control of Field Devices

FIG.4is a diagram describing example communication between the control device and the field devices. The communication is performed periodically. In the present embodiment, the communication is performed in accordance with the EtherCAT standard. The control device100functions as a controller for the field network2to control field devices including the robot210and the servo driver220. The devices may be interconnected in a daisy chain, star, or ring topology. In the present embodiment, the devices are daisy-chained. The control device100stores information in accordance with a predetermined standard into a data field in an Ethernet frame. The Ethernet frame is then transmitted sequentially to the field devices connected in series (S1and S2inFIG.4). The Ethernet frame turns at a terminal field device to return in the reverse direction to the control device100(S3and S4inFIG.4). This ends one cycle of input and output processing. In every cycle, each field device performs, on the fly, input and output processing on an Ethernet frame received and to be transmitted. A bit location and a bit width are predefined for data input or output performed by each field device. The motion processor32and the motion processor42described above store command values for the field devices into an Ethernet frame in accordance with the application program52or the IEC program51. Command values corrected based on estimation results of the estimator70are used as the command values in the above processing.

FIG.5is a diagram describing example coordinated operations of the field devices. In the example inFIG.5, the motor222operates a conveyor8. A workpiece9is placed on the conveyor8and transported in accordance with the operation of the motor222. The robot210performs a predetermined operation on the workpiece9.

In a first cycle (C1inFIG.5), for example, the servo driver220feeds back the position of the shaft of the motor222to the control device100. The operating speed of the motor222may also be fed back. In a second cycle (C2inFIG.5) following the first cycle, the control device100estimates, based on the position of the shaft of the motor222, the position of the shaft of the motor222in a third cycle (C3inFIG.5) following the second cycle, determines a target position of the robot210based on the estimated position, and transmits a control command based on the target position to the robot210. In the third cycle, the robot210operates based on the target position. In the third cycle, the workpiece9is transported by the conveyor8to the estimated position ahead of the position in the second cycle. The multiple field devices thus operate synchronously.

FIG.6is a diagram describing example communication between the control device and the field devices and an example delay in coordinated operations of the field devices.FIG.6shows the processing performed by the control device and the field devices. The master device and the slave device shown inFIG.6are field devices. The master device corresponds to the operation master device, and the slave device corresponds to the operation slave device. The operation master device is the servo driver220that controls the motor222. The operation slave device is the robot210. I/O denotes input-output refresh, and corresponds to, for example, B60inFIG.3. UPG denotes execution of a user program. MC denotes computation for motion control, and corresponds to, for example, B42inFIG.3. RC denotes computation for robot control, and corresponds to, for example, B32inFIG.3. ECAT denotes communication with EtherCAT. For the field devices with EtherCAT, IN denotes input refresh, and OUT denotes output refresh. IN and OUT correspond to an input and an output to and from the Ethernet frame inFIG.4. Trajectory denotes the calculation of a trajectory of the robot.

In cycle C11, data representing the current position is input at IN for the master device for feedback. In cycle C12, at ECAT for the master device and I/O for the control device, data is fed back to the control device100. At MC and RC for the control device, control commands for the field devices are generated. In cycle C13, the control commands are transmitted at I/O for the control device and ECAT for the slave device and are read at OUT for the slave device. A trajectory of the operation of the robot210is calculated at Trajectory. In subsequent cycle C14, the robot210operates in accordance with the calculated trajectory. The processing for blocks other than the processing described above is also performed in parallel.

As shown inFIG.6, the robot210operates in cycle C14, which is delayed from cycle C11, in which the servo driver220writes the current position for feedback, and cycle C12, in which command values are calculated through computation for motion control of the servo driver220. Although not shown, the delay may vary depending on the combination of the types of the master device and the slave device, or more specifically, whether the master device is the servo driver or the robot, or the slave device is the servo driver or the robot. In other words, the communication cycle and the processing time vary depending on whether each of the operation master device and the operation slave device is a field device that operates in accordance with a program in an execution format in which the overall program is executed at every execution of the program, or a field device that operates in accordance with an intermediate code generated by the interpreter from at least a part of a program in an execution format in which parts of the program are executed successively. This causes the delay to vary. The estimator70corrects such a delay when calculating an estimated position.

The estimated position can be calculated using the position (current position) of the shaft of the motor222and its operating speed. For example, the estimated position may be determined using Formula 1 below.
Estimated position=Current position+(current speed×correction coefficient)  (1)
The current position may be a value fed back by the servo driver220or may be a command value in a control command to the servo driver220. The current speed may be fed back by the servo driver220or may be calculated using a data row indicating current positions in past cycles. The correction coefficient is a predetermined value, and may be set in accordance with the combination of the types of the operation master device and the operation slave device. For example, the correction coefficient may be determined in association with the combination of the types of the operation master device and the operation slave device being a robot or a motor. Different correction coefficients may be used depending on whether the position fed back is used or the position indicated by the control command is used as the current position of the master device.

FIG.7is a table describing correction coefficients. The motion shaft or the shaft group corresponds to one or more motors, and is an example of a field device that operates in accordance with a program in an execution format in which the overall program is executed at every execution of the program. The robot is an example of a field device that operates in accordance with an intermediate code generated by the interpreter from at least a part of a program in an execution format in which parts of the program are executed successively. In the example inFIG.7, the number of delayed cycles is determined for each combination of the types of the operation master device and the operation slave device. Different values are also determined depending on whether the position fed back is used or the position indicated by the control command is used as the current position of the master device. For the robot, different numbers of delayed cycles may be determined further depending on an amplifier in the robot. Different numbers of delayed cycles may also be determined depending on whether the robot210is controlled in accordance with one of the IEC program51and the application program52that are in different execution formats. The correction coefficients determined in accordance with delayed cycles as shown inFIG.7can be used to correct a communication delay, thus allowing synchronous control of the field devices. For example, the correction coefficients may be predetermined to be greater for a greater number of delayed cycles.

Correction Process

FIG.8is a flowchart of an example correction process. To generate and transmit control commands to field devices that are to operate in coordination, the control device100performs the process shown inFIG.8. The estimator70first obtains the current position of the operation master device (S101inFIG.8). In this step, the current position may be a value fed back from the master device or may be a command value in a control command to the master device. For the master device being the robot, the current posture of the master device (combination of the positions of multiple motors included in the robot) may be obtained as the current position.

The estimator70then estimates a position expected to be reached by the master device (S102inFIG.8). In this step, the estimator70estimates a position expected to be reached by the master device at a time point at which the slave device performs the operation. The position expected to be reached can be calculated using Formula 1 above. In this step, the amount of correction may be changed depending on the combination of the types of the master device and the slave device, or on whether the current position of the master device is a value fed back from the master device or a value in a control command to the master device.

The motion processor32or the motion processor42determines, based on the estimated position expected to be reached, a command value for the slave device and transmits the value to the slave device (S103inFIG.8). In this step, the command value is determined to, for example, cause the slave device to operate using the position expected to be reached by the master device as a target. The slave device receives the control command containing the command value and operates in accordance with the command value.

The control device100determines whether to end the process (S104inFIG.8). In this step, the control device100determines, for example, whether the operations of the field devices in accordance with predetermined user programs have been performed. When the process is determined not to be ended (No in S104), the processing returns to S1to continue the process. When the process is determined to be ended (Yes in S104), the control device100ends the process.

As described above, in a system that performs periodic communication, the control device100can correct delays in communication and operation that occur when a field device receives a control command based on the current position and operates. In particular, the control device100can execute the application program52and the IEC program51in a synchronized manner, and thus can correct delays in an integrated manner for the operation master device and the operation slave device being, for example, a motor and a robot in different execution formats.

Although the embodiment has been described above, the control device described above is a mere example, and the control device according to one or more aspects of the present invention is not limited to the above structure. The components described in the embodiment may be modified or combined in any possible manner without departing from the spirit and the technical idea of the present invention.

A control device (100) for causing a plurality of field devices (210,220) to operate in coordination with one another in accordance with a predetermined program through a network (2) allowing periodic communication, the control device (100) comprising:an estimator (70) configured to calculate, based on a position of a first field device in a first cycle, a position of the first field device operable in accordance with a first program in a second cycle following the first cycle; anda processor (32,42) configured to determine, based on the first program, a first command value to cause the first field device to operate, to transmit the first command value to the first field device through an interface allowing communication with the plurality of field devices, to determine, based on the estimated position and a second program, a second command value to cause a second field device to operate in coordination with the first field device, and to transmit the second command value to the second field device through the interface (60).

REFERENCE SIGNS LIST