CANopen Reference Example for the NI-9853 C-Series CAN Module

[ExamplePrograms]

Description

Description-Separate-1

Overview

The CANopen protocol is a higher level protocol which is based on CAN, a message-based bus protocol which facilitates communication between devices typically on an in-vehicle network. The NI-9853 is a 2-port, high-speed CAN module for CompactRIO systems. A CANopen Reference Example has been developed to provide additional functionality to this device, by adding support for CANopen features such as network management (NMT), service data objects (SDOs), process data objects (PDOs), synchronization (SYNC), and time stamps (TIME). The CANopen Reference Example provides a high level API which allows users to interact with CANopen slave devices.

CANopen Introduction

CANopen is a communication protocol that is built on top of the CAN bus, which determines how CAN frames are handled. CANopen is used for network management and communication schemes, such as handling emergency messages, handshaking, and synchronization. 

The CAN Engine Concept

In this example, CANopen is the only higher-level protocol implemented. However, the example is designed to be modifiable to interface with other protocols or data conversions such as J1939 or CAN frame to channel conversion. These additional features can be implemented and work simultaneously on the same CAN network through the use of a set of VI’s called the CAN Engine, as shown below.

The CAN Engine VI’s manage the data going to and from the CAN network. In the host application, all data is passed through the CAN Engine Access VIs, which are non-reentrant VIs that allow sharing of the CAN Engine resource. Data sent to the CAN network from the host application is placed in a queue and transferred to the FPGA and to the CAN network. Data received from the CAN network is placed in a data table residing on the FPGA. Each data table index represents a CAN arbitration ID. Incoming CAN arbitration ID’s must be setup at run time. Incoming ID’s that are not setup are ignored. Changes to the incoming data can be detected by the host application by monitoring the data timestamp which is stored with each incoming data frame.

Basic CANopen protocol VI’s are implemented in this example, and are written entirely with LabVIEW VIs. This example is designed for the NI-9853 and should not be confused with other CANopen Reference Examples. More information about using CANopen with National Instruments products can be found in What CANopen Hardware and Software Products Does National Instruments Offer?

The example has VI’s for SDO’s, PDO’s, NMT’s and SYNC messages. Note: these CANopen VI’s have not been extensively tested and may not completely conform to CiA CANopen standards.

Implementation

The following subsections will describe the CANopen features in detail, and their implementation in the CANopen Reference Example for the NI-9853 C-Series CAN Module. 

Object  Dictionary and Service Data Objects (SDOs)

The SDO is used to set and retrieve parameters from the object dictionary of a remote device. The following image shows the front panel of the SDO Example. Note how you have the ability to specify the node address of the CANopen device, the type of SDO (i.e. read or write), and the object dictionary index and optional subindex.

The block diagram of the SDO Example is shown below. The example first needs to run the FPGA code, which accesses and sends the raw CAN data from the NI-9853 module and transfers it to the real-time processor for additional control. Next, the CAN engine is accessed, allowing the code to access the CAN shared resource. As part of the CANopen protocol, the example transitions the CANopen node to a preoperational state which prepares the slave for data transfer. Next, the message is written to the bus, and the master looks for the response to ensure that the slave has received the message. Lastly, the slave state is change to stopped to signal the end of the data transfer with that node. Finally, the CAN engine shared resource is released.

Process Data Objects (PDOs)

A PDO is essentially a "shortcut" to several variables in the Object Dictionary. Using a process called PDO mapping, any object dictionary parameter can be mapped to the data frame in a PDO. The following image shows the PDO Example, which is requesting the data of object indexes mapped to PDO1. The structure is similar to the SDO Example: the FPGA VI is run and the state of the CANopen device is changed to preoperational. The parameters for the first PDO are located at object dictionary 1800, and the communication type information is transferred to the slave device, which requests the PDO data from the slave device. Once the PDO data is transferred back to the master, the slave state is changed to stopped and the application releases the CAN engine shared resource. 

Network Management

Network management services include the ability to change the state of a slave between initializing, preoperational, operational and stopped. Certain types of CANopen communication are allowed in different states. For example, SDOs are allowed in the preoperational state, but PDOs are not. This is because SDOs are often used to initialize object dictionary parameters, whereas PDOs are often used to communicate continually updating parameters. The CANopen Reference Example for the NI-9853 C-Series CAN Module includes support for the network management (NMT) protocol, including heartbeats and synchronization. Heartbeats are used to check if a CANopen node is still "alive".

New Features Implemented in Version 2.0

The following features have been implemented in version 2.0 of the CANopen Reference Example for the NI-9853 C-Series CAN Module:

• Implementation of Batch SDO: the ability to update a list of SDOs. This includes the addition of a Windows-based configuring tool for importing an EDS file or create your own batch SDO.
• Added the ability to check for new data. 
• Changed CANopen Access to separate send and receive operations to improve the readability and scalability of the design. Included the addition of the delay VI.
• Replaced RT FIFOs with queues
• Changed timestamp so that it now represents when data is grabbed from the CAN bus.
• Improved usability by adding VI descriptions, meaningful icons, and improving connector panes.
• Added examples for checking for new data and batch SDO

Feedback

This component is maintained by the NI Systems Engineering group. 

We do not regularly monitor reader comments posted on this page.

Additional Resources

• CANopen Basics for cRIO - A more basic example of CANopen with cRIO and the NI 9853 CAN module
• What CANopen Hardware and Software Products Does National Instruments Offer?

Description-Separate-2