Cos Pre

Download as pdf or txt
Download as pdf or txt
You are on page 1of 25

Protocol Manual

CANopen Slave

Hilscher Gesellschaft fr Systemautomation mbH
Rheinstrae 78
D-65795 Hattersheim
Germany
Tel. +49 (0) 6190 / 9907 - 0
Fax. +49 (0) 6190 / 9907 - 50
Sales: +49 (0) 6190 / 9907 - 0
Hotline and Support: +49 (0) 6190 / 9907 - 99
e-mail: hilscher@hilscher.com
Homepage: http://www.hilscher.com
Index Date Version Chapter Revision
1 28.09.98 1.000 all initial version
Although this protocol implementation has been developed with great care and intensively tested, Hilscher
Gesellschaft fr Systemautomation mbH cannot guarantee the suitability of this protocol implementation
for any purpose not confirmed by us in writing.
Guarantee claims shall be limited to the right to require rectification. Liability for any damages which
may have arisen from the use of this protocol implementation or its documentation shall be limited to cases
of intent.
We reserve the right to modify our products and their specifiactions at any time in as far as this contribu-
tes to technical progress. The version of the manual supplied with the protocol implementation applies.
List of Revisions 2
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
1 Introduction to the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 . . . . . . . .
2 CANopen Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . . . . . . . .
2.1 The requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . . . . . . . .
2.2 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 . . . . . . . .
2.3 Introduction to CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . . . . . . . .
2.3.1 Insertion of CANopen into the CAN Application Layer (CAL) . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . . . . . . . .
2.3.2 The CANopen communication profile (CiA DS-301) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . . . . . . . .
2.3.3 The classification of the data types in the CANopen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . . . . . . . .
2.3.3.1 PDO (Process Data Object) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 . . . . . . . .
2.3.3.2 SDO (Service Data Object) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 . . . . . . . .
2.4 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 . . . . . . . .
2.5 Device profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 . . . . . . . .
2.6 Simple Start-Up Through Pre-Defined PDO Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 . . . . . . . .
3 Communication Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 . . . . . . . .
3.1 Parameter Communication (SDO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 . . . . . . . .
3.2 Process Data Communication (PDO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 . . . . . . .
3.3 Transmission Lock Time or also Inhibit Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 . . . . . . .
3.4 The Mapping of the PDOs and the Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 . . . . . . .
3.4.1 The Default Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 . . . . . . .
3.4.2 User-Specific Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 . . . . . . .
3.5 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 . . . . . . .
3.6 Emergency Telegrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 . . . . . . .
3.7 Nodeguarding and Lifeguarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 . . . . . . .
3.8 The Default Identifier Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 . . . . . . .
4 Capabilities of the CANopen Slave (Node) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . .
4.1 SDO and PDO Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . .
4.2 Node Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . .
4.2.1 Node Managent States and Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . .
4.2.2 Node Guarding/Life Guarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 . . . . . . .
4.3 Object Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 . . . . . . .
4.4 Handling of Process Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 . . . . . . .
4.5 Device Start-Up and Default Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 . . . . . . .
4.5.1 Device Start-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 . . . . . . .
4.5.2 PDO Default Mapping and COB IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 . . . . . . .
5 Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 . . . . . . .
5.1 Diagnostic LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 . . . . . . .
Table of Contents 3
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
1 Introduction to the system
The processing of closed loop and open loop control information for machinery
and systems with the aid of powerful microchips is widespread in modern auto-
mation technology. As a rule, such intelligent units of an automation complex are
connected together by one or more communications networks. Within the pro-
duction facility as a whole, the networks are incorporated in various hierarchical
levels, starting with the administration network for the works and ranging up to
the network of sensors and actuators in the manufacturing process.
The growing degree of automation and the demand for more and more
decentralised units has caused a considerable increase in the quantity of data
exchanged in all areas. The establishment of a new concept to accommodate this
large flow of data therefore appeared unavoidable.
The lowest hierarchical level in particular, that of sensors and actuators, required
the industry to establish a communications network in which the data generated
there simultaneously could be transmitted qualitatively and quantitatively as
rapidly as possible to the higher level process without the already time critical
process sequences noticeably suffering from the transmission speed of the bus.
In the search for a suitable bus system in the field bus area, the parallel
transmission process in which each sensor or actuator is connected individually
to the higher level controller in a network with star topography was found
unsuitable as soon as cost effectiveness calculations revealed that the costs of
installation and maintenance exceeded the benefits derived from rapid data
transfer.
The only solution here was single cable transmission with serial bus systems,
meeting the modern demands for flexible process adaptation and reconfiguration
or system expansions.
Introduction to the system 4
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
2 CANopen Fundamentals
2.1 The requirements
The connection between the decentralized process sequence and the centralized
control system established by the communications system takes place on the
lowest hierchical level via the field or process bus.
On this level, the primary requirement is that for a simple protocol sequence and
short data transfer times in communications. This guarantees the shortest possible
system reaction time to dynamic peripheral conditions.
Together with classical I/O data exchange, acyclical transmission of parameter,
diagnostic and configuration data must be possible without decisively impeding
the real time capabilities of the bus. Only in this way can a good diagnostic
concept be fulfilled and operational reliability be ensured.
2.2 Characteristics
The main function of the CANopen is the transmission of process data from the
controller system to the peripherals and vice versa in a predefined profile. The
access is done in the master-slave principle. One ore many master are controlling
their assigned slave respectively node devices on the bus in polling or event ope-
ration. A data exchange is initiated by a polling message and can be terminated
by an acknowledgment message of the addressed node device. A simultanous ac-
cess of two devices is possible, but intercepted and dissolved in the bus protocol.
The access method of CANopen permits combined operation of several bus ma-
sters, sychronous data transfer to several nodes and 2048 different communicati-
on objects called identifiers. The identifiers are defined in their functionality in
the CANopen communication profile (CiA DS-301). An identifier decides to
which of the 126 possible node device the message is transferred to. The CAN
protocol in general solves bus conflicts while simulanous bus access of two devi-
ces by message priority. This priority is specified by the header identifier of the
message itself, which is always leading the message on the bus as a header infor-
mation. The lower the identifier, the higher the priority of the message and becau-
se of the bus address is directly propotional to the identifier of the message, a
node device with a lower address has in comparison with a device of a higher ad-
dress a higher priority and herewith a better chance to send its message A device
which was interrupted in sending a message by a message higher priority, starts
its send attempt again after the high priority message has ended. If the device do
not succeed in sending its message, the device goes into a defined error state.
CANopen Fundamentals 5
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
2.3 Introduction to CANopen
2.3.1 Insertion of CANopen into the CAN Application Layer (CAL)
In the international CAN organization "CAN in Automation" (CiA) a general
description language for CAN networks came into existence with the CAL appli-
cation layer. CAL makes a useful collection of communication services available
but refuses to bind itself to their exact application. For this reason, CAL is sui-
table for a multitude of applications; but one only must always define which data
are to be transferred with which services .For this purpose, CANopen utilizes a
portion of the communication services on offer for defining an open communica-
tion service suitable for industrial systems. In this way, CANopen defines, in in-
dividual profiles such as for encoder or simple I/O devices, etc., what the data in
the various device classes mean and what their functions are. With CANopen the-
refor, it is possible to link devices of different classes by means of a network and
at he same time to communicate with each other .
2.3.2 The CANopen communication profile (CiA DS-301)
The CANopen communication profile specifies elements for exchange of real-ti-
me data and parameter data as well as offering a simplified network management.
Here, special attention is paid to the resource-saving implementation ability and
therefor of good performance of the corresponding software layer.
2.3.3 The classification of the data types in the CANopen
CANopen utilizes optimized services for various types of data. On the basis of
different requirements this results in two types of data .
2.3.3.1 PDO (Process Data Object)
Real-time data
High priority Identifier
Maximum 8 Bytes per message
Data definable per message
The process data objects allow themselves to be transmitted in a configurable
manner and on the basis of events or synchronized basically, as it is required in
the drive technologies. Thus, the PDO data exchange utilizes all the CAN-speci-
fic advantages:
CANopen Fundamentals 6
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
In the event controlled mode, a participant transfers the PDO only when a data
content has changed. This procedure can find an application, for one, at an end
device for a fixed process input alteration or, for another, in the Master system
for a fixed process data output alteration By means of this mode, the bus loading
is reduced to a minimum, a high communication capacity is achieved with a com-
paratively low Baud rate.
In the so-called Remote-Polling query, PDOs are called up cyclically by means of
a short CAN-specific Remote Telegram. A typical application is the cyclical
retrieval of process input data from the Master. The Remote-Polling query of
outputs in the Master system for node end devices is not usual in CANopen.
In the synchronized transmission, the PDOs are first transmitted to all desired
participants. These are not passed on to the connected peripherals within the
nodes as long as the Master system has not send a so-called SYNC message. As
the SYNC telegram is received simultaneously by all participants, the process da-
ta outputs are passed on to the peripherals at the same time. Normally, the Master
transmits the SYNC message in a fixedly defined time raster. By means of the
synchronized mode, for instance, it is possible to synchronize several axis of a ci-
nematic, to set outputs simultaneously or to arrange inputs in a parallel method.
Both modi can be operate in a mixed manner.
2.3.3.2 SDO (Service Data Object)
Parameter data
Lower priority Identifier
Data multiplexed on several CAN messages
Data addressed by means of Index
The Service-Data-Object (SDO) makes a high capacity data channel available for
parameter data of any desired size. Typical device parameters can be written in-
to, or retrieved from, the object directory of the device with a single Telegram-
Handshake. Here, the structure of the CANopen object directory corresponds ex-
actly to that of other bus systems so that a high degree of compatibility of the
user layer is given .The Objects to be written to, or read from, are addressed by
means of a 16Bit Index, which provides the object address. A second Index, the
so-called 8Bit Sub-Index, makes possible the sub-addressing of individual varia-
bles of the Object.
CANopen Fundamentals 7
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
2.4 Network Management
The network management supports a simplified start-up of the network and can
be modularly extended depending on the requirements of the installation. Default
values are provided for all network parameters (including device functions).Thus,
one configuration is sufficient in most cases. If the user wishes to optimize the
CANopen network, or to expand it functionally, he can set all the parameters
himself. For this purpose there are either configuration tools available from se-
veral manufacturers or parameters can be set immediately in the Hilscher Master,
which makes an additional node manager superfluous.
2.5 Device profile
In the CANopen device profile, the data contents are determined in a manufactu-
rer-independent manner which means that the base functionality of the correspon-
ding device class (e.g. input/output module group, servo drives or frequency
transformer) can be accessed in a unified manner. Thus, devices which follow the
same device profile are interchangeable. Although many optional parameters ha-
ve already been described, the device profile offers room for manufacturer-
specific function expansions.
2.6 Simple Start-Up Through Pre-Defined PDO Mapping
The variable occupation (mapping) of he process data objects makes possible the
optimal utilization of the available bus band width. For the purpose of a simple
start-up, CANopen provides default values for all parameters.Therefor, Default
Mapping of the Process Data Objects is defined in the same manner as the Identi-
fier allocation which becomes active after the first switch-on. These settings sa-
tisfy the requirements of most installations and prevent additional configuration
effort.
CANopen Fundamentals 8
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
3 Communication Model
As already mentioned in the introduction, the communications via CANopen can
be carried out logically in the process data.The process data is transmitted by me-
ans of Process Data Objects (PDOs) whilst the Service Data Object (SDO) is
available for the service data .In addition to PDOs and SDOs there are also:
Identifiers for the Boot-Up
Identifiers for the dynamic Identifier allocation according to DBT
Identifiers for the Nodeguarding/Lifeguarding.
An Identifier for the synchronization (SYNC) of inputs and outputs (or e.g.
drives)
Identifiers for emergency messages
3.1 Parameter Communication (SDO)
The parameters contained in the object directory are retrieved and described by
means of Service Data Objects. From the view of CAL, these SDOs are multiple-
xed domains, i.e. data structures of any size that are provided with a Multiplexer
(address). In CANopen the Multiplexer comprises a 16-Bit-Index and
8-Bit-Sub-Index, that address the corresponding entries in the Object Directory.In
the CAL terminology, the CANopen I/O modules are Servers for the Multiplexed
Domain SDO, that is, at the request of the Master (Client), they make data
available (Upload), or they receive data from the Master (Download). In this
manner, a Handshake takes place between the Client and the Server. If the para-
meter to be transmitted takes up to 4 Bytes, then a single Handshake is sufficient
(a Telegram Pair).For the Download, the Client sends the data together with In-
dex, Sub-Index and the Server confirms the receipt. For Upload, the Client re-
quests the data in that it transmits the Index and Sub-Index of the desired parame-
ter and the Server sends the parameter (incl. Index and Sub-Index) in its answe-
ring telegram. The same Identifier pair is used on the bus for Upload and Down-
load .In the 8 Byte sized telegrams, the various services are coded in the first data
Byte. Except for the Objects 1008h, 1009h and 100Ah (device name, hardware or
software version) all parameters of the decentralized I/O modules are only up to a
size of 4 Bytes and for this reason this description limits itself to the transmission
of these data in the speeded-up Transfer (CAL: Expedited Transfer).
Communication Model 9
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
3.2 Process Data Communication (PDO)
All real-time data are transferred via the Process Data Objects. CANopen has de-
fined default settings for the data content. These can be altered by the user by me-
ans of the so-called Mapping.
As selected, PDOs can be transferred as event controlled or synchronized. Also
the requirement of the CAN feature "Remote-Transmit-Request" is supported. In
this way the application demands can be met in a flexible manner.The PDO com-
munication parameters (Index 1400 ... 1403 and 1800 ... 1805) describe the trans-
fer behavior of the PDOs. Here the PDO Identifiers, the method of transfer, the
sending lock time (Inhibit time) and the CMS priority group are described.
The PDO Identifier can either be written directly into the corresponding Object
Directory entry or (with the use of the extended Boot-Up) it can be allocated via
the dynamic Identifier distribution according to CAL (DBT services). After swit-
ching on, the most important PDOs default Identifiers, which are led off from the
node addresses are available. In addition, the PDO Identifier Entry in the Object
Directory makes the activation and deactivation of PDOs possible.
The method of transfer defines the sender behavior of the corresponding Process
Data Object. Basically, a choice can be made between event-controlled and syn-
chronized transfer.
In the event-controlled transfer, an event which has reached the module triggers
the transfer of a PDO, in the synchronous mode, the PDO is transferred on receipt
of a Synchronization Telegram (SYNC). As the method of transfer for each PDO
is determined separately, it is possible for a module to carry out several methods
of transfer (e.g. for inputs of different real-time characteristics) simultaneously.
Communication Model 10
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
The table below clarifies the utilization of the parameters of the PDO method of
transfer:
method of
transfer
PDO transfer
(decimal) cyclic acyclic synchron asynchron polling
0 X X
1-240 X X
241-251 - reserved-
252 X X
253 X X
254 X
255 X
In the transfer type 0, the PDOs need not be transferred cyclically. The output da-
ta of a received PDO are written to the outputs upon receipt of the next following
Synchronization Telegram (SYNC). A telegram with input data is only sent if the
input process data on receipt of the SYNC, has changed since the last received
SYNC telegram.
In the transfer types n = 1 ... 240, the PDOs are transferred every nth cycle
(SYNC). The output module groups write the output values to the outputs only on
receipt of the nth SYNCs even when the values of some SYNCs were transferred
earlier.The input modules read their inputs our on receipt of the nth SYNs and di-
rectly thereafter send the corresponding PDO. An input alteration that was reset
before receipt of the the SYNC is therefor not noted. If such alteration(s) are to
be acquired, the use of the event-controlled mode is recommended.
In the transfer type 252, the PDO must be polled by means of a Remote Transmit
Telegram. The answer to this poll, however, will only be sent off after receipt of
the next Master SYNC Telegram.
The transfer type 253 means that, despite the arrival of an event, no PDO is tran-
ferred, but must be polled by the Master by means of Remote Transmit.
The transfer of a PDO of the transfer type 254 is triggered by a manufacturer-
specifoc event on the module (e.g.: alteration of a mannufacturer-specific error
signal).
The transfer of a PDO of the transfer type 255 is triggered by means of an event
described in the device profile (e.g.: the change of a digital input).
Communication Model 11
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
3.3 Transmission Lock Time or also Inhibit Time
The Inhibit Time prevents the CAN-bus being overloaded by a module with a
high priority message (too high bus loading). It defines the time period between
two telegrams with the same Identifier.a further possibility of reducing the bus
loading is the event-controlled operation in which the process picture itself is not
constantly transferred but just the the alterations of it.
3.4 The Mapping of the PDOs and the Data Storage
The objects with real-time character from theOobject Directory are depicted in
the Process Data Objects by means of the Mapping tables. The input/output mo-
dules can support up to bit type Mapping. An altered Mapping has immediate ef-
fects on the correponding PDO .
3.4.1 The Default Mapping
The Default Mapping is available after the switch-on. Digital inputs or outputs
are displayed on a bit basis in accordance with their sequence in the PDO. Analo-
ge inputs or outputs are normally depicted as 16-Bit vallues in accordance with
their sequence. No user-specific Mapping needs to take place.
3.4.2 User-Specific Mapping
By means of modification in the Mapping tables in the Object Directory (Index
1600h ... 17FFh and 1A00h ... 1BFFh), it is possible to achieve user-specific PDO
occupation. CANopen generally permits the mapping of each Object known to
the node such as, e.g. also the Error Register or the Status Register, although in
individual cases, it must be ascertained that the device also controls the Mapping
of the selected Object. Usually a list of the supported Mapping Objects will be
found in the manual of the device.As the utilization of the user-specific Mappings
leads to increased processing times in nodes it is possible that the use of this fea-
ture will increase the max. latency time of the PDO inputs or outputs.
Communication Model 12
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
3.5 Synchronization
CANopen makes it possible to poll inputs and to place outputs simultaneously.
The Synchronization telegram (SYNC), a CAN message of higher priority
without usefull data, is used for this purpose.Nodes working in syncronized mode
read their inputs out on receipt of the SYNC message and send the data directly
thereafter as soon as the CAN bus permits. Output data are written by the node
to the output only after receipt of the next SYNC message.
3.6 Emergency Telegrams
In case of a malfunction, the status of the node is transmitted by means of high
priority emergency messages (Emergency Telegrams). These telegrams have a
data length of 8 Bytes and contain comprehenssive error information.The Emer-
gency Telegram is transmitted as soon as a signalized error has occurred. When
the cause of the malfunction is removed, an emergency Telegram is again trans-
mitted in which the corresponding Bit is reset. The alteration of the "Actual Bus
State" is no error condition and does not lead to the triggering of the telegram. It
can also occur that nodes send Emergency Telegrams when they find area limit
overstepping, e.g. in analoge value measurements.
3.7 Nodeguarding and Lifeguarding
Nodeguarding and Lifeguarding mechanisms are available for malfunction moni-
toting of the CANopen network.The decentralized nodes are monitored by Node-
guarding which, on their part, by means of Lifeguarding, can recognize the mal-
function of the Guarding Master. When Guarding, the Master places Remote Fra-
mes (remote transmit request) on the Guarding Identifier of the nodes to be moni-
tored. These answer with the Guarding message (CAL Node Guarding Protocol).
This contains the current status of the Slave as well as a Toggle Bit, which must
change after each message. If the Status or the Toggle Bit do not agree with what
the Master expects or, if there is no answer, then the Master assumes a node
malfunction.The status transmitted in the Guarding Telegram can have the follo-
wing values:
1 DISCONNECTED
2 CONNECTED
3 PREPARING
4 PREPARED
5 OPERATIONAL
127 PRE-OPERATIONAL
Communication Model 13
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
The Toggle Bit transmitted in the first Guarding Telegram has the value "0".
When the Master requests the Guard message strictly cyclically, then the node
can recognize the malfunction of the Master. In the case that the node receives no
message request from the Mater in the set "Life-Time" (Guarding Time-Out), it
assumes a Master malfunction, will usually place its outputs into an error conditi-
on and sends out an Emergency Telegram.
The Life-Time is calculated from the Object parameters "Guard-Time" (Object
100Ch) and "Life-Time-Factor" (Object 100Dh):
Life-Time = Guard-Time * Life-Time Factor
If one of the two parameters is "0", there will be no monitoring of the Master (no
Lifeguarding).
There is a default setting for the Guarding Identifier (Object 100Eh) that is de-
pendent on the node address (see Default Identifier allocation). This can be alte-
red either with a direct access to the Object or by means of the corresponding
NMT services in the extended Boot-Up.The Guarding procedure can be started at
any time directly by requesting the Guarding message. This also activates the Li-
feguarding if the Guard-Time and Life-Time-Factor are unevenly zero.
Communication Model 14
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
3.8 The Default Identifier Allocation
After switching on, the nodes that work according to CANopen CiA DS 301 have
the following Default Identifier allocation available:
Object Identifier Function Parameter value
NMT 0 Boot-Up Start / Stop ---
SYNC 128 Sychronisation ---
Emergency 129-255 Status ---
TX_PDO1 385-511 Digital inputs 1800h
RX_PDO1 513-639 Digital outputs 1400h
TX_PDO2 641-767 Analog inputs 1801h
TX_PDO2 769-895 Analog outputs 1401h
TX_SDO 1409-1535 Parameter to master ---
RX_SDO 1537-1663 Parameter to node ---
ND_GUARD 1793-1919 Life-/Nodeguard 100Eh
DBT-Service 2023 Extended Boot-Up,
Database
DBT-Service 2024 Extended Boot-Up,
Database
NMT-Service 2025 Extended Boot-Up,
Management
NMT-Service 2026 Extended Boot-Up,
Management
Communication Model 15
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
4 Capabilities of the CANopen Slave (Node)
The CANopen slave (node) implements the functionality necessary for a CiA
Draft Standard 301 Rev. 3.0 compliant device on the CAN bus. It includes the
follwing logical units:
CAN message receive and transmit queue handling
process data object (PDO) transfer
service data object (SDO) transfer
node management (NMT) command handling
object dictionary access
These blocks form basically a minimum capability device with some manufactu-
rer specific extensions.
4.1 SDO and PDO Transfer
Communication with other CAN devices on the CAN bus can be accomplished
using the default SDO of the CANopen slave if access to the object dictionary is
desired. Transfer of process data can be handled by means of up to 64 PDOs (32
RxPDOs, 32 TxPDOs) provided by the DEVICE.
4.2 Node Management
4.2.1 Node Managent States and Commands
The CANopen slave firmware supports node management states and state transi-
tions of a minimum capability device:
Pre-Operational state (configuration purposes)
Prepared state (special operation defined by user application)
Operational state (normal operation)
Pre-Operational state is entered automatically after a device switch-on or reset
when all initialization steps are done. During this state all object dictionary varia-
bles of the the CANopen slave are already configured using default values. The
DEVICE is able to communicate using SDOs and to receive node management
commands.
A single Start Node command is necessary to switch the slave to Operational sta-
te and thus bring it to full operation. This enables the transmission and reception
of PDOs.All enabled TxPDOs are transmitted automatically on entering Oper-
ational state to notify the other devices of the initial process input data. If the
Operational state is left, for whatever reason, the whole process output data area
is cleared.
Capabilities of the CANopen Slave (Node) 16
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
The CANopen slave can be switched to Prepared state using the Stop Node com-
mand. As a result the COM bit in the cell HOST flags of the dual-port memory
(DPM) will be cleared and communication using SDOs or PDOs will be disabled.
However, node management commands are still accepted in Prepared state.
Once Operational or Prepared the DEVICE can be switched back to Pre-Opera-
tional state at any time using the Enter Pre-Operational command.
The DEVICE can be forced to re-initialize itself by sending it a Reset Node com-
mand. The process data area is cleared and initialization is performed. The DE-
VICE comes up again in Pre-Operational state. Sending a Reset Communication
command also triggers a re-initialization but skips the reset of the process data
area.
4.2.2 Node Guarding/Life Guarding
The DEVICE supports the CANopen specified node garding and life guarding
mechanisms. Setting the object dictionary variable Guard Time (100Ch) unequal
zero enables the processing of node guarding telegrams from the master. Enab-
ling the life guarding mechanism requires the variable Life Time Factor (100Dh)
to be set unequal zero too. The CANopen slave then guards the master by ex-
pecting a new guarding telegram within the configured life time after the last
guard telegram was received. The minimum life time supported is 10 ms. If no
node guarding message is received within the configured life time the life guar-
ding fails. The CANopen slave will clear all process output data, leave Operatio-
nal state and re-enter Pre-Operational state.
Capabilities of the CANopen Slave (Node) 17
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
4.3 Object Dictionary
All object dictionary variables implemented in the CANopen slave device are li-
sted below:
Object Description Data Type Acc. Default Value
Index Sub Type
0002h data type Signed8 Unsigned32 r 8
0003h data type Signed16 Unsigned32 r 16
0004h data type Signed32 Unsigned32 r 32
0005h data type Unsigned8 Unsigned32 r 8
0006h data type Unsigned16 Unsigned32 r 16
0007h data type Unsigned32 Unsigned32 r 32
1000h device type Unsigned32 r 301
1001h error register Unsigned8 r 0
1004h number of PDOs supported
0 number of PDOs Unsigned32 r 00200020h
1 number of synchronous PDOs Unsigned32 r 0
2 number of asynchronous PDOs Unsigned32 r 00200020h
100Bh node ID Unsigned32 r node ID
100Ch guard time Unsigned16 rw 0
100Dh life time factor Unsigned8 rw 0
100Eh COB ID node guarding Unsigned32 rw 700h + node ID
1014h COB ID emergency object Unsigned32 rw 80h + node ID
1400h RxPDO1 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw 0400200h +
node ID
2 transmission type Unsigned8 rw 254
1401h RxPDO2 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw 0400300h +
node ID
2 transmission type Unsigned8 rw 254
1402h RxPDO3 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw C0000400h
2 transmission type Unsigned8 rw 254
1403h RxPDO4 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw C0000401h
2 transmission type Unsigned8 rw 254
... ... ... ... ...
141Fh RxPDO32 communication
parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw C000041Dh
2 transmission type Unsigned8 rw 254
1600h RxPDO1 mapping parameters
Capabilities of the CANopen Slave (Node) 18
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
0 number of objects mapped Unsigned8 rw 8
1 1st object mapped Unsigned32 rw 62000008h
2 2nd object mapped Unsigned32 rw 62000108h
3 3rd object mapped Unsigned32 rw 62000208h
4 4th object mapped Unsigned32 rw 62000308h
5 5th object mapped Unsigned32 rw 62000408h
6 6th object mapped Unsigned32 rw 62000508h
7 7th object mapped Unsigned32 rw 62000608h
8 8th object mapped Unsigned32 rw 62000708h
1601h RxPDO2 mapping parameters
0 number of objects mapped Unsigned8 rw 8
1 1st object mapped Unsigned32 rw 62000808h
2 2nd object mapped Unsigned32 rw 62000908h
3 3rd object mapped Unsigned32 rw 62000A08h
4 4th object mapped Unsigned32 rw 62000B08h
5 5th object mapped Unsigned32 rw 62000C08h
6 6th object mapped Unsigned32 rw 62000D08h
7 7th object mapped Unsigned32 rw 62000E08h
8 8th object mapped Unsigned32 rw 62000F08h
... ... ... ... ... ...
161Fh RxPDO32 mapping parameters
0 number of objects mapped Unsigned8 rw 8
1 1st object mapped Unsigned32 rw 6200F008h
2 2nd object mapped Unsigned32 rw 6200F108h
3 3rd object mapped rw 6200F208h
4 4th object mapped Unsigned32 rw 6200F308h
5 5th object mapped Unsigned32 rw 6200F408h
6 6th object mapped Unsigned32 rw 6200F508h
7 7th object mapped Unsigned32 rw 6200F608h
8 8th object mapped Unsigned32 rw 00050008h
1800h TxPDO1 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw 180h + node ID
2 transmission type Unsigned8 rw 254
1801h TxPDO2 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw 280h + node ID
2 transmission type Unsigned8 rw 254
1802h TxPDO3 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw 80000380h
2 transmission type Unsigned8 rw 254
1803h TxPDO4 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw 80000381h
2 transmission type Unsigned8 rw 254
... ... ... ... ...
Capabilities of the CANopen Slave (Node) 19
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
181Fh TxPDO32 communication parameters
0 number of sub-indices Unsigned8 r 2
1 COB ID Unsigned32 rw 8000039Dh
2 transmission type Unsigned8 rw 254
1A00h TxPDO1 mapping parameters
0 number of objects mapped Unsigned8 rw 8
1 1st object mapped Unsigned32 rw 60000008h
2 2nd object mapped Unsigned32 rw 60000108h
3 3rd object mapped Unsigned32 rw 60000208h
4 4th object mapped Unsigned32 rw 60000308h
5 5th object mapped Unsigned32 rw 60000408h
6 6th object mapped Unsigned32 rw 60000508h
7 7th object mapped Unsigned32 rw 60000608h
8 8th object mapped Unsigned32 rw 60000708h
1A01h TxPDO2 mapping parameters
0 number of objects mapped Unsigned8 rw 8
1 1st object mapped Unsigned32 rw 60000808h
2 2nd object mapped Unsigned32 rw 60000908h
3 3rd object mapped Unsigned32 rw 60000A08h
4 4th object mapped Unsigned32 rw 60000B08h
5 5th object mapped Unsigned32 rw 60000C08h
6 6th object mapped Unsigned32 rw 60000D08h
7 7th object mapped Unsigned32 rw 60000E08h
8 8th object mapped Unsigned32 rw 60000F08h
... ... ... ... ... ...
1A1Fh TxPDO32 mapping parameters
0 number of objects mapped Unsigned8 rw 8
1 1st object mapped Unsigned32 rw 6000F808h
2 2nd object mapped Unsigned32 rw 6000F908h
3 3rd object mapped Unsigned32 rw 6000FA08h
4 4th object mapped Unsigned32 rw 6000FB08h
5 5th object mapped Unsigned32 rw 6000FC08h
6 6th object mapped Unsigned32 rw 6000FD08h
7 7th object mapped Unsigned32 rw 6000FE08h
8 8th object mapped Unsigned32 rw 00050008h
Object dictionary variables supported (r - readable, w - writable, m - PDO mappable)
Continued on next page.
Capabilities of the CANopen Slave (Node) 20
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
Object Description Data Type Acc. Default Value
Index Sub Type
6000h Digital Input Bytes
0 Digital Input Byte 0 Unsigned8 rm 0
1 Digital Input Byte 1 Unsigned8 rm 0
2 Digital Input Byte 2 Unsigned8 rm 0
... ... ... ...
FEh Digital Input Byte 254 Unsigned8 rm 0
6200h Digital Output Bytes
0 Digital Output Byte 0 Unsigned8 wm 0
1 Digital Output Byte 1 Unsigned8 wm 0
2 Digital Output Byte 2 Unsigned8 wm 0
... ... ... ...
FEh Digital Output Byte 254 Unsigned8 wm 0
Object dictionary variables supported (r - readable, w - writable, m - PDO mappable)
Capabilities of the CANopen Slave (Node) 21
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
4.4 Handling of Process Data
The CANopen slave supports 255 bytes of input process data and 255 bytes of
output process data. These are located at object indices 6000h and 6200h re-
spectively. Each of the 255 sub-indices refers to one data object of size
Unsigned8. Process data read from or written to these objects are mapped to spe-
cial areas of the DPM. This enables a user application to access the process data
by performing read or write operations to the DPM.
The process data objects are mapped to the follwing offsets in DPM:
Object Description Data Type Offset Address Access Type for
Index Sub in DPM User Application
6000h Digital Input Bytes
0 Digital Input Byte 0 Unsigned8 0000h write
1 Digital Input Byte 1 Unsigned8 0001h write
2 Digital Input Byte 2 Unsigned8 0002h write
... ... ... ...
FEh Digital Input Byte 254 Unsigned8 00FEh write
6200h Digital Output Bytes
0 Digital Output Byte 0 Unsigned8 0E00h read
1 Digital Output Byte 1 Unsigned8 0E01h read
2 Digital Output Byte 2 Unsigned8 0E02h read
... ... ... ...
FEh Digital Output Byte 254 Unsigned8 0EFEh read
Mapping of process data objetcs in DPM
Please refer to the Protocol Interface Manual and the Toolkit Manual for a detai-
led description of the steps to be taken for save access to the process data area.
Capabilities of the CANopen Slave (Node) 22
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
4.5 Device Start-Up and Default Values
4.5.1 Device Start-Up
After power-on the DEVICE executes its internal initialization routines. Two pa-
rameters are needed to during this initialization phase:
Node ID: Address of the CANopen slave on the CAN bus. This parameter is re-
quired to ensure node management (NMT) commands function correctly. It
also determines the initial value of some node ID dependent COB IDs. Va-
lid node IDs are in the range of 1 ... 127 (inclusive).
Baud Rate: Specifies the the baud rate to operate at within the CAN network. The
CANopen slave supports baud rates of 1 Mbit/s, 800 Kbit/s, 500 Kbit/s,
250 Kbit/s, 125 Kbit/s, 100 Kbit/s, 50 Kbit/s, 20 Kbit/s and 10 Kbit/s.
The above parameters must be given to the DEVICE prior to any bus operation. It
needs to be done only once as the node ID and the baud rate parameter are stored
permanently inside the DEVICE. This task can be accomplished using the confi-
guration program SyCon. Another way of specifying node ID and baud rate is set-
ting the appropriate parameters in DPM and then restarting (warm start) the DE-
VICE. Please refer to the protocol interface manual for more details concerning
this topic.
The initialization procedure not only enables bus operation of the DEVICE but
also initializes the whole object dictionary using default values. Please refer to
the table of object dictionary variables in this manual for the exact values written.
The initialization phase is completed by entering Pre-Operational state (minimum
boot-up behavior).
Capabilities of the CANopen Slave (Node) 23
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
4.5.2 PDO Default Mapping and COB IDs
After a device start-up or a reset only the first two receive PDOs (1400h, 1401h)
are enabled using the CiA DS 301 defined COB IDs of 200h + node ID and 300h
+ node ID. The remaining RxPDOs (1402h ... 141Fh) are also fully configured
but stay disabled. They are assigned consecutive COB IDs starting with 400h.
These RxPDOs can be enabled at any time by accessing the object dictionary
using SDO services .
The same applies to the transmit PDO area. TxPDOs at 1800h and 1801h (COB
IDs 180h + node ID and 280h + node ID) are initially enabled. The remaining
TxPDOs are configured (COB IDs: 380h upwards) but remain disabled.
Regardless of their enabled state all PDOs are completely mapped to the process
data area during initialization phase. Only one exception exists for RxPDO32 and
TxPDO32. These two PDOs contain a dummy mapping to data type Unsigned8
(object index 0005h) as their 8th mapped object. However, all PDOs are configu-
red to transport the maximum load of eight bytes. Please see the table of object
dictionary variables for all the details.
Capabilities of the CANopen Slave (Node) 24
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E
5 Diagnostic
5.1 Diagnostic LEDs
The CANopen slave device reports some internal state information to four LEDs
at the front panel of the card (backside of your PC). This way it provides the user
with tool for a quick diagnostic of the current device state.
RDY LED (Ready, yellow): permanently switched on showing the correct opera-
tion of the device internal operation system
RUN LED (Run, green): constantly lit if in Operational state, flashing with a pe-
riod of 2 Hz if not
STA LED (Status, yellow): reports each transmission of a CAN message with a
single flash
ERR LED (Error, red): switched on if the DEVICE is not in Operational state but
was already Operational before
Diagnostic 25
Copyright * Hilscher Gesellschaft fr Systemautomation mbH * Hotline and Support: +49 (0) 6190/9907-99 * Pr:COS#1E

You might also like