Canopen a technical introduction jieshao

A technical introduction
Version 3.1 / September 2005

2
C&M / S&A / CANopen Technical Introduction V3.0.ppt / March 2005
„ History of CAN / CANopen
„ Technical features
„ CANopen characteristics
„ CANopen protocol
„ Diagnostic
„ Error detection
„ What you should remember
Table of Content

3
Origin of CAN
„ 1983 Bosch developed the CAN protocol
„ 1986 Official introduction of CAN protocol
„ 1987 First CAN controller chips from Intel and
Philips Semiconductors
„ 1989 Low-cost controller chips implementing the
CAN data link layer protocol in silicon
„ 1991 Bosch’s CAN specification 2.0 published
History of CAN / CANopen

4
Origin of CANopen
History of CAN / CANopen
„ 1992-93 CiA Working Group „Higher Layer Protocols“
specifies CAL (CAN application layer)
„ 1993-94 Specification and prototyping of a distributed
system for production cells
„ 1995 Formation of CiA Interest group CANopen,
specifies CiA Draft
Æ„Communication profile for industrial automation systems“
(DSP-301)
Æ„Device profile for I/O-modules“ (DSP-401)
„ 1996-98 Specification of standard device profiles,
extensions of the communication profile and
standard applications
„ 2003 CANopen is established as a protocol for
different automation applications

5
At at glance
„ Flexibility
„ Fault tolerant capabilities
„ Increased reliability
„ Design change flexibility
„ EMC immunity
„ Better system integrity
„ Simplified diagnostics capabilities
„ Powerful error detection capabilities
Technical features

6
Protocol advantages
„ Configuration flexibility
„ Prioritization of messages
„ System wide data consistency
„ Multicast reception
„ Error detection and error signaling
„ Automatic retransmission of corrupted messages
„ Distinction between temporary errors and permanent
failures of nodes and autonomous switching off of
defective nodes
Technical features

7
CAN / CANopen specifications
„ CAN Protocol Specification 2.0 A: CAN Controller
compliant with this standard handles only standard
frames with 11-bit identifiers.
„ CAN Protocol Specification 2.0 B passive: CAN
Controller compliant with this standard transmit only
standard frames with 11-bit identifiers, but checks
received standard frames as well as extended frames
with 29-bit identifiers (even the acknowledge is given).
„ CAN Protocol Specification 2.0 B active: CAN Controller
compliant with this standard can receive and transmit
standard and extended frames.
Technical features

8
number of nodes • Not limited by layer-2 protocol
• Physical limitation by driver capacity of transceivers (64)
• Logical limitation when using node specific identifiers (127)
max. number of message identifier • Standard format: 2048 (11 bit identifier 211
)
• Extended format: 536.870.912 (29 bit identifier 229
)
Length of data field [bytes] 8 4 2 1
max. number of messages / s at
1Mbit/s
8772 12195 15150 17240
max. latency time of highest
priority message / µs
135 88 78 68
Miscellaneous
Technical features

9
Communication relations
„ Multimaster Protocol
ÆAny communication structure is possible
ÆEvent-Oriented Message Transmission
– Reduced bus load
– Short latency time for real-time data
„ Priority-Based Message Transmission
ÆShort latency time for high priority messages, even at very high bus
load caused by low priority messages.
1 : N
N : M
CANopen Characteristics

10
Data length
„ Limited Data Length
Æ Sufficient for data communication in cars, machines, lower level
automation
Æ Transmission of data also possible in electro - magnetically heavy
disturbed environment
Æ Short latency time for high priority messages
Æ Segmented transmission of data more than 8 bytes
t

11
General
„ Bus Topology
Æ High system configuration flexibility
Æ Restricted drop length
Æ Bus line termination required
„ Synchronous Protocol, NRZ Signal Coding
Æ Improved usage of transmission bandwidth
Æ Bit synchronization mechanism required
„ Limited Product of Bus-Length*Data-Rate
Æ Due to bit-wise arbitration the possible maximum bus length
decreases with increasing data rate.

12
Data transmission and error detection
„ Random, Collision free Bus Arbitration
Æ High priority message may monopolize the bus, appropriate
system design required
Æ No collision solving mechanism required, non-destructive
arbitration
„ Very Effective Error Detection Mechanisms
Æ Very high data integrity
„ Error Signaling instead of Message Confirmation
Æ Very short error recovery time
Æ System wide consistence of data
Æ Reduced bus load
„ Error Confinement Mechanisms
Æ Switch off of defective nodes

