Can Canopen

8/13/2019 Can Canopen

1/60

2013 Wind River and Octrian All Rights Reserved

CAN and CANopen:Interconnecting Embedded Devicesto enable the Internet of Things

Stephen Olsen, Product Line Manager, Operating System Platforms, Wind RiverLalita Godbole, Founder, Octrian LLC


2/60

2013 Wind River and Octrian All Rights Reserved2

Session Outline

Introduction

Design of distributed applicationsCAN protocol technical overview

SocketCAN interface

CAN for the Internet of ThingsCANopen


3/60


What is CAN?

Controller Area Network

Originated in automotive industry as communications busin automobiles

Used in safety-critical applications

Defines how a message is delivered

Does not define the meaning of the message


4/60


CAN Applications

Proprietary protocols

Example: ECU to ECU communication in a vehicle

Open protocols based on CAN

IDB-C (automotive)

J1939 (automotive)

DeviceNet (industrial)

CANOpen (industrial)


5/60


Distributed Application

Design

Multiple devices required to

perform the task: Robot arm

Welding gun and temperaturesensor

Video camera

Monitoring system

Conveyor belt

Temperature sensors

Safety proximity sensors

Etc.

Robot arm

Welding gun

Monitoring system

Camera


6/60


Devices

Each device in the distributedapplication has its own processoror programmable logic device

To make the application work,devices must be able to sendmessages to each other

Robot arm

Welding gun

Camera

Monitoring system


7/60


Bus Architecture

Bus architecture connects alldevices to onecommunication line

Protocol needed to handleownership of bus

Robot arm

Welding gun

Monitoring system

Camera

Bus


8/60


Implementation Step 1:

Determine messages

Determine what needs to be

communicated between devices

Robot arm

Welding gun

Camera

Monitoring system

Position

command

Temperature

reading

Weldcommand

Proximity

reading


9/60


Temperature

readings


Define messages

Define all the different messages

that need to be communicated Sort them in order of priority

Proximity

values

Position

commands

Weld

commands


10/60



Sending messages

Program each node to send out

appropriate messages onto thebus as needed

Robot arm

Welding gun

Monitoring system

Camera


11/60



Receiving messages

Program each node to accept

messages that concern them andto react to those messages

Robot arm

Welding gun

Monitoring system

Camera


12/60



Error conditions

Program each node to act

on error conditions Example: Broken physical

connection in networkautomatically turns offwelding gun and freezes

robot arm

Robot arm

Welding gun

Monitoring system

Camera

Off

Freeze

Sound

alarm


13/60


Bus Protocol Criteria

High priority messages must notbe delayed by low prioritymessages

Devices must be able to detectwhen they are disconnected fromthe network

Glitches in physical layer must notresult in a miscommunication of

message

Warning!

I say:Move

forward

I hear:

Move

backward

Disturbance


14/60


CAN Physical Layer


15/60


15

Media Layer

Twisted pair carries

the signal


16/60

2013 Wind River and Octrian All Rights Reserved 16

Terminating Resistors

Both ends of the CAN cable is

terminated by 120

across thetwisted pair

120 120


17/60


Physical Link Layer

Differential Voltages are interpreted as bits of data

110010110..


18/60


Baud Rates

Baud rate = bits per second

Typically 100kb/s to 1Mkb/s

Faster baud rates need shorter cable lengths


19/60


CAN Flexible Data-Rate (CAN FD)

Still uses CAN bus arbitration method

Arbitration process

CRC delimiter

Receiver ACKs


20/60


Occupied Bus

Data takes up the entire bus

No other data can be sent untilcurrent transmission is finished

All nodes receive the same dataYes

Yes

Yes


21/60


Messages

Messages are identified by their

functionality Functionality is assigned by

distributed application (user ofCAN protocol)

Brake

commandsDiagnostic

information

Temperature

requests

Speed

control

messages

Temperature

readings


22/60


Message Filtering

I need speed control

messages, brake

commands, andtemperature readings

I need speed control

messages and

diagnostic information

All nodes receive the samemessage

Upon receiving the message, eachnode decides whether or not itneeds that type of message


23/60


Message Priority

All messages are ordered bypriority

Priority is determined by theidentifier

Message identifiers areassigned according to priority

Smaller identifiers have higherpriority

Important for distributedapplication to assign prioritiescorrectly and avoid using thesame message identifier

Higher

priority

Brake

commands

Diagnostic

information

0x101

0x330

Temperature

requests

Speed

control

messages

0x220

Temperature

readings0x240

0x250


24/60


Arbitration

When two nodes start sending

different messages at exact sametime, the higher priority messagealways takes precedence

Sender of low priority messagebacks off and retries when the bus

is idleYes

No

Yes

Yes

Accept

