introduction to canopen n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to CANopen PowerPoint Presentation
Download Presentation
Introduction to CANopen

Loading in 2 Seconds...

play fullscreen
1 / 28

Introduction to CANopen - PowerPoint PPT Presentation


  • 139 Views
  • Uploaded on

Introduction to CANopen. CANopen Introduction. The CANBUS defines only the layers 1 and 2 (ISO11898); in practice these are completely handled by the CAN hardware

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Introduction to CANopen' - dore


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
canopen introduction
CANopen Introduction
  • The CANBUS defines only the layers 1 and 2 (ISO11898); in practice these are completely handled by the CAN hardware
  • However, a high level protocol is necessary in order to define how the CAN message frame's 11-bit identifier and 8 data bytes are used. Interoperability and interchangeability of devices of different manufactures requires a standardized application layer and ‘profiles’.
    • The application layer provides a set of services and protocols useful to every device on the network
    • The communication profile provides the means to configure devices and communication data and defines how data is communicated between devices
    • Device profiles add device-specific behaviour for (classes of) devices (e.g. digital I/O, analog I/O, motion controllers, encoders, etc.).
canopen protocol layer interactions
CANopen Protocol Layer Interactions
  • The protocol layer interactions describe the communication on the different layers. On the CANopen application layer the devices exchanges communication and application objects. All these objects are accessible via a 16-bit index and ´8-bit sub-index.
  • These communication objects (COB) are mapped to one or more CAN frames with pre-defined or configured Identifiers. The CAN physical layer specifies the bit level including the bit-timing.
canopen device model

Server SDOs

Client SDOs

Tx PDOs

Rx PDOs

Communication

Interface

Object

Dictionary

Application

Process

I/O signals

Logical addressing Scheme for Accessing of communication and device parameters, data and functions

Device functions

CAN bus

Process

NMT, SYNC,

EMCY, Time

stamp

CANopen Device Model
  • A CANopen device can be divided into three parts:
    • communication interface and protocol software
    • object dictionary
    • process interface and application program
  • The communication interface and protocol software provide services to transmit and to receive communication objects over the bus. The object dictionary describes all data types, communication objects and application objects used in this device. It is the interface to the application software.
canopen communication protocols
CANopen Communication Protocols
  • CANopen communication objects transmitted via the CAN network are described by the services and protocols. They are classified as follows:
    • The real-time data transfer is performed by the Process Data Objects (PDOs) protocol.
    • With Service Data Objects (SDOs) protocols the read and write access to entries of a device object dictionary is provided.
    • Special Function Object protocols provide application-specific network synchronization, time stamping and emergency message transmissions.
    • The Network Management (NMT) protocols provide services for network initialization, error control and device status control.
process data object pdo
Process data object (PDO)
  • Process data objects are used for fast transmission of process data. A PDO can carry a payload of 8 bytes, which is the maximum payload of a CAN frame.
  • The transmission of a PDO uses the consumer producer model of CAN extended by synchronous transfers.
  • The synchronous transfer of PDOs relies on the transfer of SYNC messages on the CAN bus.
  • A PDO is sent in cyclical mode after a configurable number (1 to 240) of received SYNC messages. It is also possible to wait for the availability of data from the application process and send a PDO after the next received SYNC message. This is called acyclical synchronous transfer.
service data object sdo
Service data object (SDO)
  • Service data objects are intended for transmission of parameters.
  • SDOs provide access to the object dictionary of remote devices.
  • An SDO has no length restriction. If the payload does not fit into the CAN frame, it will be split over several CAN frames.
  • Each SDO is acknowledged. SDO communication uses a peer-to-peer communication with one peer acting as server and the other acting a client.
