Patent Description:
Industrial control devices (hereinafter also referred to as "controllers") such as programmable logic controllers (PLCs) and robot controllers have been introduced to various production sites. The controllers control various types of industrial driving devices to thereby automate manufacturing processes.

The controller controls the driving device via a field network that performs fixed-cycle communication such as EtherCAT (registered trademark). Packet data is transmitted over this field network, and the controller and the driving device communicate with each other by reading data from and writing data to this packet data.

The packet data is saved in a buffer within the controller for abnormality analysis and the like. Since the buffer has a limited capacity, some of the packet data in the buffer is deleted when the buffer is overflown. For abnormality analysis, packet data immediately prior to the occurrence of abnormality is important. Regarding techniques for preventing such loss of packet data, Japanese Patent Laying-Open No. <CIT> (PTL <NUM>) discloses a controller intended to "enable an abnormality analysis to be easily and reliably performed in the FA system of the EtherCAT. " This controller stops a packet monitoring function upon occurrence of abnormality, to prevent the deletion of important packet data. A further prior art document is <CIT> which discloses a controller system. According to this document, in a controller system, constituted of plural controllers mutually connected through a transmission line, each controller is provided with a storing means for storing data to be processed by its own controller and the other controllers and a data writing and reading means for writing the data to be processed by its own controller in the storing means of its own controller and the other controllers, and reading the data written in the storing means from the storing means of its own controller and the other controllers.

A plurality of controllers may be connected to the same network. To conduct a more detailed analysis, not only packet data buffered in one controller but also packet data buffered in another controller may be needed. It is thus desired to prevent the loss of packet data for any appropriate one of controllers connected to the same network.

The present disclosure has been made to solve the above problem, and an object in one aspect thereof is to provide a technique capable of preventing the loss of packet data for any appropriate one of controllers connected to the same network. This object is achieved by the subject-matters of the independent claims. Further advantageous modifications and embodiments of the invention are the subject-matter of the dependent claims.

In one example, there are provided a plurality of controllers each of which controls a driving device to be controlled. The plurality of controllers each include: a buffer; a communication module for performing packet communication with one or more other controllers; a packet monitor module for buffering packet data generated in its own controller and packet data received by its own controller in the buffer; and a stop module for stopping, in response to a predetermined stop condition being satisfied, a buffering function of the packet monitor module for a controller specified from the plurality of controllers.

According to this example, each controller can stop not only the buffering function in its own controller, but also the buffering function in another controller. Thus, not only the loss of packet data buffered in its own controller, but also the loss of packet data buffered in the another controller can be prevented.

In one example, the stop module stops, in response to receiving a stop instruction to stop a buffering function from the one or more other controllers, a buffering function of the packet monitor module in its own controller.

According to this example, the stop module can stop the buffering function not only by transmitting the instruction to stop a buffering function to another controller, but also by receiving the stop instruction from the another controller.

In one example, the packet data has source information for identifying a source controller, and destination information for identifying a destination controller. The FA system further includes an external device configured to communicate with the plurality of controllers. The external device includes a communication module for receiving packet data stored in the buffer of each of the plurality of controllers from each of the plurality of controllers, and a display for displaying the source information and the destination information about each packet data received from each of the plurality of controllers.

According to this example, a record of packet data remains in both a source controller and a destination controller. Therefore, if a pair of records does not remain in controllers, it means that the packet data has been lost for some reason. The display of the source information and the destination information for each packet data allows a user to easily determine which packet data has been lost in which controller.

In one example, the display displays packet data having matching source information and matching destination information in a corresponding manner.

According to this example, the user can more easily find out which packet data has been lost in which controller.

In one example, the display displays packet data, in which a pair of packet data having matching source information and matching destination information does not exist, in a display mode different from other packet data.

According to this example, the user can immediately find out which packet data has been lost.

In one example, the plurality of controllers each include an interface unit for connecting an external storage device, and a save module for saving, in response to a predetermined save condition being satisfied, packet data stored in the buffer of the controller specified from the plurality of controllers in the external storage device connected to the specified controller.

According to this example, each controller can save the buffered packet data in the external storage device, to prevent the loss of the buffered packet data.

In one example, a controller that controls a driving device to be controlled includes: a buffer, a communication module for performing packet communication with one or more other controllers; a packet monitor module for buffering packet data generated in the controller and packet data received by the one or more other controllers in the buffer; and a stop module for stopping, in response to a predetermined stop condition being satisfied, a buffering function of the packet monitor module for the controller or a controller specified from the one or more other controllers.

In one example, a method of controlling a controller that controls a driving device to be controlled includes: performing packet communication with one or more other controllers; buffering packet data generated in the controller and packet data received by the one or more other controllers in a buffer of the controller; and stopping, in response to a predetermined stop condition being satisfied, the buffering for the controller or a controller specified from the one or more other controllers.

Embodiments according to the present invention will be described hereinafter with reference to the drawings. In the following description, like reference signs indicate like parts and components, and such parts and components have the same names and functions. Accordingly, detailed description thereof is not repeated.

