Patent Description:
In various production sites, factory automation (FA) systems for automating production processes have been widely used. The FA systems include various industrial drive devices. The industrial drive devices include, for example, a moving table for moving a workpiece, a conveyor for conveying the workpiece, and an arm robot for moving the workpiece to a predetermined destination. Those drive devices are controlled by an industrial controller such as a programmable logic controller (PLC) or a robot controller.

The controller controls various drive devices in accordance with a program designed in advance by a designer (hereinafter, also referred to as "user program"). There is an application for assisting in developing such a user program (hereinafter, also referred to as "development tool"). By writing a program on the development tool, the designer can develop an arbitrary user program suitable for a drive device to be controlled.

Regarding the development tool of user programs, <CIT> (PTL <NUM>) discloses a development assistance device for "allowing even a programmer who does not know or is unfamiliar to a concept of a namespace to easily create a user program by using "word" grouping by a namespace method, without being conscious of the concept of the namespace in particular".

Moreover, <CIT> discloses a control system according to the preamble of claim <NUM>.

Further prior art documents are <CIT> and <CIT>.

In recent years, controllers connectable to a plurality of networks have been widely used. An external device communicatively connected to a controller can monitor a state of the controller and a state of a drive device to be controlled by accessing variables included in a user program during execution of the user program.

It is necessary to set in advance a variable to be published to the external device (hereinafter, also referred to as "public variable") and a variable not to be published to the external device (hereinafter, also referred to as "private variable") for security. However, because an enormous number of variables are included in the user program, it is extremely troublesome to specify each variable as a public variable or private variable.

The present invention has been made in order to solve the above problem, and an object in one aspect is to provide a technology for performing a publishing setting of a variable to an external device more easily. This object is solved by the subject-matter of independent claim <NUM>. Preferred embodiments are subject-matters of the dependent claims. The invention is as defined in the claims, wherein aspects of the invention are set out below.

According to an aspect of the invention, a control system includes a development assistance device and a controller configured to communicate with the development assistance device. A development tool configured to develop a user program for controlling the controller is installable in the development assistance device. At least one variable included in the user program belongs to a predetermined namespace. The development tool is configured to accept, for the namespace, a publishing setting for determining whether to publish the variable belonging to the namespace to an external device that is communicatively connected to the controller.

The controller includes a program execution unit configured to control a drive device to be controlled in accordance with the user program received from the development assistance device, and update the variable belonging to the namespace in accordance with an execution result of the user program, and a publishing setting unit configured to publish the variable belonging to the namespace to the external device in a case where the publishing setting received from the development assistance device indicates "publish".

According to this aspect of the invention, the publishing setting of the variable to the external device is performed for each namespace included in the user program, and whether to publish each variable is determined on the basis of the publishing setting set for the namespace. This eliminates the need for the designer to individually set each variable as a public variable. As a result, the publishing setting of the variable to the external device becomes easier.

In a further aspect of the present invention, the publishing setting is configured to be set for each variable belonging to the namespace. The publishing setting for the namespace is reflected as an initial value in the publishing setting for the variable.

According to this aspect of the invention, the publishing setting set for the namespace is reflected as the initial value in the publishing setting of each variable, and thus the designer can save time and labor for performing the publishing setting of each variable. Further, the designer can individually change the publishing setting of each variable. As a result, the designer can not only reduce time for performing the publishing setting of each variable, but also flexibly set publish/not publish" of each variable in accordance with individual circumstances.

According to a further aspect of the invention, the publishing setting unit determines whether to publish the variable belonging to the namespace to the external device by prioritizing the publishing setting for the variable over the publishing setting for the namespace.

According to this aspect of the invention, the publishing setting individually set for each variable is more likely to reflect intention of the designer than the publishing setting set for the namespace. Thus, the intention of the designer is reflected more reliably by prioritizing the publishing setting for the variable over the publishing setting for the namespace.

According to a further aspect of the invention, the publishing setting further includes a communication setting indicating a communication protocol. In a case where the controller and the external device communicate with each other by using the communication protocol indicated by the communication setting, the publishing setting unit publishes the variable belonging to the namespace to the external device.

According to this aspect of the invention, the controller can divide variables into public and private variables in accordance with the communication protocol.

According to a further aspect of the invention, the development assistance device further includes a volatile storage device and a nonvolatile storage device. The publishing setting includes a holding setting indicating whether to hold the variable belonging to the namespace. The publishing setting unit stores the variable belonging to the namespace in the nonvolatile storage device in a case where the holding setting indicates "hold", and stores the variable belonging to the namespace in the volatile storage device in a case where the holding setting indicates "not hold".

According to this aspect of the invention, the controller can properly use the variable to be held in the volatile storage device and the variable to be held in the nonvolatile storage device in accordance with a usage mode.

According to a further aspect of the invention, a development assistance device configured to communicate with a controller configured to control a drive device to be controlled in response to a control command specified in a user program includes: a communication interface configured to communicate with the controller; and a storage device configured to store a development program for providing a development tool configured to develop the user program. At least one variable included in the user program belongs to a predetermined namespace. The development tool is configured to accept, for the namespace, a publishing setting for causing the controller to determine whether to publish the variable belonging to the namespace to an external device that is communicatively connected to the controller. The communication interface transfers the user program and the publishing setting to the controller on the basis of acceptance of transfer operation of the user program by the development tool.

According to a further aspect of the invention, a development assistance program executed by a development assistance device configured to communicate with a controller configured to control a drive device to be controlled in response to a control command specified in a user program causes the development assistance device to execute starting a development tool configured to develop the user program. At least one variable included in the user program belongs to a predetermined namespace. The development assistance program causes the development assistance device to further execute accepting, for the namespace, a publishing setting for causing the controller to determine whether to publish the variable belonging to the namespace to an external device that is communicatively connected to the controller, and transferring the user program and the publishing setting to the controller on the basis of acceptance of transfer operation of the user program by the development tool.

In a certain aspect, a publishing setting of a variable to an external device can be performed more easily.

