Overview
Download
1 / 22

Overview - PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on

Overview.

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 'Overview' - colm


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
Overview

Overview

  • CANopen is a CAN-based higher layer protocol. It was developed as a standardized embedded network with highly flexible configuration capabilities. CANopen was designed for motion-oriented machine control networks, such as handling systems. By now it is used in many various fields, such as medical equipment, off-road vehicles, maritime electronics, public transportation, building automation, etc

  • In CAN, a single messages is kept short and only contains up to 8 data bytes

  • Benefits:

  • There can be many messages per second (rule over thumb: up to 10,000 per second at 1 Mbit, worst case of 20,000 per second)

  • •No single message can occupy/block the network for a long time

  • •Best for small sensors and actuators

  • (I/O modules, encoder, push buttons, temperature,…)

  • Concept: send less data –more often


Overview

Overview (Continued)

  • The CANopen communication profile was based on the CAN Application Layer (CAL) protocol. Version 4 of CANopen (CiA DS 301) is standardized as EN 50325-4.The CANopen specifications cover application layer and communication profile (CiA DS 301), as well as a framework for programmable devices (CiA 302), recommendations for cables and connectors (CiA 303-1) and SI units and prefix representations (CiA 303-2). The application-layer as well as the CAN-based profiles are implemented in software

  • CANopen unburdens the developer from dealing with CAN-specific details such as bit-timing and implementation-specific functions. It provides standardized communication objects for real-time data (Process Data Objects, PDO), configuration data (Service Data Objects, SDO), and special functions (Time Stamp, Sync message, and Emergency message) as well as network management data (Boot-up message, NMT message, and Error Control).

  • CANOpen specified networking bit rates are

    • •10 kbps

    • •20 kbps

    • •50 kbps

    • •125 kbps

    • •250 kbps

    • •500 kbps

    • •800 kbps

    • •1000 kbps


Overview

Configuration

Configure Master Node ID

Configure Network Baud Rate


Overview

Nodes

  • Main CANOpen trunk with termination resistors.

  • Each node must have a unique node ID .

    In the range of 1 to 127.

  • Maximum length depends on network speed

    Example: about 250m with 250kbps

  • Default CAN message identifiers for messages in CANOpen network is as shown in table below.

  • The default message identifiers used by CANopen nodes are directly related to their node ID.

  • The node ID gets ‘embedded’ into the message identifier

  • On CAN using an 11-bit message identifier,

    the node ID is in bits 0-7.

  • Bits 8-10 contain message type information

  • IDs not listed are free and may be used by system integrator


Overview

Nodes (Continued)

  • CANOpen Node with ID 5 will have following message identifiers.


Overview

Elements

  • CANOpen Services, Protocols and Communication objects are as follows

    • Process Data Objects (PDO)

    • Service Data Objects (SDO)

    • Network Management Objects (NMT)

    • Special function objects (Sync, Emcy, Time)

    • Error control: Heartbeat protocol

    • Device model and object dictionary


Overview

Protocol – Process Data Object (PDO)

  • Process Data Objects (PDOs) are mapped to a single CAN frame using up to 8 bytes of the data field to transmit application objects. Each PDO has a unique identifier and is transmitted by only one node, but it can be received by more than one (producer/consumer communication).

  • PDO transmissions may be driven by an internal event, by an internal timer, by remote requests and by the Sync message received

  • Event- or timer-driven: An event (specified in the device profile) triggers message transmission. An elapsed timer additionally triggers the periodically transmitting nodes.

  • Remotely requested: Another device may initiate the transmission of an asynchronous PDO by sending a remote transmission request (remote frame).

  • Synchronous transmission:

    • In order to initiate simultaneous sampling of input values of all nodes, a periodically transmitted Sync message is required.

    • Synchronous transmission of PDOs takes place in cyclic and acyclic transmission mode.

    • Cyclic transmission means that the node waits for the Sync message, after which it sends its measured values. Its PDO transmission type number (1 to 240) indicates the Sync rate it listens to (how many Sync messages the node waits before the next transmission of its values).

    • Acyclically transmitted synchronous PDOs are triggered by a defined application-specific event. The node transmits its values with the next Sync message but will not transmit again until another application-specific event has occurred.


