JP2004126817A - Setting tool device and program product - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a setting tool device that facilitates setting in EDS-supporting/non-supporting devices. <P>SOLUTION: The setting tool device comprises a setting tool body 11 for making a function request such as parameter setting or monitor requesting to a device, a device-unified interface 12 for receiving the function request by the setting tool body, and an expansion module 14 created in compliance with the device. The setting tool body communicates only with the device-unified interface, and executes actual setting in the device or the like from the device-unified interface via the expansion module. The addition of an expansion module accommodates a new device without replacement of the setting tool body. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a setting tool device and a program product.
[0002]
BACKGROUND OF THE INVENTION
Programmable controllers (PLCs) used in factory automation (FA) input ON / OFF information of input devices such as switches and sensors, and perform logical operations according to a sequence program (user program) written in a ladder language or the like. Execute. The PLC is controlled by outputting ON / OFF information signals to output devices such as relays, valves and actuators in accordance with the obtained calculation results.
[0003]
The connection between the PLC, the input device, and the output device may be directly connected to the PLC or may be connected via a network. When a network system connected by such a network is constructed, transmission / reception of the ON / OFF information is performed via the network. At this time, information is normally transmitted in a master-slave system in which the PLC side is the master and the device side is the slave.
[0004]
As a network connecting the above-described PLC and each device, DeviceNet (device net), which is one form of a field network, is used. The device net can easily interconnect control devices such as a PLC, a personal computer (PC), a sensor, and an actuator, and can connect products (devices) of different vendors to the same network.
[0005]
In the device net specification, a common file format called an EDS file is defined for information of each device in order to enable device setting regardless of a device maker. As a result, even in a multi-vendor environment in which devices from different vendors on the same network are connected, using a personal computer tool such as a configurator that can understand the EDS file, browsing of the connected devices and individual devices can be performed. Parameters can be easily set. Further, the device itself has profile data (data including Identity).
[0006]
By the way, the EDS file includes update history information of information, information specifying a device such as a product name or a model vendor name called “Identity”, an IO size called “IO Info”, and a device size. Storage specifications are defined for common items of each device such as various parameters. In addition, vendor-specific and value-added options can be added.
[0007]
In other words, as devices become more sophisticated, there are some that cannot be described with the parameter items defined in the EDS file, and there are many that do not use the EDS file in order to differentiate manufacturers.
[0008]
Then, in order for a user to set a device that does not use an EDS file for describing parameters (setting information) existing on the same network, a setting tool dedicated to each company is required. In addition, in order to be able to set a device of another manufacturer, it is necessary to have the manufacturer disclose device setting information and the like. Therefore, incorporating different implementations for each device into a single piece of software requires a great deal of effort and is not practical.
[0009]
Furthermore, even if it can be incorporated into a single piece of software, when a new device is provided, the program corresponding to the setting information of the device must be improved, which is troublesome. As a conventional setting tool, there are the inventions disclosed in the following patent delegations 1 to 3.
[0010]
[Patent Document 1]
JP-A-11-122250
[Patent Document 2]
JP-A-2000-273832
[Patent Document 3]
JP 2001-202324 A
[0011]
An object of the present invention is to provide a setting tool device and a program product that can easily perform settings for different devices and that can support various communication interfaces.
[0012]
[Means for Solving the Problems]
The setting tool device according to the present invention includes: a setting tool main body for making a function request such as a parameter setting or a monitor request to a device; and a device unified interface for receiving a function request of the setting tool main body. By transmitting and receiving data to and from an extension module that can communicate with the device unified interface and is created for the device, a request corresponding to the function request received from the setting tool body is directed to the extension module. Output function.
[0013]
The device unified interface may have a function of returning information obtained by adding information owned by itself to the information sent from the extension module in response to the request to the setting tool body.
[0014]
Further, the extension module may have a plurality of types, and one may be for a standard-compliant device connected to a network. The standard correspondence means that the embodiment corresponds to EDS.
[0015]
Furthermore, it is preferable to mount the extension module. Note that, in a normal case, a standard-compatible extension module is mounted as a standard in a setting tool device, but in the present invention, it is not always necessary to mount the extension module in advance. The extension module can be added later regardless of whether or not it is compatible with the standard. Therefore, even when the number of extension modules is “0”, it functions as a setting tool device. Of course, a plurality of extension modules may be mounted in advance.
[0016]
Further, in each of the above-mentioned inventions, when the identification information set for the device and the correspondence list of the extension module for the device are stored and acquired, and the identification information of the device is acquired, the extension module for the device is obtained from the correspondence list. It is preferable to have a function of combining the identification information and the extension module to generate an object for the device, and constructing a virtual network using the generated object. The identification information corresponds to the Identity information in the embodiment. Further, the correspondence list may be created and stored in advance, or may be generated each time according to the invention described below.
[0017]
Also, the identification information set for the device, a setting file including information for associating the extension module for the device, and the extension module are stored and stored in the setting file at a predetermined timing. It is preferable to have a function of reading information and the extension module and generating a correspondence list of the identification information and the extension module for the same device. The predetermined timing is, for example, when the apparatus is started.
[0018]
According to the present invention, it is possible to perform settings for devices of different vendors and for different devices that are not standard compatible (for example, EDS file compatible) with a single piece of software (the setting tool body). Further, by making the device corresponding portion an independent extension module and exposing the device unified interface, the device can be independently developed by the company itself or a device manufacturer. In addition, it can be added sequentially by using an independent extension module. Therefore, it is not necessary to change the setting tool main body when dealing with a new device, and it is easy to deal with a new device. Further, by applying the same structure to the communication interface, it becomes possible to support communication interfaces of various companies.
[0019]
In the program product according to the present invention, a setting tool program for making a function request such as a parameter setting or a monitor request to a device, and a device unified interface program for receiving a function request issued in accordance with the execution of the setting tool program The device unified interface program executes data transmission / reception with an extension module created for the device, and outputs a request corresponding to the received function request to the extension module A program part for processing is provided.
[0020]
Further, the device unified interface program is a process for acquiring information transmitted from the extension module in response to the request, and information obtained by adding information possessed by itself to the setting tool program. It is preferable to provide a program portion for executing a process of returning the program.
[0021]
BEST MODE FOR CARRYING OUT THE INVENTION
FIG. 1 shows a preferred embodiment of the present invention. As shown in FIG. 1, the setting tool 10 includes a setting tool body 11, a device unified interface (virtual device) 12, an extension module 14, a communication unified interface 15, and an interface communication module 16. Each processing unit is configured by an application program, and is installed on a personal computer or other computer to generate a setting tool.
[0022]
The setting tool body 11 implements the original functions of the setting tool for setting parameters and requesting monitoring of the device, and for notifying user operations. Normally, for an EDS-compatible device, the setting tool main body 11 recognizes the contents described in the EDS file and performs various settings for a device connected to the network. In addition, for a device that does not support EDS, a predetermined process such as setting and monitoring is executed for the device by installing a program dedicated to the device. That is, the type of the device to be processed is recognized, and a request is made in a method corresponding to the type.
[0023]
On the other hand, in the present invention, the access destination of the setting tool main body 11 is, as shown in FIG. The parameter setting and the monitor request for the actual device are transmitted and received by the device unification interface 12 to and from the extension module 14 created for each device, and the setting for each device is performed. The device information is collected and returned to the setting tool main body 11.
[0024]
Events issued by the setting tool main body 11 include “function request”, “support function inquiry”, and “user operation notification”. The “function request” includes, for example, a request for displaying the parameters of the device, a monitor request, and a parameter setting / editing request. "Support function inquiry" is for inquiring about what function the device supports. That is, since the setting tool main body 11 does not know what kind of function the device that is going to perform corresponds to, the function is to support (support) the function to be executed before making a function request. To ask. Further, the “user operation notification” is for notifying each device of the content of the user operation. That is, for example, when the node address assigned to a certain device is changed, the change is notified to another device. Thereby, each device constituting the network can know the change of the node address, so that communication can be performed normally thereafter.
[0025]
The device unification interface 12 is the only device that the setting tool body 11 can identify in the setting tool 11 as described above, and defines this as a virtual device. As described above, in order to make the virtual device, which is the only device accessible by the setting tool main body 11 in the setting tool 10, compatible with any real device, a portion depending on the real device is separated as the extension module 14, and A common interface is also provided between the virtual device and the extension module 14. The part common to all the actual devices is mounted on the device unified interface 12.
[0026]
Therefore, as shown in FIG. 3, the device unified interface 12 (virtual device) implements a unified interface 12a used when communicating with the setting tool body 11, and functions and information common to each device. It has a main body 12b and an extension module unified interface 12c used for communication between the extension module 14. The main body 12b also includes resources such as screen data (including a display character string) common to each device.
[0027]
Further, the extension module 14 includes an extension module unification interface 14a for communicating with the device unification interface 12 (virtual device), and an extension module main body 14b for storing a part dependent on the actual device. Here, the extension module main body 14b executes a process corresponding to an event received via the device unified interface 12, and includes resources such as screen data (including a display character string).
[0028]
As described above, the mounting on the extension module 14 (the extension module body 14b) depends on the actual device, but by using the unified single interface 12c, 14a, the virtual device 12 The real device can be accessed by the single extension module unified interface 12c.
[0029]
Here, an example of processing in the device unification interface 12 and the expansion module 14 in response to a function request from the setting tool main body 11 will be described. As described above, the implementation common to the devices and the screen data (including the display character string) are stored in the main body 12b of the virtual device, and those dependent on the real device are stored in the expansion module main body 14b of the expansion module 14. Then, when receiving a function execution request from the setting tool main body 11, the device unified interface 12 acquires the screen data in the extension module 14, combines the common screen data held by itself, and The screen is configured and returned to the setting tool body 11. As described above, in response to the received function request, the main body 12b further requests and obtains necessary information from the extension module 14, and synthesizes the information possessed by itself and the obtained information. It returns to the setting tool main body 11.
[0030]
As a specific example, for example, when a property information display request for a device is received from the setting tool main body 11, a screen necessary for disclosing property information to the designated extension module 14 for the real device is displayed. Make further requests for data and combine the results obtained. As a result, the device A is as shown in FIG. 4, for example, and the device B is as shown in FIG. 5, for example.
[0031]
In FIGS. 4 and 5, the screen data for the entire screen in the foreground screen is held by the device unified interface 12, which is a virtual device, and the second and subsequent screen data correspond to each real device. It is provided on the extension module 14 side. Further, specific numerical values and data displayed in each screen data are held by the extension module 14. That is, item names such as “description”, “node address”, and “vendor” on the first general screen are held by the device unified interface 12 as part of the screen data. Then, the data corresponding to each item is obtained from the extension module 14, synthesized, and displayed.
[0032]
As a result, the setting tool main body 11 makes a request to disclose the property information having the same content, but the content finally displayed has a display layout appropriate for each actual device as shown in FIGS. Can be displayed. In addition, depending on the type of the actual device, there is of course no second or subsequent one, that is, a device composed of only the common screen data held by the device unified interface 12. Also in this case, specific data is obtained from the extension module 14 as necessary.
[0033]
Further, when the device unified interface 12 receives a support function inquiry, the device unification interface 12 inquires the extension module 14 of the corresponding real device whether the function is supported, and receives a response from the extension module 14 to respond. Whether it is possible or not is returned to the setting tool body 11.
[0034]
Further, when the device unification interface 12 receives the user operation notification, the content of the received operation notification is transferred to each extension module 14.
[0035]
The extension module 14 is created corresponding to the actual device as described above. Therefore, there are devices for devices that support EDS, and devices for devices that do not support EDS. Normally, an extension module 14 for an EDS-compatible device always exists, and each of the EDS-compatible real devices is accessed using the extension module 14. In addition, a unique extension module 14 is prepared for each EDS-incompatible real device, and access is performed using the extension module 14.
[0036]
With this configuration, regardless of the type of the device to be processed, the setting tool main body 11 performs data exchange with the device unified interface 12 when performing predetermined processing such as setting and monitoring of the device. What is necessary is just to send and receive. In other words, a single command for executing various processes is required. As a result, even if a new type of device is subsequently generated, the setting tool main body 11 sends a command to the device unified interface 12 when it attempts to execute a predetermined process on the new device. As a result, a predetermined process can be executed on the new device, so that a device can be easily added.
[0037]
Some devices take a form in which another device (child device) is further connected to the device. Therefore, the extension module has a structure that can be extended by setting the setting information of the child device in an external file (EDS format) correspondingly. Then, the setting file of the child device is stored in a directory for each extension module, and is managed inside each extension module in the same way as a plug-in manager described later in the setting tool.
[0038]
On the other hand, all the devices corresponding to the device net hold information for specifying each device called an Identity object. Therefore, in the present embodiment, the corresponding extension module is associated with the actual device based on the Identity information.
[0039]
Specifically, as shown in FIG. 6, a setting file 17 for performing the above association is prepared. That is, this setting file 17 contains information (vendor ID, device type, product code, etc.) similar to the Identity information held by the real device, the file name of the extension module 14 used for the device, and the setting tool 10. A file name of a display icon 18 for displaying a device and a file name of an EDS file 19 for displaying a corresponding device list (component list) on the setting tool 10 are described.
[0040]
As described above, the setting file 17 is associated with each of the extension modules 14, the display icons 18 and the EDS file 19 by the file name. Therefore, by accessing the setting file 17 and extracting the file name of each piece of information stored therein, necessary data can be read based on the extracted file name. This setting file is created for each actual device. Therefore, the setting file 17 for a certain real device is uniquely associated with the identity, and the setting file and the extension module 14, the display icon 18 and the EDS file 19 are associated with the file name as a key. And the extension module are uniquely associated via the setting file.
[0041]
As described above, since the association between the real device and the extension module 14 is performed by the description of the setting file 17, by adding a setting file corresponding to the real device, a single module can cope with a plurality of real devices. Can be.
[0042]
Next, in the case where settings are actually performed on a device using the setting tool 10 shown in FIG. 1, a configuration as shown in FIG. 7 is employed. That is, in the actual setting tool 10, the setting file 17 and the extension module 14 are stored in a specific directory (database 21) and are read all at the time of starting the software. Create and manage module correspondence lists.
[0043]
Then, a virtual network 23 composed of objects corresponding to the network constituted by the real devices is generated in the setting tool 10, and various requests and other instructions are performed by specifying the objects on the virtual network 23. Become.
[0044]
First, construction of a virtual network is performed by executing the following procedure. That is, the setting tool 10 is connected to the network 30. Then, (1) the setting tool 10 scans the network 30 and acquires the Identity information held by the device 31 connected to the network 30.
[0045]
(2) Next, the read Identity object is constructed in the virtual network 23 in the setting tool 10.
[0046]
{Circle around (3)} Inquire of the plug-in manager 22 about the module corresponding to the Identity constructed in step {2}. That is, it is checked whether or not the acquired Identity is registered in the plug-in manager 22.
[0047]
(4) If the acquired Identity is registered and the corresponding module exists, the module is called to construct a device object, which is combined with the Identity object created in (2). If the corresponding Identity (module) does not exist, a basic module using the EDS file is called to construct a device object and combine it.
[0048]
By executing the above processes (1) to (4) for all devices 31 connected to the network 30, a virtual network consisting of objects corresponding to all the real devices constituting the network 30 is created. It can be built on the setting tool 10. Note that the device unified interface 12 is linked to each object. Each of the above-described processes is executed by, for example, an instruction from the setting tool main body 11.
[0049]
Then, the virtual network thus generated is displayed on the display screen of the setting tool main body 11 as shown in FIG. That is, the window on the right side in the figure is a display area of the virtual network, and three objects are generated in the figure. As shown in the figure, each object displays a display icon 18 linked in the setting file 17 and an Identity (product name or the like) stored in the setting file 17.
[0050]
In this state, by clicking the icon of the object, a device (extension module) can be specified, and for the specified device, display of predetermined property information and other various requests can be performed.
[0051]
Further, in the above-described example, the method of acquiring the identity information online from the real device and creating the virtual device has been described. However, the present invention is not limited to this, and the device list held by the setting tool 10 may be selected. , A virtual network can be constructed offline.
[0052]
As an example, a list of device lists is displayed in the left window shown in FIG. Then, the designer can select a device to be used from the device list, and add the device to the virtual network by dragging and dropping the device onto the virtual network display window on the right side. Each device (product name) listed in the device list is associated with at least Identity information, and accesses the plug-in manager 22 based on the Identity information of the specified device to acquire a corresponding module. Thereafter, a virtual network can be constructed by the same processing as the online virtual network described above.
[0053]
When a module corresponding to a new device (for example, device C) is added, an interface for installation is provided in a setting tool, and a setting file to be added and a module are specified, so that a specific directory in which the module is stored is set. Copy the file to Thereafter, the plug-in manager 22 is reconfigured.
[0054]
In the above-described embodiment, an example has been described in which a single device unified interface is used when setting a device. However, the communication interface can be unified by the same idea. That is, there are various communication interfaces, for example, Ethernet (registered trademark) and RS-232C. Also, the communication interface may differ depending on the manufacturer.
[0055]
Therefore, normally, since the setting tool main body 11 directly transmits and receives data to and from each communication interface, it is necessary to prepare a program portion corresponding to each communication interface. Therefore, it is necessary to upgrade the version of the program in order to support a new communication interface.
[0056]
However, in the present embodiment, the communication unified interface 15 is provided similarly to the device unified interface 12, and the setting tool main body 11 transmits and receives data only to and from the communication unified interface 15. Then, a communication module 16 for each communication interface is provided, and the communication module 16 for the communication interface can communicate with the communication unified interface 15. As a result, the setting tool main body 11 can communicate with another device via an arbitrary communication interface, but a command or the like used at that time may be one type corresponding to the communication unified interface 15. Therefore, even when a new communication interface is added later, it is only necessary to prepare and add a communication module (communication module C) for the new communication interface, and it is not necessary to improve the setting tool body. Therefore, a communication interface can be easily added.
[0057]
【The invention's effect】
As described above, in the present invention, a device unified interface and a communication unified interface are provided, and the setting tool main body transmits and receives data to and from the unified interface, and transmits data to and from the originally set destination device and communication partner. Since transmission and reception are performed by an extension module or communication module corresponding to the unified interface, settings for different devices can be easily performed, and various communication interfaces can be supported.
[Brief description of the drawings]
FIG. 1 is a diagram showing a preferred embodiment of the present invention.
FIG. 2 is a diagram showing a relationship between a setting tool main body, a device unified interface, and an extension module.
FIG. 3 is a diagram illustrating a relationship between a device unified interface and an extension module.
FIG. 4 is a diagram showing an example of property information display.
FIG. 5 is a diagram illustrating an example of property information display.
FIG. 6 is a diagram illustrating a relationship between a setting file and an extension module and the like.
FIG. 7 is a diagram showing a preferred embodiment of the present invention.
FIG. 8 is a diagram illustrating an example of a display screen according to the present embodiment.
[Explanation of symbols]
10 Setting Tool
11 Setting tool body
12 Device Unified Interface
12a Unified interface
12b body
Unified interface for 12c extension module
14 Extension module
14a Expansion module unified interface
14b Extension module body
15 Communication unified interface
16 Communication module for interface
17 Setting wet file
18 Display icons
19 EDS file
21 Database
22 Plug-in Manager
23 Virtual Network
30 Network
31 devices