In the following description, the same parts and components will be denoted by the same reference signs. Names and functions thereof are also the same. Therefore, detailed description thereof will not be repeated.

Referring to <FIG>, an application example of the present invention will be described. <FIG> shows a configuration example of a control system <NUM>.

Control system <NUM> is an FA system for automating production processes. In the example of <FIG>, control system <NUM> includes one or more development assistance devices <NUM>, one or more controllers <NUM>, one or more drive devices <NUM>, and one or more external devices <NUM>.

Development assistance device <NUM>, controller <NUM>, and external device <NUM> are connected to a network NW1. For network NW1, EtherNET (registered trademark), object linking and embedding for process control unified architecture (OPC-UA), or the like is adopted. The OPC-UA is a communication standard defined for implementing data exchange, without depending on the type of a vendor, operating system (OS), or the like. By using controller <NUM> compatible with the OPC-UA, external device <NUM> can easily access data (variables) managed in controller <NUM>.

Development assistance device <NUM> is, for example, a laptop or desktop personal computer (PC), a tablet terminal, a smartphone, or another information processing device capable of developing a control program for controller <NUM>. External device <NUM> is, for example, a human machine interface (HMI), a laptop or desktop PC, a server, a tablet terminal, a smartphone, or another display device.

Controller <NUM> and drive device <NUM> are connected to a network NW2. For network NW2, it is preferable to adopt a field network that performs cyclic communication and guarantees data arrival time. As the field networks that perform such cyclic communication, there are known EtherCAT (registered trademark), EtherNet/IP (registered trademark), CompoNet (registered trademark), and the like.

Drive device <NUM> includes various industrial devices for automating production processes. Examples of drive device <NUM> encompass a robot controller 300A, a servo driver 300B, an arm robot 301A controlled by robot controller 300A, and a servomotor 301B controlled by servo driver 300B. Drive device <NUM> may also include a visual sensor for capturing an image of a workpiece, another device for use in the production processes, and the like.

A development tool <NUM> is installable in development assistance device <NUM>. Development tool <NUM> is an application for assisting in developing a control program for controller <NUM>. Examples of development tool <NUM> encompass "Sysmac Studio" manufactured by OMRON Corporation. A designer can design a control program for controller <NUM> on development tool <NUM> and install the designed control program as a user program <NUM> in controller <NUM>. User program <NUM> is typically transmitted to controller <NUM> as an executable file compiled by development assistance device <NUM>.

The designer can specify an arbitrary namespace or variable for user program <NUM> on development tool <NUM>. At least one variable included in user program <NUM> belongs to a predetermined namespace.

The "variable" is an identifier given to data used in a source code of user program <NUM>. The "variable" is typically data showing a state of controller <NUM> or drive device <NUM>. In other words, the "variable" refers to data whose value changes in accordance with a state of each configuration of controller <NUM> or drive device <NUM>. The "variable" may include data indicating a value, data represented as an array, data represented as a structure, and various pieces of data that can be specified in user program <NUM>.

The "namespace" is an abstraction for determining a scope of a set of variables. That is, the "namespace" includes one or more variables. The designer defines variables on the namespace defined by himself/herself. Variables having the same name defined in different namespaces are regarded as different variables. This reduces a possibility of collisions between variable names.

In this embodiment, development tool <NUM> of user program <NUM> is configured to set, for the namespace, a publishing setting (attribute) for causing controller <NUM> to determine whether to publish variables included in user program <NUM> to external device <NUM>. That is, development tool <NUM> is configured to collectively set, for each namespace specified in user program <NUM>, whether to publish variables belonging to the namespace. The term "publish" means to make variables accessible from external device <NUM>. Meanwhile, the term "not publish" or "make private" means to make variables inaccessible from external device <NUM>.

The set publishing setting is downloaded to controller <NUM> together with user program <NUM> as publishing setting information <NUM>. User program <NUM> and publishing setting information <NUM> are downloaded to controller <NUM> as different pieces of data in the example of <FIG>, but may be downloaded as integrated data.

Controller <NUM> includes a control device <NUM> and a storage device <NUM>.

Control device <NUM> includes a publishing setting unit <NUM> and a program execution unit <NUM> as functional configurations. Storage device <NUM> stores user program <NUM> and publishing setting information <NUM> downloaded from development assistance device <NUM>.

Program execution unit <NUM> starts executing user program <NUM> on the basis of acceptance of a command to start executing user program <NUM>. Thereafter, program execution unit <NUM> controls drive device <NUM> in response to a control command specified in user program <NUM>. At this time, program execution unit <NUM> sequentially updates values of variables in accordance with an execution result of user program <NUM>.

Publishing setting unit <NUM> sets publishing or not publishing of each variable on the basis of publishing setting information <NUM> received from development assistance device <NUM>. As described above, publishing setting information <NUM> specifies, for each namespace, a publishing setting for determining publish/not publish. For a namespace whose publishing setting indicates publish, publishing setting unit <NUM> makes variables belonging to the namespace accessible from external device <NUM>. Meanwhile, for a namespace whose publishing setting indicates not publish, publishing setting unit <NUM> makes variables belonging to the namespace inaccessible from external device <NUM>.

In this way, the designer can set publish/not publish of variables for each namespace. Controller <NUM> collectively publishes variables belonging to a namespace whose setting indicates publish, and does not publish variables belonging to a namespace whose setting indicates "not publish". This eliminates the need for the designer to individually set publish/not publish of each variable included in user program <NUM>. As a result, a publishing setting of the variable to external device <NUM> becomes easier, and the number of development steps is reduced, as compared with the related art.

The namespace is generally divided for each meaningful set by the designer. Therefore, the designer sets publish/not publish of variables for the namespace, thereby collectively setting publish/not publish of the variables for each meaningful set. For example, in a case where the namespace is defined for each controller name or drive device name, the designer can collectively set publish/not publish of variables of a variable group related to the controller or a variable group related to the drive device.

