The Meyle CANopen encoder is an absolute encoder. The version described sends its current position to another station via the 
"CAN-bus" transmission medium (physically: screened and twisted two-wire line). 
The serial bus system CAN (Controller Area Network), which had been originally devel­oped for automotive uses, is gaining ground in industrial automation technology. The system is multimaster compatible, i.e. sev­eral CAN- stations are able to request the bus at the same time. The data transfer is regulated by the message's priority. The message with the highest priority (deter­mined by the identifier) will be received immediately. Within the CAN system, there are message identifiers but no transport addresses. The message which is being sent can be received by all stations at the same time (broadcast). By means of a special filter method, the station only accepts the relevant

messages which is of importance for this station. The identifier transmitted with the message is the basis for the decision as to whether the message will be accepted or not. 
The bus coupler is standardised according to the international standard ISO-DIS 11898 (CAN High Speed) and allows data to be transferred at a maximum rate of 1 MBit/s. The most significant feature of the 
CAN-protocol is its high level of transmission reliability (Hamming distance = 6). The CAN­Controller Intel 82527 used in the encoder is basic as weil as full-CAN compatible and supports the CAN-specification 2.0 part B (standard protocol with 11-bit- identifier as weil as extended protocol with 29-bit identifier). 

In applications, where the position of a drive or of other parts of a machine has to be recorded and signalled to the control system, the encoder can carry out this function. The encoder can resolve, for 

instance, positioning tasks by sending the check-back signal concerning the present drive position via the CAN bus to the positioning unit. 

• synchronisation of the devices,
• auto-configuration of the network,
• comfortable access to all device parame­ters.
 

CANopen uses four communication objects (COB) with different features: 

• Process Data Objects (PDO) for real-time data
• Service Data Objects (SDO) for the transfer of parameters and programs
• Network Management (NMT, Life­Guarding)
• predefined objects (for synchronisation, time stamp, emergency message)

• simultaneous data input and output.
• cyclical and event-controlled process data processing,
 

All device parameters are stored in an object directory. The object directory contains the description, data type and structure of the parameters as weil as their addresses (index). 
The directory consists of three parts: 

• communication
• profile parameters,
• device profile parameters and manufactur­er specific parameters.
 

This profile describes a standardised and binding, but manufacturer-independent defi­nition of the interface for encoders. The pro­file not only defines which CANopen func­tions are to be used, but also how they are to be used. This standard allows an open and manufacturer-independent bus system. The device profile consists of two object cat­egories 

• the standard category C1 describes all the basic functions the shaft encoder must contain

• the extended category C2 contains a vari­ety of additional functions which either have to be supported by category C2 shaft encoders (mandatory) or which are option­al. Category C2 devices thus contain all C1 and C2 mandatory functions as weil as, depending on the manufacturer, further optional functions. In addition, an address­able area is defined in the profile, to which, depending on the manufacturer, different functions can be assigned.

In CANopen, the data is transferred by means of two different communication types (COB = Communication Object) with differ­ent features: 

• Process Data Objects (PDO) 
• Service Data Objects (SDO) 
 

The priority of the message objects is determined by the COB identifier. The process data objects (PDO) serve the highly dynamic exchange of real-time data (e.g. position of the shaft encoder) with a maximum length of 8 Byte. 