13
Network length and bit rate
„ Total length at defined bit rate
Bit rate
[kBit/s]
1000 800 500 250 125 50 20 10
max. bus
length [m]
20 40 100 250 500 1000 2500 5000
Bit rate
[kBit/s]
1000 800 500 250 125 50 20 10
Single
Branch [m]
0.3 3 5 5 5 60 150 300
Sum per
TAP [m]
0.6 6 10 10 10 120 300 600
Min. TAP
Spacing*
[m]
3.6 6 6 6 72 180 360
Total [m] 1.5 15 30 60 120 300 750 1500
* can be calculated for each TAP. TAP Spacing = 60% of the total of all branches in the TAP
„ Drop length limitation

14
Producer / Consumer
CANopen protocol
„ CANopen is using the Producer/Consumer model. Each
station of the network can listen to the messages of the
transmitting station and decides, using the bit
arbitration, if the messages is accepted or not.
„ This model is the bases for the CAN broadcast
communication.

15
The message types
„ Data messages
Æ Process Data Object (PDO)
– fast transmission of process data
Æ Service Data Object (SDO)
– transmission of parameters
„ Predefined messages
Æ Set of messages for synchronization (SYNC), time stamp
distribution (TIME STAMP), notification of device failures
(emergency message, EMCY).
„ Network Management messages (NMT)
Æ Set of messages to control the node communication status and for
monitoring the communication status of the device
CANopen protocol

16
PDO transmission modes
„ (1) Asynchronous Transmission
Æ Event-oriented transmission of a PDO after occurrence of profile -
or manufacturer-specific event or after expiration of an event
timeout
„ (2) Synchronous Transmission
Æ Transmission of a PDO immediately after reception of a specified
number (PDO rate) of SYNC objects.
Æ Acyclic synchronous: Single Transmission of a PDO
Æ Cyclic synchronous : Repeated transmission of a PDO
„ (3) Transmission on Request
Æ Transmission of a PDO after reception of a request frame.
„ „Transport Capacity“ of a PDO = 8 Byte ⇒ max. 64Bit
CANopen protocol

17
SDO transmission requirements
„ Access to all entries in Object Dictionary Entry
Æ requires specification of Dictionary Entry by index (16 Bit) and
subindex (8 Bit) within SDO protocol
„ Transmission of Object Dictionary Entries > 8 byte
Æ requires fragmentation (segmentation) in SDO protocol (flow
control)
„ Up- and download of data (read and write data)
Æ requires specification of executed service within SDO protocol
„ Data length of most Object Dictionary Entries is <= 4
bytes
Æ requires specific way of transfer of up to 4 data bytes within SDO
protocol in order to save transmission time
„ A standard SDO is able to transmit 8 bytes
CANopen protocol

18
SDO transmission types
„ Expedited Transfer
Æ fast SDO transfer type for transferring data with up to 4 bytes
„ Non-Expedited Transfer (Segmented, Fragmented)
Æ SDO transfer type for transferring data with any number of bytes
Æ Flow control after 7 transmitted bytes
„ Blocktransfer
Æ SDO transfer type for transferring data with any number of bytes
Æ fast transfer method with flow control only after transmitting a block
of data with n*7 bytes (1<=n<=127)
Æ Requires much more resources for implementation and processing
than non-expedited transfer
CANopen protocol

19
Watchdog mechanism
„ Two watchdog mechanisms exist for CANopen
Æ Node Guarding
Æ Heartbeat
„ Node Guarding
Æ The network manager is polling each device to check the health
after a configured period of time
„ Heartbeat
Æ Each device gives a life sign to the network manager or to other
devices
– less bus load
– health check between devices possible
CANopen protocol

20
Layer model
CANopen protocol
„ Application Profiles to reflect
application needs
Physical Layer
Device Profiles
Data link Layer
Application Layer
Application Profiles
ISO11898-2
ISO11898-1
EN50325-4
„ Device Profiles & Device Description to
support common behavior
„ CANopen is using Layer 1, 2 and 7 of the
ISO/OSI model
Æ Layer 1 and 2 is CAN
Æ Layer 7 is CANopen
Device Profiles
ISO14745-2

21
Media access logic
„ If a transmission is occurring, a node must wait until it is
complete before attempting to transmit
Time
Node “Y”
Node X’s Transmission Node Y’s Transmission
Interframe
Space
Network Latency Time
Node Y wants to transmit
It listens to the network and hears traffic
Must wait until transmission is complete
for at least 3 bit times (Interframe Space)
> 3 bit times
CANopen protocol

