Page Comparison

...

The COB-IDs for the first server SDO are pre-defined and must not be changed in order to ensure the connection to the device. The COB-IDs are built according to the following rules:

COB − ID_TX = 580h_{+ <node-ID>              (1)}

COB − ID_RX = 600h_{+ <node-ID>              (2)}

These equations are valid for the SDO server point of view.

The second SDO service type is the SDO client (CSDO), who initiates the SDO service. Typical SDO client applications are configuration tools and control units. The corresponding entries in the object dictionary are:

index_SSDO = 1200h_{+ (<server SDO number> − 1)       (3)}

index_CSDO = 1280_h + (<client SDO number> − 1)        (4)

Every CANopen device must have at least one SDO server. Each device can support up to 128 server SDOs and 128 client SDOs.

The SDO parameters are organized in a structure (Table 3). All entries can be changed besides the value for the first server SDO. The index 0022his only a reference to the structure type. It has to be replaced with the computed index mentioned above.

Table 3: structure of SDO parameters

Process data objects

Process data messages, in CANopen called Process Data Objects (PDO), are used to perform the real-time data transfer between different automation units. PDOs have to be transmitted quickly, without any protocol overhead and within a pre-defined structure.

For PDOs different transmission modes are distinguished (Figure 4):

...

Figure 4: PDO transmission types

Asynchronous event-driven PDOs are sent on event (application/profile specific or timer) or on a remote request. Synchronous PDOs can be triggered cyclic or acyclic with the SYNC message.

An explicit confirmation for PDOs is not required and it carries no overhead. CANopen suggests a high priority in order to ensure their real-time behavior. CANopen defines PDO producer and PDO consumer. The producer sends PDOs and the consumer receives PDOs. Commonly a CANopen device can fulfill both properties.

...

Figure 5: PDO communication model

The PDO communication parameters reside in the object dictionary. The indices for PDO communication objects are calculated as follows:

index_{RPDO_para} = 1400h_{+ (<RPDO number> − 1)          (5)}

indexT_{PDO_para} = 1800h_{+ (<TPDO number> − 1)         (6)}

The range of the PDO numbers is 1...512. That means up to 512 Receive PDOs (RPDO) and up to 512 Transmit PDOs (TPDO) are possible for a device.

The PDO communication parameters are described with a structure (Table 4). The index 0020his only a reference to the structures type and is used from the PDO communication parameter objects.

Table 4: structure of PDO communication parameter

The sub-index 0 contains the number of implemented PDO communication parameters. Only sub-index 1 and 2 are mandatory.

Sub-index 1 describes the used COB-ID of the PDO. This value is bit-coded. A detailed description is shown in Table 5. A PDO communication channel between two devices is created by setting the RPDO COB-ID of one device to the TPDO COB-ID of the other device. For PDOs a 1:1 and a 1: n communication is possible. This means that there is always only one transmitter, but an unlimited number of receivers.

Table 5: structure of PDO COB-ID parameter

The transmission type (sub-index 2) describes the kind of PDO transmission see Table 6. For synchronous PDO it is possible to define a scaling factor. Transmission type 1 means PDO will be triggered with each SYNC object. If this entry has the value 240, the PDO will be sent/received with each 240th SYNC.

Table 6: PDO transmission types

The inhibit time (sub-index 3) defines a minimum time period between two PDO transmissions. This feature ensures that messages with lower priorities than the current PDO can be transmitted in the case of continuous transmission of the current PDO and the PDO consumers are able to process the received PDO data.

The event timer (sub-index 5) is only relevant for asynchronous TPDOs. It defines an event timer. Once the event time is elapsed, the transmission of this PDO is started.

The SYNC start value (sub-index 6) requires SYNC messages with a SYNC counter. The SYNC start values specifies the SYNC counter number with which the PDO transmission starts.

The content of the PDO is encoded in the PDO mapping entries. A PDO can contain up to 64 single data elements from the object dictionary. In the case of 64 of the data are bits. The data are described via its index, sub-index and length. The PDO mapping parameter resides also in the object dictionary. The indices for PDO mapping objects are calculated as follows:

index_{RPDO_map} = 1600h_{+ (<RPDO number> − 1)       (7)}

index_{TPDO_map} = 1A00h_{+ (<TPDO number> − 1)       (8)}

The PDO mapping parameters are described with a structure (Table 7). The index 0021his only a reference to the structures type and is used from the PDO mapping parameter objects.

Table 7: structure of PDO mapping parameter

Sub-index 0 contains the number of mapped variables. The maximum of entries is either 64 or 8. This fact depends on the PDO mapping granularity. (This is a feature of the CANopen Library implementation, not of the standard.) Many devices support only byte-wise PDO mapping. The sub-index defines the order of the variables on the PDO message. The data are assigned in ascending order in the PDO message.

The entries from sub-index 1 contain a logical reference to the variables, which are to be transmitted/received (Table 8). The data object is described by its index and sub-index and its length. The length value represents the data’s length in bits.

