Scribd
Upload
25 views

CAN Overview

The document discusses the history and technical details of Controller Area Network (CAN) bus technology. It describes CAN milestones, examples of CAN systems and components, message transmission procedures, and other CAN concepts like remote frames, filtering, and establishing a global database through message broadcasting.

Uploaded by

Daniel scanio
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
25 views

CAN Overview

The document discusses the history and technical details of Controller Area Network (CAN) bus technology. It describes CAN milestones, examples of CAN systems and components, message transmission procedures, and other CAN concepts like remote frames, filtering, and establishing a global database through message broadcasting.

Uploaded by

Daniel scanio
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

Controller Area Network

Some CAN Milestones


Development
on CAN starts NMEA
at BOSCH SAAB Training 2000
CAN Target control
published
Dornier CAN
Intel joins in Weaving machine
the project First
working
CAN chip CAN chips Timberjack
Mercedes 3000
available S model

82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 00 01 02
ROVAC Robot CAN Extended ISO 11898 DeviceNet
concept Kingdom CAN ODVA TTCAN
ROVAC Robot CAN
demonstrated Kingdom
International
Example of a CAN system
Inductive Sensors
Sensor
module
Digital I/O
module

Drop
cables Trunk
cable

(A segment on a DeviceNet CAN bus)


Some CAN cables and modules

9-pole DSUB I/O module

DN C-type connector Sensor module

DN mini-style Pneumatic control


connector

Motion Control
CANHUG connector
Schematic of a CAN module

Power
SRAM Supply
Micro-
Controller VCC

Flash RAM GND

CAN_L

CAN Tx CAN_H

Controller Rx
Message Transmission
The message will be sent to all modules by HW.
The transmitter will send messages bit by bit
according to the CAN protocol.
• All modules, including the transmitter, will:
– Be active in all bus activity.
– Check for errors.
– Force retransmit of an erroneous message.
• All modules, except for the transmitter, will:
– Acknowledge a correct message reception.
– Have a copy of a correct message.

This is CAN ::: everything else is HLP or application specific


CAN message

11 or 29 bits

CAN Id/ DLC


Priority 4bits
The Philosophy of CAN
If a module has information that is needed
elsewhere in a system, make it available on the
CAN bus
• New information => send it on the CAN bus
• All modules will have identical information
• The receiving modules will store all needed data
In this way you will get a global database, where
the same information is available in all modules.
The source and destination of the information are
of no importance.
A Telephone Network
• Who is the client?
• Who is the server?
• If the communication fails, what will happen?
• On errors, what can be done?
Get the phone number to the receiver
Dial the phone number ==>
<== Get a ring or busy signal in return
<== Answer and identify yourself
Tell that the temperature to display is 85°F ==>
<== Acknowledge that the information is received
End the message transfer by saying “good bye” ==>
Disconnect the connection
A Computer Network
• Who is the client?
• Who is the server?
• If the communication fails, what will happen?
• On errors, what can be done?
Get the printer device address
Establish a connection to the device ==>
<== Acknowledge the existence of the device
Print the temperature value, 85°F ==>
<== Acknowledge that the printing is done
End the transfer by disconnecting the device ==>
Disconnect the connection
How this is done in a CAN System!

• Who is the client?


• Who is the server?
• If the communication fails, what will happen?
• On errors, what can be done?
The module measuring the temperature, uses an event to
start the transfer:
85°F
Get the CAN identification for temperature and link that to
the temperature value.
Send the information on the CAN bus ==>
The display module recognises the identifier and shows the
temperature.
The Remote Frame

The CAN hardware of some CAN controllers


supports a certain kind of events: The remote
frame
• An identifier with request RTR will force the
same identifier with data to be sent.
• The remote frame can be transmitted by any
module, possible at the same time.
• The DLC (Data Length Code) has to have the
same value in the remote frame as in the data
frame, but will have no data bytes.
Filtering and Selection
The filtering and selection in the receiver will be
according to the information available in the
message. The information in a CAN message
can belongs to any of three main parts:
• PRIO
– priority / identifier
• DLC
– Data Length Code [0..8]
• Data
– Number of bytes according to the DLC
Filtering and selection can be made in all three
parts.
CAN message

11 or 29 bits

CAN Id/ DLC


Priority 4bits
Filtering and Selection

• Filtration by CAN controllers


– All CAN controllers support some kind of filtration
in the priority / identifier.
– Some CAN controllers support filtration in some of
the data bytes.
• Filtration by module software
– All kinds of filtration, but the above mentioned,
have to be taken care of by module software.
– The three parts – PRIO, DLC, the data bytes – are
available for filtration handled by module software.

You might also like