CANopen servo drives

Specifications

Ports available1 CAN port
LED SignalsCANopen run LED (according to CiA-303)
CANopen error LED (according to CiA-303)
Modes of operation


CiA-402 drive device profile
  • Voltage mode
  • Current mode
  • Cyclic synchronous current mode
  • Current amplifier mode
  • Profile velocity
  • Profile position
  • Homing modes
  • Cyclic synchronous position mode
  • Cyclic synchronous velocity mode
Process data objectRPDO and TPDO 1 to 4 are available.
Up to 32 bytes on each direction.
Up to 15 different registers can be mapped on each direction.
Synchronous or asynchronous transmission and reception.
Service data objectSupported.
EMCYSupported.

Device node-ID and baudrate can be configured using this service.
Fast-scan service is supported.
Life guard protocolImplemented.
HeartbeatSupported heartbeat producer.
Time StampSupported time stamp consumer.

Communication objects (CiA301)

Network Management (NMT)

The network management (NMT) protocols provide services for network initialization, error control and device status control. NMT objects are used for executing NMT services. The NMT follows a master-slave structure and therefore requires that one CANopen device in the network fulfills the function of the NMT master. All other CANopen devices are regarded as NMT slaves. An NMT slave is uniquely identified in the network by its Node-ID, a value in the range of 1 to 127.

NMT state machine

The NMT state machine defines the communication status for CANopen devices.
NMT state machine

Transition

Event

(1)

After power on the system goes directly to initialization state

(2)

Once initialization is completed the system enters to Pre-operational state

(3), (6)

Reception of Start remote node command

(4), (7)

Reception of Enter pre-operational state command

(5), (8)

Reception of Stop remote node command

(9), (10), (11)

Reception of Reset node command

(12), (13), (14)

Reception of Reset communication command

NMT state initialization

The initialization state could be divided into three sub-states that are executed in a sequential way: Initializing (performs the basic CANopen initialization), Reset application (in where all manufacturer-specific and standardized profile area parameters are set) and Reset communication (where the communication profile and parameters are set). 
At the end of initialization state the device sends a boot-up message and goes directly to Pre-Operational state.

NMT state pre-operational

In Pre-Operational state, the communication using SDO messages is possible. PDO messages are not yet defined and therefore communication using these message is not allowed. The device will pass to Operational message after receiving a NMT start node command.
Normally the master puts a node in Pre-Operational state during the set-up and configuration of device parameters.

NMT state operational

In Operational state all kind of messages are active, even PDO messages.

NMT state stopped

When entering in Stopped state, the device is forced to stop all communications with the exception of the NMT commands. (Node Guarding & Life Guarding).

NMT states and communication object relation

Following table shows the relation between communication states and communication objects. Services on the listed communication objects may only be executed if the devices involved in the communication are in the appropriate communication states 


Pre-Operational

Operational

Stopped

NMT services

X

X

X

NMT error control

X

X

X

PDO


X


SDO

X

X


Sync object

X

X


Emergency object

X

X


NMT services

The structure of each NMT service command is as follows:

COB-ID (hex)

Number of Bytes

Data field

Byte 1

Byte 2

000

2

Command specifier

Node ID


The possible NMT services commands are the followings:

Command specifier (hex)

Command description

01

Start remote node

02

Stop remote node

80

Enter pre-operational

81

Reset node

82

Reset communication


Example of NMT services:

COB-ID (hex)

Number of Bytes

Data (hex)

Description

000

2

80 01

NMT Host commands node 1 into Pre-Operational state

000

2

01 01

NMT Host commands node 1 into Operational state

000

2

02 01

NMT Host commands node 1 into Stopped state

000

2

82 01

NMT Host commands a communication reset to node 1

701

1

00

Node 1 response with a boot-up message

NMT error control

Node guarding service

