Technical classification

The application and communication properties of a Beckhoff IO device (EtherCAT terminal EL/ES/EM/EK, EtherCAT Box EP/EQ, special designs CU) are determined by the following three elements: the device, the firmware (optional) and the EtherCAT slave device description (ESI).
An electronic automation device with fieldbus connection consists of many further (internal) components and software such as the ESC (EtherCAT Slave Controller, the real-time communication IC); however, the three mentioned above are those that outwardly define the device’s properties for the user.

Details of the three components:

The material device itself, the ‘hardware’ (HW)

• is marked by Beckhoff with the hardware version, e.g. HW01.
• in EtherCAT parlance the device is also often referred to as a slave in the sense of the fieldbus topology, because it is addressed by the EtherCAT master.
• the hardware version.
• is printed on the outside of the device, see serial number/batch number
• can be read from the CoE directory in devices that have one
• can be read by the EtherCAT master from the EtherCAT/ESI-EEPROM since 2012/01
• is coded in decimal or hexadecimal depending on the device series

The firmware that runs on it, if applicable

• Note: firmware (FW) is the name given to the program code made by the manufacturer (Beckhoff) and executed on a µC (microcontroller, FPGA or processor). Not all devices have to have a µC and thus firmware!
• this can consist of several files if necessary and must be loaded to the IO device. Usually these are *.efw or *.rbf files
• is marked by Beckhoff with the firmware version, e.g. FW02
• the firmware version
• is printed on the outside of the device, see serial number/batch number.
• can be read from the CoE directory in devices that have one.
• can be read by the EtherCAT master from the ESI-EEPROM since 2012/01.
• if a firmware update of the device is carried out, the imprint on the housing is to be adapted accordingly by the person performing the update or by the user.

The EtherCAT ESI communication description as the device description file for the EtherCAT master (in case of Beckhoff: integrated in the TwinCAT software)

• describes the EtherCAT communication interface between device and master in all aspects that are relevant to data communication and synchronization
• is on the one hand programmed by Beckhoff on the IO device itself (into the so-called EtherCAT/ESI-EEPROM)
• so that the device can announce basic information of its own accord on being scanned by the EtherCAT master: size of the process data (PDO), setting options (CoE) and others.
• in addition this ESI contains the basic settings for the IO device itself that are relevant to its function and are read on the device by the µC or other control components at power-on.
• should on the other hand be available to the EtherCAT master as a file
• since the EtherCAT master software now ‘knows’ the slave even without electrical access, the user can also create his bus configuration ‘offline’, i.e. without live contact to the IO device, as is absolutely necessary when scanning.
• and in addition the EtherCAT master knows how it must address the slave over EtherCAT and the functions that the latter offers. As a result, cyclic process data and CoE directory of the slave, for example, are determined for the master. Without an ESI file the master does not know the device at all.
• if an EtherCat slave is to be connected to the NC in TwinCAT, the availability of the ESI device description is absolutely necessary
• Note: there are EtherCAT masters that obtain the device information from the slave only by scanning and do not require any ESI file from the device.
  If necessary TwinCAT can also operate ‘on-line’ without the availability of an ESI file; however, it is recommended that the correct ESI file be available for TwinCAT for a simple reason: many EtherCAT devices now have a wide range of functions and extensive setting options. This then results in a large ESI file that can perhaps no longer be saved in the local EtherCAT/ESI-EEPROM – although the reduced information which is then available there is sufficient for basic operation of the device, the full function and diagnostic scope of the device is not available.
  In addition, offline configuration is possible only if the ESi file is available.
• is marked by Beckhoff with the so-called revision e.g. -0018
  if there is a change in the contents/function of the ESI, the revision number is usually increased by +1
• the revision
• can be read by the EtherCAT master from the EtherCAT/ESI-EEPROM.
• can also be read from the CoE directory in devices that have one.
• has been printed on the outside of the device since 2014/01 → "Rev. xxxx"
• if a revision update of the device is carried out, the imprint on the housing (if there is one) is to be adapted accordingly by the person performing the update or by the user.

Due to their properties, all three elements can have an effect on

• functional properties, e.g. filter, sample rate, output rate, input sensitivity and others
• temporal behavior e.g. during bootup,
• behavior and diagnosis in case of error
• communication features, e.g. process data, parameter directory,
• Distributed Clocks properties, e.g. types of trigger, synchronicity, latency and others
• exterior appearance

These three elements are to be found as follows in the application world:

Explanations on the basis of the principles mentioned above:

• the ESI is programmed in the device (EtherCAT/ESI-EEPROM) and determines the EtherCAT interface from the point of view of the µC; the EtherCAT real-time communication is performed by the ESC (EtherCAT Slave Controller).
• the EtherCAT master requires the ESI in order, for example, to incorporate it into its system configuration. To do this it can read the EtherCAT/ESI-EEPROM online. If the ESI is directly available to it, however, then offline configuration is also possible.
  As a result, master and slave/device now have the same definition of the EtherCAT interface and can communicate with one another.
• the µC (if there is one) maps the function of the device and communicates with the ESC for this. It also controls the IO side of the device, if this not already done by the ESC.
• the parameter directory ‘CoE’ (CANopen-over-EtherCAT) of the device is managed by the µC, i.e. ‘online’. The ESI file also contains a copy of this, the so-called ‘CoE offline dictionary’. This enables the user to view the possible functions offline in advance and if necessary to preconfigure the start-up list.
  Changes in the online CoE are saved fail-safe in Beckhoff IO devices and in the AX2000  in general in a local EEPROM (unless parameterized differently). The AX5000, conversely, has an SoE directory (Sercos-over-EtherCAT), which always starts in the default state on power on; changes required by the user must be loaded to the slave, for example by startup list, on each bootup of the EtherCAT master.

Illustrated in a simplified manner, these three elements map the entire device, wherein the ESI is used both in the device and in the master:

Depending on the type, the entire device can also be marked by a sequential, unique device number. See also the Identification notes.