This data is transferred with high priority {low COB identifier). PDOs are broadcast messages and put their information simulta­neously at the disposal of all desired receivers. The service data objects (SDO) form the communication channel for the transfer of device parameters (e.g. programming of the shaft encoder's resolution). Since these parameters are transferred acyclically (e.g. only once when starting up the network), the SDO objects have a low priority {high COB identifier). 

The basic functions of the PROFIBUS DP are only described in extracts in here. For additional information, please refer to 

the standards on PROFIBUS DP, i.e. DIN 19245-3 and EN 50170 respectively. 

The Meyle Profibus encoders are absolute encoders. The version described sends its current position to another station via the transmission medium "PROFIBUS DP" (physically: screened and twisted pair line). The Profibus encoder supports all class 1 and 2 functions listed in the encoder profile . PROFIBUS-DP is standardised and binding, but manufacturer-independent definition for a variety of applications in the field of pro­duction, process and automation. The requirements of openness and independ­ence from the manufacturer are stipulated in the European standard EN 50 170. 

PROFIBUS-DP permits the communication of devices produced by different manufac­turers without any particular adaptations of the interfaces. PROFIBUS DP is a special standard version for a quick data exchange within the field level which has been opti­mised in terms of speed and low connection costs. Central with local field devices like drives, valves, or encoders. The data exchange between these devices is pre­dominantly cyclical. The communication functions required for this exchange are determined by the functions of the PROFIBUS DP according to the EN 50 170 European standard. 

In systems, where the position of a drive or of any other part of a machine has to be recorded and transmitted to the control system, the encoder is doing this function. The encoder can resolve, for instance, 

positioning tasks by sending the feedback signal concerning the present drive position via the PROFIBUS DP to the positioning unit.

• Address assignment for the DP slaves via the bus
• Cyclical user data transfer between DP master and DP slave(s)
• Configuration of the DP master (DPM1) via the bus
• Single DP slaves are dynamically activated or deactivated
• Control of the DP slave's configuration.
• Powerful diagnostic functions, 3 stepped diagnostic message levels.

• DP master class 2 (DPM2), e.g. program­ming/ project planning devices
• DP master class 1 (DPM1), e.g. central automation devices like SPC, PC
• DP slave e. g. devices with binary or ana­logue input/output, drives, valves
 

Operate: cyclical transfer of input and output data 

The extensive diagnostic functions of PROFIBUS DP allow a quick localisation of possible errors. The diagnostic messages 

are transmitted by means of the bus and are joined together at the master. 

To ensure a high level of exchangeability between the devices, the system perform­ance of PROFIBUS DP has also been stan­dardised. lt is mainly determined by the operational status of the DPM1. The DPM1 can either be controlled locally or via the bus by the project planning device. The following three main states are available: 

The DPM1 has entered the data transfer phase. In case of a cyclical data traffic, the input is read by the DP slaves while the out­put is transferred to the DP slaves. After an error has occurred during the data transfer phase of the DPM1, like for example, the failure of a DP slave, the response of the system is determined by the operating parameter "Auto Clear". lf this parameter has

been set to true, the DPM1 will set the out­put of all the respective DP slaves to the safe status, as soon as a DP slave is no longer available for user data communication. Afterwards, the DPM1 changes to the clear status. lt this parameter is = false, the DPM1 remains, even if an error occurs, in the oper­ate status, and the user can determine the response of the system at his own decision. 

There is no data traffic between DPM1 and the DP slaves. 

The DPM1 reads the input information of the DP slaves and maintains the safe status of the DP slaves' output. 

The data traffic between the DPM1 and the respective DP slaves is automatically handled by the DPM1 in a fixed, recurring order. When configuring the bus system, the user assigns a DP slave to the DPM1. In addition the slaves are in- or excluded from the user data communication. The data traffic between the DPM1 and the DP slaves is subdivided in three phases: parameterisa­tion, configuration, and data transfer. Before including a DP slave in the data transfer phase, the DPM1 checks during the parameterisation and configuration phase, 

whether the planned set configuration cor­responds to the actual configuration of the device. For this check, the device type, the information on the format and the length as weil as the number of input and output lines have to be correct. Due to this check it is ensured that the parameterisation is reliable and correct at the end. In addition to the user communication, which is automatically executed by the DPM1, the user can request the new parameterisation data to be sent to the DP slaves. 

PROFINET, launched by PROFIBUS Interna­tional (PI), is a new-generation industri­al-ethernet-technology-based automation bus standard. PROFINET provides a sound and complete network solution for automation communi-

cation, including topical issues in the field of automation such as real-time Ethernet, motion control, distributed automation, fail-safe and network security. This cross­supplier technology is compatible with industrial Ethernet and existing profibus technology to protect existing investment.

To achieve the above communication functions, the following three communication proto­col levels are defined. [1] 

• TCP/IP is for PROFINET CBA and factory debugging, with a response time of about 100ms.
• RT (real-time) communication protocol is for PROFINET CBA and PROFINET 10, with a response time of less than 1 Oms.
 

IRT 0sochronous real-time) communication protocol is for PROFINET 10 communication of the drive system, with a response time of less than 1 ms. Ethernet analysis tools help to record and display the packets of the PROFINET communication protocol. Some software interpret PROFINET data frames.