Referring to <FIG>, a processing flow regarding the above-described processing of setting a public variable/private variable will be described. <FIG> is a sequence diagram showing a data flow among development assistance device <NUM>, controller <NUM>, drive device <NUM>, and external device <NUM>.

In step S10, development assistance device <NUM> accepts a command to start development tool <NUM>. Based on this, development assistance device <NUM> displays a design screen of user program <NUM>. <FIG> shows a design screen <NUM> as an example of a user interface provided by development tool <NUM>. Design screen <NUM> is displayed on, for example, a display unit <NUM> of development assistance device <NUM>.

User program <NUM> can be written in any programming language. As an example, user program <NUM> may be specified by a ladder diagram (LD), an instruction list (IL), a structured text (ST), a sequential function chart (SFC), or any combination thereof. Alternatively, user program <NUM> may be specified in a general-purpose programming language such as JavaScript (registered trademark) or C language.

In the example of <FIG>, user program <NUM> is written by a ladder diagram. The designer can design user program <NUM> suitable for drive device <NUM> to be controlled by combining arbitrary function blocks or specifying an input/output relationship of variables and function blocks on design screen <NUM>. The function block is a component into which a function repeatedly used in user program <NUM> is formed.

In the example of <FIG>, user program <NUM> includes variables A1 to A3 and function blocks FB1 and FB2. Function block FB1 executes its function on the basis of a value of variable A1 associated with an input unit thereof. A result of the execution is reflected in variable A2 associated with an output unit of function block FB1. Function block FB2 executes its function on the basis of a value of variable A2 associated with an input unit thereof. A result of the execution is reflected in variable A3 associated with an output unit of function block FB2. As described above, the designer can design arbitrary user program <NUM> by combining variables and function blocks on design screen <NUM>.

Referring to <FIG> again, in step S14, development tool <NUM> accepts call operation of a publishing setting screen. Based on this, development tool <NUM> displays the publishing setting screen.

<FIG> shows a publishing setting screen <NUM> as an example of a user interface provided by development tool <NUM>. Publishing setting screen <NUM> accepts, for each namespace specified in user program <NUM>, a setting regarding publishing of variables.

More specifically, publishing setting screen <NUM> includes a display field <NUM> for namespaces and a setting field <NUM> for publishing settings. Setting field <NUM> for publishing settings includes a setting field <NUM> that accepts a setting of a publishing range, and a setting field <NUM> that accepts a setting of an access authority of a destination to which the variables are published (publishing destination).

Display field <NUM> displays a list of the namespaces specified in user program <NUM>. The namespaces displayed in display field <NUM> may be automatically extracted from setting information of development tool <NUM>, or may be edited by a user.

Setting field <NUM> accepts a setting of a publishing range of variables. The setting of the publishing range of the variables is specified by, for example, a communication protocol. As an example, setting field <NUM> displays pull-down menus arranged vertically so that each pull-down menu corresponds to each namespace. When the designer presses the pull-down menu, a list of communication protocol options is displayed. As an example, the options include "publish", "not publish", "EtherNet/IP (EIP)", and "OPC-UA". The designer can select an option from the displayed options.

In a case where "publish" is selected, variables included in a selected namespace are published to arbitrary external device <NUM>, without depending on the communication protocol. In a case where "not publish" is selected, the variables included in the selected namespace are not published to external devices <NUM>. In a case where "EIP" is selected, the variables included in the selected namespace are published only to external device <NUM> that implements communication by EtherNet/IP. In a case where "OPC-UA" is selected, the variables included in the selected namespace are published only to external device <NUM> connected to a communication network that implements communication by OPC-UA.

As described above, the publishing setting that can be set includes a communication setting for specifying a communication protocol. In a case where controller <NUM> and external device <NUM> communicate with each other by using the set communication protocol, publishing setting unit <NUM> of controller <NUM> publishes variables belonging to the namespace to be set to external device <NUM>. Thus, controller <NUM> can divide public variables and private variables in accordance with the communication protocol. The type of the communication protocol is determined on the basis of, for example, information included in a communication packet.

Setting field <NUM> accepts a setting of an access authority of a publishing destination of variables. As an example, setting field <NUM> displays pull-down menus arranged vertically so that each pull-down menu corresponds to each namespace. When the designer presses the pull-down menu, a list of options regarding the access authority is displayed. As an example, the options include "R/W", "R", "W", and "-".

In a case where "R/W" is selected, development tool <NUM> gives an access authority to read and write the variables included in the selected namespace to external device <NUM> serving as the publishing destination. In a case where "R" is selected, development tool <NUM> gives an access authority to only read the variables included in the selected namespace to external device <NUM> serving as the publishing destination. In a case where "W" is selected, development tool <NUM> gives an access authority to only write the variables included in the selected namespace to external device <NUM> serving as the publishing destination. In a case where "-" is selected, development tool <NUM> gives an access authority not to read or write the variables included in the selected namespace to external device <NUM> serving as the publishing destination.

Note that the publishing setting does not necessarily need to be performed on publishing setting screen <NUM>. For example, the publishing setting may be set on any screen provided by development tool <NUM>. As an example, a list of namespaces is displayed on any screen provided by development tool <NUM> (e.g., design screen <NUM>). On the basis that the designer has selected a namespace from the list of the namespaces, a screen for performing a publishing setting of the selected namespace may be displayed.

In a case where a save button <NUM> on publishing setting screen <NUM> is pressed, development assistance device <NUM> saves the publishing setting set on publishing setting screen <NUM> as publishing setting information <NUM>. In a case where a cancel button <NUM> on publishing setting screen <NUM> is pressed, development assistance device <NUM> closes publishing setting screen <NUM>, without saving the publishing setting set on publishing setting screen <NUM>.