Table 8: structure of PDO mapping entry

A special case of PDO mapping is the so called PDO dummy mapping. With this kind of PDO mapping, it is possible to blind out irrelevant data. This feature is used for a 1:n communication, where each receiver utilizes only a part of the PDO. For PDO dummy mapping the indices 0001h -0007h are used. These indices are only references to data types and the entries are only space holders with the data type corresponding size, see Table 9.

Table 9: indices of PDO dummy mapping entries

The PDO mapping can be static or dynamic. It is not allowed to change the PDO mapping during run-time for static PDO mapping. In contrast, the dynamic PDO mapping allows the configuration of the PDO mapping during run-time if the PDO is disabled.

Emergency object

The Emergency object (EMCY) is a service, which signals internal fatal device errors. The error types are defined in the communication profile and the device profiles. The EMCY is transmitted with highest priority.

CANopen defines EMCY producer and EMCY consumer. The producer transmits EMCYs and the consumers receive them.

The EMCY telegram consists of 8 bytes. It contains an EMCY error code, the contents of object 1001hand 5 bytes of an additional information. The additional information is manufacturer-specific.

Additional an error handling exists. Each transmitted error code and the first two bytes of the manufacturer-specific additional information will be pushed in the predefined error field on index 1003h. This field can contain up to 255 error entries. The value of sub-index 0 shows the current number of entries. The most recently occurred error will be always inserted on the top of this field (sub-index 1). All older entries will be moved down.

When all errors are cleared on the device, an EMCY with error code 0 will be sent.

Synchronization object

The Synchronization object (SYNC) is a network wide system clock. It is the trigger for synchronous message transmission. The SYNC has a very high priority in order to guarantee a minimum of jitter.

Time Stamp object

The Time Stamp object provides a common time reference. It is transmitted with high priority. The time is encoded in the type Time of Day. This data type contains the milliseconds since midnight and the number of days since January 1, 1984.

Error Control mechanisms

For node monitoring two different mechanisms are defined:

• Heartbeat and

• Node Guarding.

Each device has to provide one of the error control mechanisms. For new devices Heartbeat shall be preferred.

Heartbeat

Heartbeat (HB) is an error control mechanism without need for remote frames. Each Heartbeat producer cyclically transmits a Heartbeat message. One or more Heartbeat consumers receive this message and monitor the Heartbeat producer. Each Heartbeat producer uses a certain period defined in object 1017h (Heartbeat producer time). Heartbeat starts immediately if the Heartbeat producer time is greater zero.

The Heartbeat consumer has to monitor the Heartbeat producer. For monitoring the Heartbeat consumer has an entry for each Heartbeat producer in its object dictionary. The Heartbeat consumer Time in object 1016h can be different for each Heartbeat producer but shall be greater than the Heartbeat producer time. Usually the Heartbeat will be configured by the network Configuration Manager. The resolution of the Heartbeat times is 1ms.

Heartbeat has a big influence on network load - but in effect, the half of the load of the Node Guarding monitoring!

Node Guarding

The Node Guarding (NG, also known as Life Guarding) is the active periodical monitoring of certain network nodes. Each node can be checked from the NMT master with a certain period specified in object 100Ch (guard time). A second parameter in object 100Dh (life time factor) defines a factor when the connection shall be detected as lost.

The resolution of the guarding time is 1 ms. The condition for Node Guarding on a slave device is that guard time and life time factorare not zero. Node Guarding is started with the first guarding telegram of the master.

During Node Guarding the master sends a RTR frame to each guarded slave. The slave answers with its current state and a toggle bit. This toggle bit alternates for each cycle.

Node Guarding has a big influence on network load!

Boot-up message

After a CANopen node has finished its own initialization and entered in the node state NMT/PRE-OPERATIONAL it has to send the Boot-upmessage. This message indicated that the device is ready for communication. This protocol uses the same CAN-identifier as the error control protocol (Heartbeat or Node Guarding).

Network behavior

CANopen uses the state machine shown in Figure 6 for the handling of communication functions.

...

Figure 6: NMT state machine

After power-on a device is going to be initialized and set in the state NMT/PRE-OPERATIONAL automatically. In this state reading and writing to its object dictionary via SDO is possible. The device can now be configured. That means setting of objects or changing of default values in the object dictionary like preparing PDO transmission.

Afterwards the device can be switched into the NMT/OPERATIONAL state via the command Start Remote Node in order to start PDO communication. PDO communication can be stopped by the network master by simply switching the remote node back to NMT/PRE-OPERATIONAL by using the Enter Pre-Operational State command.

Via the Stop Remote Node command the NMT master can force the slave(s) to the state NMT/STOPPED. In this state no services besides network and error control mechanisms are available.

The command Reset Communication resets the communication on the node. All communication parameters will be set to their defaults. The application will be reset by Reset Node. This command resets all application parameters and calls Reset Communication command.

