Non-Native Devices: .eds and .gsd files

When designing a control system, sometimes it becomes necessary or advantageous to communicate with devices that were not made by the PLC manufacturer. If these devices need to be placed on an Ethernet, DeviceNet or Profibus network there are methods that manufacturers have developed to make this easier.

In order to communicate properly with devices that aren’t native to a manufacturer’s platform, information about the device needs to be transferred into a controller’s I/O configuration. Examples of devices that can be controlled over a network are Variable Frequency Drives (VFDs), servo systems, remote I/O blocks, vision systems and other controllers.

Both eds and gsd files can be viewed and modified using a simple text editor such as Notepad.

Siemens method of adding devices involves the use of a .gsd (General Station Description) file. All field devices with slave functionality as well as all class 1 masters that require compatibility with Profibus and Profinet must be described by the manufacturer using these text-based files.

The following is from the Profibus manual. ProfiNet (Siemens version of Ethernet) files follow a similar format.

“Project planning tools for the PROFIBUS-DP master to be included in the project interpret the content of slave GSD files and generate from it a master parameter set for the class 1 master that will be in charge of payload traffic.

A class 1 master uses information from the GSD files of connected slaves to determine the expansion level of the bus, which services are supported by the slave in question, and the form in which data is exchanged.

GSD files are required for project planning and commissioning. Every manufacturer of a PROFIBUS-DP class 1 master provides a project planning tool for the class 1 master that knows the internal data structure of both the class 1 master and the host system. When making the project, the necessary GSD files must be made known to the project planning tool. This usually takes place when the GSD files are copied onto the PC’s hard disk. (A precise path indication can be obtained from the description of the project planning tool). When planning a system project, the project planning tool interprets GSD file data for the chosen field device. Plausibility checks are also carried out at this early stage to ensure that project planning data has the correct logical construction.

A GSD file may be present either once, as when its construction is language-neutral (*.gsd) or several times, as when it has been written in a particular local language. In this case, a separate GSD file should be used for each language and they should only differ from each other in their visible-string type parameters. Language-related GSD files differ in the last letter of their extensions (*.gs?).

Default (language-neutral): ?=d
German ?=g
English ?=e
French ?=f
Italian ?=i
Portuguese ?=p
Spanish ?=s

The following rules apply for GSD-file names:

Abc_0008.gsd

signifying the following:

Abc_ = company identifier (here company Abc_), always 4 characters
0008 = Ident number 0008 assigned by the PNO , always 4 characters in hexadecimal
.gsd = default. Language-neutral GSD(E) file

The properties of a devices are described with key words and values.

For historical reasons, there are different revisions of GSD syntax with an increasing number of key words. The latest version today is (2013) Version 5. The first key word therefore indicates the version of the GSD file:

GSD_Revision = 1
Vendor_Name= “Company_ABC & Co”
Model_Name= “Modular I/O Station”
Revision= “Version 01”

The manufacturer’s name, model name and revision of the device are limited to 32 characters as a visible string.

Revision_Number= 05

Version identifier for the DP device. The revision number here must match the revision number in the slave-specific diagnosis.

Ident_Number=0x00A2

The ident number identifies the type of DP device. Every field device is characterized by an ident number allocated to it by PROFIBUS International. It creates a unique reference to the GSD file and therefore to the technical data of that field device. Variants of field devices, which can be described with a GSD file, can use the same ident number (for example modular devices). It is only possible to exchange data with a field device if the DP master identifies the DP slave uniquely with the ident number during system start-up (parameter setting telegram).

An ident number may be ordered from PROFIBUS International. It is also possible to view here a list of currently used ident numbers.

Protocol_Ident= 0 ;PROFIBUS-DP device

Protocol used by DP device.

0: PROFIBUS-DP,
16 to 255: vendor-specific

Station_Type= 0 ;PROFIBUS-DP Slave

DP device type
0: DP slave,
1: DP master (class 1)”

After importing a .gsd file into a Siemens project, the device appears in the I/O folder for easy selection while defining the networking and I/O structure of the project. So far, I have never had a problem with this procedure when using Siemens PLCs. On the other hand…

Allen-Bradley’s method of communicating with non-native devices uses a different type of text file called an “Electronic Data Sheet” or eds.

Unlike gsd files, it is not as simple as simply importing the eds into the project. In versions of RSLogix5000 prior to release 20, it was necessary for the vendor to create an Add-On Profile (AOP) according to Allen-Bradley’s instructions and have it approved for inclusion. In other words, if the device is not present in your software for selection (as all of the A-B devices are), you will not be able to add it yourself.

The eds can be imported using RSLinx, but this simply gives the RSWho browsing tool a method of displaying the node and its icon. It does not provide a tag configuration that can be used to access the device; this still needs to be done using the Generic Ethernet Module object. Even when the eds file is provided, the object often shows up as a yellow question mark in RSWho; this is often due to some part of the file not matching the device’s attributes exactly. Even a rev. number seems to cause this to happen.

