Multi-line version
This chapter describes the properties of port’s multi-line version. With this version a single process application can access more than one CAN network (CAN line). So it is possible to implement CANopen for multiple CAN lines on target platforms without an operating system, with a single-tasking operating system or a multi-tasking operating system with a reduced resource protection mechanism.
Such applications can be devices, which use an internal and an external CANopen network e.g. production cells, robots etc. Furthermore it is possible to build gateways between several networks. The CANopen network functionality (master/slave) can be different for each CAN line. Other typical applications are data loggers, monitoring systems and global network masters.
An easy way to build a multi-line system is to use a PC with more than one CAN card or multi-port CAN cards.
A multi-CAN line device has <number of CAN lines> object dictionaries, see Figure 61. This means that the device behavior can be different for each line.
There are two special compiler-defines for the multi-line usage:
CONFIG_MULT_LINES define for maximum number of CAN lines
CO_MAX_CAN_LINES is used for actual number of CAN lines
Figure 61: object dictionary structure for multi-line devices
If a device variable shall be accessible by two or more lines, the address references in the object dictionary of all lines have to point to the same variable (Listing 34). The object dictionary index of this variable can be different on every line.
/* values line 0 */
UNSIGNED32 l0_p301_device_type = 0x00000000UL;
UNSIGNED8 l0_p301_error_register = 0x00;
UNSIGNED8 myInterlineValue = 0x00;
/* values line 1 */
UNSIGNED32 l1_p301_device_type = 0x00000000UL;
UNSIGNED8 l1_p301_error_register = 0x00;
/* definition of object dictionary line 0 */
OBJDIR_T objDirLine0[] = { \
{(UNSIGNED8 *) &l0_p301_device_type, l0_p301_device_type_desc, \
0x1000, 1} \
, {(UNSIGNED8 *) &l0_p301_error_register, l0_p301_error_register_desc, \
0x1001, 1}, ...
, {(UNSIGNED8 *) &myInterLineValue, l0_myInterLineValue_desc, 0x2200, 1}
}
/* definition of object dictionary line 1 */
OBJDIR_T objDirLine1[] = { \
{(UNSIGNED8 *) &l1_p301_device_type, l1_p301_device_type_desc, \
0x1000, 1} \
, {(UNSIGNED8 *) &l1_301_error_register, l1_p301_error_register_desc, \
0x1001, 1}, ...
/* link to variable of line 0 */
, {(UNSIGNED8 *) myInterLineValue, l1_myInterLineValue_desc, 0x4200, 1}
/* end of link to variable of line 0 */
, {(UNSIGNED8 *) &l1_otherVal, l1_otherVal_desc, 0x5001, 1}
}
/* object dictionary manager */
OBJDIR_T *objDirMan[2] = {objDirLine0, objDirLine1};Listing 34: example to global objects for multi-lines
Figure 62 shows the software layers and the inter-line communication of the multi-line version.
Figure 62: software layers for multi-line devices
Every CAN line has its own CAN driver module. For identical hardware on each line the same module can be used. In this case only the CAN controller address has to be switched and the received message put into the corresponding receive buffer. The chosen driver concept ensures that the CAN controller can be different on every line. If all CAN controllers are equal, code size can be saved. Furthermore an inter-driver communication is possible.
The reason for a communication like this is to realize a configuration gateway. Such a gateway is the basis for configuration of all nodes in all connected networks by one network participant. Usually the gateway has to have a shadow object dictionary of each node to parameterize these nodes (see inter-line communication). If any object dictionary is changed the gateway shadow dictionary has to receive an update. An update means a new configuration of the gateway (device must be programmable) or new compilation of the software (not practicable).
The condition for doing this is to have one client SDO on the side which has to be configured and one server SDO (default) on the side of the configuration software. A SDO connection has to be established via a control word which contains the line number and the node-ID. It has to be ensured that this connection is only possible in the PRE-OPERATIONAL state in order to prevent application errors in a certain CAN line. In this bypass mode received server messages are transmitted as client messages and all client messages received are transmitted as server answers to the originator. The easiest way to do this is to copy the data from the receive buffer of the one line to the transmit buffer of the other line. After the configuration, the bypass mode shall be exited.
All functionality which is coded into the driver is hardware dependent and mostly not portable. Such message handling is only an exception for weak performance micro controllers.
Each message from a CAN line goes via the CAN driver and the CANopen Library to user indication CANopen Library interfaces. These interfaces are the indication functions i.e. pdoInd(). All of these functions have a parameter canLine which gives the information about the source line. For the request interfaces e.g. writePdoReq() the parameter canLine selects the destination line (CAN line selector).
It is very easy to distribute messages over various CAN networks via this mechanism. The transmission of a message to another line can be triggered with the reception of a message.