A short introduction on CANopen
|
Automating with CANopen
CANopen is a standard for distributed industrial automation technology
based on CAN-bus. It was developed by the manufacturer and users
association CiA (CAN in Automation) and has been standardized since
late 2002 as CENELEC EN 50325-4. CANopen has established itself in a
number of areas of industrial communication (e.g. mechanical
engineering, drive systems and components, medical devices, building
automation, vehicle construction, etc.). The fundamental communications
mechanisms are described in the so-called Communication Profile.
Devices from different manufacturers can be used in a CANopen network
and work in harmony with each other. Frameworks complement the
communication profile for specific applications. This is how frameworks
are defined for safety-compliant data transfer ("CANopen Safety") or
for programmable devices (e.g. PLCs). The so-called object directory is
the central element of every CANopen device and describes the device's
functionality.
Object Directory
The object directory is the central element of a CANopen device. It
describes the complete functionality of the device from the vantage
point of the network. The object directory represents the interface
between the network and the application. All entries in the object
directory are referenced using a 16-bit index and an 8-bit sub-index.
The object directory contains all of the parameters accessible via the
network. Device identifiers, manufacturer name, communications
parameters for the PDOs and SDOs and device monitoring ("error
control"), for example, are stored in the generally applicable area of
the object directory. The device-specific area contains the connection
to the process; that is, the I/O functionality (analog and digital
inputs and outputs), parameters for drives, mapping of a PLC process
image. The behavior in the event of an error can also be configured in
the object directory. Accordingly, the behavior of a device can be
adapted to the respective utilization requirements using the object
directory.
Device Profiles
Device profiles describe the properties and features of the most
important device types that are utilized in automation technology. Both
functions and parameters of the respective standard device types are
defined. All parameters are stored in the object directory. In this
way, it is ensured that the CANopen devices can be accessed in the same
fashion using the CANbus. This creates the prerequisite for a
far-reaching multi-vendor capability through interoperability and
interchangeability of different manufacturers' devices. Device profiles
are defined for digital and analog I/O devices, drives PLCs,
controllers, for example. The parameters and properties of the CANopen
devices are described in a standardized EDS file (electronic data
sheet) in ASCII format. It can be understood as a 'form' containing all
device properties that are accessible over the network. The actual
parameters of a particular device configuration are stored in the DCF
(device configuration file). A DCF is derived from an EDS.
Data Transfer using PDO/SDO
CANopen differentiates between two data transfer mechanisms. Fast
exchange of short process data is done using process data objects
(PDOs, Process Data Object). Access to the entries of the object
directory is done via SDO (Service Data Object). PDOs can be
transferred event-controlled, cyclic or on-demand. Transfer is done
without protocol overhead as broadcast objects. A PDO transfers up to 8
bytes of data. A synchronization message synchronizes the sending and
data migration network-wide. The properties of each PDO can be
configured in the object directory. This includes the communications
parameters (CAN-identifiers, transmission type, etc.) and the
assignment of the process data to the respective PDO using so-called
PDO mapping. SDOs are confirmed data transfers using 2 CAN-telegrams.
They establish point-to-point communication between two devices. In
this way, large data packets (> 8 bytes) can be transferred for each
SDO.
Network Management
Network management (NMT) is available for control of the device status.
It is structured as a master – slave relationship. A CANopen device
sends a signal to the NMT master via a boot-up message that it is
initialized and is active on the network. The device status of
individual devices or of the entire network can be specifically
influenced using NMT commands. Every device status is characterized by
specific properties. PDOs are transferred only in the OPERATIONAL
status. Configuration of the device can be done in the PRE_OPERATIONAL
condition. The STOPPED condition blocks communication by means of both
PDOs and SDOs. "Node – Guarding and "Heartbeat" are two alternative
services that monitor the communication capability and the status of a
CANopen device. Alarm messages are defined for reporting device errors.
These high-priority 'emergency' messages are transferred
event-oriented. Standardized error codes describe in more detail the
errors that occur.
CANopen Safety
CANopen networks enable transfer of safety-oriented information. Safety
functions (e.g. Emergency OFF, Two-handed operation) can be integrated
into a CANopen network. Special safety-relevant services (SRDO, Safety
Relevant Data Object) accept the communication. An SRDO transfers up to
8 bytes of safety information. Transfer of the data is done redundantly
in a defined time window.
|
|
|
Sitemap
Printversion
We appreciate your feedback!