Introduction

This document describes how to set up an application to use the CANOpenIOServer component and how to configure the CANOpenIOServer instance to communicate correctly on the CAN bus.

About

The CANOpenIOServer component implements a CANOpen master but also supports slave mode for testing purposes. CANOpen protocols like PDO, SDO, SYNC, NMT, EMCY and functions like node guarding, heartbeat are supported, but not all are implemented to meet the full CANOpen specification. See the next chapters for detailed description of the supported CANOpen protocols.

Terms and Definitions

COBID structure

Function code in COBID are used to define a protocol (NMT, SYNC, EMCY, PDO, SDO...).

CAN frame structure

The following frame data format is used by all can transport layers (wire level format varies according to respective transport standard Ethernet/CAN).

CANOpenIOServer overview

Notable objects in CANOpenIOServer

Some of the items to note in CANOpenIOServer are:

Signals

Parameters

Alarms

Properties

CANOpenIOServer component configuration

Configuration procedure

To start configuring the IOServer it must be added to your application in configure mode. See CANOpen Setup Guide for tutorial.

There are various types of CANOpenIOServer models available in resources:

The following typically must be done to the added CANOpenIOServer component to configure the i/o server:

1. Configure the CAN controller transport properties. (Set baud rate if required on PCI transport. Set IP addresses and ports when using UDP transport.)
2. Add a CANOpenIOServer.MasterNode/CANOpenIOServer.SlaveNode for each node in your CANOpen network. Make sure that the node Address is set correctly.
3. Add one or more CANOpenIOServer.TPDO and/or CANOpenIOServer.RPDO to your Nodes to receive/transmit PDO telegram data from/to the node.
4. Add ObjectDictonary entries to the Node if it needs custom configuration (CANOpenIOServer.CustomODEntry and some pre-configured OD Entries available in resources).
5. Customize Node send frequency Fs if different from IOServer fs and SYNC frequency SyncFs for IOServer.

SocketCAN TransportLayer Properties in CANOpenPCIIOServer

All OS side configuration for CAN interfaces in Linux should be done during controller boot init scripts in /etc/init.d

Possible content of such init script may look like this:

# Loading modules into kernel (use PLX socketcan driver)
modprobe can
modprobe can-raw
modprobe can-bcm
modprobe vcan
modprobe plx_pci

# Initializing can0
/sbin/ip link set can0 type can bitrate 250000 restart-ms 100
/sbin/ip link set can0
echo 1000 > /sys/class/net/can0/tx_queue_len
ifconfig can0 up

# Initializing can1
/sbin/ip link set can1 type can bitrate 250000 restart-ms 100
/sbin/ip link set can1
echo 1000 > /sys/class/net/can1/tx_queue_len
ifconfig can1 up

UDP TransportLayer Properties CANOpenUDPIOServer

When TransportLayer is set to UDP, CANOpen telegrams are sent over UDP packets on Ethernet. As UDP packets are not guaranteed to reach destination this needs to be taken into account when setting up Heartbeat or Node guarding for Nodes to allow for packet loss.

Property configuration

IOServer processing rate

The fs dictates the update rate for incoming channels value propagation in component and outgoing channel values routed from the IOServer to other components.

By default the fs Property is also used to set the sending interval of RPDO telegrams, except when Node's Fs Property is set (usually a lower value from a component fs). TPDO is still received at the nodes transmit rate, but the outputs from IOServer are not updated faster than the defined components fs.

SYNC telegram sending

CANOpenIOServer has Property SynchFs to control SYNC telegram sending. Specify the frequency at which to send out a SYNC message (rate defined in Hz). This setting has no relation to Property fs of CANOpenIOServer component.

Set to 0 or blank to disable sending SYNC telegrams.

ResetNode command during startup

To broadcast a ResetNode telegram when the CANOpenIOServer master boots, set the Property BroadcastResetNodeAtStartup.

This will ensure that the nodes are restarted and reconfigured with the current Object Dictionary values. If nodes should not be restarted when the master boots, set this value to 0 (or blank/not specified).

Slave

When Slave Property is set, the IOServer is enabled to receive and process can telegrams.