The NMT Master can monitor the communication status of each node using the Node Guarding protocol.
During node guarding, a controller is polled periodically and is expected to respond with its communication state within a pre-defined time frame. Note that responses indicating an acceptable state will alternate between two different values due to a toggle bit in the returned value. If there is no response, or an unacceptable state occurs, the NMT master could report an error to its host application. 
The NMT master sends a node guarding request using the following a Remote Frame message:

COB-ID (hex)

Number of Bytes

RTR

700 + Node ID

0

1

The NMT slave will generate a node guarding answer using the following message:

COB-ID (hex)


Number of Bytes


RTR


Data field (Byte 1)

Bit 7

Bit 6 to 0

700 + Node ID

1

0

Toggle

NMT communication state

Note that the slave answers toggling a bit between consecutive responses. The value of the toggle bit of the first response after the guarding protocol becomes actives is zero. 
The state of the heartbeat producer could be one of the followings:

Communication State value (hex)

State definition

00

Boot-up

04

Stopped

05

Operational

7F

Pre-operational

Example of NMT Node guarding:

COB-ID (hex)

Number of Bytes

RTR

Data field (hex)

Description

701

0

1

-

Master sends a CAN remote frame without data to node 1.

701

1

0

7F

Node 1 sends the actual NMT state (pre-operational) toggling the 7th bit.

701

0

1

-

Master sends a CAN remote frame without data to node 1.

701

1

0

FF

Node 1 sends the actual NMT state (pre-operational) toggling the 7th bit.

Life guarding service

In Life guarding protocol the NMT slave monitors the status of the NMT master. This protocol utilizes the objects Guard time (0x100C) and Life time factor (0x100D) to determine a "Lifetime" for each NMT slave (Lifetime = Guard Time * Life Time Factor). If a node does not receive a Node Guard message within its Lifetime, the node assumes communication with the host is lost sends an emergency message and performs a fault reaction. Each node may have a different Lifetime. 

Example of NMT life guarding:

COB-ID (hex)

Number of Bytes

RTR

Data field (hex)

Description

701

0

1

-

Master sends a CAN remote frame without data to node 1

701

0

1

-

Master sends a CAN remote frame without data to node 1

Delay Higher than Guard Time * Life Time Factor

81

8

0

30 81 11 00 00 00 00 00

Node 1 send an EMCY indicating the lifeguard error

Note: to start the Life Guarding protocol, both Guard Time and Life Time Factor need to be different than 0, and a first CAN remote frame without data needs to be send to each node.

Heartbeat service

The heartbeat protocol defines an error control service without need for remote frame. A heartbeat producer (in this scope a controller) transmits a Heartbeat message cyclically. Transmit cycle of heartbeat message could be configured using the object Producer heartbeat time (0x1017). If the Heartbeat is not received by the consumer (in this scope a master) within an expected period of time (normally specified as Consumer heartbeat time) it could report an error to its host application.  Devices based on summit are only heartbeat producers. 
The heartbeat message generated by the producer will be as follows:

COB-ID (hex)


Number of Bytes


Data field (Byte 1)

Bit 7

Bit 6 to 0

700 + Node ID

1

Reserved

NMT communication state


The state of the heartbeat producer could be one of the followings:

Communication State value (hexadecimal)

State definition

00

Boot-up

04

Stopped

05

Operational

7F

Pre-operational

Example of NMT heartbeat:

COB-ID (hex)

Number of Bytes

Data field (hex)

Description

705

1

7F

Node 5 sends a heartbeat indicating pre-operational state.

705

1

7F

After producer heartbeat time, Node 5 sends again a heartbeat indicating pre-operational state.

Boot-up service

An NMT slave issues the Boot-up message to indicate to the NMT-Master that it has entered the state Pre-operational from state Inititalising.
Example of NMT Boot-up:

COB-ID (hex)

Number of Bytes

Data field (hex)

Description

701

1

00

Node 1 sends a boot-up NMT message

Layer Setting Services (LSS)

LSS service is available from the master with COB-ID 2021d (0x7E5), this service allow to identify and configure CANopen devices without knowing the Node-Id. The device will answer the master's transmissions at COB-ID 2020d (0x7E4). LSS allow to configure device Node-ID and baudrate.