An application of the present invention is described with reference to <FIG> shows an overview of an FA system <NUM>.

FA system <NUM> is a system for controlling an object, such as equipment and an apparatus, to automate a manufacturing process. FA system <NUM> includes a plurality of controllers. Two controllers 100A and 100B are shown in <FIG> as an example of the plurality of controllers. The plurality of controllers are hereinafter also collectively referred to as controller(s) <NUM>.

Controllers 100A and 100B may be connected to a same network N1. Network N1 employs EtherNet/IP (registered trademark), for example.

Controllers 100A and 100B each include a buffer <NUM>, a communication module <NUM>, a packet monitor module <NUM>, and a stop module <NUM>.

Buffer <NUM> is a volatile storage area in controller <NUM>, for example. In one example, buffer <NUM> is a storage area such as a random access memory (RAM) or a cache memory.

Communication module <NUM> is a functional module for implementing communication with another communication device by packet communication. The "another communication device" is a concept that includes any appropriate communication device excluding its own controller. For example, the another communication device includes another controller, a driving device <NUM> to be controlled by its own controller (see <FIG>), and an information processing terminal such as a server connected to a controller.

Packet monitor module <NUM> is a functional module for capturing transmitted and received packet data. More specifically, packet monitor module <NUM> sequentially buffers packet data generated in its own controller and packet data received by its own controller from another communication device in buffer <NUM>, for transmission to another communication device. Buffer <NUM> is limited in size, and packet monitor module <NUM> manages buffer <NUM> in a First In First Out (FIFO) mode or a Last In First Out (LIFO) mode.

The "packet data" is a concept that includes any appropriate communication data of a certain size transmitted via controller <NUM>. Examples of the packet data include communication data generated in accordance with a communication protocol of EtherNet/IP, communication data generated in accordance with a communication protocol of EtherNet (registered trademark), communication data generated in accordance with a communication protocol of EtherCAT, communication data generated in accordance with a communication protocol of CompoNet (registered trademark), and communication data generated in accordance with a communication protocol of Object Linking and Embedding for Process Control Unified Architecture (OPC-UA).

Stop module <NUM> is a functional module for stopping the function of buffering the packet data by packet monitor module <NUM>. More specifically, in response to a predetermined stop condition <NUM> being satisfied, stop module <NUM> stops the buffering function of packet monitor module <NUM> for a controller specified from controllers connected to network N1. Stop condition <NUM> is satisfied, for example, in response to the occurrence of an error in its own controller. Stop condition <NUM> will be described later in detail.

When its own controller is specified as a stop target, stop module <NUM> outputs a stop instruction to stop the buffering function to packet monitor module <NUM> of its own controller. In response to accepting the stop instruction, packet monitor module <NUM> stops the process of buffering the packet data.

In contrast, when another controller is specified as a stop target, stop module <NUM> generates an instruction to stop the buffering function, and transmits the stop instruction to the another controller via communication module <NUM>. The another controller that has received the stop instruction stops the function of buffering the packet data.

Since buffer <NUM> has a limited capacity, some of the packet data in buffer <NUM> is deleted when buffer <NUM> is overflown. FA system <NUM> according to the present embodiment can stop not only the buffering function in its own controller, but also the buffering function in another controller. Thus, not only the loss of packet data buffered in its own controller, but also the loss of packet data buffered in the another controller can be prevented.

An example apparatus configuration of FA system <NUM> is described with reference to <FIG> schematically shows the apparatus configuration of FA system <NUM>.

FA system <NUM> includes one or more controllers <NUM>, one or more development support devices <NUM>, and one or more driving devices <NUM>. In the example of <FIG>, three controllers 100A to 100C and one development support device <NUM> are illustrated.

Controller <NUM> has a plurality of physical communication ports. A different network may be connected to each communication port. In the example of <FIG>, controller <NUM> has two communication ports P1 and P2. Network N1 is connected to communication port P1. A network N2 is connected to communication port P2.

Controller <NUM> and development support device <NUM> are connected to network N1 via a hub <NUM>. Additionally, any appropriate information processing device may be connected to network N1. In one example, a display such as a human machine interface (HMI) or a server device may be connected to network N1.

Examples of development support device <NUM> include a notebook personal computer (PC), a desktop PC, a tablet terminal, and a smartphone. A development tool <NUM> may be installed in development support device <NUM>. Development tool <NUM> is an application for supporting the development of a control program for controller <NUM>. Examples of development tool <NUM> include "Sysmac Studio" manufactured by OMRON Corporation. A user can design a control program for controller <NUM> on development tool <NUM>, and install the designed control program in controller <NUM>. The created control program is transmitted to controller <NUM> as an executable file compiled by development support device <NUM>.

Lower-level network N2 preferably employs a field network that performs fixed-cycle communication, which guarantees a data arrival time. Known examples of such a field network that performs fixed-cycle communication include EtherCAT and CompoNet. Controller <NUM> controls driving device <NUM> to be controlled in accordance with the control program created on development support device <NUM>.

