Scribd
Upload
433 views

CANopen

This document provides an overview of CANopen, a higher-layer protocol built on top of Controller Area Network (CAN). It was originally designed for motion control applications. CANopen defines standardized communication profiles and device profiles to provide interoperability between devices from different manufacturers. It supports master-slave communication and real-time process data exchange using process data objects and configurable device parameters using service data objects. CANopen provides network management functions for device configuration, monitoring, and synchronization.

Uploaded by

np2930
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
433 views

CANopen

This document provides an overview of CANopen, a higher-layer protocol built on top of Controller Area Network (CAN). It was originally designed for motion control applications. CANopen defines standardized communication profiles and device profiles to provide interoperability between devices from different manufacturers. It supports master-slave communication and real-time process data exchange using process data objects and configurable device parameters using service data objects. CANopen provides network management functions for device configuration, monitoring, and synchronization.

Uploaded by

np2930
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 31

Higher Layer Protocol based on Controller Area Network (CAN)

Prepared by Nisarg Pandya (121060752029)

What is CANopen ?
Higher Layer Protocol based on Controller Area Network (CAN) All CAN features are available: Simplicity, high reliability, extremely short reaction/error recovery times Master/Slave configuration, Multi-Master & direct communication between Slaves supported Was originally designed for Motion Control
CANopen 2

Contd..
Open system, non-proprietary Supports device profiles for Digital I/O, Analog I/O, Motion Controllers, Sensors, Actuator, etc.

All CANopen devices speak the same language


Ultimate goal: interchangeable Manufacturer-independence, devices are

CANopen

Higher Layer Protocols


Why Higher Layer Protocols? Data Transport of more than 8 bytes Embedded Systems require appropriate communication model based on Master/Slave configuration Network Management (Network StartUp, Node Monitoring, Node Synchronization, etc.)

CANopen

Higher Layer Protocols


CANopen Suited for embedded applications Was originally designed for motion control Developed/Maintained by CAN-in-Automation User Group Manufacturer-Independent Protocol

CANopen

A Short History of CANopen


1983 Start of Bosch internal project to develop in-vehicle network 1986 Official introduction of the CAN protocol 1987 First CAN controller chips by Intel & Philips 1991 Bosch publishes CAN specification 2.0 1992 CAN in Automation (CiA) established 1992 CAN Application Layer (CAL) protocol by CiA 1992 First automobiles equipped with CAN (Mercedes Benz) 1993 ISO 11898 standard published 1994 First International CAN Conference (iCC) 1994 Allen Bradley introduces DeviceNet 1995 ISO 11898 amendment (extended frame format) 1995 CANopen protocol introduced
CANopen 6

CANopen Applications
Semiconductor Industry (Wafer Handlers, etc.) Robotics, Motion Control Applications Passenger/Cargo Trains (Brake Control, Wagon Communication) Aircrafts (AC, Seat Adjustment) Elevators (e.g. Otis) Building Technologies (Light & Door Control Systems, Sensors, etc.) Medical Equipment (X-Ray, CAT scanners, etc.) Household Utilities (Coffee Machine, Washer, etc.) Aerospace (Satellites)

CANopen

Benefits of Using CANopen


Physical and Data Link Layer implemented in Silicon SW Development Engineer is not involved with writing protocol features

Low Cost Implementation


Very Reliable, Error-Resistant

Worldwide Acceptance
Last, but not leastCANopen Saves You Money!
CANopen 8

CANopen Characteristics
Standardized protocol services provided, available as source code off- the-shelf Protocol supports node IDs in addition to CAN message IDs

Supports up to 127 nodes in a network, each node requires a unique ID


Very low resources/memory print CANopen Slave ~1020k ROM, <1k RAM CANopen Master ~2030k ROM, ~1k RAM
CANopen 9

CANopen Reference Model

CANopen

10

Device Profiles
Profile DS-401 DS-402 DS-403 DS-404 DS-405 DS-406 DS-407 DS-408 DS-409 DS-410 DS-412 DS-413 DS-414 DS-415 DS-416 DS-417 S-418 DS-419 DS-420 Device Generic I/O modules Drives and motion control Not allocated Measuring devices and closed loop controllers IEC 61131-3 programmable devices Encoders Public transportation - Passenger Information Systems Fluid Power Technology - Hydraulic drives and proportional valves Vehicle door control Declinometers Medical Devices Truck Gateways Weaving Machines Road Construction Machinery Building Door Control Lift Control Systems D Battery Modules Battery Chargers Extruder Downstream Devices
CANopen 11