<FIG> shows an example of a data structure of saved publishing setting information <NUM>. As shown in <FIG>, publishing setting information <NUM> associates variables with a publishing setting for each namespace specified in user program <NUM>. As an example, a plurality of namespaces specified in user program <NUM> are associated with "Root". A "variable A1" to a "variable A3" are associated with a namespace represented as a "name A". "Variable A1" to "variable A3" shown in <FIG> correspond to "variable A1" to "variable A3" shown in <FIG>. In the example of <FIG>, a "publishing setting A" is associated with the namespace represented as "name A". "Publishing setting A" corresponds to contents set for the namespace of "name A" in setting field <NUM> (see <FIG>) of publishing setting screen <NUM>.

Referring to <FIG> again, in step S20, development tool <NUM> accepts compiling operation. Based on this, development tool <NUM> compiles user program <NUM> designed on design screen <NUM> in step S14. Thereafter, development tool <NUM> accepts download operation for transferring a compilation result to controller <NUM>. Based on this, development tool <NUM> transfers publishing setting information <NUM> generated in step S14 together with compiled user program <NUM> to controller <NUM>. Controller <NUM> stores received user program <NUM> and publishing setting information <NUM> in storage device <NUM> (see <FIG>).

In step S22, controller <NUM> accepts a command to execute user program <NUM>. Based on this, controller <NUM> starts executing user program <NUM>. In a case where user program <NUM> is a cyclic executive program, controller <NUM> repeatedly executes a command group included in user program <NUM> at each predetermined control cycle. More specifically, controller <NUM> executes the first to last lines of user program <NUM> in one control cycle. In the next control cycle, controller <NUM> executes the first to last lines of user program <NUM> again. Controller <NUM> generates a command value at each control cycle, and outputs the command value to drive device <NUM>.

In step S30, controller <NUM> receives a request to access an internal variable from external device <NUM> during execution of user program <NUM>.

In step S32, controller <NUM> refers to publishing setting information <NUM> (see <FIG>) described above and determines whether or not publishing of the variable requested in the access request is permitted. More specifically, controller <NUM> determines that publishing of the variable to be accessed is permitted in a case where a publishing range condition, a publishing destination condition, and an access authority condition are satisfied.

More specifically, the publishing range condition is satisfied in any of the following cases (a1) to (a3).

(a1) A case where "publish" is specified for the namespace to which the variable to be accessed belongs.

(a2) A case where, when "EIP" is specified for the namespace to which the variable to be accessed belongs, communication with external device <NUM> serving as an access request source is realized by EtherNet/IP.

(a3) A case where, when "OPC-UA" is specified for the namespace to which the variable to be accessed belongs, communication with external device <NUM> serving as the access request source is implemented by OPC-UA.

The access authority condition is satisfied in any of the following cases (b1) and (b2).

(b1) A case where, when the access request is a "Read" request, the access authority set for the namespace to which the variable to be accessed belongs is set to "R" or "R/W".

(b2) A case where, when the access request is a "Write" request, the access authority set for the namespace to which the variable to be accessed belongs is set to "W" or "R/W".

In a case where controller <NUM> determines that publishing of the variable requested in the access request is permitted (YES in step S32), controller <NUM> executes processing in step S34. If not (NO in step S32), controller <NUM> does not execute the processing in step S34.

In step S34, in a case where the access request is a "Read" request, controller <NUM> transmits the variable to be accessed to external device <NUM>. In a case where the access request is "Write", controller <NUM> rewrites the variable to be accessed to a specified variable, and transmits the rewritten result to external device <NUM>.

In step S36, external device <NUM> reflects the variable received from drive device <NUM> on the variable monitoring screen. <FIG> shows a variable monitoring screen <NUM> as an example of a user interface provided by external device <NUM>. Variable monitoring screen <NUM> is displayed on, for example, a display unit <NUM> of external device <NUM>.

In the example of <FIG>, external device <NUM> includes objects OB1 to OB4. Each of objects OB1 to OB4 is associated with any variable, and graphically shows a value of the variable.

Object OB1 is, for example, an image showing a tachometer. Object OB1 is associated with a variable indicating a valve pressure value of a drive device A, and the meter of object OB1 is sequentially updated in accordance with the value of the variable.

Object OB2 is, for example, an image showing a tachometer. Object OB2 is associated with a variable indicating a valve pressure value of a drive device B, and the meter of object OB2 is sequentially updated in accordance with the value of the variable.

Object OB3 is, for example, an image showing a thermometer. Object OB3 is associated with a variable indicating a temperature of drive device A, and the meter of object OB3 is sequentially updated in accordance with a value of the variable.

Object OB4 is, for example, an image showing a thermometer. Object OB4 is associated with a variable indicating a temperature of drive device B, and the meter of object OB4 is sequentially updated in accordance with a value of the variable.

Referring to <FIG>, a modification example of publishing setting information <NUM> described with reference to <FIG> will be described. <FIG> shows an example of a data structure of publishing setting information 212A according to the modification example.

In publishing setting information <NUM> described above, a publishing setting is associated with a namespace. Meanwhile, in publishing setting information 212A according to the modification example, a publishing setting is associated not only with a namespace but also with each variable. The publishing setting for each variable can be set on, for example, publishing setting screen <NUM> of development tool <NUM> described above. That is, publishing setting screen <NUM> is configured to accept not only the publishing setting for the namespace but also the publishing setting for each variable belonging to each namespace.

Contents of the publishing setting that can be set for the variable are typically the same as contents of the publishing setting that can be set for the namespace. As an example, the publishing setting for the variable includes a communication setting for specifying a communication protocol to be permitted. In addition, the publishing setting for the variable includes a publishing destination setting for specifying a publishing destination. In addition, the publishing setting for the variable includes an access authority setting of external device <NUM> serving as the publishing destination.

Development tool <NUM> reflects the publishing setting for the namespace as an initial value in the publishing setting for the variable. More specifically, on the basis that the publishing setting for the namespace has been set, development tool <NUM> causes each publishing setting associated with each variable belonging to the namespace to inherit the publishing setting for the namespace. In the example of <FIG>, "publishing setting A" set for "namespace A" is inherited by "variable A1" and "variable A2" belonging to "namespace A". This facilitates the publishing setting for the variable.