Driving device <NUM> is a collection of devices for directly or indirectly performing prescribed work on a workpiece. In the example of <FIG>, driving device <NUM> includes a robot controller 300A, a servo driver 300B, an arm robot 301A controlled by robot controller 300A, a servo motor 301B controlled by servo driver 300B, and the like. Driving device <NUM> may also include a vision sensor for taking an image of the workpiece, and any other device used in the manufacturing process.

FA system <NUM> typically has the following setting functions A to C.

(Function A) Function of accepting, by development support device <NUM>, various settings for packet monitor module <NUM> (see <FIG>).

(Function B) Function of switching, by each controller, operation modes of packet monitor modules <NUM> of its own controller and another controller in accordance with the settings accepted in the function (a).

(Function C) Function of collecting, by development support device <NUM>, packet data that has been buffered by packet monitor module <NUM> of each controller.

In a typical usage example, these functions A to C are sequentially executed. These functions A to C will be hereinafter described in order.

Function A of FA system <NUM> is initially described with reference to <FIG>. <FIG> is a sequence diagram showing a flow of a setting process for packet monitor module <NUM> (see <FIG>).

It is assumed that, in step S10, development support device <NUM> accepts operation of starting development tool <NUM>. In response, development support device <NUM> displays a program creation screen. <FIG> shows a program creation screen <NUM> which is an example user interface provided by development tool <NUM>. Program creation screen <NUM> is displayed on, for example, a display <NUM> of development support device <NUM>.

The user can develop a control program for controller <NUM> on program creation screen <NUM>. <FIG> shows a user program <NUM> which is an example control program for controller <NUM>. User program <NUM> may be written in any programming language. In one example, user program <NUM> may be defined in a ladder diagram (LD), or is defined in any of an instruction list (IL), a structured text (ST), and a sequential function chart (SFC), or a combination of them. Alternatively, user program <NUM> may be defined in a general-purpose programming language such as JavaScript (registered trademark) or C language.

In the example of <FIG>, user program <NUM> is written in a ladder diagram. A designer can design user program <NUM> suitable for driving device <NUM> to be controlled, by combining any appropriate function blocks or defining input-output relations of variables and function blocks on program creation screen <NUM>. The function block is a function that is repeatedly used in user program <NUM> and that has been made into a component.

In the example of <FIG>, user program <NUM> includes variables "A" to "C" and function blocks FB1, FB2. Function block FB1 executes, based on a value of the variable "A" associated with its input unit, a predetermined function defined in function block FB1. A result of the execution is reflected in the variable "B" associated with an output unit of function block FB1. Function block FB2 executes, based on a value of the variable "B" associated with its input unit, a predetermined function defined in function block FB2. A result of the execution is reflected in the variable "C" associated with an output unit of function block FB2. In this manner, the designer can design any appropriate user program <NUM> by combining the variables and function blocks on program creation screen <NUM>.

Development tool <NUM> provides various function blocks. In one example, above-described stop module <NUM> (see <FIG>) for stopping the function of buffering the packet data is provided as a function block. Additionally, a start module for starting execution of the function of buffering the packet data is provided as a function block. Additionally, a save module for saving the packet data buffered in buffer <NUM> in an external storage device (for example, a memory card) is provided as a function block.

Referring again to <FIG>, it is assumed that, in step S12, development tool <NUM> invokes a setting screen for making various settings for packet monitor module <NUM> (see <FIG>). In response, the setting screen is displayed on display <NUM> of development support device <NUM>.

<FIG> shows a setting screen <NUM> which is an example user interface provided by development tool <NUM>. Setting screen <NUM> is a user interface that accepts various settings for packet monitor module <NUM>.

As shown in <FIG>, setting screen <NUM> includes setting columns <NUM>, <NUM>, <NUM>, <NUM>, a save button <NUM>, and a cancel button <NUM>. The settings input to setting screen <NUM> set a condition for starting the process of buffering the packet data, a condition for stopping the process of buffering the packet data, a condition for saving the packet data, a condition for transferring the packet data, and the like.

More specifically, setting column <NUM> accepts a setting for specifying an operation mode of packet monitor module <NUM>. Examples of the specifiable operation mode include "start," "stop," "save" and "transfer. " In one example, the specifiable operation modes are listed in response to a button 41A being pressed. The user can select one operation mode from the displayed list of operation modes, to specify the operation mode of packet monitor module <NUM>.

Setting column <NUM> accepts a setting for specifying an execution condition. In setting column <NUM>, for example, an error type of an event log that may occur in controller <NUM>, an error type indicated by packet data, and the like may be specified. Candidates for the execution condition that can be specified in setting column <NUM> are typically defined in advance. For example, the candidates for the specifiable execution condition are listed in response to a button 42A being pressed. The user can select one execution condition from the displayed list of execution condition candidates, to specify the execution condition.

In the following, an execution condition with "start" specified in setting column <NUM> is also referred to as a "start condition. " An execution condition with "stop" specified in setting column <NUM> is also referred to as a "stop condition. " An execution condition with "save" specified in setting column <NUM> is also referred to as a "save condition. " An execution condition with "transfer" specified in setting column <NUM> is also referred to as a "transfer condition.