Node-id modification protocol

Previous requirement is to set the desired device on the net to Selective configuration state. 

To modify the Node-ID, the master may send a message with command '17', indicating the Node-ID that the device must take.

  • NID: Node-ID to apply to the device.
  • Error code
           0: Node-ID configured successfully.
           1: Node-ID out of range.
  • Specific error: reserved for future uses.

After Node-ID is configured, it is necessary to make a communication reset of the node to apply the new Node-ID to the communication objects.

Bit-timing modification protocol

Previous requirement is to set the desired device on the net to Selective configuration state. 

To modify the bit-timing, the master may send a message with command '19', indicating the new baudrate that the device must take. Bit timing must be selected by using the table + index identification.

  • Table selector:
           0: CiA bit timing table
           1 - 255: reserved for future use
  • Table index: 
           0: 1Mbps.
           1: 800Kbps (not supported).
           2: 500Kbps.
           3: 250Kbps.
           4: 125Kbps.
           5: 50Kbps.
           6: 20Kbps.
           7: 10Kbps.
  • Error code: reserved for future uses.
           0: Bit-timing configured successfully.
           1: Bit-timing not supported.
  • Specific error: reserved for future uses.

After bit-timing is configured, it is necessary to send a bit-timing activation message.

Example

In this example, we will change from the initial node 15, to node 8. As it can be seen on the following image, only one device is detected, which has been connected with a PCAN driver.  


By PCAN-view software, the following sequence has been recorded when changing from one node to another. LSS messages transmitted by the LSS master device shall use the CAN-ID 2021d (0x7E5). LSS messages transmitted
by the LSS slave device(s) shall use the CAN-ID 2020d (0x7E4). Comment that data is transferred in litte-endian, this means, the order of the bytes of a data are swapped.

Apart from that, the last two lines corresponds to a NMT reset node and a boot-up message respectively.

Switch state selective protocol

By the following five lines, the drive connected is analyzed. Such as, vendor ID, product code, revision number or serial number.

Configure bit timing parameters protocol

On the following two lines, the baudrate is configured. In this case, baudrate has not been changed, so the initial and final baudrate are the same.

Configure node-ID protocol

The protocol defined here is used to implement the configuration of the node_ID service.

Store configuration protocol

The following two lines are the ones in charge to store the new configuration.

Switch state global protocol

Finally, state is switches to a waiting state.

EMCY service

The EMCY service is an asynchronous producer-consumer protocol on which the producer indicates that an error has been detected by sending an EMCY message. The consumer can easily know the error source that has been detected by the node at the error instant without polling the statusword or the error register. 

Each produced EMCY message is reflected in register 0x1001. The EMCY message can both indicate that an error has been produced and also that an error condition has been removed (error code "no error"). Each error indicate the code of the error, and also the affected module. 

An emergency object is sent only once per error event.

The reaction on the received EMCY messages is application-specific. By default the EMCY message CAN ID is "0x80 + Node ID". The COB-ID can be modified by means of SDO service through the register 0x1014.


The data content of the emergency message uses the following structure:

COB-ID (hex)

Byte number:

1

2

3

4

5

6

7

8

080 + Node ID


Emergency error code

Error register
(Object 0x1001)

Reserved (zero values)

Example 1

COB-ID (hex)

Number of Bytes

Data field (hex)

Description

89

8

72 73 21 00 00 00 00 00

Node 9 sends a digital encoder runaway error (0x7372) emergency message.

89

8

00 00 00 00 00 00 00 00

Node 9 indicates that the error condition has been removed.

Refer to error identification section for the error code description list.  

Linking faults with EMCY service

Faults can be linked to EMCY service by means of register 0x5821. This register links a general purpose output of the motion controller to one input of the communication controller. With this link the communication controller can generate EMCY messages.

Index

Sub Index

Name

Data Type

Acc.

Pdo Map.

NVM

Value range

Default value

Units

0x5821

0x00

Error notification source

UINT8