The designer can individually change each inherited publishing setting on publishing setting screen <NUM>. In the example of <FIG>, the publishing setting of "variable A2" is changed from "publishing setting A" to "publishing setting B". Thus, the designer can not only reduce time for performing the publishing setting of each variable, but also flexibly switch a setting between publish/not publish of each variable in accordance with individual circumstances.

Publishing setting unit <NUM> (see <FIG>) of controller <NUM> determines whether to publish the variable belonging to the namespace to external device <NUM> by prioritizing the publishing setting for each variable over the publishing setting for the namespace. That is, in a case where the publishing setting for the variable is set, publishing setting unit <NUM> determines whether to publish a target variable on the basis of the publishing setting for the variable while ignoring the publishing setting for the namespace. In the example of <FIG>, publishing setting unit <NUM> determines publish/not publish of "variable A1" on the basis of "publishing setting A", and determines publish/not publish of "variable A2" on the basis of "publishing setting B".

It can be typically expected that, as a usage mode, a publishing setting is performed for the namespace and thereafter publishing settings are individually performed for the variables. Therefore, the publishing setting individually set for each variable is more likely to reflect intention of the designer than the publishing setting set for the namespace. The intention of the designer is reflected more reliably by prioritizing the publishing setting for the variable over the publishing setting for the namespace.

In the above description, there has been described an example where the publishing setting set for the namespace is inherited by the variable belonging to the namespace. However, a publishing setting set for a higher namespace may be inherited by a lower namespace. More specifically, the designer can hierarchically define namespaces in development tool <NUM>. The higher namespace can include one or more lower namespaces. In such a case, development tool <NUM> causes the lower namespace to inherit a publishing setting of the higher namespace. Meanwhile, development tool <NUM> does not cause the higher namespace to inherit a publishing setting of the lower namespace.

The publishing settings are set by using the pull-down menus on publishing setting screen <NUM> described with reference to <FIG>, but the publishing settings may be set by another method. Hereinafter, referring to <FIG>, a modification example of publishing setting screen <NUM> shown in <FIG> will be described.

<FIG> shows a publishing setting screen 33A as another example of the user interface provided by development tool <NUM>. Publishing setting screen 33A is a modification example of publishing setting screen <NUM> described above with reference to <FIG>.

As shown in <FIG>, publishing setting screen 33A includes a display field <NUM> for namespaces and a setting field 50A for publishing settings. Setting field 50A for publishing settings includes setting fields 61A and 61B that accept a setting of a communication protocol, and setting fields 63A and 63B that accept a setting of an access authority of a publishing destination.

Setting fields 61A and 61B accept a setting regarding a communication protocol. As an example, checkboxes are displayed side by side in setting fields 61A and 61B so as to correspond to each namespace. The checkboxes are provided in accordance with the number of communication protocols with which controller <NUM> is compatible. In the example of <FIG>, "EIP" and "OPC-UA" are shown as selectable communication protocols.

In a case where the checkbox of "EIP" is selected, variables included in the corresponding namespace are published to external device <NUM> that performs communication by EtherNet/IP. In a case where the checkbox of "OPC-UA" is selected, variables included in the corresponding namespace are published to external device <NUM> that performs communication by OPC-UA. In a case where none of the checkboxes is selected, variables included in the corresponding namespace are not published to external device <NUM>.

Setting fields 63A and 63B accept a setting of an access authority of a publishing destination of variables. As an example, checkboxes are displayed side by side in setting fields 63A and 63B so as to correspond to each namespace. The checkboxes are provided in accordance with the number of types of access authority. In the example of <FIG>, "R" and "W" are shown as selectable access authorities.

In a case where both "R" and "W" are selected, development tool <NUM> gives an access authority to read and write variables included in a selected namespace to external device <NUM> serving as the publishing destination. In a case where only "R" is selected, development tool <NUM> gives an access authority to only read the variables included in the selected namespace to external device <NUM> serving as the publishing destination. In a case where only "W" is selected, development tool <NUM> gives an access authority to only write the variables included in the selected namespace to external device <NUM> serving as the publishing destination. In a case where both "R" and "W" are not selected, development tool <NUM> gives an access authority not to read or write the variables included in the selected namespace to external device <NUM> serving as the publishing destination.

In a case where save button <NUM> on publishing setting screen 33A is pressed, development assistance device <NUM> saves the publishing setting set on publishing setting screen 33A as publishing setting information <NUM>. In a case where cancel button <NUM> on publishing setting screen 33A is pressed, development assistance device <NUM> closes publishing setting screen 33A, without saving the publishing setting set on publishing setting screen 33A.

Referring to <FIG>, another modification example of publishing setting screen <NUM> described with reference to <FIG> will be described. <FIG> shows a publishing setting screen 33B as another example of the user interface provided by development tool <NUM>. Publishing setting screen 33B is a modification example of publishing setting screen <NUM> described above with reference to <FIG>.

A setting field <NUM> for publishing settings on publishing setting screen 33B is different from that on publishing setting screen <NUM> shown in <FIG> in that setting field <NUM> further includes a setting field <NUM> for setting holding/non-holding of variables. The other points are the same as those described with reference to <FIG>, and description thereof will not be repeated below.

Setting field <NUM> accepts a setting of holding/non-holding of variables for each namespace. As an example, setting field <NUM> displays checkboxes arranged vertically so that each checkbox corresponds to each namespace. Variables belonging to the namespace selected in setting field <NUM> are stored in a nonvolatile storage device (e.g., a storage device <NUM> described below) in development assistance device <NUM>. That is, values of the variables are held even in a case where a power supply of development assistance device <NUM> is turned off. Meanwhile, variables belonging to namespaces not selected in setting field <NUM> are stored in a volatile storage device (e.g., a main memory <NUM> described below) in development assistance device <NUM>. That is, values of the variables are not held in a case where the power supply of development assistance device <NUM> is turned off.