Setting column <NUM> accepts a setting for specifying a controller for which the instruction is intended. The controller for which the instruction is intended may be selected from among predetermined candidates, or may be specified by input of identification information (for example, a controller name or an IP address) on the controller. In one example, candidates for the controller that can be specified as the controller for which the instruction is intended are listed in response to a button 45A being pressed. The user can select one controller from the displayed list of controller candidates, to specify the controller for which the instruction is intended.

In response to the execution condition specified in setting column <NUM> being satisfied, controller <NUM> causes packet monitor module <NUM> of the controller specified in setting column <NUM> to operate in the operation mode specified in setting column <NUM>.

In one example, when the start condition is satisfied, controller <NUM> causes the controller for which the instruction is intended and which is associated with the start condition to start executing packet monitor module <NUM>.

When the stop condition is satisfied, controller <NUM> causes the controller for which the instruction is intended and which is associated with the stop condition to stop packet monitor module <NUM>. The stop condition corresponds to above-described stop condition <NUM> (see <FIG>).

When the save condition is satisfied, controller <NUM> causes the controller for which the instruction is intended and which is associated with the save condition to save the buffered packet data in its own controller.

When the transfer condition is satisfied, controller <NUM> causes the controller for which the instruction is intended and which is associated with the transfer condition to transfer the buffered packet data to a specified destination.

Setting column <NUM> accepts a setting for specifying ON/OFF of a notification function. When ON is specified in setting column <NUM>, a notification of the occurrence of an error is provided when the execution condition specified in setting column <NUM> is satisfied. The notification of the occurrence of an error may be provided by sound such as an alarm, or by a displayed message and the like. When OFF is specified in setting column <NUM>, a notification of the occurrence of an error is not provided even when the execution condition specified in setting column <NUM> is satisfied.

When save button <NUM> is pressed, development support device <NUM> saves setting information <NUM> that has been input to setting screen <NUM>. When cancel button <NUM> on setting screen <NUM> is pressed, development support device <NUM> closes setting screen <NUM> without saving setting information <NUM> that has been input to setting screen <NUM>.

Referring again to <FIG>, it is assumed that, in step S14, development tool <NUM> accepts compiling operation. In response, development tool <NUM> compiles user program <NUM> created on program creation screen <NUM>. It is assumed that development tool <NUM> then accepts operation of downloading a result of the compilation. In response, development tool <NUM> transfers setting information <NUM> stored in step S12 together with compiled user program <NUM> to controller <NUM>. Controller <NUM> saves received user program <NUM> and setting information <NUM> in an internal storage device.

An example of function B of FA system <NUM> is now described with reference to <FIG> and <FIG>. <FIG> is a sequence diagram showing a flow of data among controllers 100A to 100C when stop condition <NUM> is satisfied. <FIG> is a conceptual diagram schematically showing operation modes of controllers 100A to 100C when stop condition <NUM> is satisfied.

Step numbers shown in <FIG> correspond to step numbers shown in <FIG>.

It is assumed that, in step S30A, controller 100A is started. In response, controller 100A starts executing the packet monitoring function of packet monitor module <NUM>.

It is assumed that, in step S30B, controller 100B is started. In response, controller 100B starts executing the packet monitoring function of packet monitor module <NUM>.

It is assumed that, in step S30C, controller 100C is started. In response, controller 100C starts executing the packet monitoring function of packet monitor module <NUM>.

It is assumed that, in step S31A, controller 100A accepts an instruction to execute user program <NUM> stored in its own controller. In response, controller 100A starts executing user program <NUM>.

It is assumed that, in step S31B, controller 100B accepts an instruction to execute user program <NUM> stored in its own controller. In response, controller 100B starts executing user program <NUM>.

It is assumed that, in step S31C, controller 100C accepts an instruction to execute user program <NUM> stored in its own controller. In response, controller 100C starts executing user program <NUM>.

In step S32, controller 100A determines whether or not any of the execution conditions defined in setting information <NUM> has been satisfied. It is assumed, for example, that the stop condition which is an example of the execution conditions has been satisfied. In this case (YES in step S32), controller 100A switches control to step S34. When it is determined that none of the execution conditions defined in setting information <NUM> has been satisfied (NO in step S32), controller 100A executes the process of step S32 again.

In one example, it is assumed that controllers 100A to 100C have been specified as controllers for which the instruction is intended. In this case, controller 100A stops the process of buffering the packet data in its own controller, and the process of buffering the packet data in other controllers 100B and 100C.

More specifically, in step S34, stop module <NUM> of controller 100A stops the buffering function of packet monitor module <NUM> in its own controller. Accumulation of the packet data in buffer <NUM> of controller 100A is thus stopped.

