This paper talks with readers about how to understand and write EDS files.
Why is the EDS file very important? A well-designed EDS file will make the integration of equipment very easy; A poorly designed EDS file will cause many misjudgments or in some cases it is impossible to realize the integration of devices at all. The following are some suggestions for writing well-designed EDS files. The different parts of EDS will be introduced in the order in which they appear (in the order in which they appear in EDS ASCII file, in the order of brackets []), and their functions and the information they contain will be described. [file] file segment. This section is used to manage EDS files. If the keywords provided are insufficient to provide some management details, you should use comments to add additional information. For example, it includes: device name, creation date, creation time, modification date, modification time, version number, URL address and so on. It is strongly recommended to use URL (Uniform Resource Locator) keyword so that users can find the latest version of EDS file. Example: The following is the paragraph of [document] of a product of Vanke Company:
[file] DescText? = "EDS file of WAGO I/O system with Ethernet /IP coupler";
Date of creation? = 04-22-2004;
When was it created? = 12:00:00;
ModDate = 04-22-2004； ?
mod time = 12:00:00；
Revision? = 1. 1;
$? HomeURL = "/wago web/Germany/ger/support/downloads/data/75034 1 _ 1 . eds "； [Equipment] Equipment section. This section contains ID information to match EDS files found on the network. This section contains the most important elements in the EDS file. Recognition is achieved by reading the first five attributes of the ID object and comparing them with the corresponding information in the EDS file. They are: supplier code, supplier name, product type, product type name and product code.
Any devices distinguished by runtime options must be hidden in different EDS files, so they must have different ID object attributes.
After EDS is installed, an icon file will be specified in the Devices section to automatically assign icons to devices. The practice of not using icons is strongly opposed, because icons are the best graphical representation to distinguish the types/series of devices in the network. For users, this is also the easiest way to distinguish identities. Example: The following is the [device] paragraph of a product of Vanke Company:
[device] VendCode? = 40; ? $ supplier code
VendName？ = "Wago Company "; ? $ Name of supplier
ProdType？ = 12; $ Product Type-Communication Adapter
ProdTypeStr = "communication adapter"; $ product type string
ProdCode？ = 34 1; $ product code
Majerev? = 1; ? $ major version
Ming Leifu? = 1; ? $ minor version
ProdName？ = " WAGO Ethernet-STD "；
catalog = " 750-34 1 "；
$ Icon？ = " 75034 1 _ 1 . ico "； [Equipment Classification] Equipment classification section. This section classifies EDS/ devices used for Ethernet /IP.
This is a requirement for all devices used in Ethernet /IP. It must contain at least one network portal to Ethernet /IP. For example, the following is the [Equipment Classification] section of a product of Vanke Company.
[Equipment classification]
++++++++++++++++++++++++++++++++This section specifies the CIP connection of the device.
After the [file] file segment, the [device] device segment and the [device classification] device segment are the most important segments of an Ethernet /IP device, which can only be the target of CIP connection. EDS-based configuration tools can only use the connections specified in this section. And all trigger and transition types should be realized by connecting n portals. For example, the connection 1 belongs to the category 1, which is only used for input; Connection 2 belongs to category 1 and is only used for listening. Connection categories 0 and 1 are usually specified in the EDS file (category 0 is used for secure connections and category 1 is used for other connections). Today, no other transmission category has been used, and there is no EDS-based tool to translate other categories.
If there are multiple connections, different options can establish connections with different functions for devices, and each connection needs to be marked with a connection n entry. Only in a few cases can connection n entries of multiple connections be "multiplexed", for example, using parameters of connection point information. Using the transmission type and selecting the connection parameters must generate a meaningful combination to match the function of the target device. If some options are mutually exclusive, but the device can support them, then select a series of separate connection n entries to override them. Tools like EZ-EDS can help users prevent some illegal combinations, but not all. This tool can also help users decode the trigger/transmission values and connection parameters of 32-bit encryption. Choosing a meaningful name for each independently connected n-entry can help users make fewer mistakes in use. All N entrances need a path; Otherwise, the target device will not connect to any data. We strongly recommend supporting all three application paths (configuration, consumption and production), because this is also one of the recommendations of ODVA organization, that is, the recommended function of Ethernet /IP devices. When configuring paths, you usually don't need to use symbols (labels) to connect. From source to destination (o->; T) and from destination to source (t->; O) Attributes (request data interval, size and format) can use some very meaningful information. When the RPI (Request Packet Interval) value is not specified, the configuration tool can select any value that can be supported according to the given bus (network), and the value may exceed the capability of the device. Using a fixed RPI value does not need much consideration, because it is a value that can only be selected. In most cases, it is best to use the parameter n entry in the EDS file to define the minimum/maximum/default value of RPI. For size and format, at least one value should be filled in these two areas. If both areas are filled in, the large and small areas take precedence; Only format areas are used, defined by numbers, and large cells are left blank; If you do not use format, you can leave it blank. It is strongly recommended to define the format. In the configuration properties section, two configuration formats and two configuration dimensions are allowed. This feature can handle modular devices well. The first part of the data generated in the Forward_Open request is used for the consumption of the adapter; The second part of the data is forwarded to the corresponding module to meet the requirements of the module. For non-modular equipment, one part is enough. For example, the following is a section of [Connection Manager] of a product of Vanke Company.
[Connection Manager] [Assembly] Assembly, [Params] parameter and [ParamClass] parameter category segment.
These segments should be properly filled in the EDS file according to the requirements of other parts, for example, connecting the N entry.
If the parameter value is not limited to a sub-area, for example, a minimum/maximum value is defined in the area at the entrance of parameter n, then there will be a good data when enumerating. When configuring parameters for Ethernet /IP devices, we hope to put them into the configuration assembly. You can define a single parameter in EDS, but some commercial tools are not allowed to access a single parameter inside the device and can only work with explicit information (Get/Set_Attribute_Single or Get/Set_Attribute_All).
Example: The following is a [ParamClass] paragraph of a product of Vanke Company.
[param class]MaxInst = 10； ? % of the total number of configuration parameters
Descriptor? = 0x0A？ $ supports all complete attributes and is stored in non-volatile storage.
CFG assembly = 0；
[Capacity] Capacity segment.
This paragraph describes the communication capability of the device itself (so it is very useful for the company). You should describe the number of connections and the connection speed (frames per second). [Port] Port segment.
This section provides port information, which is only useful for devices that need to perform CIP routing. Although allowed, this section is unnecessary for devices that support a single CIP port. When a switch is built into a device, such as a device with multiple Ethernet ports, the network segment is still unnecessary (or limited to one port) unless the device performs CIP routing from one port to another.
Editor: Liu Jing