Overview

Protocol – Process Data Object (PDO) (Continued)

  • PDO mapping:

    • The default mapping of application objects as well as the supported transmission mode are described in the Object Dictionary for each PDO.

    • PDO identifiers should have high priority to guarantee a short response time.

    • PDO transmission is not confirmed.

    • The PDO mapping defines which application objects are transmitted within a PDO (i.e. for PLC based system, Register values are sent over PDOs e.g. %R50,%R100 etc ).

    • It describes the sequence and length of the mapped application objects.

    • If dynamic mapping during operational state is supported, the SDO Client is responsible for data consistency


Overview

Protocol – Process Data Object (PDO) (Continued)

  • Per default, each node has access to 8 PDOs, messages with process data in them

  • •4 Transmit PDOs (TPDO)

  • •4 Receive PDOs (RPDO)

  • Per default, all transmit PDOs are received and handled ONLY by the master

  • Per default, ONLY the master is allowed to use the CAN message IDs used for transmit PDOs

  • •So it’s only the master who can send data to the nodes

  • With dynamic linking, PDOs are re-assigned

  • •Nodes can be configured to

  • -Use specific CAN IDs for transmit PDOs

  • -Listen to specific CAN IDs for receive PDOs

Master

Predefined PDO Connections

Dynamic PDO Linking


Overview

RPDO Configuration

Configure Receive PDO mapping parameters : This screen guides to store received message data in required PLC(OCS) registers.

Configure Receive PDO message parameters : Message ID, Message transmission type , whether message exists or Not and whether RTR allowed or not.


Overview

TPDO Configuration

Configure Transmit PDO mapping parameters : This screen guides to link given PLC(OCS) register data to required bytes of transmitting message.

Configure Transmit PDO message parameters : Message ID, Message transmission type, Message Timing parameter , whether message exists or Not and whether RTR allowed or not.


Overview

Protocol – Service Data Object (SDO)

  • Used for Point-To-Point communication between a configuration tool or master/manager and the nodes

  • Allows complete access to all entries in the Object Dictionary of a node

  • •Includes all process data

  • Confirmed communication mode

  • •Each request gets a response

  • Supports transfer of long data blocks such as upload or download of code blocks

  • •Up to 7 bytes per message, every message confirmed by receiver

  • •Special “block transfer mode” allows transmitting blocks of messages with just one confirmation

  • The SDO transport protocol allows transmitting objects of any size.

  • The first byte of the first segment contains the necessary flow control information including a toggle bit to overcome the well-known problem of doubly received CAN frames.

  • The next three byte of the first segment contain index and sub-index of the Object Dictionary entry to be read or written.

  • The last four byte of the first segment are available for user data.

  • The second and the following segments (using the very same CAN identifier) contain the control byte and up to seven byte of user data.

  • The receiver confirms each segment or a block of segments, so that a peer-to-peer communication (client/server) takes place.

Default CAN IDs used for SDO Communication


Overview

SDO Configuration

Configure Client SDO message parameters : Message ID, SDO exists or not, Client ID and Node ID. SDO client is supported by Master only.

Configure Server SDO message parameters : Message ID, SDO exists or not, Client ID and Node ID. SDO server is supported by both Master and Slave Node.


Overview

Protocol – Network Management (NMT)

  • The Network Management objects include Boot-up message, Heartbeat protocol, and NMT message.

    Boot-up message, and Heartbeat protocol are implemented as single CAN frames with 1-byte data field

  • The NMT message transmitted by the NMT master forces the nodes to transit to another NMT state .

  • The NMT message is mapped to a single CAN frame with a data length of 2 byte. Its identifier is 0. The first byte contains the command specifier and the second contains the Node-ID of the device that must perform the command (in the case of Node-ID 0 all nodes have to perform the command).

  • The CANopen state machine specifies the states Initialization, Pre-Operational, Operational and Stopped After power-on, each CANopen device is in the state Initialization and automatically transits to the state Pre-operational. In this state, transmission of SDOs is allowed. If the NMT master has set one or more nodes into the state Operational, they are allowed to transmit and to receive PDOs. In the state Stopped no communication is allowed except that of NMT objects.

  • A device sends the Boot-up message to indicate to the NMT master that it has reached the state Pre-operational