Claims (9)

A setting tool that requests function settings such as parameter settings and monitor requests for the device;
A device unified interface for receiving a function request of the setting tool body,
The device unified interface is capable of communicating with the device unified interface and transmitting and receiving data to and from an extension module created in accordance with the device, so that a request corresponding to the function request received from the setting tool body is generated. A setting tool device having a function of outputting to the extension module. The device unified interface has a function of returning, to the setting tool body, information obtained by adding information owned by itself to information transmitted from the extension module in response to the request. 2. The setting tool device according to 1. 3. The setting tool device according to claim 1, wherein the extension module has a plurality of types, and one is for a standard-compliant device connected to a network. 4. The setting tool device according to claim 1, further comprising the extension module. The identification information set for the device and the correspondence list of the extension module for the device are stored and held,
When the device identification information is acquired, an extension module for the device is acquired from the correspondence list, the identification information and the extension module are combined to generate an object for the device, and a virtual network is constructed using the created object. The setting tool device according to any one of claims 1 to 4, wherein the setting tool device has a function of performing the setting. Identification information to be set on the device, and a setting file including information for associating the extension module for the device,
Storing the extension module,
2. A function for reading information stored in the setting file and the extension module at a predetermined timing and generating a correspondence list of the identification information and the extension module for the same device. 6. The setting tool device according to any one of items 1 to 5. A setting tool that requests function settings such as parameter settings and monitor requests for the device;
A communication unified interface to be accessed when the setting tool body performs communication,
The communication unified interface transmits and receives data to and from a communication module created in accordance with a communication interface of a network to which a communication partner of the setting tool main body is connected. A setting tool device having a function of enabling communication of the setting tool. A setting tool program for requesting device settings such as parameter settings and monitor requests;
A device unified interface program that receives a function request issued along with the execution of the setting tool program,
The device unified interface program is a program for executing processing of transmitting and receiving data to and from an extension module created for the device and outputting a request corresponding to the received function request to the extension module. A program product characterized by having a part. The device unified interface program, a process of acquiring information sent from the extension module in response to the request,
9. The program product according to claim 8, further comprising a program portion for executing a process of returning information obtained by adding information owned by the user to the acquired information to the setting tool program.

Images