To test out the slave it is simplest to use two CANOpenUDPIOServer components with corresponding configuration, with one of them having the Slave property set and using a SlaveNode, while the other having the Slave property not set and using a MasterNode. In Linux it is possible to use virtual can driver "vcan" for configuring CANOpenPCIIOServer.

Node configuration

Nodes are added to the CANOpenIOServer by adding resource CANOpenIOServer.MasterNode and/or CANOpenIOServer.SlaveNode (Nodes will be added to the CanInterface section in the IOServer). Configuration of nodes tells the IOServer how to communicate with each node on the CanOpen bus, or how to emulate each node (if SlaveNode). It is also important to note that RPDO and TPDO telegram transmit and receive in SlaveNode are reversed compared to MasterNode.

For MasterNodes:

• When adding a TPDO, the Input Attribute is default set.
• When adding CDPSignalChannels to this TPDO, the Input Attribute is default not set.
• When adding a RPDO, the Input Attribute is default not set.
• When adding CDPSignalChannels to this RPDO, the Input Attribute is default set.

For SlaveNodes:

• When adding a TPDO, the Input Attribute is default not set.
• When adding CDPSignalChannels to this TPDO, the Input Attribute is default set.
• When adding a RPDO, the Input Attribute is default set.
• When adding CDPSignalChannels to this RPDO, the Input Attribute is default not set.

Node Fs Attribute

Nodes Fs attribute is intended for reducing the RPDO default transmit rate defined by component fs for nodes that don't use trigger based sending as a means to reduce bus traffic.

Node guarding

GuardTime Property (in seconds) configures the CANOpenIOServer to send node guarding request to the node. LifeTimeFactor (Life Time in ObjectDictonary) is the multiplier for node guarding timeout for slave. The LifeTimeFactor multiplied by GuardTime defines the time limit for the reception of a node guarding message by the slave. CANOpenIOServer.GuardTimeODEntry and CANOpenIOServer.LifeTimeODEntry resources should be added to the Node configuration, matching the Values with GuardTime and LifeTimeFactor.

If a node guarding message is not received during this time, CANOpen node will assume an error has occurred. Since this mechanism is a provider-initiated service, it enables the CANOpen slave nodes to be notified if the master fails. Normally, the slave will then go to error state, which will be reported via the Emergency protocol.

The usage of node guarding is optional.

Heartbeat

A node can be configured to use the heartbeat protocol instead of the Node guarding protocol by setting Heartbeat Property. The GuardTime times LifeTimeFactor Properties will then be used for node heartbeat grace time in master, after the time expires the node is considered to be in Unknown state (see nodes NodeState signal). CANOpenIOServer.HeartbeatPTimeODEntry resource (“Heartbeat Producer Time”) must be added to the Node configuration to cause the CANOpen node to send out the heartbeat.

Network Management Service

With NMT enabled, a start command is sent to each node during startup.

The current state of each node can be monitored with nodes NodeState Signal. The signal will show the last known node state from node.

Object Dictionary

The Object Dictionary (OD) or SDO configuration is set of registers that all nodes must implement. It gives access to information about CAN communication parameters and other node parameters in a standardized manner. The object dictionary is addressed using two parameters, an Index and a Subindex.

The CANopen standard defines which objects (Entries) in the object dictionary a node is required to implement, which objects a node may implement, and which objects a node may use freely for customer or application-specific data.

By writing to the OD it is possible to configure parameters such as which data is transmitted in the PDOs (PDO mapping parameters), which CAN Ids a node should receive and transmit, when TPDOs should be transmitted and a lot more.

During startup of a node, when it is in the PreOperational state, the master may write new values to the object dictionary in the node to configure it (using SDOs telegrams). The values will typically be reset to default values when the node is restarted.

The information about which objects a node supports is supplied by either the node vendor (typically the EDS file), the documentation for the “Device Profile” that the node adheres to, or by the CANOpen standard. To be able to take advantage of an object in the object dictionary, one need to know the index, subindex, data type and meaning of each object that one wants to use.

Before master starts the node, it will write OD entries data using index, subindex values to the node's object dictionary using SDO messages. The Name and Unit Properties are not actually transferred, but used for documentation and status reporting only.

Disable use of "size used" and "unused bytes" fields in SDO expedited download messages

