Fieldbus & Industrial Networking

Continuous EtherCAT at all levels

September 2011 Fieldbus & Industrial Networking

The widely known EtherCAT Device Protocol, often referred to simply as the EtherCAT protocol, is used at the field level for I/O communication within a machine or machine part. Special features are, among others, the highly accurate determinism with very low cycle times (down to <100 μs), precise synchronisation for drive and measurement applications as well as low cabling and commissioning costs when using the technology at the I/O level. The process control level requires further communication options in order to operate a plant or a factory. EtherCAT with the EtherCAT Automation Protocol offers a solution to this.

The devices at field level are controlled by a higher-level controller. Large plants such as in the automotive industry incorporate numerous machine lines. Here, the controllers of each area of the plant need to exchange data and, under certain circumstances, the exchange of data between I/O devices from different parts of the plant may be useful.

This results in the following requirements for a communication protocol to be used at production control level:

* Data exchange between EtherCAT masters (master-master communication) = data exchange at controller level.

* Data exchange between EtherCAT master and visualisation.

* Connectivity of higher-level controls to devices in lower-level EtherCAT segments (routing).

* Data exchange between EtherCAT masters and other devices, such as configuration tools.

Additional requirements:

* Standard Ethernet communication interface.

* No strict requirements for cycle time and synchronicity.

* Cyclic communication in the millisecond range.

* Use of standard infrastructure elements such as switches for the networking of devices.

These requirements are met by the EtherCAT Automation Protocol (EAP), which strengthens the vertical integration of EtherCAT throughout the overall system.

EtherCAT protocol types

The EtherCAT protocol can be transmitted via Ethernet (EtherType 0x88A4), via UDP (User Datagram Protocol, UDP port 0x88A4) or via TCP (Transmission Control Protocol, TCP port 0x88A4). Here, the transmission medium is irrelevant: fast Ethernet or Gigabit Ethernet connections via copper or optical fibre are just as possible as the use of the protocol via a wireless connection. This way, it is possible to integrate even complex parts of the plant that cannot be connected via a fixed cable (eg, floor conveyor, rack storage and retrieval systems).

The EtherCAT frame appends itself to the user data in these telegrams. The header of the EtherCAT frame specifies the EtherCAT protocol type.

EtherCAT slaves that are connected to an EtherCAT master always use the EtherCAT Device Protocol.

For the implementation of the protocol, an EtherCAT communication chip, the EtherCAT Slave Controller (ESC), is used in the EtherCAT slaves. This exclusively evaluates telegrams of type 1. Cyclic and acyclic data can be transmitted in an EtherCAT frame with this type.

Types 4 and 5 are used for the EtherCAT Automation Protocol. If process data follow, then type 4 is used; in the case of mailbox data, type 5 is in the EtherCAT frame header. The mailbox protocols (CoE, SoE and FoE), as already used with the EtherCAT Device Protocol, can similarly be used with the EtherCAT Automation Protocol.

EAP message routing

Message routing must be possible from the configuration tool via the EtherCAT master to the EtherCAT slave, so that master devices can exchange data with one another or, for example, so that a configuration tool can set para-meters in a drive in the lower-level EtherCAT segment.

To this end, the EtherCAT Mailbox Protocol AoE (Automation Device Protocol over EtherCAT) is used. This protocol is advantageous because it is capable of routing and can therefore be passed through several levels in order to reach the lower level object directories.

Each Ethernet port in the master is implemented as an AoE device and has its own AoE NetID assigned. Routing from one port to another is performed by an AoE router in the master, which is similarly assigned an AoE NetID. Any port or AoE device and the associated information can be accessed via the AoE NetID. The information that will be made available to the network is structured in object directories. Their precise content differs depending on the task of the AoE device/port.

Object directory

An object directory is a list of variables and parameters. Each entry is addressed via an index of its own and possibly via a sub-index. The entire index space is subdivided into several ranges. The separation of the index space into defined ranges makes the structuring of the data clear. Moreover, this is the basis for the use of algorithms with which the collation of the process data (PDO configuration and PDO assignment) is organised.

Profile-specific range for the EAP

The profile-specific range from index 0x6000 onwards is defined by so-called device profiles. Corresponding device profiles have been specified for many classes of devices (drives, I/O devices). The Modular Device Profile (MDP profile number 5001) is used for the EAP and defines the use of the index space. Special classes of devices are classified into this grid by sub-profiles (eg, for gateway devices). The EtherCAT Automation Protocol has its own sub-profile number (1000) like the EtherCAT Device Protocol (1100) for the EtherCAT master function to the lower-level EtherCAT segment. The AoE router has the sub-profile number 9000.

On a master that supports both the EtherCAT Automation Protocol and the EtherCAT Device Protocol, the ports to the respective network have their own object directory with the corresponding sub-profile number.

Sub-profile 1000 – EtherCAT Automation Protocol

The object directory for sub-profile 1000 is used for the configuration of the communication relationship between two EAP devices. It describes the process data, as used for the EAP.

Sub-profile 1100 – EtherCAT Device Protocol

The object directory of the EtherCAT segment lists all connected slaves. A slave is described here in the object directory as a module.

Sub-profile 9000 – EtherCAT Router Information

The router object directory contains a list with available device interfaces and their AoE NetIDs.

EAP – cyclic data exchange

The exchange of process data in the EAP can take place following either the ‘Pushed’ or the ‘Polled’ principle. In ‘Pushed’ mode each communication device sends its data cyclically or in a multiple of its own cycle. The receiver can be configured to specify which data should be received from which sender. The configuration between the sender and receiver data is performed via the object directory according to sub-profile 1000.

In ‘Polled’ mode the data is queried by the devices. To this end, a device, frequently the higher-level master computer, sends a telegram to the devices to which these reply with their own telegram. This also makes it possible to synchronise the devices.