In step S36, stop module <NUM> of controller 100A generates an instruction to stop the buffering function, and transmits the stop instruction to other controllers 100B and 100C. In response to receiving the stop instruction from controller 100A, stop module <NUM> of controller 100B stops the buffering function of packet monitor module <NUM> of controller 100B. Accumulation of the packet data in buffer <NUM> of controller 100B is thus stopped. Likewise, in response to receiving the stop instruction from controller 100A, stop module <NUM> of controller 100C stops the buffering function of packet monitor module <NUM> of controller 100C. Accumulation of the packet data in buffer <NUM> of controller 100C is thus stopped.

In this manner, controller <NUM> has the function of stopping the buffering functions of its own controller and the other controllers in response to the predetermined stop condition being satisfied. Preferably, the buffering functions of its own controller and the other controllers are simultaneously or substantially simultaneously stopped. Thus, each controller can leave in buffer <NUM> packet data buffered in the same period of time.

Function C of FA system <NUM> is now described with reference to <FIG>. <FIG> is a sequence diagram showing a flow of a process of collecting the buffered packet data from each controller.

It is assumed that, in step S50, development support device <NUM> accepts operation of displaying an event log screen. In response, development support device <NUM> displays the event log screen. <FIG> shows an event log screen <NUM> which is an example user interface provided by development tool <NUM>. Event log screen <NUM> is displayed on, for example, display <NUM> of development support device <NUM>.

Development support device <NUM> displays event logs collected from each controller <NUM> on event log screen <NUM>. Event log screen <NUM> has display columns <NUM> to <NUM>. Display column <NUM> displays the importance of an occurring error. Display column <NUM> displays a communication protocol in which the error has occurred. Display column <NUM> displays a communication port where the error originated. Display column <NUM> displays an event name. Display column <NUM> displays an event code. Display column <NUM> displays a details button.

Referring again to <FIG>, in step S52, in response to one of the details buttons displayed in display column <NUM> being pressed, development support device <NUM> displays a confirmation screen for accepting a determination of whether or not to start the packet collection. <FIG> shows an example confirmation screen.

<FIG> shows a confirmation screen <NUM> as an example confirmation screen. Confirmation screen <NUM> has a button <NUM> indicating "YES" and a button <NUM> indicating "NO". When button <NUM> indicating "YES" is pressed, development support device <NUM> starts collecting the packet data in each controller <NUM>. When button <NUM> indicating "NO" is pressed, development support device <NUM> simply closes confirmation screen <NUM>.

Referring again to <FIG>, in step S60, in response to button <NUM> indicating "YES" on confirmation screen <NUM> being pressed, development support device <NUM> transmits a request to acquire packet data to each of specified controllers 100A to 100C.

In step S62, controllers 100A to 100C each acquire the packet data stored in buffer <NUM> (see <FIG>) of its own controller, and transmit the packet data to development support device <NUM>.

In step S70, development support device <NUM> displays a result of the collection of the packet data collected from each of controllers 100A to 100C. <FIG> shows a packet data collection result screen 37A which is an example user interface provided by development tool <NUM>.

Packet data in accordance with EtherCAT, EtherNET, EtherNet/IP and the like includes an EtherNet header. This EtherNet header includes source information (for example, an IP address) for identifying a source controller, and destination information (for example, an IP address) for identifying a destination controller. Additionally, the packet data includes information such as a destination port number.

Based on the information defined in the packet data, collection result screen 37A displays the source IP address and the destination IP address for each collected packet data. A record of packet data remains in both a source controller and a destination controller. Therefore, if a pair of records does not remain in controllers, it means that the packet data has been lost for some reason. The display of the source IP address and the destination IP address for each packet data allows the user to easily determine which packet data has been lost in which controller, thereby facilitating analysis of a communication error.

Preferably, collection result screen 37A displays packet data having matching source information and matching destination information in a corresponding manner. In the example of <FIG>, these packet data pieces are displayed in a row. For example, as indicated in a broken line portion <NUM>, a record of packet data transmitted from controller 100A having an IP address of "A" to controller 100B having an IP address of "B" remains in both controller 100A and controller 100B. Development support device <NUM> displays these corresponding packet data pieces collected from controller 100A and controller 100B side by side. This allows the user to more easily find out which packet data has been lost in which controller, thereby further facilitating the analysis of a communication error.

Preferably, collection result screen 37A displays packet data, in which a pair of packet data having matching source information and matching destination information does not exist, in a display mode different from other packet data. That is, packet data in which a pair of packet data does not exist is highlighted. The highlighting is implemented by, for example, hatched display, display with a particular color (for example, red), or blinked display. In the example of <FIG>, the highlighting is implemented by hatched display (broken line portions <NUM> and <NUM>). The highlighting of the packet data in which a pair of packet data does not exist allows the user to immediately find out which packet data has been lost.

Packet data collection result screen 37A is not limited to the example of <FIG>. <FIG> shows a collection result screen 37B, which is a variation of collection result screen 37A. As shown in <FIG>, collection result screen 37B has a search condition input area <NUM> and a search result display area <NUM>.

Search condition input area <NUM> accepts various conditions for searching for packet data. In one example, input area <NUM> accepts identification information on a controller as the search condition. The search condition that can be specified in input area <NUM> is not limited to the identification information on a controller. In one example, a communication protocol, a port number or the like may be input as the search condition.