Some nodes do not support that the data size fields in the SDO expedited download message is set (one bit indicates that the size is used, and two bits indicates the number of unused data bytes). To set these bits 0 for all expedited SDO downloads for a node, unset the attribute UseSDODataSize on the node.

Supported data types

The following table lists data types that are currently supported by the CANOpenIOServer:

Limitations

Currently, only expedited SDO transfer is supported. That is, only values that will fit in a single SDO message can be transferred. This effectively means that only 4 bytes of data can be transferred per OD entry.

PDO configuration

TPDO and RPDO

Supported data types in PDO

The following data types can be used when instantiating CDPChannels inside node elements (data within PDOs). See chapter CDPChannel. Note that these may differ from the data types valid when specifying ObjectDictionary entries, see chapter about the Object Dictionary

CDPChannel

CANOpenIOServer supports CDPChannels to connect to/from CDPSignals.

CDPSignalChannels supports all the internal elements of CDPSignal. Operators are also available. For example ScalingOperator can be used to scale channel values.

Custom COBIDs

It is possible to receive a custom COBID, for instance a RPDO sent out by another master on the CAN bus. For that one needs to disable Nodes NMT Property to prevent the IOServer from trying to manage that node.

To configure custom COBID

• Add MasterNode
• Disable NMT Property for the MasterNode
• Add CANOpenIOServer.RPDO to MasterNode
• Set the Input Property to true on the RPDO to prevent the IOServer itself from sending this RPDO (since this is a RPDO, which normally would be sent out by the master, but in this case is sent out by another master).
• Set the COBID Property if you want to receive custom PDOs with COBID

The same technique can be used to send out a PDO with a custom Address that does not need to exist on the network:

• Disable nodes NMT Property
• Set custom address
• Configuring the node

Monitoring and Debugging

Standard Signals

A range of signals exist in the CANOpenIOServer to allow monitoring the network traffic either by looking at the signal values manually or by using the signals to trigger alarms.

Status signals

The following signals are created for each node:

Emergency protocol

The following eight error signals are also created for each node:

The signals are set to the value received in last emergency telegram from a node. These values can also be received via CM_CAN_EMERGENCY Message when EmergencyRouting Property is set on the Node.

Debug tips

Set the Debug Property at runtime to a value between 1 and 10 to get more debug output.

Troubleshooting

Problem

The Node is not configured with the correct OD parameters after reboot.

Cause

The configuration is only written to the node when the node is started by the master. If the master is restarted while the node stays in its operational state (for instance because it's not configured to use node guarding or heartbeat), the new configuration will not be set.

Solution

To force the new configuration to be set, simply reboot the node.

Or, set BroadcastResetNodeAtStartup to make the master broadcast a ResetNode command when it restarts to ensure that all nodes are reconfigured.

Appendix

Reading speed from Position encoder

To read the speed one needs to set the send period and change the PDO mapping in the encoder to enable reading the speed.

• Add Node for the Position encoder
• Set the node address
• To Node add CustomODEntry set Index to 1a01, SubIndex to 0, Name to "PDO2 nParam", Type to unsigned char, Value to 0
• To Node add CustomODEntry set Index to 1a01, SubIndex to 1, Name to "PDO2 value 1", Type to unsigned long, Value to 0x60040020
• To Node add CustomODEntry set Index to 1a01, SubIndex to 1, Name to "PDO2 value 2", Type to unsigned long, Value to 0x60300110
• To Node add CustomODEntry set Index to 1a01, SubIndex to 0, Name to "PDO2 nParam", Type to unsigned char, Value to 2
• To Node add CustomODEntry set Index to 3010, SubIndex to 1, Name to "Speed Enable", Type to unsigned char, Value to 1
• To Node add TPDO set Nr to 1, Name to "TPDO1"
• To TPDO1 add CDPSignalChannel<unsigned short> set Name to "position"
• To TPDO1 add CDPSignalChannel<unsigned short> set Name to "turns"
• To Node add TPDO set Nr to 2, Name to "TPDO2"
• To TPDO2 add CDPSignalChannel<unsigned short> set Name to "position"
• To TPDO2 add CDPSignalChannel<unsigned short> set Name to "turns"
• To TPDO2 add CDPSignalChannel<short> set Name to "speed"