Structure of the process data

The content of a process data telegram is described in the same way as the process data of an EtherCAT slave. A telegram corresponds to a SyncManager area, so that the structure of the process data of a telegram is determined via the PDO assignment and PDO configuration.

A device defines its output variables (Tx process variables) in the index range from 0x6000. An index is used for each variable (variable 1: 0x6000, variable 2: 0x6001, etc). The name, length and variable type, eg, process or diagnostic data, are combined with the actual value of the variable. Only the variable value itself is transmitted in the process data telegram.

The process variables can then be grouped arbitrarily with the aid of the Tx Mapping PDOs from 0x1A00. A variable can also be transferred into several PDOs. The structures of variables described via the mapping are combined with a variable ID, version (Version) and age (Quality). This is done in the Tx process data range from 0xD000.

The process data must now be assigned for the transmission of an Ethernet frame. The assignment and order of each process data is defined via the assign objects in the range from 0x8000.

On the receiver side, the sender of the received frames is determined by the publisher ID in the frame header. With this, the variable ID and version from the PDO header, the receiver can find the Process Data Index (from 0xE000) containing the reference to its internal target variable. Thus, the index of the target variables, in which the received variable value is stored as an input variable, is determined via the mapping PDO found (from 0x1600).

The configuration of the process data structure at the receiver side is arbitrary, as at the sender side. The index assigned to an Rx process variable is independent of the index of the Tx process variable. Since the output and input variables are pre-configured, the establishment of an additional connection before the beginning of communication is no longer necessary.

EAP – acyclic data exchange

In order to configure the output and input variables and to access the object directories of the master or those of the EtherCAT slaves, acyclic access is enabled to these. To this end, the AoE (Automation Device Protocol over EtherCAT) protocol is used. This allows multiple object directories to be addressed.

A telegram of type 5 (mailbox communication) is used as the transport protocol. The structure of the frame is identical to the mailbox communication within an EtherCAT segment.

The mailbox protocols CoE, SoE and FoE can in turn be mapped on the AoE protocol. As a result, a configuration tool can be connected to the master, for example, in order to access a drive in the EtherCAT network for configuration purposes.

Example of plant automation with EAP

The production of solar modules involves a large number of process steps, for which marking and identification systems, measuring units and special handling modules are used.

The conveyor system used is divided into as many as 14 process islands, wherein each segment is equipped with a control computer and an operating computer. Furthermore, Control Panels can be connected as necessary at any point on the production line.

The exchange of data is realised through the EAP. Each station exchanges status and control information bi-directionally with both the previous and next station: 600 bytes in each direction with a cycle time of ten milliseconds. Added to this is the communication with the control computer, which additionally exchanges up to 1 Kbyte of data bi-directionally with each station.

For more information contact Kenneth McPherson, Beckhoff Automation, +27 (0)11 795 2898, ,


Share this article:
Share via emailShare via LinkedInPrint this page

Further reading:

New XTS functionality enables novel solutions in machine building
November 2019, Beckhoff Automation , Motion Control & Drives
XTS is a smart transport system of magnetically driven movers that travel along tracks consisting of motor modules and guide rails. A Beckhoff Industrial PC is able to control the movers independently ...

Process 4.0 breakfast seminar series
November 2019, Beckhoff Automation, VEGA Controls SA , News
Beckhoff Automation recently partnered with VEGA to present another highly successful series of breakfast seminars at venues across the country, with the theme Process 4.0. Beckhoff managing director, ...

PC-based control platform optimises water treatment product dosing
October 2019, Beckhoff Automation , System Integration & Control Systems Design
Clean water is vital in both consumer and commercial areas, including numerous industrial applications, such as mining, petroleum refining and groundwater remediation, in addition to residential applications

Interference-free Ethernet media converter
October 2019, Phoenix Contact , Fieldbus & Industrial Networking
The new FL MC EF 660 SCRJ media converter from Phoenix Contact enables the connection of cost-effective polymer and HCS/PCF fibre technology. The optical transmission of data via fibre optics is free ...

I/O solutions with Profinet redundancy
October 2019, Turck Banner , Fieldbus & Industrial Networking
Turck’s Simple IO-Link Device Integration, SIDI for short, simplifies the handling of IO-Link. As its first fieldbus module with Profinet S2 system redundancy, the company has introduced the TBEN-L5-8IOL. ...

Tektronix simplifies automotive Ethernet testing with new software
October 2019, Comtest , Fieldbus & Industrial Networking
Tektronix has released two new software packages that greatly simplify Automotive Ethernet testing, debug and protocol decode, for use with its 5 and 6 series mixed-signal oscilloscopes (MSO). Using the ...

How fieldbus systems are really selected
September 2019 , Fieldbus & Industrial Networking
The majority of users do not actively select their fieldbus at all – they select the control system vendor and whatever bus system this vendor provides will ‘do the job.

Flexible communication across building and mobility applications
September 2019, Beckhoff Automation , System Integration & Control Systems Design
TwinCAT OPC UA connects research and innovation infrastructure on Empa campus.

Process 4.0 Breakfast Seminar Series 2019
September 2019, Beckhoff Automation, VEGA Controls SA , News
Beckhoff Automation, in partnership with VEGA, are proud to present the second South African Process 4.0 Seminar for industry. The 2019 seminars are aimed at industry segments such as oil and gas production, ...

Fibre optic distributor for network expansion on demand
September 2019, Jasco Trading t/a Webb Industries , Fieldbus & Industrial Networking
Jasco’s Webb Industries has introduced Telegärtner’s new, modular rail-mount fibre optic distributor, which can be extended according to actual needs. The stackable modules allow quick and easy additions ...