RW

No

Yes

0 to 3

0

-

Register values:

  • 0: EMCY link is disabled, EMCY is only available for communication errors.
  • 1: EMCY link is based in motion controller's output 1. Health function is mapped to GPO1.
  • 2: EMCY link is based in motion controller's output 2. Health function is mapped to GPO2.
  • 3: EMCY link is based in motion controller's output 3. Health function is mapped to GPO3.

Process data object (PDO)

PDOs are messages send without confirmation used for real time information transfer. PDOs are mapped to a single CAN frame and can contain multiple object dictionary entries with a maximum of 8 bytes of data. Each PDO has an identifier and is transmitted by only one node in the network, however it could be received by more than one node. PDOs must be configured previous to using them.

There are two types of PDO messages: Transmit PDO (TPDO) and Receive PDO (RPDO).

The trigger event of the PDO message could be configured using the communication parameter object and the object dictionary entries transmitted could be also defined using the PDO mapping list.

Therefore, each PDO is defined by means of:

  • A PDO communication parameter
  • A PDO mapping object

Ingenia motion controllers include 4 RPDO and 4 TPDO.

Transmit PDO (TPDO)

TPDOs are configured to send data from node to master after the occurrence of a trigger event or after a remote request by means of a RTR.

TPDOs have three transmission types:

  • Internal event or timer: Message transmission is triggered when the value mapped into the PDO has changed or when the specified time (event-timer) has elapsed. PDO transmission is controlled by producer.
  • Remotely request: Message transmission is initiated on receipt of a RTR message. PDO transmission is driven by the PDO consumer.
  • Synchronously trigger: Message transmission is triggered by the reception of a certain number of SYNC objects (see TPDO1 definition for further information). The PDO transmission is controlled by the SYNC producer.

Example of an internal event TPDO:

COB-ID (hex)

Number of Bytes

Data field (hex)

Description

182

2

63 22

Node ID 2 sends the Transmit PDO1 with a content value of 0x2263.

Receive PDO (RPDO)

The master uses the RPDO to write data to objects in the nodes.

RPDOs have two transmission types:

  • Asynchronous: Message content is applied upon receipt of the RPDO. The PDO reception is controlled by the PDO producer.
  • Synchronously trigger: Message content is applied after the reception of a certain number of SYNC objects. The PDO reception is controlled by the SYNC producer.

Example of an asynchronous RPDO:

COB-ID (hex)

Number of Bytes

Data field (hex)

Description

202

2

22 12

Master sends a RPDO1 to Node 2 with a content value of 0x1222.

Mapping procedure

The steps to configure the PDO mapping are (Example for setting the RPDO 1):

  1. Place the controller into NMT pre-operational.
  2. Destroy the PDO writing a 1 into the valid bit of SubIndex 0x01 of PDO communication parameter. (0x1400 RPDO1 - bit 31 of COB-ID used)
  3. Unmap all registers from PDO by setting SubIndex 0x00 to zero. (0x1600 RPDO1 mapping parameter).
  4. Modify mapping by changing the values in the corresponding SubIndexes. (0x1600 RPDO1 mapping parameter).
  5. Enable mapping by setting SubIndex 0x00 to the number of mapped objects. (0x1600 RPDO1 mapping parameter).
  6. Create PDO by setting a 0 into the valid bit of SubIndex 0x01 of PDO communication parameter. (0x1400 RPDO1 - bit 31 of COB-ID used)
  7. Place the controller into NMT operational.

Storing an user-defined mapping

The drive includes 4 PDO mapping on each direction, with a pre-defined mapping configuration. These PDOs can be modified by the user (see mapping procedure) and stored in the NVM memory. The store of this configuration can be done by using register 0x1010 (store parameters).

To recover the default configuration, it can be done using register 0x1011 (Restore default parameters). 

In addition, all the PDO related configuration (including mapping and COB-ID) will be recovered to their defaults if the node-ID of the device is modified (using LSS).

If node-ID is modified, PDO configuration will be restored to defaults.