xPC Target    

CAN-AC2 and CANopen Devices

xPC Target CAN-AC2 supports CAN specification 2.0a and 2.0b but this does not generally include the CANopen protocol on driver level. Nevertheless it is possible to access CANopen devices by the CAN-AC2 drivers in a general way.

CANopen knows two types of messages i.e. SDO and PDO. SDOs are used to setup or initialize a CANopen device for a certain behavior. PDOs are messages that contain real-time data (i.e. converted A/D values from a analog input device) and are CAN-type messages with no CANopen object, index, and subindex information.

xPC Target applications that have to access CANopen devices over the CAN-AC2 drivers transmit SDOs during the initialization phase and the termination phase of the driver. PDOs are sent or received during the simulation phase of the driver.

Because SDOs and PDOs are regular CAN-messages the CAN-AC2 drivers have to provide a way to transmit SDOs during the initialization and termination phase of the CAN-AC2 set up driver block to initialize the different CANopen devices in the network. This is done by providing a c-file within your project directory that describes the SDO messages to send to setup and terminate the CANopen device. During the compilation stage of the xPC Target application (build-process) this c-file, which has to have the filename CANAC2_setup.c, is then included into the setup driver.

This implementation has the advantage of accessing a specific CANopen device without the need to have special driver blocks for this device. It is, therefore, a general implementation but has the disadvantage that the user must be able to provide the information (messages) to properly set up and terminate the communication with a specific CANopen device. This information is provided either by the CANopen device manufacturer or by the CAN-CIA association (www.can-cia.de).

For an explanation of how to write the CANAC2_setup.c file for a specific CANopen device, see the example below. In this example an analog input device from Selectron (www.selectron.ch) with the name AIC711 is used to get the A/D-converted values over the CAN-network into the xPC Target application.

Example: Accessing the AIC711 CANopen Device from Selectron

The AIC711 contains four analog input channels with a resolution of 12bits and a minimal update-time (sample time) of 10ms.

As explained in earlier chapters, the CAN-AC2 drivers use the dynamic object model to reach low latency times. Therefore the A/D values from the AIC711 have to be received in such a way that they are compatible to the object model of the driver.

The AIC711 has to be seen as a CANopen server and the xPC Target CAN-AC2 drivers (the xPC Target application) as a CANopen client. The AIC711 offers two ways of getting the converted A/D-values over the network:

In the synchronous mode, the client transmits a remote frame to the server to invoke an A/D-conversion of a specified channel. It then waits (poll) until the converted value is received by an ordinary CAN data-message which will contain the values. Synchronous mode leads to large latency times up to 20ms (Tsmin=10ms). During this time period, the xPC Target gets stuck and this is inacceptable.

In addition, the synchronous mode does not fit into the dynamic object model implementation of the xPC Target CAN-drivers because remote frames have to be transmitted.

In the asynchronous mode, the AIC711 sends PDOs automatically in a regular manner to the client. A change in an analog input value invokes automatically an A/D-conversion. After conversion, a PDO-message is constructed and sent automatically to the client. This mode fits well into the object model of the drivers. Therefore the CANopen devices should always be used in asynchronous mode if used with xPC Target.

Regarding the information in the AIC711 CANopen manual (provided by Selectron), the following initialization messages (SDOs) and termination messages (SDOs) must be invoked.

The node id of the AIC711 device is set over DIP-switches and, in this example, it is assumed that the node id is set to 11 (decimal). The device is connected to CAN-port 1 of the CAN-AC2-board.

Then the CANAC2_setup.c file could look as follows

As soon as this file is placed into your project directory and the xPC Target application is rebuilt, the messages defined above will be sent during initialization and termination phase of the Setup block.

The Simulink model could look as follows

The Receive block will read continuously the object to which the AIC711 sends the PDOs (i.e. the converted A/D-values).

Because the output of this block contains the 8 bytes of the received CAN-data as a double value, a conversion block (AIC711conversion) is necessary to split the 8 bytes (double) into 4 doubles (output signals) that represent the A/D value in volts for each of the four analog input channels. The conversion is made according to the data representation of object 6401. Use the aselmasaic711.c file as a template to implement conversion blocks for other CANopen devices. The third channel is then stored with an outport block, which can be visualized by the xPC Target scope functionality.

Because CAN-messages with id 0 (boot) and 1536+node_id (SDO) have to be sent and CAN-messages with id 640+node_id (PDO) have to be received over CAN-port 1, the dialog box of the Setup block must look as follows:

The Receive block receives the data (PDO) over CAN-message 640+node-i and must look as follows:

If more than one CANopen device is connected to the network, the dialog boxes of the Setup and Receive blocks and the CANAC2_setup.c file have to be extended accordingly. If you need for-loops in the CANAC2_setup.c, use the variable CANAC2_counter.

If an analog output device (or digital output device) is connected to the network, you must drag an additional Send block into the model to send the PDOs to the newly connected CANopen server.


  CAN-AC2-PCI with SJA 1000 United Electronic Industries (UEI)