In response to the search condition being input to input area <NUM>, development support device <NUM> searches the collected packet data for packet data that matches the specified search condition, and lists the packet data that matches the specified search condition in search result display area <NUM>. As a search result, for example, an IP address of a source controller, an IP address of a destination controller, a communication protocol that was used for communication, a destination port number, and remarks are displayed.

A saving function of saving the buffered packet data is described with reference to <FIG> is a sequence diagram showing a control flow when the function of saving the packet data is executed.

In step S80, controller 100A determines whether or not the save condition defined in setting information <NUM> (see <FIG>) has been satisfied. When it is determined that the save condition defined in setting information <NUM> has been satisfied (YES in step S80), controller 100A switches control to step S82. Otherwise (NO in step S80), controller 100A executes the process of step S80 again.

Controllers for which the instruction is intended are associated with the save condition defined in setting information <NUM>. In one example, it is assumed that controllers 100A to 100C are associated, as controllers for which the instruction is intended, with the save condition. In this case, controller 100A executes a process of saving the packet data buffered in its own controller, and a process of saving the packet data buffered in other controllers 100B and 100C.

More specifically, in step S82, controller 100A saves the packet data buffered in buffer <NUM> of its own controller in an external storage device (for example, a memory card <NUM> described later). Thus, the packet data in controller 100A is saved as log data.

In step S84, controller 100A generates an instruction to save the packet data, and transmits the save instruction to other controllers 100B and 100C. In response to receiving the save instruction from controller 100A, controller 100B saves the packet data buffered in buffer <NUM> of controller 100B in the external storage device (for example, memory card <NUM> described later). Thus, the packet data in controller 100B is saved in the external storage device. Likewise, in response to receiving the save instruction from controller 100A, controller 100C saves the packet data buffered in buffer <NUM> of controller 100C in the external storage device (for example, memory card <NUM> described later). Thus, the packet data in controller 100C is saved in the external storage device.

A starting function of causing packet monitor module <NUM> to start the buffering process is described with reference to <FIG> is a sequence diagram showing a control flow when the function of starting the buffering process by packet monitor module <NUM> is executed.

In step S90, controller 100A determines whether or not the start condition defined in setting information <NUM> (see <FIG>) has been satisfied. When it is determined that the start condition defined in setting information <NUM> has been satisfied (YES in step S90), controller 100A switches control to step S92. Otherwise (NO in step S90), controller 100A executes the process of step S90 again.

Controllers for which the instruction is intended are associated with the start condition defined in setting information <NUM>. In one example, it is assumed that controllers 100A to 100C are associated, as controllers for which the instruction is intended, with the start condition. In this case, controller 100A starts a process of buffering the packet data in its own controller, and a process of buffering the packet data in other controllers 100B and 100C.

More specifically, in step S92, controller 100A causes packet monitor module <NUM> of its own controller to start the buffering function. Thus, the process of buffering the packet data in buffer <NUM> of its own controller is started.

In step S94, controller 100A generates an instruction to start the buffering function, and transmits the start instruction to other controllers 100B and 100C. In response to receiving the start instruction from controller 100A, controller 100B causes packet monitor module <NUM> of controller 100B to start the buffering function. Accumulation of the packet data in buffer <NUM> of controller 100B is thus started. Likewise, in response to receiving the start instruction from controller 100A, controller 100C causes packet monitor module <NUM> of controller 100C to start the buffering function. Accumulation of the packet data in buffer <NUM> of controller 100C is thus started.

In this manner, controller <NUM> has the function of starting the buffering functions of its own controller and the other controllers in response to the predetermined start condition being satisfied. Preferably, the buffering functions of its own controller and the other controllers are simultaneously or substantially simultaneously started.

Hardware configurations of controller <NUM> and development support device <NUM> are described in order with reference to <FIG> and <FIG>.

The hardware configuration of controller <NUM> is initially described with reference to <FIG> is a schematic diagram showing an example hardware configuration of controller <NUM>.

Controller <NUM> includes a communication interface <NUM>, a control device <NUM> such as a central processing unit (CPU) or a micro-processing unit (MPU), a chip set <NUM>, a main memory <NUM>, a nonvolatile storage device <NUM>, an internal bus controller <NUM>, a fieldbus controller <NUM>, and a memory card interface <NUM>.

Control device <NUM> reads a control program <NUM> stored in storage device <NUM>, and executes control program <NUM> by deploying it to main memory <NUM>, thereby implementing any appropriate control on driving device <NUM> to be controlled and the like. Control program <NUM> includes various programs for controlling controller <NUM>. In one example, control program <NUM> includes a system program <NUM>, user program <NUM>, and the like. System program <NUM> includes an instruction code for providing basic functions of controller <NUM>, such as data I/O processing and execution timing control. User program <NUM> is downloaded from development support device <NUM>. User program <NUM> is appropriately designed depending on the control target, and includes a sequence program 210A for performing sequence control and a motion program 210B for performing motion control.