Ignore

High

priority

High priority

message is on

network. Try again

when bus is idle.


25/60


Message Frames

1 bit: Start signal

11 or 29 bits: Message

identifier

6 bits: Number of data

bytes (0 8)

0 8 bytes: Data

16 bits: Checksum

2 bits: Acknowledge


26/60


Error Detection

Nodes that detect errors send out an error signal immediately

Sender detects error signal and aborts message immediately

Sender retries as soon as bus is idle

Time

Sender

Any nodeError detected

Sending

message

Sending

error signal

Error signal

detected

Resending


27/60


Error Types (1 of 2)

Frame error

Message received violates CAN message structure

Checksum errorChecksum does not match rest of CAN message

#

Sender node receives no ACK signalACK error ?


28/60


Error Types (2 of 2)

Bus monitoringerror

Sender, monitoring the bus as it is sending, receives a bit

different from the one it sent

00110110101000110011011010100010

mismatch

Bit-stuffing error

Signal received violates bit-stuffing rule

000001 111110 000000 111111

Correct:

6th bit after 5

consecutive matching

bits is stuffed

Error:

6th consecutive

matching bit violates

bit-stuffing rule


29/60


CAN PropertiesProtection against intermittent bus errors

Ensures timely delivery of high priority messages

Allows multi-casting: All nodes listen to same message

Notification of broken network

Fault confinement


30/60


Controller Functionality

CAN controllers take care of

Sending and receiving messages Message arbitration

Message filtering

ACK signalling

Error-checking

Resending of unsent messages

Calculating checksum

Bit-stuffing

Bus-monitoring during send action

Keeping track of error count

Bus-off when error limit isexceeded

Accept

Ignore

000001111110


31/60


SocketCANStandard Linux CAN drivers use SocketCAN

Uses Sockets with a different protocol family

AF_CAN and not AF_NET

Use industry standard socket interface

socket(PF_CAN, SOCK_RAW, CAN_RAW);

write(s, &frame, sizeof(struct can_frame));

Provide various socket level filters for CAN messages.

CAN_RAW_FILTER, CAN_RAW_ERR_FILTER,


32/60


CAN for the Internet of Things


33/60


An Interconnected World

Internet of Things

Machines talking to Machines

What brings smarts within the Machine ?

RemoteControl


34/60


An Interconnected WorldWhat brings smarts within the Machine ?

actuators

HMI

Monitor

actuators

sensors

sensors


35/60


actuators

HMI

Monitor

actuators

sensors

sensors

An Internet of things within a machine

CAN BusController Area Network


36/60


Why CANopen ?

Quick and Easy Deployment

Ease of application configuration

Standard Object Oriented Design

Plug and Play

Ease of connectivity

Interoperabili ty of devices and tools


37/60


Typical Applications Medical systems

Vehicle automation

Vending machines

Rail vehicles

Power generation

Maritime electronics

Robotics

Defense

Robot Arm

Medical

Systems

Automotive


38/60


CANopen Protocol


39/60


CANopen Deep Dive

Physical CAN Transceiver(ISO 11898)

Network

Data Link

Transportation

Session

Session

Application CANopen

CAN Controller

(CAN 2.0 A)


40/60


CANopen: Basic Concepts

Object Dictionary

CAN Message Specification (CMS) Defines contents and types of CMS objects via DS 301 Communication Profile

Network management

Layer management

Distributor

Device and Application Profiles

Electronic Data Sheet

Device Configuration File


41/60


Object Dictionary

Every device must implement an object dictionary

Communication

object (NMT, SYNC,TIMESTAMP, Emergency)

Communicationobject

(Server / Client SDO)

Communication

object(Receive/ Transmit PDO)

Application

object

Object

Dictionary

State Machine

ProcessApplication object

CAN

bus

I/O

Obj t Di ti


42/60


Object Dictionary

Index Object

0000 Not used

0001 001F Static Data Types

0020 003F Complex Data Types

0040 005F Manufacturer Specific Data Types

0060 007F Device Profile Static Data Types

0080 009F Device Profile Complex Data Types

00A0 0FFF Reserved

1000 1FFF Communication Profile Area

2000 5FFF Manufacturer Specific Profile Area

6000 9FFF Standardized Profile Area

A000 FFFF Reserved


43/60


Object Dictionary Entries

Index Object Name Data Type Access

Attribute

Mandatory(M) or

Optional (O)

1000 VAR Device Type UNSIGNED32 RO M

1001 VAR Error Register UNSIGNED8 RO M1002 VAR Manufacturer

Status Reg

UNSIGNED32 RO O

1003 ARRAY Pre-defined

error field

UNSIGNED8 RO O

1200 RECORD Server SDO

Comm

Parameter

SDO COMM

PAR