Overview

NMT Configuration

Configure Slave Node ID

Select Slave NMT start

Configure Slave Boot sequence, which is controlled by Master


Overview

Protocol – Special Function Objects

  • CANopen also defines three specific protocols for synchronization, emergency indication, and time-stamp transmission

  • Synchronization object (Sync) :

    • The Sync Object is broadcast periodically by the Sync Producer.

    • The time period between Sync messages is defined by the

      Communication Cycle Period, which may be reset by a configuration

      tool to the application devices during the boot-up process .

    • The Sync message is mapped to a single CAN frame with the identifier

    • 128 by default.

    • The Sync message does not carry any data


Overview

Protocol – Special Function Objects (Continued)

  • Emergency Message :

    • The Emergency message is triggered by the occurrence of a device internal

      error situation and are transmitted from an Emergency producer on the concerned

      application device. This makes them suitable for interrupt type error alerts.

    • Emergency message is transmitted only once per ‘error event’. As long as no

    • new errors occurs on a device, no further Emergency message can be transmitted.

    • Zero or more Emergency consumers may receive these.

    • The reaction of the Emergency consumer is application-specific.

    • CANopen defines several Emergency Error Codes to be transmitted in the

    • Emergency message, which is a single CAN frame with 8 data byte.

  • Time-Stamp Message:

    • By means of Time-Stamp, a common time frame reference is provided to

      application devices.

    • It contains a value of the type Time-of-Day.

    • This object transmission follows the producer/consumer push model.

    • The associated CAN frame has the pre-defined identifier 256 and a

    • data field of 6-byte length


Overview

Special Function Configuration

Configure Special function object parameters such as their ID and timing parameters


Overview

Error Control Protocol

  • Node Guarding Protocol :

    • This protocol is used to detect remote errors in the network.

    • Each NMT Slave uses one remote COB for the Node Guarding Protocol.

    • This protocol implements the provider initiated Error Control services.

    • The NMT Master polls each NMT Slave at regular time intervals. This time-interval is called the guard time and may be different for each NMT Slave.

    • The response of the NMT Slave contains the state of that NMT Slave.

    • The node life time is given by the guard time multiplied by the life time factor. The node life time can be different for each NMT Slave.

    • If the NMT Slave has not been polled during its life time, a remote node error is indicated through the 'Life Guarding Event' service.


Overview

Error Control Protocol (Continued)

  • Heartbeat Protocol :

    • The Heartbeat Protocol defines an Error Control Service without need for remote frames.

    • A Heartbeat Producer transmits a Heartbeat message cyclically. One or more Heartbeat Consumer receive the indication. The relationship between producer and consumer is configurable via the object dictionary.

    • The Heartbeat Consumer guards the reception of the Heartbeat within the Heartbeat Consumer Time. If the Heartbeat is not received within the Heartbeat Consumer Time a Heartbeat Event will be generated.


Overview

Error Control Protocol Configuration

Configure required error control protocol together with their timing parameters.


Overview

Device Model

Any CANopen device can be seen as a generic device. This generic device is connected to CAN on one side and connected to application specific I/O data on the other side. The application is the key knowledge of the device manufacturer. The interface between the application and CAN is realized by an object dictionary. The object dictionary is unique for any CANopen device and represents the whole access to its implemented application in terms of data as well as in terms of configuration. To gain access to the object dictionary each CANopen device has to realize a CANopen protocol stack. This CANopen protocol stack is a piece of software, which normally is implemented on the same controller that is used by the application software.

The CANopen protocol stack consist of different functions for different purposes.

Process Data Object (PDO) is used to transmit the application data. The application data is transmitted without any protocol overhead in broadcast.

Service Data Object (SDO) is used to gain access to all device parameters. SDO is used for direct device to device communication.

Error Control is used to validate that any device is working proper in terms of CANopen communication.

Network Management is used to control the network in terms of CANopen communication and indirectly in terms of system behavior.