Chip set <NUM> controls each component to implement the process as the entire controller <NUM>.

Storage device <NUM> stores various types of data in addition to control program <NUM>. In one example, storage device <NUM> stores above-described setting information <NUM> (see <FIG>) and the like.

Internal bus controller <NUM> is an interface that exchanges data with various devices coupled to controller <NUM> through an internal bus. As an example of such devices, an I/O unit <NUM> is connected.

Fieldbus controller <NUM> is an interface that exchanges data with various driving devices <NUM> coupled to controller <NUM> through a fieldbus. As an example of such devices, robot controller 300A and servo driver 300B are connected. Additionally, a driving device such as a vision sensor may be connected.

Internal bus controller <NUM> and fieldbus controller <NUM> can provide any appropriate command to the device connected thereto, and also acquire any appropriate data managed by the device. Internal bus controller <NUM> and/or fieldbus controller <NUM> also function(s) as an interface for exchanging data with robot controller 300A or servo driver 300B.

Communication interface <NUM> controls data exchange through various wired/wireless networks. Controller <NUM> communicates with an external device such as development support device <NUM> via communication interface <NUM>. Controller <NUM> performs packet communication with another communication device via communication interface <NUM>.

Memory card interface <NUM> is an interface unit for connecting memory card <NUM> (for example, an SD card) which is an example external storage medium. Memory card interface <NUM> is configured such that memory card <NUM> can be inserted therein and removed therefrom, and can write data to and read data from memory card <NUM>.

The hardware configuration of development support device <NUM> is now described with reference to <FIG> is a schematic diagram showing the hardware configuration of development support device <NUM>.

In one example, development support device <NUM> is a computer configured in accordance with a general-purpose computer architecture. Development support device <NUM> includes a control device <NUM> such as a CPU or an MPU, a main memory <NUM>, a nonvolatile storage device <NUM>, a communication interface <NUM>, an input/output (I/O) interface <NUM>, and a display interface <NUM>. These components are connected to communicate with one another via an internal bus <NUM>.

Control device <NUM> executes a development support program 208A stored in storage device <NUM> by deploying it to main memory <NUM>, thereby implementing various types of control in development tool <NUM>. Development support program 208A is a program for providing a development environment of user program <NUM>. Storage device <NUM> stores, in addition to development support program 208A, various types of data and the like generated with development tool <NUM>. Examples of the data include above-described user program <NUM> created on development tool <NUM>, and above-described setting information <NUM>.

Communication interface <NUM> exchanges data with another communication device via a network. Examples of the another communication device include controller <NUM>, and an external device such as a server. Development support device <NUM> may be configured to download various programs such as development support program 208A from the another communication device via communication interface <NUM>.

I/O interface <NUM> is connected to operation unit <NUM>, and captures a signal indicating user operation from operation unit <NUM>. Operation unit <NUM> is typically a keyboard, a mouse, a touch panel, a touch pad or the like, and accepts operation from the user.

Display interface <NUM> is connected to display <NUM>, and transmits an image signal for displaying an image to display <NUM> in accordance with a command from control device <NUM> and the like. Display <NUM> is a liquid crystal display (LCD), an organic electro luminescence (EL) display or the like, and presents various types of information to the user. On display <NUM>, various types of screens provided by development tool <NUM> (for example, above-described program creation screen <NUM> and setting screen <NUM>) may be displayed. While development support device <NUM> and display <NUM> are shown as separated from each other in the example of <FIG>, development support device <NUM> and display <NUM> may be integrally configured.

Functions of controller <NUM> and development support device <NUM> are described with reference to <FIG> shows an example functional configuration of controller <NUM> and development support device <NUM>.

As shown in <FIG>, controllers 100A and 100B each include, as a functional configuration, a communication instruction execution module <NUM>, communication module <NUM>, a communication driver <NUM>, and packet monitor module <NUM>. These functional modules are implemented in system program <NUM> (see <FIG>), for example. Communication module <NUM> includes a client function 152A and a server function 152B.

User program <NUM> is installed in controllers 100A and 100B on development support device <NUM>. User program <NUM> includes, for example, as one function thereof, stop module <NUM> for stopping the process of buffering the packet data by packet monitor module <NUM>, a start module <NUM> for starting the process of buffering the packet data by packet monitor module <NUM>, and a save module <NUM> for saving the buffered packet data in the external storage device. The functional modules of controller <NUM> are typically executed by control device <NUM> (see <FIG>).

Since the functions of communication module <NUM>, packet monitor module <NUM> and stop module <NUM> are as described above, description of these functions is not repeated.

Communication instruction execution module <NUM> is a functional module for controlling communication module <NUM>. In one example, in response to accepting an instruction to stop the buffering from stop module <NUM>, communication instruction execution module <NUM> generates a CIP parameter for generating a CIP message, and outputs the CIP parameter to client function 152A. The CIP parameter will be described later in detail.

Communication driver <NUM> is software for communication interface <NUM> (see <FIG>). Communication driver <NUM> is provided by a manufacturer depending on the type of communication interface <NUM>, and may be installed in advance or as needed. Controller <NUM> implements the communication with another controller and development support device <NUM> via communication driver <NUM>.