22
Frame format
1
Bit
11
Bits
1
Bit
6
Bits
0 ... 8
bytes
15
Bits
1
Bit
1
Bit
1
Bit
6
Bits
>=3
Bits
Interframe
Space
End of Frame
ACK Delimiter
ACK Slot
CRC Delimiter
CRC Sequence
Data Field
Control (2 bits reserved for future, DLC0-3 is the data
length code )
RTR Bit
Identifier
Start of Frame
{
RTR = Remote Transmission Frame
CRC = Cyclic Redundancy Check
ACK = Acknowledge
DLC = Data Length Code
Interframe
Space
ACK
CANopen protocol

23
The CAN identifier ( COB-ID )
„ COB-ID: Communication object identifier
Æ Specification 2.0A or 2.0B passive supports 11 bit identifier
• SYNC
• NMT Control
• EMCY
• TPDO
• RPDO
• TSDO
• RSDO
Node address
( 0 for all, 1-127 for the nodes)
Function code
Bit
10
Bit
9
Bit
8
Bit
7
Bit
6
Bit
5
Bit
4
Bit
3
Bit
2
Bit
1
Bit
0
CANopen protocol

24
Physical Signaling
„ Bus level 0 = dominant
„ Bus level 1 = recessive
„ Bus idle = recessive
„ The dominant level overrides the recessive level
„ Bit coding is NRZ (Non-Return to Zero) w/bit stuffing
„ Output of nodes:
#1 #2 #3 resulting bus level
0 0 0 0
0 0 1 0
0 1 0 0
...
1 1 1 1
CANopen protocol

25
Bus Arbitration Principle (1)
„ Several nodes may start transmission of a CAN frame as
soon as they monitor the bus as idle
„ During arbitration every node monitors bus line to detect
whether its transmitted bit is overwritten by a message
of higher priority
Æ Recessive bit level = 1
Æ Dominant bit level = 0
„ As soon as a transmitting node detects a “dominant” bit
while transmitting a “recessive” bit it releases the bus,
immediately stops transmission and starts receiving the
frame
CANopen protocol

26
„ Within one system each message must be assigned to a
unique message identifier
„ Data frames with a given identifier and a non-zero data
length code may be initiated by only one node
„ Every remote frame should have a system-wide data
length code
Æ Otherwise overwriting of data or data length code
– bit errors until bus-off of node(s)
CANopen protocol

27
Identifier Control Data
10 9 8 7 6 5 4 3 2 1 0
Field Field
CANopen device 1 0 0 0 1 1 0 0 0 0 0 0 1 0 11
CANopen device 63 0 0 0 1 1 0 1 01
Resulting CAN frame 0 0 0 1 1 0 0 0 0 0 0 1 0 01
E
O
F
C
R
C
A
C
K
S
O
F
R
T
R
Node 63 losing arbitration
and stops transmitting!
Node 63 still ACKs message.
CANopen protocol
Arbitration filed

28
Bit Stuffing Principle
„ CAN will detect an error after 6 consecutive bits of the
same value. Therefore a so called “Stuff Bit” will be
inserted in the frame after 5 consecutive bits.
„ The CRC, ACK and EOF are of fixed form and will be not
stuffed.
„ The receiver will automatically remove the “Stuff Bits”
from the frame
CANopen protocol

29
Frame Types
„ DATA Frame
Æ Used for sending normal messages
„ ERROR Frame
Æ ERROR ACTIVE frame:
– Six consecutive dominant bits
Æ ERROR PASSIVE frame:
– Six consecutive recessive bits
„ REMOTE Frame
Æ Used to request a DATA Frame with the same Identifier
„ OVERLOAD Frame
Æ Used for flow control purposes
– provides a delay between the transmission of frames
CANopen protocol

30
Acknowledgments
„ ALL nodes check all messages for validity
Æ Each node will acknowledge valid messages in the ACK Slot
– this indicates to the sending node that at least one node has
received its message correctly
Æ Each node will flag invalid messages with an error frame
– this indicates to all nodes that at least one node did not receive the
message correctly
„ There is no separate acknowledge frame
CANopen protocol

31
Error handling (1)
„ CAN defines a Error State Machine with three error
states
Æ Error Active
Æ Error Passive
Æ Bus Off
„ Reaction to errors is different in each state
„ Thresholds are defined by CAN and are part of the
CAN chip
Diagnostic

32
Error handling (2)
„ Error counters track Tx and Rx errors
Æ Transmit errors count more heavily than receive errors.
„ Good messages will decrement error counters
Æ Accounts for temporary disturbances
Æ Allows transitions to/from Error Active and Passive states
Æ CAN does not allow a transition from the BUS OFF state
Æ Once the BUS OFF state is reached, the node normally requires
a power cycle to return to any other state.
Diagnostic

33
Error State (1)
„ Error Active
Æ Assumption is that network errors are not this node’s fault
Æ Upon detection of an error:
– node will immediately transmit an ERROR ACTIVE FRAME
– causes all nodes to abort the current message
„ Error Passive
Æ Assumption is that error may be this node’s fault
Æ Upon detection of an error:
– node will immediately transmit an ERROR PASSIVE FRAME
– this will not affect other nodes unless the node that detects the error
was the transmitting node (ie: this was a bit error)
Diagnostic

34
Error State (2)
„ BUS OFF
Æ Assumption is that this node is faulty
Æ This node is not allowed access to the network
Æ Normally the node needs to be power cycled
– Exception (normally not implemented but mentioned here for
completeness): A node which is ‘bus off’ is permitted to become
‘error active’ (no longer bus off) with its error counters set to zero (0)
after 128 occurrence of 11 consecutive ‘recessive’ bits have been
monitored on the bus
Diagnostic

35
Error State (3)
„ The value of two error counters
determine a node’s error handling
status
„ Increment/Decrement of error
counters according to sophisticated
rules, e.g.
Æ Increment error counter by 8 on a given
error
Æ Decrement error counter by 1 with each
successful operation.
Error Active
Error Passive
BUS OFF
Reset and Configuration
RX_Cnt < 128
and
TX_Cnt < 128
RX_Cnt > 127
or
TX_Cnt > 127
TX_Cnt > 255
Reset
and
reception
of
128
*
11
bit
recessive
bits
RX_Cnt: Value Receive Error Counter
TX_Cnt: Value Transmit Error Counter
Diagnostic

36
Facilities
„ Bit Errors
Æ Transmitting node checks bit on bus versus what it sent, and finds it
to be different
„ Stuff Error
Æ Occurs after the 6th consecutive bit of the same value (See Error
Flags)
„ Acknowledgment Error
Æ Transmitting node did not detect a dominant bit value in the Ack Slot
„ CRC Error
Æ 16 bit value recalculated by receiving node did not match
transmitted value
„ Form Error
Æ delimiter and other packet format violations
Error detection

37
Capability
„ Resulting “Error Detection Capability” measured by
probability for non-detection of a disturbed message:
– <10-10 * Message Error Rate
„ Example:
• Data Rate 500 Kbit/s
• Bus load 25 %
• Average message length 80 Bit
• Operating time 2000h/ Year
• Average error rate 10-3
• Probability of a message with an undetected error: 10-13
• Mean time between this event: 1000 years
Error detection

38
Error Signaling Error Frame
If any node detects an error it starts the transmission of an
error frame
Data or
Remote
Frame
6
Error
Flag
0, ..,
6
Echo
Error Flag
6, ..,
12
Resulting Error Flag
8
Error Delimiter
3
Inter-
missio
n Field
Error-detecting node transmits 6-Bit (dominant) error flag at
next bit time
1) Other nodes detect bit-stuffing error within 6th bit of error
flag
2) and start transmission of own error flag.
⇒Destruction of actual message; secure network-wide data
consistency.
1) Not for CRC-error; Transmission starts after following ACK-delimiter bit
2) Unless an error flag for a previous error condition (form error) has already been started
Error detection

39
What you should remember
„ Differential signal transmission
„ transmission rate up to 1 Mbit/s
„ bus length and transmission rate are depending
„ max. 127 devices on the network
„ max. 8 byte per PDO
„ No telegram loss in case of collision
„ Multi master capability
„ Synchronization of messages possible

40
„ Produce Consumer model
„ PDO for process data
Æ several transmission modes possible
„ SDO for service data and large data
„ Node address influence the priority of the message
Æ see the arbitration method
„ Two watchdog mechanisms possible
Æ Heartbeat
Æ Node Guarding
„ CANopen is one application layer on CAN

41
for your attention

Canopen a technical introduction jieshao

More Related Content

Similar to Canopen a technical introduction jieshao (20)

Recently uploaded (20)

Canopen a technical introduction jieshao