A PROFINET CBA system includes many automated components, mechanical, elec­tronic or IT variables generated by standard programming tools. Components are described by PROFINET Component Descrip­tion (PCD) files in XML format. Planning tools load these descriptions and establish logical relationships between the different components. This mode is considerably influenced by the EC 61499 standard. The basic concept of PROFINET CBA is that many times the automation system can be divided into several small subsystems, clear1y 

distinguished from each other. PROFINET components are generally controlled by only a few input signals. With these components, the program written by the user activates a specific function in the component and transmits the output signal to another, using a maker-neutral technology. Com­ponent-based communication requires only planning, not programming. PROFINET CBA communication (non-real-time communi­cation) is suitable for systems with a bus cycle time of 50-100 ms. 

PROFINET network communicates with external devices through PROFINET 10. PROFINET 10 defines the communication function of external devices connected to the field. lts basis is the real-time concept of cascading. PROFINET 10 defines the controller (with "master function" equipment) and other equipment (with "slave function" equipment) complete data exchange, param­eter setting and diagnosis functions. PROFINET 10 is designed to provide fast data transmission between Ethernet-con­nected devices and supports the provid­er-consumer model. Devices that support the PROFI BUS communication protocol can be seamlessly connected to the PROFINET network without the need for IO-proxy and other devices. Device developers may use commercially available Ethernet controllers to develop PROFINET 10 devices. PROFINET 10 is suitable for systems with network cycle times of several milliseconds. [2]

PROFINET 10 system package: 

• 10 controller that controls the automated task.
• 10 devices, generally field devices controlled and monitored by 10 controller. One 10 device may include several modules or sub-modules.
• 10 monitor, a PC software, can set param eters and diagnose the status of individual modules.

PROFINET 10 establishes an application relation (AR) between the 10 controller and the 10 device, in which communication relations (CR) with different characteristics such as parameter transmission, periodic data exchange, and warning processing are defined. 

Each module in the PROFINET network has the following three addresses: 

• MAC addresso
• IP addresso
• Device name is the logical name defined for the module in the entire network configuration. Since PROFINET uses TCP/P, MAC address and IP address are used. In case a device is replaced with another, its MAC address changes, and the IP address is the result
 

of dynamic addressing. To have a fixed name for a certain device on the network, a device is named. 
To assign IP addresses, subnet masks and default gateways, the following two methods are defined: 
DCP (Protocol) (Discovery and Configura­tion Protocol). 
DHCP (Dynamic Hast Configuration Protocol).

In the PROFINET 10 network, program data and warnings are transmitted in real time. The real-time of PROF-INET is according to the definition of IEEE and IEC, which allows real-time services to be processed within a limited time within a network cycle. Real-time communica­tion is the basis for PROFINET 10 data

exchange. When processing, the real-time data is higher than that of TCP (UDPVIP data in priority. PROFINET RT, the basis for decentralized peripheral real-time commu­nication, is also for the PROFINET compo­nent model (PROFINET CBA). The bus cycle time for general data exchange is within hundreds of microseconds. 

The isochronous data exchange of PROF­INET is defined in the isochronous real time (IRT) function. PROFINET 10 field devices with IRT functionality have switch ports integrated in the field devices and can be based on Ether­net controllers ERTEC 400/200.The bus cycle time for general data exchange is from hundreds of milliseconds to several micro-

seconds. The difference between isochro­nous communication and real-time commu­nication is that the former features a high degree of certainty. The start time of the bus cycle can be maintained to a high accuracy with a jitter of up to 1 µs. Motion control applications like motor position control programs use isochronous real-time commu­nication. 

Application profile (profile) is a special device or a pre-defined function and feature configu­ration for a special application. The PROFINET application profile is formu­lated by the PI (PROFIBUS & PROFINET International Association) working group and issued by PI. Application profiles contribute to the openness, interoperability and interchange­ability of equipment, so end users can be sure that similar equipment provided by different equipment manufacturers will have standardized functions and usage methods.

Choices by users promote the competition of equipment manufacturers, which improves the function of the product and lowers the cost. PROFINET has many application profiles, such as for encoders, PROFldriveand PROFIsafe. There are even dedicated application profiles for trains. In 2009, German automakers proposed the PROF­lenergy application profile, which mainly manages energy consumption during vehicle manufacturing.