In response to accepting the stop instruction, for example, server function 152B stops packet monitor module <NUM> of its own controller. The stop instruction may be voluntarily issued from its own controller, or may be issued from another controller or development support device <NUM>.

An example where the stop instruction is issued from development support device <NUM> is described. The user confirms that an error has occurred in one of controllers <NUM> on development support device <NUM>, and selects controller <NUM> in which the buffering function is to be stopped on development support device <NUM>. In response, development support device <NUM> transmits an instruction to stop the buffering function to controller 100A, which is specified controller <NUM>.

Development support device <NUM> has a communication module <NUM> and a communication driver <NUM> as functional modules. Communication module <NUM> includes a client function 252A. The functional modules of development support device <NUM> are typically executed by control device <NUM> (see <FIG>).

Communication driver <NUM> is software for communication interface <NUM> (see <FIG>). Communication driver <NUM> is provided by a manufacturer depending on the type of communication interface <NUM>, and may be installed in advance or as needed. Development support device <NUM> implements the communication with controller <NUM> via communication driver <NUM>.

As described above, communication module <NUM> generates, based on a CIP parameter, a CIP message that defines a control command for packet monitor module <NUM>. Specific examples of the CIP parameter will now be described with reference to <FIG>.

<FIG> shows CIP parameters for making settings for packet monitor module <NUM>.

In one example, the CIP parameters include a service code with regard to the setting of enabling/disabling of packet monitor module <NUM>. For example, when "0x4E" is input as the service code, a current set value indicating enabling/disabling of packet monitor module <NUM> is acquired. When "0x4F" is input as the service code, enabling/disabling of packet monitor module <NUM> is set in accordance with input.

Additionally, the CIP parameters include a service code with regard to various settings for packet monitor module <NUM>. For example, when "0x50" is input as the service code, various current settings for packet monitor module <NUM> are acquired. When "0x51" is input as the service code, various settings for packet monitor module <NUM> are set in accordance with input.

<FIG> shows CIP parameters for specifying an instruction to execute packet monitor module <NUM>.

In one example, the CIP parameters include a service code for starting the packet monitoring process of packet monitor module <NUM> (that is, the process of buffering the packet data). For example, when "0x4B" is input as the service code, the packet monitoring process by packet monitor module <NUM> is started.

Additionally, the CIP parameters include a service code for stopping the packet monitoring process of packet monitor module <NUM>. For example, when "0x4C" is input as the service code, the packet monitoring process by packet monitor module <NUM> is stopped.

Additionally, the CIP parameters include a CIP parameter for saving the packet data buffered by packet monitor module <NUM> in the external storage device. For example, when "0x4D" is input as the service code, the buffered packet data is saved in the external storage device.

<FIG> shows a CIP parameter for acquiring a current state of packet monitor module <NUM>.

In one example, the CIP parameter includes a service code for acquiring the current state of packet monitor module <NUM>. For example, when "0x52" is input as the service code, the current state of packet monitor module <NUM> is acquired. Examples of the state of packet monitor module <NUM> include a state in which the packet monitoring is set to disabled, a state indicating that the packet monitoring is being stopped, and a state indicating that the packet monitoring is being executed.

As described above, in response to the predetermined stop condition being satisfied, controller <NUM> stops the buffering function of packet monitor module <NUM> for the specified controllers. That is, controller <NUM> can stop not only the buffering function in its own controller, but also the buffering function in another controller. Thus, not only the loss of packet data buffered in its own controller, but also the loss of packet data buffered in the another controller can be prevented.

It should be understood that the embodiments disclosed herein are illustrative and non-restrictive in every respect. The scope of the present invention is defined by the claims.

Claim 1:
A factory automation, FA, system comprising a plurality of controllers (100A to 100C) each of which is configured to control a driving device to be controlled, each of the plurality of controllers (100A to 100C) including:
a buffer (<NUM>);
a communication module (<NUM>) configured to perform packet communication with one or more other controllers;
a packet monitor module (<NUM>) configured to buffer packet data generated in its own controller and packet data received by its own controller in the buffer (<NUM>); and
a stop module (<NUM>) configured to stop, in response to a predetermined stop condition (<NUM>) being satisfied, a buffering function of the packet monitor module (<NUM>) for a controller specified from the plurality of controllers (100A to 100C), characterised in that,
the packet data has source information for identifying a source controller, and destination information for identifying a destination controller, and
the FA system further comprises an external device (<NUM>) configured to communicate with the plurality of controllers (100A to 100C), the external device (<NUM>) including
a communication module (<NUM>) configured to receive packet data stored in the buffer (<NUM>) of each of the plurality of controllers (100A to 100C) from each of the plurality of controllers (100A to 100C), and
a display (<NUM>) configured to display the source information and the destination information about each packet data received from each of the plurality of controllers (100A to 100C), wherein
the display (<NUM>) is configured to display packet data having matching source information and matching destination information in a corresponding manner.