RW M

6000 ARRAY Read 8 input

lines

UNSIGNED8 RO O

S i D t Obj t (SDO )


44/60


Service Data Objects (SDOs)

Client Server Data Byte 1

601(e.g.)

ID

S

0

E

1

N

3 .. 2

X

4

CCS

7 .. 5Index

Bytes 1, 2

Sub-Index

Byte 3

Data

Bytes 4 .. 7

581(e.g.)

ID

SCS

7 .. 5Index

Bytes 1, 2

Sub-Index

Byte 3

Reserved

Bytes 4 .. 7

X

4 .. 0

Byte 0

Example: Expedited SDO download

Client Command Byte

Server Command Byte

P D t Obj t (PDO )


45/60


Process Data

Process Data Objects (PDOs)

Producer Consumer

Bytes 0 to 8

385

(example)

IDrequest

indication

Example: Asynchronous PDO

CANopen state machine


46/60


CANopen state machine

Power- ON / Hardware Reset

Stop Remote

Node indication

Stopped

Init Done. Automatic transition

to Preoperational state.

Initialization

Pre-operational

Operational

Start Remote

Node indication

Enter Pre-

operational state

indication

Start Remote

Node indication

N t k M t M t Sl M d l


47/60


Network Management : Master-Slave Model

Mandatory standard method of starting operation of a CANopen

network.

Bootup

Initialization of NMT Slaves.

Global control of application data exchange

Module Control

Heartbeat / Node Guarding

NMT Master monitors status of NMT slaves Life Guarding

NMT Slaves detect failures in NMT master

Error Control

Electronic Data Sheet (EDS)


48/60


Electronic Data Sheet (EDS)

EDS

Configurationof CANopen

devices

Designing

networkswith

CANopendevices

Managing

projectinformationon differentplatforms

Electronic Data Sheet (EDS):

Template for a device from a

particular vendor

Manufacturer-independentstandardized tools

Device Configuration File (DCF):

Incarnation of configured device

(includes bit-rate and node id)



49/60



Device Profiles

Application Profiles

Defines the interface of a single device

Specification of required and optional devices in a system

Object Dictionary Layout

Communication interface between devices

Specifies mandatory and optional device functionality

Extensions via vendor specific profile range

Examples


50/60


Examples

Device Profiles

Application Profiles

CiA 423 Application profile for rail vehicle power drive systems

CiA 436 Application profile for construction machineries

CiA 401 CANopen device profile for generic I/O modules

CiA 402 CANopen device profile for drives and motion control

CiA 425 Set of device profiles for medical add-on devices

Device Configuration


51/60


Device Configuration

Template

for

differentconfigurati

ons for

one

device

type

EDS

ID=2

250Kbps

ID=110

500 Kbps

DCF Device


52/60


DEBUGGING TOOLS

CAN Tools: CAN Analyser


53/60


CAN Tools: CAN Analyser

CANopen analysis and Configuration


54/60


CANopen analysis and Configuration

Example: Medical


55/60


Example: Medical

OCTRIANs VxWorks 6.9.x CAN driver with POSIX

interface

OCTRIANs VxWorks port of CANopen stackHardware used: ARM processor with on-chip CAN

controllers

Leading Medical Electronics

companys Gantry Controller

Gantry - part of CT scanner withmultiple sensors and actuators

Automated with CAN and CANopen

CAN Interfaces


56/60


CAN Interfaces

Ideal Stack for Real-Time Devices


57/60


Ideal Stack for Real Time Devices

Hardware

Operating System [VxWorks]

CAN drivers

CANopen

Application

Real

Time

Network

Octrian Enables Fast Time to Market


58/60


CAN Driver Support for VxWorks

CANopen stack on VxWorks

iMX6TI AM335X

IXXAT PCI , PCIe, PC104Plus cards

PEAK Systems PCI, PCIe, PC104Plus cards

KVASER PCI, PCIe, PC104Plus cards

iMX6

TI AM335X

IXXAT PCI , PCIe, PC104Plus cards

PEAK Systems PCI, PCIe, PC104Plus cardsKVASER PCI, PCIe, PC104Plus cards

Readily Available Drivers and Stacks

Active Wind River + Octrian Engagements


59/60


g g

Large Manufacturer: Industrial Automation

Fluid mixing system with many sensors and actuators with hardreal-time (millisecond accuracy) requirements

Large Manufacturer: Medical Devices

External pace maker Gantry controls

Octrian: Wind River Strategic Partner


60/60


Octrian: Wind River Strategic Partner

World leader in embedded and mobile

software.

Expert in VxWorks and Linux for

CAN Drivers and Protocol Stacks

Stephen Olsen

[email protected].

Lalita Godbole

[email protected]

Documents

Can Canopen