The organisation of CANopen in reference to the ISO Open System Interconnect model is shown in Figure 1.
This consists of on the top level the CANopen device and communication
Figure 1 CANopen communication reference model.
B.Hallgren ATLAS DCS
A high level protocol is necessary in order to define how the CANbus
11 bit identifier and the 8 data
bytes are used among the different nodes on a bus segment. It exits
several standards which uses the
CAN bus. CERN has chosen CANopen, which is supported by the CAN
in Automation (CiA) organisation.
It was originally developed from an EEC ESPRIT III project and has
found applications in industrial
automation applications. There are detailed specifications available
from CiA.
1.0 The ISO/OSI layer model and CANopen
1.2 Minimal Functionality Devices2.0 Network Management in CANopen - initialisation and operation
1.0 The ISO/OSI layer model and
CANopen
The organisation of CANopen in reference to the ISO Open System Interconnect
model is shown in Figure 1.
This consists of on the top level the CANopen device and communication
Figure 1 CANopen communication reference model.
profiles. On the data link layer there is the CAN controller, which
conforms to CAN 2.0A and/or 2.0B, while the physical
layer is specified in the ISO 11898 standard. The data link layer and
the physical layer is implemented in hardware, see [1].
CANopen uses the concept of device profiles. Manufacturers can produce
standardised devices by conforming to the
guidelines contained in a CANopen device profile. Networks of devices
from independent manufacturers can be
constructed without having to write specialised specific software for
networking each device together. Basic network
operation is guaranteed by defining mandatory device characteristics.
It is possible to implement additional functions
with the help of the optional and the manufacturer specific part of
the profiles. There are a number of standard profiles
available from CiA, among them CiA-401 [2], which covers I/O modules
and CiA-404 [3] for measuring devices and
closed loop controllers. The profiles are implemented in a standardised
database called object dictionary. There exit
software tools to read, configure and change entries in the dictionary
of a device. The object dictionary is not stored
in the CANopen node itself, it is defined in the Electronic Data Sheet
(and on paper), so a master (application) will
know the data type and size of every object.
The communication profile defines that in a CANopen network there must
be at least one master application and one
or several slave applications. The master performs the boot-up process
and checks and maintains the network in
operational state. It also manipulates the object dictionary entries
and the CAN identifiers of the connected devices.
The communication profile defines several methods for transmission
and reception of messages over the CAN bus.
Synchronous data transfers allow network wide co-ordinated data acquisition
and actuation. Synchronous transfers
are supported by predefined communication objects i.e. synchronisation
messages transmitted on a cyclic time period
and time stamp messages. Asynchronous or event messages may be sent
at any time and allow a device to immediately
notify another device without having to wait for a synchronous data
transfer to take place. The content of both
synchronous and event messages (Process Data Objects) may be dynamically
configured at network boot up by the
network master using Network Management. Although CAN is restricted
to transfers of a maximum of 8 bytes of
information, data transfers larger than 8 bytes in length are also
provided for by the protocol (Service Data Objects).
The detailed specifications of the CANopen communication profile are
contained in the CiA DS 301 document [4].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2.0 Network Management in CANopen - initialisation and operation
Network management is used to control the operating state of devices
in a CANopen network with the
following functions is available:
To determine whether nodes are still functional CANopen using NMT lifeguarding
techniques whereby
individual nodes that support lifeguarding are polled using CAN remote
frames to see whether they are
still functional. The functional status of the device is returned in
the reply to the remote frame. Inhibit
times/timeouts may also be implemented so that if the master does not
receive a reply from a node within
a certain time period the node is regarded as dysfunctional and an
error may be flagged. Also nodes
supporting inhibit times can also signify an error condition should
they not receive a lifeguarding remote
frame within the time period negotiated at boot time with the cell
master.
NMT services can also be used to bring all or selected nodes into various
operating states at any time.
For example, the network master can broadcast an Enter_Preoperational_State
message to all nodes to
bring them into a state where further configuration information may
be downloaded to the device using
service data messages. Alternatively, a single node may be brought
into its Pre-Operational state
(or configuration mode) by using the same message with different protocol
information whilst keeping
all other devices fully operational.
2.1 Network Management in CANopen - implementation
Every slave node contains a state machine with the four states called:
[1] Initialisation, [2] Pre-Operational,
[3] Operational and [4]
Prepared. There are five different NMT
messages, which permit a CANopen master
to change the state of one slave or all slaves simultaneously:
Start_Remote_Node,
Stop_Remote_Node,
Enter_Pre-Operational_State,
Reset_Node,
Reset_Communication.
[1] Initialisation at power
on the CANopen slave (with minimum boot-up capability) performs an
initialisation sequence and enters automatically into the Pre-Operational
state.
[2] In the Pre-Operational state, the node will perform the following functions:
Perform its internal I/O function,
Allow communication via the SDO channel for configuring e.g. PDO mapping,
communication parameters
Node guarding and respond to node-guarding protocol.
Change state to:
Perform its internal I/O function
Have it’s PDO channels active (synchronised if required)
Have it’s SDO channels active
Send emergency messages on an error event .
Change state to:
(no SDO/PDO/emergency communication)
But it will perform its internal I/O function.
Change state to:
The NMT message format is (CAN header + 2 data bytes):
|
|
|
|
|
|
|
|
CS (Command Specifier) has five values according to the
NMT function wanted:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Node_ID can be 1 to 127 to select a single node, or 0 to select
all nodes. The hardware switch defines
the Node_ID. The CANopen slave does not send any CAN message back with
these 5 NMT commands.
2.2 CANopen Node Guarding
This is used to detect communication errors in the network. The node
guarding (NMT)
master can check its slaves and the slaves can check the master (life
guarding). Node guarding
should be used if a slave isn’t polled on a regular time base.
The object dictionary contains Node guarding configuration:
100CH: guard time (in milli-seconds)
100DH: life time factor (* guard time = life time)
100EH: node guarding identifier (default 700H + Node_ID)
Life guarding is enabled for a slave when the node guarding master
checks the slave state via
a Remote Transmit Request (RTR) on the Node Guarding COB_ID, and the
guard time and
the life time factor are nonzero:
The NMT master message format is:
|
|
|
|
The NMT slave replies with its current state:
|
|
|
|
|
|
| iiiiiii | Node ID |
| t | toggle bit, has to toggle every Node guarding request (1st time zero) |
| sssssss | node state:
3 = Pre-Operational 4 = Prepared 5 = Operational |
If the node-guarding master doesn’t receive the current state reply
within the guard time, it signals a
remote error for that slave to the application.
If the slave doesn’t receive this request during its ‘life time’ (guard time * life time factor) then
the slave will: Switch to pre-operational state.
If the node-guarding master restarts, it will detect the changed operational
state of the slave and signal
this error to the application.
3.0 A comparison of the data communication objects in CANopen
Two different mechanisms exist in CANopen for data transfer. Service
Data Object (SDO) transfers
are mainly used for large, low priority data transfers between devices
and are transmitted asynchronously.
They are typically used for configuring devices on a CANopen network.
Individual parameters are
addressed using a 16-bit index and an 8-bit sub-index addressing mechanism.
Data transfers in this mode
The second mode of communication is by use of Process Data Object (PDO)
transfers. Process
data messages (synchronous and event/asynchronous) are mainly used
for real-time transfer of data
and typically have a higher priority on the CAN bus than service data
messages. Data in a PDO
telegram is limited to 8 bytes or less. The format and data content
of the message may be fixed or
dynamically configured using SDO data transfers. SDO transfers may
be thought of as high load
lower speed transfers and PDO transfers thought of as small load high
speed transfers hence the
analogy between the lorry and the sports car.
3.1 Process Data Object (PDO) transfer modes
CANopen supports different modes for transfer of real-time data. One
method is simply to send a
PDO message on the occurrence of an event. For example, a digital I/O
transmits the state of its
input lines when they change state. An analogue input module might
send the state of an input
line once the state of that input line has changed by a pre-configured
amount. Another method is
by means of synchronous data transfers. In this mode, a very high priority
synchronisation telegram
(SYNC) is sent on a set time period. The SYNC telegram is broadcast
to all devices and on reception
of the telegram those devices that are configured to respond to it
send data onto the bus. Data is
also sent from the controlling device to those devices requiring it.
Data transmitted from the device
on reception of the SYNC is commonly referred to as actual data
whilst data sent to the device is
commonly referred to as command data. For a digital I/O module
the actual data may be the state
of its input lines whilst the command data would be the new
state to set the outputs to. After
receiving command data the device then actuates on reception
of the next SYNC telegram. Thus in
a network consisting of several digital output devices all outputs
may be set synchronously.
Command and actual data may be configured so that the transfer
takes place only every
Nth SYNC telegram helping to reduce bus loading.
Data may also be transferred as an event but synchronously i.e. an event
happens on the device
and a PDO message is sent as actual data once a SYNC message
has been received. Synchronous
data communication is one of CANopen’s most powerful features and ensures
predictable bus loading.
3.2 CANopen Process Data Objects example
When, for instance, the device has one 16 bit analogue output, this
value can be mapped in the
first 2 bytes of a PDO. A CAN message to this device will therefore
contain only two data bytes.
Because a PDO transfer does not need any confirmation, setting this
16 bit analogue output just
needs one CAN Message with 2 data bytes, total of 60 bits over the
CAN bus. The same function
with the SDO method would need 2 CAN messages with 8 data bytes, a
total of 216 bits over the
bus. Reading an analogue input can be done by a remote request of the
PDO, these 2 CAN messages
then take 104 bits over the bus. Another method is that the PDO can
be transferred after a SYNC
message. This could even trigger PDOs on all devices in the network.
3.3 PDO - reconfiguration
If a device has multiple in- or outputs, they can be mapped into a single
PDO (e.g. four 16 bits analogue inputs),
as long as the PDO length doesn’t exceed 8 bytes (maximum of a single
CAN message).
Mapping dictionary object into a PDO is done (via the SDO) using dictionary
objects 1600H
or 1601H (for receive PDOs of output nodes) and 1A00H or 1A01H (for
transmit PDOs of input nodes).
Example of PDO mapping (analogue input 16 bits and float):
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These results in the following CAN message:
|
|
||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
not used |
|
||||||
Changing the (variable) PDO mapping is only possible when the node is
in its pre-operational state (see ‘Boot-up sequence’).
If the node contains non-volatile memory, this is needed only once
when reconfiguring is wanted. When changing
the PDO mapping fails (node not pre-operational, object is not mappable
or PDO becomes longer then 8 bytes),
the node responds with a ‘Abort domain transfer’.
3.4 PDO Transmission Type
The transmission of a PDO can be initiated (triggered) is different ways, according to the PDO transmission type.
One method is Asynchronous transmission
The PDO can be triggered by:
The PDO can only be triggered by the Network SYNC message, this can be done in different ways:
Acyclic:
|
|
conditions to trigger PDO A=both needed, O=one or both |
|
||
| Sync | RTR | Event | ||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
The DS401 I/O device profile declares the transmission type of every PDO at 255:
transmit (input) PDOs are asynchronous, event driven (change of input) or requested with a RTR.
receive (output) PDOs are asynchronous.
3.5 PDO inhibit time
When a PDO is triggered by an I/O event (e.g. change of digital input
or reception of a RS232 character) it is
possible that the PDO is triggered at such a high rate that it causes
a ‘traffic jam’ on the CAN bus. To prevent
this situation, a transmit PDO (on input nodes) has a PDO inhibit time
parameter. This is a counter with a 100 ms
resolution, which will inhibit the next PDO transmission for a period
of time.
References:
[1] CiA DS-301, V3.0: CANopen Communication Profile, October 1996.
[2] Newcastle University Robotics and Automation
group
http://www.ncl.ac.uk/~nrauto/canproto.htm