network management objects nmt
Network management objects (NMT)
  • The network management objects (NMT) change the state, or monitor the status, of a CANopen device.
  • A NMT message is a message with CAN identifier 0. This gives the NMT messages the highest possible priority. The NMT message always consists of two bytes payload in the CAN frame. The second byte contains the node ID of the addressed node.
  • It is possible to address all devices with one NMT message with the reserved node ID 0. The first byte encodes the NMT command.
  • A CANopen device starts in the Initialization state after switching the power on. Then`the device performs its initialization. When the device has completed its initialization it issues a boot-up NMT object to notify the master.
  • The heartbeat protocol for monitoring the device status is implemented with NMT objects.
special function objects sync emcy time
Special function objects (SYNC, EMCY, TIME)
  • CANopen may have a SYNC producer to synchronize the actions of the CANopen nodes. A SYNC producer issues (periodically) the SYNC object. The SYNC object has the CAN identifier 128. This may introduce some jitter due to the priority of this message.
  • A device internal error may trigger an emergency (EMCY) object. The reaction of the EMCY consumers depends on the application. The CANopen standard defines several emergency codes. The EMCY object is transmitted in a single CAN frame
  • with eight bytes.
  • A CAN frame with the CAN ID 256 with six bytes payload can be used to transmit the time of day to several CANopen nodes. This time stamp (TIME) object contains the daytime value in the Time-Of-Day data type.
  • CANopen supports two methods of monitoring the status of devices (watchdog mechanisms).
    • A network manager may poll each device regularly in configurable time intervals. This is called node guarding. Node guarding is, however, bandwidth consuming.
    • Another mechanism is that each device regularly sends a heartbeat message. This saves bandwidth compared to the node guarding protocol.
canopen profiles
CANopen Profiles
  • Device Profiles specify supported application objects, additional error codes, and default PDO mappings. There are mandatory objects, optional objects and manufacturer-specific objects. Device Profiles standardized by CiA use the Object Dictionary entries from 6000h to 9FFFh.
  • CANopen Application Profiles describe a specific application including all devices and optionally some additional specifications of the physical layer. CANopen device and application profiles.
  • Available profiles
    • CiA 401 I/O modules
    • CiA 402 Electric drives
    • CiA 404 Transducer
    • CiA 405 Programmable logic controllers
    • CiA 406 Encoders
    • CiA 408 Proportional valves and hydraulic transmission
    • CiA 410 Inclinometers
    • CiA 412 X-ray collimators
    • CiA 413 Truck gateways
    • CiA 414 Yarn-feeding units
    • CiA 415 Road construction machinery
    • CiA 416 Door control
    • CiA 417 Lift control systems
    • CiA 418 Battery modules
    • CiA 419 Battery chargers
    • CiA 420 Extruder downstream devices
    • CiA 422 Municipal vehicles
    • CiA 425 Medical diagnostic add-on modules
internal device structure
Internal Device Structure
  • CANopen devices are logically structure in three parts
    • CAN interface
    • Device’s application
    • Object Dictionary
      • Parameter list
      • Provides access to the device configuration and process data
      • It is accessed using the CANopen protocol stack
internal device structure1
Internal Device Structure
  • CANopen devices are logically structure in three parts
    • CAN interface
    • Device’s application
    • Object Dictionary
      • Parameter list
      • Provides access to the device configuration and process data
      • It is accessed using the CANopen protocol stack
internal device structure2
Internal Device Structure
  • CANopen devices are logically structure in three parts
    • CAN interface
    • Device’s application
    • Object Dictionary
      • Parameter list
      • Provides access to the device configuration and process data
      • It is accessed using the CANopen protocol stack
canopen object dictionary
CANopen Object Dictionary
  • Heart of every CANopen device
    • It is present in every device
  • It represents a grouping of objects accessible via the network in an ordered and pre-defined fashion
    • Each object is addressed using a 16-bit index and 8-bit subindex
  • Object Dictionary is structured in several index range
    • 1000h to 1FFFh → communication behaviour
    • 2000h to 5FFFh → application behaviour (manufacturer specific)
    • 6000h to 9FFFh → application behaviour (standardized profiles)
      • it is possible to provide up to eight device/application profile implementations within one CANopen device
    • A000h to BFFFh → network variables and system variables
canopen object dictionary2
CANopen Object Dictionary
  • Each node not only implements its object dictionary but also a server that handles read/write operations to its OD
  • The way to access OD entries is using SDO transfers (client/server peer-to-peer communication)
canopen object dictionary3
CANopen Object Dictionary
  • Each node not only implements its object dictionary but also a server that handles read/write operations to its OD
  • The way to access OD entries is using SDO transfers (client/server peer-to-peer communication)
canopen object dictionary4
CANopen Object Dictionary
  • Each node not only implements its object dictionary but also a server that handles read/write operations to its OD
  • The way to access OD entries is using SDO transfers (client/server peer-to-peer communication)
electronic data sheet
Electronic Data Sheet
  • In the object dictionary the device designer indicates the supported device functionality by implementing the related objects
  • The communication behaviour is adjusted in the appropriate objects in the index range 1xxxh
  • Parameters and results required or generated by manufacturer specific device functions, can be indicated in the index range 2000h to 5FFFh
  • In addition manufacturer specific status information and process data can be represented to the network in that index range.
  • EDS is a “human readable” representation of the CANopen object dictionary
    • ASCII
    • XML
eds architecture
EDS “architecture”

EDS

Profile(s)

EDS

Vendor

Specific

Specifies the process data variables a node knows and the default configuration and communication settings

Device

EDS

 Defines the format of

an Object Dictionary

that may apply to

multiple nodes of that type

Device

Config.

File

(DCF)

Stores configuration

parameters of a

specific node 

eds entries
EDS Entries
  • A 16-bit index is used to address all entries within the object dictionary.
    • In case of a simple variable this references the value of this variable directly.
    • In case of records and arrays however, the index addresses the whole data structure
    • For complex object dictionary entries such as arraysorrecords with multiple data fields the sub-index references fields within a data-structure pointed to by the main index
  • Example: manufacture specific RS-232 interface
    • Defines an entry in index 6092h to define communication parameters for that module
canopen eds profiles
CANopen EDS Profiles
  • Device Profiles specify supported application objects, additional error codes, and default PDO mappings. Device Profiles standardized by CiA use the Object Dictionary entries from 6000h to 9FFFh.
  • Devices of different manufacturers can be accessed via the bus in exactly the same manner. In this way, a very high degree of vendor independence is achieved as the devices are interoperable and exchangeable. Therefore, CANopen is on one hand standardized, but on the other hand it is still open to a nearly unlimited field of applications.
  • Available profiles
    • CiA 401 I/O modules
    • CiA 402 Electric drives
    • CiA 404 Transducer
    • CiA 405 Programmable logic controllers
    • CiA 406 Encoders
    • CiA 408 Proportional valves and hydraulic transmission
    • CiA 410 Inclinometers
    • CiA 412 X-ray collimators
    • CiA 413 Truck gateways
    • CiA 414 Yarn-feeding units
    • CiA 415 Road construction machinery
    • CiA 416 Door control
    • CiA 417 Lift control systems
    • CiA 418 Battery modules
    • CiA 419 Battery chargers
    • CiA 420 Extruder downstream devices
    • CiA 422 Municipal vehicles
    • CiA 425 Medical diagnostic add-on modules
canopen eds profiles e g transducer profile
CANopen EDS Profiles(e.g. Transducer profile)
  • DS404 defines transducers and close-loop controllers
    • Interfaces to sensors, actuators and PID-controllers
  • Sensor data that are available after the A/D conversion are saved to object dictionary of the device
    • Parameters are configurable via SDO
    • Process data are written to the OD after scaling
    • Analog input values are storable in different formats (specific area in the OD)
      • Floating integer (field value (FV): 6100h, process value (PV) 6130h)
      • 16-bit integer (FV: 7100h, PV: 7130h)
      • 24-bit integer (FV: 8100h, PV: 8130h)
      • 32-bit integer (FV: 9100h, PV: 9130h)
  • Up to 199 analog input channels
    • Process data of each channel sent using PDOs
  • The profile also defines output channels
    • Allows close-loop controller
eds pressure transducer example
EDS Pressure Transducer Example

JUMO CANtrans p Ceramic Pressure transmitter with CANopen output (40.2055)

  • The pressure measurement is digitized and made available for further processing via the CANopen serial bus protocol (CAN slave).
  • Several useful extra functions have been implemented through the DS 404 (Transducer profile) device profile.

J_P_0101.eds

discussion
Discussion
  • Since CANbus/CANopen will become an ECSS standard, ESA needs to ensure that the SOIS work is compatible
  • One advantage of using CANopen is that it will force the use of EDS and thus suppliers/integrators will be obliged to provide them
  • The CANopen EDS approach seems to cover both the communication and functional interface how can we fit this within SOIS and the use of other EDS definitions?
  • So far we have assumed the use of xTEDS for functional interfaces and TEDS for the communication interface definitions – do we arrive at a SOIS definition that can serve everything?
  • Alternatively, what will be ask the device manufactures to comply with?

Functional

DVS

SPA

X-TEDS

CAN

EDS

SOIS

EDS

SpaceWire

Milbus

1451

TEDS

Comms

DAS

CANBus

Existing

1451 device

others