Object Dictionary

CANopen

12

Index 0000h 0001h 025Fh 0260h 0FFFh

Object Not Used Data Type Reserved Common to any Device

1000h 1FFFh
2000h 5FFFh 6000h 9FFFh A000h AFFFh B000h FFFFh

Communication Profile Area


Manufacturer Specific Profile Area Standardized Device Profile Area Network Variables Reserved for Future Use Device Specific

CANopen

13

CANopen

14

Communication Interface

CANopen

15

Communication Interface
SDO Service Data Object Supports transfer of data of any length (Configuration data, program download, etc.) Confirmed communication, each request results in a response

PDO Process Data Object Provides backward compatibility to CAN Transfer of max. 8 data bytes without protocol overhead Used for real-time transmission of process data

CANopen

16

SDO Service Data Object


Used for point-to-point communication between two nodes acting as SDO Client and SDO Server Provides Read/Write access to all entries in Object Dictionary of a node Read/Write Data is identified by Index & Sub-Index Supports transfer of any length of data Confirmed communication, each request results in a response 2 CAN identifiers per SDO Mainly used for device configuration and download/upload of large data blocks Each CANopen device must support at least the Default-Server-SDO which always provides basic access to the device
CANopen 17

SDO Transfer Modes


Expedited Transfer Fast SDO transfer mode for data up to 4 bytes Non-Expedited Transfer (Segmented Transfer) SDO transfer mode for any length of data Flow control after 7 transmitted bytes Block transfer SDO transfer mode for any length of data Fast transfer method with flow control after block transfer of 1127 bytes
CANopen 18

SDO Protocol

CANopen

19

PDO Process Data Object


Used for real-time transmission of process data Provides very efficient transmission of data according to ConsumerProducer model Transfer of max. 8 bytes without protocol overhead Definition of transmitted data described per PDO Mapping Unconfirmed transfer (correct reception of data is handled by CAN protocol) 1 CAN identifier per PDO Number of Transmit/Receive PDOs of a device according to application needs

CANopen

20

PDO Transmission Modes


Event Driven PDO transmitted upon occurrence of an event, e.g. change of input An optional event timeout can be defined to trigger the transmission after a given time elapsed without any event Polling (Remote Request) PDO is transmitted only upon request from a remote device (per remote frame) Synchronized PDO is only transmitted upon reception of a SYNC message

CANopen

21

PDO Protocol

CANopen

22

System Services
Notification of Device Errors Emergency functionality to signal failures of application or communication System-wide Synchronization of Processes Simultaneous execution of processes System-wide time reference Common time base throughout the network

CANopen

23

Network Management

CANopen

24

Network Management
Network Management is based on Master/Slave relationship Tasks of a CANopen Master/Manager Controlling the network boot-up process Verification and supervision of system consistency Download of configuration data to new devices Controlling the communication status of a device Device Monitoring Node-Guarding (Master/Slave Monitoring) Heartbeat (Device status is transmitted as broadcast information, each device can monitor other devices)

CANopen

25

Device Communication State

CANopen

26

Further CANopen Network Services


Configuration Manager Enables automatic download of configuration data to new and unconfigured CANopen devices, e.g. in case of exchange of faulty device. Allows Plug & Play. SDO Manager Manages dynamic establishment of SDO connections between devices during run-time. Layer Setting Services Additional services for configuration of node ID and baud rate via CAN, no DIP Switches required.

CANopen

27

Further CANopen Network Services


Flying Manager Allows more than one CANopen Master/Manager, e.g. for backuppurposes. Negotiation of active Master performed automatically. Redundancy (Fault Tolerant CANopen) Uses two independent CAN lines for communication.

CANopen

28

Conclusion
According to CANopen communication profile and the appropriate CANopen device profile two independent manufacturers can produce standardized devices, which can be incorporated seamlessly into the same CANopen CAN network.

3 levels of compatibility can be distinguished: Conformance Interoperability Interchangeability

CANopen

29

Refrences
www.can-cia.org CANopen-high-level protocol for CAN-bus by H. Boterenbrood NIKHEF, Amsterdam March 20, 2000 The Future of CAN / CANopen and the Industrial Ethernet Challenge by Wilfried Voss, President esd electronics, Inc USA canopen-solutions.com/canopen_fundamentals_en.html en.wikipedia.org/wiki/CANopen http://www.esd-electronics.us

CANopen

30

CANopen

31

You might also like