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 (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 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

Configuration Configure Network Baud Rate Configure Master Node ID

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

Nodes (Continued)  CANOpen Node with ID 5 will have following message identifiers. CAN IDCommunication Object 0hNMT Service 80hSYNC Message 85hEmergency Message 100hTime Stamp Message 185h1 st Transmit PDO 205h1 st Receive PDO 285h2 nd Transmit PDO 305h2 nd Receive PDO 385h3 rd Transmit PDO 405h3 rd Receive PDO 485h4 th Transmit PDO 505h4 th Receive PDO 585hTransmit SDO 605hReceive SDO 705hNMT Error Control

Elements  CANOpen Services, Protocols and Communication objects are as follows  Process Data Objects (PDO) Process Data Objects (PDO)  Service Data Objects (SDO) Service Data Objects (SDO)  Network Management Objects (NMT) Network Management Objects (NMT)  Special function objects (Sync, Emcy, Time) Special function objects (Sync, Emcy, Time)  Error control: Heartbeat protocol Error control: Heartbeat protocol  Device model and object dictionary Device model and object dictionary

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.

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

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

RPDO Configuration Configure Receive PDO message parameters : Message ID, Message transmission type, whether message exists or Not and whether RTR allowed or not. Configure Receive PDO mapping parameters : This screen guides to store received message data in required PLC(OCS) registers.

TPDO Configuration Configure Transmit PDO message parameters : Message ID, Message transmission type, Message Timing parameter, whether message exists or Not and whether RTR allowed or not. Configure Transmit PDO mapping parameters : This screen guides to link given PLC(OCS) register data to required bytes of transmitting message.

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 Default CAN IDs used for SDO Communication  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.

SDO Configuration 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. Configure Client SDO message parameters : Message ID, SDO exists or not, Client ID and Node ID. SDO client is supported by Master only.

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

NMT Configuration Select Slave NMT start Configure Slave Node ID Configure Slave Boot sequence, which is controlled by Master

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

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

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

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.

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.

Error Control Protocol Configuration Configure required error control protocol together with their timing parameters.

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)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)Service Data Object (SDO) is used to gain access to all device parameters. SDO is used for direct device to device communication. Error ControlError Control is used to validate that any device is working proper in terms of CANopen communication. Network ManagementNetwork Management is used to control the network in terms of CANopen communication and indirectly in terms of system behavior.