Referring to <FIG> and <FIG>, a variable search function using contents of a publishing setting as a search key will be described. <FIG> shows screen transition of a search screen <NUM> obtained in a case where a namespace is input as the search key. <FIG> shows screen transition of search screen <NUM> obtained in a case where a communication protocol is input as the search key.

Search screen <NUM> includes an input unit <NUM> that accepts a namespace as the search key, an input unit <NUM> that accepts a variable name as the search key, an input unit <NUM> that accepts a communication protocol as the search key, and a display area <NUM> for a search result.

Based on input of the search key to input units <NUM> to <NUM>, development assistance device <NUM> searches for variables corresponding to the input search key by referring to publishing setting information <NUM> (see <FIG>) described above. Then, development assistance device <NUM> displays each variable extracted as a search result and a publishing setting set for the each variable side by side. Thus, the designer can easily check the publishing setting set for each variable.

For example, as shown in <FIG>, "name A" is input to input unit <NUM>. Based on this, development assistance device <NUM> searches for variables belonging to the namespace of "name A" by referring to publishing setting information <NUM> (see <FIG>). Then, development assistance device <NUM> displays each variable extracted as a search result and a publishing setting set for each variable side by side.

As another example, as shown in <FIG>, a checkbox of "EIP" in input unit <NUM> is selected. Based on this, development assistance device <NUM> searches for variables whose publishing settings indicate "EIP" by referring to publishing setting information <NUM> (see <FIG>). Then, development assistance device <NUM> displays each variable extracted as a search result and a publishing setting set for the each variable side by side.

Referring to <FIG>, hardware configurations of development assistance device <NUM>, controller <NUM>, and external device <NUM> will be described in order.

First, referring to <FIG>, the hardware configuration of development assistance device <NUM> will be described. <FIG> is a schematic diagram showing the hardware configuration of development assistance device <NUM>.

Development assistance device <NUM> includes a computer configured in conformity with a general-purpose computer architecture as an example. Development assistance device <NUM> includes a control device <NUM> such as a central processing unit (CPU) or a micro-processing unit (MPU), volatile main memory <NUM>, nonvolatile storage device <NUM> such as a flash memory, a communication interface <NUM>, an input/output (I/O) interface <NUM>, and a display interface <NUM>. Those components are communicably connected to each other via an internal bus <NUM>.

Control device <NUM> implements various kinds of processing in development tool <NUM> by loading a development assistance program 110A stored in storage device <NUM> into main memory <NUM> and executing development assistance program 110A. Development assistance program 110A is a program for providing a development environment of user program <NUM>. Storage device <NUM> stores not only development assistance program 110A but also various types of data and the like generated in development tool <NUM>. The data includes, for example, user program <NUM> designed on development tool <NUM> and publishing setting information <NUM> described above.

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

I/O interface <NUM> is connected to an operation unit <NUM>, and receives a signal indicating user operation from operation unit <NUM>. Operation unit <NUM> typically includes a keyboard, a mouse, a touchscreen, a touchpad, and the like, and accepts operation from the user.

Display interface <NUM> is connected to display unit <NUM>, and transmits an image signal for displaying an image to display unit <NUM> in response to a command from control device <NUM> or the like. Display unit <NUM> includes a liquid crystal display (LCD), an organic electro luminescence (EL) display, or the like, and presents various types of information to the user. Various screens provided by development tool <NUM> can be displayed on display unit <NUM>. In the example of <FIG>, development assistance device <NUM> and display unit <NUM> are shown as separate components, but development assistance device <NUM> and display unit <NUM> may be integrally configured.

Next, referring to <FIG>, the hardware configuration of controller <NUM> will be described. <FIG> is a schematic diagram showing an example of the hardware configuration of controller <NUM>.

Controller <NUM> includes a communication interface <NUM>, control device <NUM> such as a CPU or an MPU, a chipset <NUM>, a main memory <NUM>, storage device <NUM>, an internal bus controller <NUM>, a field bus controller <NUM>, and a memory card interface <NUM>.

Control device <NUM> reads a control program <NUM> stored in storage device <NUM>, loads control program <NUM> into main memory <NUM>, and executes control program <NUM>, thereby implementing arbitrary control of robot controller 300A, servo driver 300B, and the like. Control program <NUM> includes various programs for controlling controller <NUM>. As an example, control program <NUM> includes a system program <NUM>, user program <NUM>, and the like. System program <NUM> includes command codes for providing basic functions of controller <NUM>, such as data input/output processing and execution timing control. User program <NUM> is downloaded from development assistance device <NUM>. User program <NUM> is arbitrarily designed in accordance with a target to be controlled, and includes a sequence program 210A for executing sequence control and a motion program 210B for executing motion control.

Chipset <NUM> controls each component, thereby implementing processing of the entire controller <NUM>.

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

Field bus controller <NUM> is an interface that exchanges data with various drive devices <NUM> connected to controller <NUM> via a field bus. As an example of such devices, robot controller 300A and servo driver 300B are connected. In addition, a drive device such as a visual sensor may be connected.

Internal bus controller <NUM> and field bus controller <NUM> can give an arbitrary command to the connected device, and can acquire arbitrary data managed by the device. Further, internal bus controller <NUM> and/or field bus controller <NUM> also function as an interface for exchanging data with robot controller 300A and servo driver 300B.

Communication interface <NUM> controls exchange of data via various wired/wireless networks. Controller <NUM> communicates with development assistance device <NUM> and external device <NUM> via communication interface <NUM>.

Memory card interface <NUM> is configured so that a memory card <NUM> (e.g., SD card), which is an example of an external storage medium, is detachable, and can write data to the memory card <NUM> and read data from the memory card <NUM>.

Next, referring to <FIG>, the hardware configuration of external device <NUM> will be described. <FIG> is a block diagram showing the hardware configuration of external device <NUM>.

External device <NUM> has a hardware configuration having a general-purpose architecture. That is, external device <NUM> is implemented as a kind of personal computer. However, external device <NUM> may be implemented by using dedicated hardware, instead of general-purpose hardware.