Version 20 of RSLogix5000 has made some improvements to creation of the AOP by using the eds file. The following information is extracted from RTA Automation’s blog, an article on the Ethernet/IP eds changes in v20:

Quick Summary

Despite the marketing hype as to the value of EDS values prior to 2012 there was no advantage to constructing EDS files with complete product data. Few, if any, tools were able to use these kinds of EDS files in the way they were intended.

Now with V20 of RsLogix5000 this has all changed. This White Paper describes the changes and how device vendors can take advantage of these changes.

EDS File Overview

Electronic Data Sheets (EDS) are simply ASCII files that describe how a device can be used on an EtherNet/IP network. It describes the objects, attributes and services available in the device.

At the minimum, an EDS file conveys the identity information required for a network tool to recognize the device. For EtherNet/IP Scanners, the EDS File conveys information on the EtherNet/IP Adapters I/O messages. It details the specifics of the Input Message produced by the EtherNet/IP Adapter and the Output message consumed by the Adapter.

The amount of information stored in an EDS file varies from device to device. Some manufacturers store the minimum amount of information in the EDS file while other devices store all the details of every object and attribute in the device.

EDS files are sometimes shipped with a device in some media format like a CD or made available on the device manufacturers website. Some devices with extended data storage contain the EDS file internally within the device.

EDS File Structure

File Section – Administers the EDS file. Sometimes the URL keyword provides a link to a website where the latest version of the EDS can be found.

Device Section – Provides keying information that matches the EDS to a particular revision of a device. The first three attributes of the Identity Object (Object #1) are used by network tools to verify that this EDS file (Vendor, Model,…etc) plus the device revision matches the information found in the device. The network tool will not connect to a device unless all four Identity Object Parameters match.

Some people mistakenly believe that the Minor Revision number is included in this match but that is not true.

The ODVA recommends that the icon for the device be specified in the EDS so that users can have a graphical way of distinguishing devices.

Device Classification Section – Classifies the EDS for an EtherNet/IP network. The Device Classification Section is required for all EtherNet/IP devices.

Connection Manager Section – Identifies the CIP connections that are available in the device. This section indicates to the EtherNet/IP Scanner the Triggers and Transports available in the device. If a device supports multiple connections then every connection must be detailed in this section.

Only connections that are specified in this section can be used in an EDS-based configuration tool.

Assembly, Params and ParamClass section – These sections are filled in as needed. For values that are limited to a limited to a defined set of values, Enumeration can be used to specify those values. Value ranges can be specified here also for Configurable parameters.

Capacity Section – This section indicates the number of connections available in the device and the connection speeds

Port Section – This section describes the Ethernet port. It is only applicable to devices that perform CIP routing. It is unnecessary for devices containing a single CIP port.

Configuration Data

EDS Files also support definition of the Configuration block. The Configuration data block is simply a series of data words that are downloaded to device on power up or reset. These blocks provide one-time initialization of an EtherNet/IP device.

Changes in V20 of RsLogix5000

After many years, V20 of Rockwell’s RsLogix5000 programming tool added support for EDS Files. Here’s a list of the changes:

Configuration Support

This version of RsLogix provides the capability for an end user to configure a device using the Enumeration, Ranges and other limitations imposed on a configuration parameter as specified in the EDS file.

Prior to this version, end users typically had to use a vendor tool, a web page, a built in display or some other mechanism to configure a device. Now configuration of all devices can be done from within one, identical tool.

Configuration Data Block Support

Configuration data blocks can now also be defined by RsLogix5000 if it is exposed as a meaningful data structure in the EDS File.

Module Discovery

You can now browse for devices on the network with supported EDS files and add them into the I/O scan list with a single button press. You no longer need to know the catalog number, slot number or network address to add a device to the I/O tree.

What’s still Missing

One disappointment. We were disappointed to learn that, unlike the configuration data, the EtherNet/IP Servers Input and Output Assemblies are still defined as Tags composed of a block of data even when the EDS has defined the structure in a meaningful way.

In other words, other than being able to view a device as an icon from the I/O tree, there hasn’t been that much of a change. The eds file still doesn’t create the tags and structures needed by itself.

The other less obvious problem is that while vendors may provide an eds file on their website or even within the device itself, they usually don’t provide the information needed to create a Generic Ethernet Module unless asked. I have not been able to easily extract the information needed for Assembly Instances or Data Types easily from the eds either; it seems to always be trial and error.

A couple of weeks ago in Miami I needed to add a couple of devices to my project and ran into this problem. It was quite frustrating; I eventually was able to solve the problem with help from both the vendor and some excellent input from a couple of guys at www.plctalk.net. The complete thread can be found HERE if you are interested.