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.
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.
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.
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.
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 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".
The following features have been implemented in version 2.0 of the CANopen Reference Example for the NI-9853 C-Series CAN Module:
This component is maintained by the NI Systems Engineering group.
You can give us feedback by posting questions and comments through the CANopen Reference Example for the NI-9853 C-Series CAN Module discussion thread.
We do not regularly monitor reader comments posted on this page.
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.