The difference between NMT master and NMT slave devices is the initiation of the state transitions. The NMT master controls the NMT state transitions of each device in the network.

All needed NMT commands use only CAN identifier 0. The commands are distinguished with a command specifier in the first data byte of the NMT message, see Table 10. The second byte specifies the addressed node-ID. If the node-ID is zero the command is valid for all nodes in the network (broadcast).

Table 10: NMT message

Table 11 shows the availability of the CANopen services depending on the NMT state.

Table 11: availability of CANopen services depending on NMT state

In order to reduce configuration effort for simple networks a mandatory default identifier allocation scheme, called pre-defined connection set, is defined not only for NMT messages, also for the other services. These identifiers are available in the NMT/PRE-OPERATIONAL state directly after initialization (if no modifications have been stored) and may be modified by means of dynamic identifier distribution or SDO access (default way). A device has to provide the corresponding identifiers only for the supported communication objects.

The cob-ID is built from a function code, representing the object type, and the 7 bit module or node-ID. A simplified overview about the pre-defined connection set is shown in Table 12.

Table 12: cob-IDs according to pre-defined connection set

The resulting CAN-ID for a COB is built:

CAN-ID = ((function code) * 128) + <node-ID>                                                                               (9)

The CAN-IDs for further CANopen services can be assigned free with exception of restricted CAN-IDs. The restricted CAN-IDs are specified in the communication profile standard CiA-301 as follow:

Table 13: restricted CAN-IDs

The priority order of the communication services according to CiA-301 shall be:

1. NMT (lowest CAN-ID),

2. SYNC,

3. TIME,

4. EMCY,

5. synchronous PDOs,

6. asynchronous PDOs,

7. MPDOs

8. SDOs and

9. error control (highest CAN-ID).

The CAN-IDs can be configured about standardized communication objects via SDO.

CANopen LEDs

The CiA-303-3 provides a standardized way for state indication of a CANopen device. There is an ERR LED and a RUN LED. It is also possible to use only one of the two LEDs or instead of two single color LEDs a bicolor LED.

The RUN LED is green and indicates the CANopen state. The ERR LED is red and shows errors of the physical layer.

Table 14: states indicated by ERR LED (**… not supported by CANopen Library)

Table 15: states indicated by RUN LED

Flying Master

The Flying Master mechanism provides services for transferring the NMT master service from one node to another node. The Flying Master principle is based on Heartbeat monitoring of all NMT master capable devices in the network. If the active NMT master fails a new negotiation is started automatically, depending on a priority of nodes and the node number of the NMT master capable devices. The NMT master negotiation is won by the node with the highest priority (prior = 0) and the lowest node-ID. The active NMT master monitors the network cyclically for other active NMT masters and starts a new NMT master negotiation if necessary.

All Flying Master devices have to implement object 1F80hwhere bit 0 (NMT master) and 5 (Flying Master) are set. Otherwise they cannot participate in the master negotiation process.

Figure 7 shows the procedure for the Flying Master startup. The services are defined in the standard CiA-302-2.

...

Figure 7: Flying Master startup

Layer Setting Services

The Layer Setting Services (LSS) provides services and CANopen protocols to inquire or to change network parameters via the CAN network. The services are defined in the standard CiA-305. The standard CiA-305 uses a CAN bit timing table for the configuration of the CAN bit rate. Each LSS device can support more than one bit timing table. Therefore every table has a number and each CAN bit rate in the bit timing table has a table index number. The CiA-305 specifies the table with the number 0 with the following CAN bit rates:

Table 16: CAN bit timing table 0 of CiA-305

Safety

Services and CANopen protocols for safety critical communication are defined in the standard CiA-304. For safety critical communication Safety Relevant Data Objects (SRDO) are used. SRDOs are sent periodically. To increase safety, the data of an SRDO is transmitted twice. The second time the data is sent inverted. All SRDOs have their own COB-ID.

...

Figure 8: SRDO timing (SCT…safe-guard cycle time, SRVT…safety relevant object validation time)

The receiver of an SRDO has to check the incoming SRDO for correctness of the order, correctness of data and the time period. All information (timings, COB-ID, mapping) for SRDO is stored in the object dictionary.

1.1      CANopen device profiles

A device profile defines a standard device. For these standard devices a basic functionality has been specified, which has to exhibit every device within a class. The CANopen Device Profiles ensure a minimum of identical behavior for a kind of devices.

...

Figure 9: communication architecture with device profile CiA-402

A typical communication architecture is shown in Figure 9.

If a device uses a standardized device profile it has to provide all items defined as mandatory in the standard. Additional the manufacturer can decide about supported optional objects. All parameters and data, which are not covered by the standardized device profiles can be realized as manufacturer-specific objects.

The constantly growing list of currently available profile databases can always be found at port’s homepage.

Implementation of device profiles can be done very easily by using the Industrial Communication Creator from port. This tool provides profile databases with all objects for many of the standardized device profiles. Missing device profiles can be easily implemented by using the Industrial Communication Creator as data entry tool.