More specifically, external device <NUM> includes a control device <NUM> such as a CPU or an MPU, a main memory <NUM>, a storage device <NUM> such as a flash memory, a communication interface <NUM>, an I/O interface <NUM>, a field bus interface <NUM>, and a display unit <NUM>. Those components are connected via an internal bus <NUM> so as to perform data communication with each other.

Control device <NUM> reads a control program (not shown) stored in storage device <NUM>, loads the control program into main memory <NUM>, and executes the control program, thereby controlling external device <NUM>. That is, control device <NUM> is combined with main memory <NUM> and storage device <NUM> to realize a control unit that executes control operation.

Communication interface <NUM>, I/O interface <NUM>, and field bus interface <NUM> mediate exchange of data between external device <NUM> and another communication device.

More specifically, communication interface <NUM> mediates communication with controller <NUM> via network NW1 (see <FIG>) or the like. For communication interface <NUM>, for example, a component capable of performing communication conforming to EtherNET can be adopted.

I/O interface <NUM> mediates communication with various user interface devices (e.g., keyboard and mouse). For I/O interface <NUM>, for example, a component capable of performing USB communication or serial communication can be adopted.

Field bus interface <NUM> mediates exchange of data with controller <NUM>. For field bus interface <NUM>, for example, a component capable of performing communication conforming to EtherCAT can be adopted.

Display unit <NUM> presents various types of information to the user and accepts operation from the user. More specifically, display unit <NUM> includes a display <NUM> and a touchscreen <NUM>. Display <NUM> typically includes an LCD, an organic EL display, or the like. Touchscreen <NUM> is mounted on display <NUM> and accepts touch operation by the user. Display <NUM> is typically a pressure-sensitive or press-type device.

Referring to <FIG>, a function of controller <NUM> will be described. <FIG> shows an example of a functional configuration of controller <NUM>.

Controller <NUM> includes communication interface <NUM>, a resource manager <NUM>, an event management unit <NUM>, a tool interface <NUM>, a nonvolatile memory <NUM>, a program execution unit <NUM>, an OPC-UA server <NUM>, and an EIP server <NUM>.

Communication interface <NUM> communicates with an external device 400A functioning as an OPC-UA client 450A, an external device 400B functioning as an EIP client 450B, and development assistance device <NUM>. Development tool <NUM> of user program <NUM> is installed in development assistance device <NUM>. Tool interface <NUM> receives user program <NUM> designed on development tool <NUM> and publishing setting information <NUM> set on development tool <NUM> via communication interface <NUM>.

Resource manager <NUM> holds substance of each variable in controller <NUM>, and performs management of each variable, reading and writing each variable, and the like. As an example, in a case where resource manager <NUM> receives a command to read (command to acquire) a variable, resource manager <NUM> accesses the variable to be read and transmits the variable to a source that has transmitted the read command. In a case where resource manager <NUM> receives a command to write a variable, resource manager <NUM> accesses the variable to be written and rewrites the variable to a specified value. The commands to read and write each variable are issued from, for example, program execution unit <NUM>, OPC-UA server <NUM>, and EIP server <NUM>.

Further, resource manager <NUM> holds publishing setting information <NUM> that specifies a relationship among a namespace, a variable, and a publishing setting. Publishing setting information <NUM> is read from storage device <NUM> (see <FIG>) of controller <NUM>. Upon receipt of a command to register definition of a namespace and a variable or a command to delete the definition thereof, resource manager <NUM> performs registration processing or deletion processing on publishing setting information <NUM>.

OPC-UA server <NUM> includes an OPC-UA communication stack <NUM> and a main program <NUM>. OPC-UA communication stack <NUM> temporarily holds transmission data to OPC-UA client 450A and reception data from OPC-UA client 450A. Main program <NUM> is software for implementing a server function of OPC-UA server <NUM>.

EIP server <NUM> includes an EIP communication stack <NUM> and a main program <NUM>. EIP communication stack <NUM> temporarily holds transmission data to EIP client 450B and reception data from EIP client 450B. Main program <NUM> is software for implementing a server function of EIP server <NUM>.

Referring to <FIG>, a control structure of development assistance device <NUM> will be described. <FIG> is a flowchart showing a part of processing executed by development assistance device <NUM>. The processing shown in <FIG> is implemented by control device <NUM> of development assistance device <NUM> executing development assistance program 110A (see <FIG>) described above. In another aspect, a part of or the whole processing may be executed by a circuit element or another hardware.

In step S110, control device <NUM> determines whether or not a command to start development tool <NUM> has been accepted. In a case where control device <NUM> determines that the command to start development tool <NUM> has been accepted (YES in step S110), control device <NUM> switches control to step S120. If not (NO in step S110), control device <NUM> executes the processing in step S110 again.

In step S120, control device <NUM> determines whether or not operation for opening design screen <NUM> (see <FIG>) described above has been accepted. This operation is performed on operation unit <NUM> (see <FIG>). In a case where control device <NUM> determines that the operation for opening design screen <NUM> has been accepted (YES in step S120), control device <NUM> switches the control to step S122. If not (NO in step S120), control device <NUM> switches the control to step S130.

In step S122, control device <NUM> displays design screen <NUM> on display unit <NUM> (see <FIG>) of development assistance device <NUM>. Thus, the designer can write user program <NUM> on design screen <NUM>.

In step S130, control device <NUM> determines whether or not operation for opening publishing setting screen <NUM> (see <FIG>) described above has been accepted. This operation is performed on operation unit <NUM>. In a case where control device <NUM> determines that the operation for opening publishing setting screen <NUM> has been accepted (YES in step S130), control device <NUM> switches the control to step S132. If not (NO in step S130), control device <NUM> switches the control to step S140.

In step S132, control device <NUM> displays publishing setting screen <NUM> on display unit <NUM> of development assistance device <NUM>. Thus, the designer can perform publishing settings of variables for each namespace specified in user program <NUM>. Information set on publishing setting screen <NUM> is stored as publishing setting information <NUM> (see <FIG>) described above.

