CiA 402: Internationally standardized profile

for electrical drives

Holger Zeltwanger - August 04, 2008

Since many years, several suppliers of frequency inverters, servo controllers, and stepper motors
have used the CiA 402 profile as embedded network (system bus system) to link several devices. In
addition, many drive vendors provide CiA 402 compliant interfaces to communicate with the host
controller or encoders and other sensors.

General and type-specific PDO mapping

The new features of the internationally standardized include a type-specific PDO mapping. PDOs
(Process Data Objects) are unconfirmed single CAN messages described by two parameter sets (PDO
communication parameter set and PDO mapping parameter set). PDOs are used in CANopen
networks to transmit real-time commands and real-time status information as well as set values and
current values. In case of drives and motion controllers, they transmit the control-word received
from the host controller and the status-word transmitted to the host controller.

The PDO mapping parameter set contains pointer to addresses in the CANopen object dictionary,
where the information to be transmitted is stored or where the received data shall be stored.
Theoretically the system designer is able to map up to 64 single-bit information into one PDO. In
practice, normally you map data single- or multi-byte wise into PDOs. For example, the mapped
control-word is a 4-byte process data.

Figure 0: Structure of the IEC 61800-7 series of PDS profiles

In the beginning, CiA 402 specified just a generic PDO mapping, which was used for frequency
inverter, servo controller, or stepper motor. There were seven pre-defined PDOs to be transmitted
(TPDO) and eight pre-defined PDOs to be received (RPDO). According to the CiA 301 CANopen
application layer specification (EN 50325-4), only four TPDOs and four RPDOs are assigned with
pre-defined CAN identifiers. Pre-defined CAN identifiers determine the content of the message as
well as its priority on the network. The not pre-defined PDOs are disabled at all. They need to be
configured (in minimum enabled and assigned with a CAN identifier) by the system designer
regarding the PDO communication parameter. The PDO mapping parameters are already pre-
defined.

Figure 1: Type-specific CANopen PDO mapping for frequency converters

The PDO configuration was not a problem for complex drive devices that requires anyhow some
sophisticated configuration for different drive-specific parameters. To configure also the PDO
communication was not a big deal for well-educated system design engineers. However, for simple
low-cost drives and motion controllers, the user did not like any sophisticated configuration by
means of software tools and detailed knowledge of CANopen protocols and profiles. In particular,
low-cost frequency inverters should be integrated into CANopen networks without configuration.
That is why the type-specific PDOs were introduced. They are optimized for frequency inverters on
one side and servo controllers as well as stepper motors on the other side. In the device type object
(index 1000h) the used PDO mapping is indicated as well as the kind of motion control function
(frequency inverter, servo controller, or stepper motor). The host controller reads the PDO behavior
by means of SDO (Service Data Object). SDO is a confirmed peer-to-peer communication protocol
providing a client-server communication service.
Figure 2: Type-specific CANopen PDO mapping for servo controller and stepper motor

The client (in this case the host controller) has always the initiative. It reads the device type object
of the server (drive or motion controller) in order to get knowledge of the function and the used PDO
mapping (generic or type-specific). The host controller knows than how to operate and communicate
with the drive or motion controller. SDO communication may also be used to reconfigure the drive
and motion controller including the PDO communication and mapping parameter sets. Simple
devices do not need any configuration because they are used just in the pre-configured manner.

Different operation modes

Even if the drives and motion controllers use the type-specific PDO mapping, it could be necessary
to change the pre-defined configuration of the operation mode. Devices compliant to CiA 402 may
support different operation modes. In particular, servo controller and stepper motors may use
different modes. The change of operation modes is also possible on the fly during runtime. The
operation modes include profile position, profile velocity, profile torque mode, and interpolated
position mode.
Figure 3: CiA 402 finite state automation (FSA)

CiA 402 specifies also a homing mode with many options. In the IEC 61800-7-201 standard some
new operation modes have been introduced (cyclic sync position, velocity, or torque mode). They are
suitable for non-intelligent drives and motion controllers. All the intelligence including the trajectory
generator is located in the host controller and not in the drive or motion controller. On the one hand
this unburdens the drive devices from local control tasks, on the other hands it concentrates all
intelligence in to the host controller, which is not always desired. Ethercat users who want to use
the CiA 402 profile requested these cyclic sync modes. The CiA 402 profile could also be
implemented on other (Ethernet-based) network technologies.

CiA 402 on Ethernet-based networks

All CANopen profiles can be used on other than CAN-based networks, too, if they implement the
CANopen dictionary and CANopen functional compatible communication services. The more the
protocols comply the easier is the development of gateways. There are CiA 402 implementations for
Ethercat, Ethernet-Powerlink, Safetynet p, and Varan available. The use of the CANopen dictionary
structure and the CANopen profiles is generally permitted to any interested party, if they fulfill the
following conditions:

• The structure of the CANopen dictionary is not changed and use as specified in CiA 301.

• The index range 6000h to 9FFFh is reserved for standardized CANopen profiles by CiA.

• The index range 1000h to 1FFFh is free for non CAN-based communication technology consortia
with three exceptions: The objects 1000h, 1001h, and 1018h are specified by CiA. The world-wide
unique vendor-ID contained in 1018h is assigned by CiA only.

• The index range A000h to AFFFh shall be used for network variables.

• The index range B000h to BFFFh shall be for system variable as specified in CiA 302-7
(respectively in CiA 400).

• The index range C000h to FFFFh is reserved for CiA use. The finite state automaton (FSA)
specified in IEC 61800-7-201 shall be implemented. The transitions are caused by the control-word
received from the host controller by means of PDOs or due to internal events. The FSA status is
provided by means of the status-word to the host controller. Process data, configuration parameter
as well as status information shall be addressed in the object dictionary as defined in the CiA 402
standard. Most of these parameters are optional, meaning they are only implemented, if the device
provides the corresponding functionality. There is only small set of mandatory parameters, because
the drive and motion control functionality differs widely. Nevertheless, the system designer and end-
user benefit from standardized profiles.
Figure 4: Block diagram of CANopen drives featuring CiA 402

The CiA 402 profile safes host controller software investments by means of reusing software
routines and packages. Another benefit is the reduction of education effort. Once learnt the CiA 402
basic principles and the CANopen communication mechanism (such as PDO configuration), you are
able to configure and integrate each CiA 402 compliant device. Only some device-specific functions
have to be learnt extra.

Summary

The type-specific PDO mapping simplifies system integration. The CiA 402 profile specification as
described in IEC 61800-7-201 has also been simplified, meaning not used process data and
parameters have been dropped. The introduced cyclic sync operation modes allow an optimized use
on master/slave communication systems such as Ethercat. Other Ethernet-based networks such as
Ethernet-Powerlink, Safetynet p, and Varan are also using CiA 402 for standardized motion control
applications. In CANopen networks, CiA 402 is implemented also on very small sized motion
controllers. They are used in many embedded control applications including mission-critical medical
equipment. Those applications require a high-reliable network with a very low probability of non-
detected errors. Only CAN provide such features, typical examples include image diagnostic devices
as well as intensive care unit (ICU) patient beds.

Holger Zeltwanger is CEO of CAN in Automation (CiA)