In step S140, control device <NUM> determines whether or not compiling operation has been performed on user program <NUM>. This operation is performed on operation unit <NUM>. In a case where control device <NUM> determines that the compiling operation has been performed on user program <NUM> (YES in step S140), control device <NUM> switches the control to step S142. If not (NO in step S140), control device <NUM> switches the control to step S150.

In step S142, control device <NUM> executes compiling processing of user program <NUM>. Thus, an executable file of user program <NUM> is generated.

In step S150, control device <NUM> determines whether or not operation for downloading user program <NUM> to controller <NUM> has been accepted. This operation is performed on operation unit <NUM>. In a case where control device <NUM> determines that the operation for downloading user program <NUM> to controller <NUM> has been accepted (YES in step S150), control device <NUM> switches the control to step S152. If not (NO in step S150), control device <NUM> switches the control to step S160.

In step S152, control device <NUM> transfers a compilation result of user program <NUM> generated in step S142 and publishing setting information <NUM> generated in step S132 to specified controller <NUM>.

In step S160, control device <NUM> determines whether or not operation for terminating development tool <NUM> has been accepted. In a case where control device <NUM> determines that the operation for terminating development tool <NUM> has been accepted (YES in step S160), control device <NUM> terminates the processing shown in <FIG>. If not (NO in step S160), control device <NUM> returns the control to step S120.

Referring to <FIG>, a control structure of controller <NUM> will be described. <FIG> is a flowchart showing a part of processing executed by controller <NUM>. The processing shown in <FIG> is implemented by control device <NUM> of controller <NUM> executing a program. In another aspect, a part of or the whole processing may be executed by a circuit element or another hardware.

In step S210, control device <NUM> determines whether or not a command to execute user program <NUM> has been accepted. In a case where control device <NUM> determines that the command to execute user program <NUM> has been accepted (YES in step S210), control device <NUM> switches control to step S220. If not (NO in step S210), control device <NUM> executes the processing in step S210 again.

In step S220, control device <NUM> determines whether or not the control cycle of user program <NUM> has arrived. As described above, because user program <NUM> is a cyclic executive program, control device <NUM> repeatedly executes a command group included in user program <NUM> at every predetermined control cycle. In a case where control device <NUM> determines that the control cycle of user program <NUM> has arrived (YES in step S220), control device <NUM> switches the control to step S222. If not (NO in step S220), control device <NUM> switches the control to step S230.

In step S222, control device <NUM> executes the first to last lines of user program <NUM> in one control cycle. In the next control cycle, controller <NUM> executes the first to last lines of user program <NUM> again. Controller <NUM> outputs a command value to drive device <NUM> at the each control cycle.

In step S230, control device <NUM> determines whether or not the control cycle of publishing processing of variables has arrived. Because a delay of processing and a delay of communication are not allowed in the FA system, an execution period of the publishing processing of the variables is allocated in advance. This execution period arrives at each predetermined control cycle. In a case where control device <NUM> determines that the control cycle of the publishing processing of the variables has arrived (YES in step S230), control device <NUM> switches the control to step S240. If not (NO in step S230), control device <NUM> returns the control to step S220.

In step S240, control device <NUM> determines whether or not a request to access variables has been received from any external device <NUM>. In a case where control device <NUM> determines that the request to access variables has been received from any external device <NUM> (YES in step S240), control device <NUM> switches the control to step S250. If not (NO in step S240), control device <NUM> returns the control to step S220.

In step S250, control device <NUM> determines whether or not publishing of the variables requested in the access request to external device <NUM> serving as a transmission source of the access request is permitted. A method of the determination has been described above, and thus description thereof will not be repeated. In a case where control device <NUM> determines that publishing of the variables requested in the access request to external device <NUM> serving as the transmission source of the access request is permitted (YES in step S250), control device <NUM> switches the control to step S252. If not (NO in step S250), control device <NUM> returns the control to step S220.

In step S252, control device <NUM> transmits the variables requested in the access request to external device <NUM> serving as the transmission source of the access request.

As described above, development assistance device <NUM> is configured to accept, for each namespace and each variable defined in user program <NUM>, a publishing setting for determining whether to publish variables belonging to each namespace. The set publishing setting is transmitted to controller <NUM>. Controller <NUM> publishes the variables belonging to the namespace whose setting indicates "publish" to external device <NUM>.

Thus, the designer can perform publishing settings of variables to external device <NUM> for each namespace. That is, the designer does not need to individually set each variable as a public variable. As a result, the publishing setting of the variable to external device <NUM> becomes easier.

Claim 1:
A control system, comprising:
a development assistance device (<NUM>); and
a controller (<NUM>) configured to communicate with the development assistance device (<NUM>), wherein:
a development tool (<NUM>) configured to develop a user program (<NUM>) for controlling the controller (<NUM>) is installable in the development assistance device (<NUM>), the user program (<NUM>) including one or more variables belonging to a predetermined namespace, and the development tool (<NUM>) is configured to accept, for the namespace, a publishing setting for determining whether to collectively publish the one or more variables belonging to the namespace to an external device (<NUM>) that is communicatively connectable to the controller (<NUM>); and
the controller (<NUM>) includes
a program execution unit (<NUM>) configured to control a drive device (<NUM>) to be controlled in accordance with the user program (<NUM>) received from the development assistance device (<NUM>), and update the one or more variables belonging to the namespace in accordance with an execution result of the user program (<NUM>), characterized in that
a publishing setting unit (<NUM>) configured to collectively publish the one or more variables belonging to the namespace to the external device (<NUM>) in a case where the publishing setting received from the development assistance device (<NUM>) indicates "publish",
the development tool (<NUM>) is configured to set the publishing setting for each variable belonging to the namespace and reflect the publishing setting for the namespace as an initial value in the publishing setting for the variable, and
the publishing setting unit (<NUM>) configured to determine whether to publish the variable belonging to the namespace to the external device (<NUM>) by prioritizing the publishing setting for the variable over the publishing setting for the namespace.