CANopen description CERN ATD-DCS A high level protocol is necessary in order to define how the CANbus 11 bit identifier and the 8 data bytes are used among the different nodes on a bus segment. It exits several standards which uses the CAN bus. CERN has chosen CANopen, which is supported by the CAN in Automation (CiA) organisation. It was originally developed from an EEC ESPRIT III project and has found applications in industrial automation applications. There are detailed specifications available from CiA. 1.0 THE ISO/OSI LAYER MODEL AND CANOPEN ....................................................................................... 2 1.2 MINIMAL FUNCTIONALITY DEVICES ............................................................................................................. 3 2.0 NETWORK MANAGEMENT IN CANOPEN - INITIALISATION AND OPERATION........................... 4 2.1 NETWORK MANAGEMENT IN CANOPEN - IMPLEMENTATION......................................................................... 5 2.2 CANOPEN NODE GUARDING ........................................................................................................................ 7 3.0 A COMPARISON OF THE DATA COMMUNICATION OBJECTS IN CANOPEN ................................ 8 3.1 3.2 3.3 3.4 3.5
PROCESS DATA OBJECT (PDO) TRANSFER MODES ......................................................................................... 8 CANOPEN PROCESS DATA OBJECTS EXAMPLE .............................................................................................. 9 PDO - RECONFIGURATION ............................................................................................................................ 9 PDO TRANSMISSION TYPE ......................................................................................................................... 10 PDO INHIBIT TIME ..................................................................................................................................... 11
REFERENCES:.................................................................................................................................................. 12 APPENDIX......................................................................................................................................................... 13 A.0 DEVICE PROFILE PRINCIPLE ........................................................................................................................ 13 A.1 OBJECT DICTIONARY 0000…0FFFH / TYPE DEFINITION ............................................................................. 15 A.2 OBJECT DICTIONARY 1000…1FFFH / COMMUNICATION OBJECTS............................................................... 16
CANopen description: canoproto4.doc 18/06/98
1.0 The ISO/OSI layer model and CANopen The organisation of CANopen in reference to the ISO Open System Interconnect model is shown in Figure 1. This consists of on the top level the CANopen device and communication
Figure 1 CANopen communication reference model. profiles. On the data link layer there is the CAN controller, which conforms to CAN 2.0A and/or 2.0B, while the physical layer is specified in the ISO 11898 standard. The data link layer and the physical layer is implemented in hardware, see [1]. CANopen uses the concept of device profiles. Manufacturers can produce standardised devices by conforming to the guidelines contained in a CANopen device profile. Networks of devices from independent manufacturers can be constructed without having to write specialised specific software for networking each device together. Basic network operation is guaranteed by defining mandatory device characteristics. It is possible to implement additional functions with the help of the optional and the manufacturer specific part of the profiles. There are a number of standard profiles available from CiA, among them CiA-401 [2], which covers I/O modules and CiA-404 [3] for measuring devices and closed loop controllers. The profiles are implemented in a standardised database called object dictionary. There exit software tools to read, configure and 2
CANopen description: canoproto4.doc 18/06/98
change entries in the dictionary of a device. The object dictionary is not stored in the CANopen node itself, it is defined in the Electronic Data Sheet (and on paper), so a master (application) will know the data type and size of every object. The communication profile defines that in a CANopen network there must be at least one master application and one or several slave applications. The master performs the boot-up process and checks and maintains the network in operational state. It also manipulates the object dictionary entries and the CAN identifiers of the connected devices. The communication profile defines several methods for transmission and reception of messages over the CAN bus. Synchronous data transfers allow network wide co-ordinated data acquisition and actuation. Synchronous transfers are supported by predefined communication objects i.e. synchronisation messages transmitted on a cyclic time period and time stamp messages. Asynchronous or event messages may be sent at any time and allow a device to immediately notify another device without having to wait for a synchronous data transfer to take place. The content of both synchronous and event messages (Process Data Objects) may be dynamically configured at network boot up by the network master using Network Management. Although CAN is restricted to transfers of a maximum of 8 bytes of information, data transfers larger than 8 bytes in length are also provided for by the protocol (Service Data Objects). The detailed specifications of the CANopen communication profile are contained in the CiA DS 301 document [4]. In summary the CANopen communication standard defines four types of messages (communication objects): Network administration messages such as Network Management (NMT), e.g. to turn on or turn off a slave node (highest priority). Predefined Messages such as the synchronisation time stamp and emergency messages. Process data messages with one predefined identifier and 1 to 8 data bytes. Service Data Messages e.g. multiple CAN messages with acknowledgement between master and slave (has low priority).
1.2 Minimal Functionality Devices In order to cope with simple slave nodes the CiA 301 profile also specifies what minimal functionality a CANopen device must provide. The configuration effort for simple networks is reduced with mandatory default identifiers. These identifiers are available directly after initialisation (if no modifications have been stored) and may be modified by means of dynamic distribution. Only a selection of the identifiers has to be supported by a device node. Up to 127 nodes is supported on network. The boot up sequence is also considerably simplified and the device boots directly into a pre-operational state. A single message from the master then makes the device fully operational. The supported CAN identifiers for the device are statically allocated and pre-configured by means of the devices DIP switches (for example). The CAN 11 bit identifier is allocated with the four most significant bits implementing the function code and the 7 other bits are the node ID. Table 1 shows the pre-defined identifier for a minimal slave node.
3
CANopen description: canoproto4.doc 18/06/98
Table 1 Predefined identifier for minimal CANopen devices Database Database Resulting Communication Mapping Identifier Index Index
Message
Function code (binary)
NMT
0000
000H
-
-
SYNC
0001
080H
(1005H)
-
TIME STAMP
0010
100H
-
-
EMERGENCY
0001
081-0FFH
-
-
DIP switch + 080H
PDO1 (tx)
0011
181-1FFH
1800H
1A00H
DIP switch + 180H
PDO1 (rx)
0100
201-27FH
1400H
1600H
DIP switch + 200H
PDO2 (tx)
0101
281-2FFH
1801H
1601H
DIP switch + 280H
PDO2 (rx)
0110
301-37FH
1401H
1601H
DIP switch + 300H
SDO (tx) server
1011
581-5FFH
1200H
-
DIP switch + 580H
SDO (rx) client
1100
601-67FH
1280H
-
DIP switch + 600H
Nodeguard
1110
701-77FH
(100EH)
-
DIP switch + 700H
Comments Highest priority
DIP switch = 01H to 7EH or 127 nodes
2.0 Network Management in CANopen - initialisation and operation Network management is used to control the operating state of devices in a CANopen network with the following functions is available: 1. Dynamic or static distribution of CAN identifiers for SDO/PDO communication and error services. 2. Control over node operating states and communication modes for individual or multiple nodes. 3.
Periodic polling of nodes to detect nodes that is no longer alive or functioning correctly.
Their configured module ID initially identifies nodes connected to a CANopen network. The module ID may be configured by setting DIP switches on the device. When the network initialises and boots the network master initially establishes a dialog with individual network dialog with each connected slave by means of the NMT services. Once this dialog has been established the CAN identifiers for communication of the process data messages are allocated to the node. Any configuration information may be downloaded to a device from the cell master 4
CANopen description: canoproto4.doc 18/06/98
using SDO’s. This includes any configuration information for the data content of any process data messages that the device may support. To determine whether nodes are still functional CANopen using NMT lifeguarding techniques whereby individual nodes that support lifeguarding are polled using CAN remote frames to see whether they are still functional. The functional status of the device is returned in the reply to the remote frame. Inhibit times/timeouts may also be implemented so that if the master does not receive a reply from a node within a certain time period the node is regarded as dysfunctional and an error may be flagged. Also nodes supporting inhibit times can also signify an error condition should they not receive a lifeguarding remote frame within the time period negotiated at boot time with the cell master. NMT services can also be used to bring all or selected nodes into various operating states at any time. For example, the network master can broadcast an Enter_Preoperational_State message to all nodes to bring them into a state where further configuration information may be downloaded to the device using service data messages. Alternatively, a single node may be brought into its Pre-Operational state (or configuration mode) by using the same message with different protocol information whilst keeping all other devices fully operational. 2.1 Network Management in CANopen - implementation Every slave node contains a state machine with the four states called: [1] Initialisation, [2] PreOperational, [3] Operational and [4] Prepared. There are five different NMT messages, which permit a CANopen master to change the state of one slave or all slaves simultaneously: Start_Remote_Node, Stop_Remote_Node, Enter_Pre-Operational_State, Reset_Node, Reset_Communication. [1] Initialisation at power on the CANopen slave (with minimum boot-up capability) performs an initialisation sequence and enters automatically into the Pre-Operational state. [2] In the Pre-Operational state, the node will perform the following functions: Perform its internal I/O function, Allow communication via the SDO channel for configuring e.g. PDO mapping, communication parameters Node guarding and respond to node-guarding protocol.
5
CANopen description: canoproto4.doc 18/06/98
Change state to: • • •
Operational_ State Prepared_ State Reset the node
by the Start_Remote_Node command. by the Stop_Remote_Node command. by the Reset_Node or Reset_Communication commands.
[3] In the Operational_State the node will perform the following functions: Perform its internal I/O function Have it’s PDO channels active (synchronised if required) Have it’s SDO channels active Send emergency messages on an error event . Change state to: • • •
Prepared_ State by the Stop_Remote_Node command. Pre-Operational_State by the Enter_Pre-Operational_State command. Reset the node by the Reset_Node or Reset_Communication commands.
[4] In the Prepared_State the node is disabled (no SDO/PDO/emergency communication) But it will perform its internal I/O function. Change state to: • • •
Pre-Operational_State by the Enter_Pre-Operational_State command. Operational_ State by the Start_Remote_Node command. Reset the node by the Reset_Node or Reset_Communication commands.
The NMT message format is (CAN header + 2 data bytes): CAN Header
Byte 1
Byte 2
000H
CS
Node_ ID
CS (Command Specifier) has five values according to the NMT function wanted: 6
CANopen description: canoproto4.doc 18/06/98
NMT function
CS
Start_Remote_Node
01H
Stop_Remote_Node
02H
Enter_Pre-Operational_State
80H
Reset_Node
81H
Reset_Communication
82H
Node_ID can be 1 to 127 to select a single node, or 0 to select all nodes. The hardware switch defines the Node_ID. The CANopen slave does not send any CAN message back with these 5 NMT commands. 2.2 CANopen Node Guarding This is used to detect communication errors in the network. The node guarding (NMT) master can check its slaves and the slaves can check the master (life guarding). Node guarding should be used if a slave isn’t polled on a regular time base. The object dictionary contains Node guarding configuration: 100CH: guard time (in milli-seconds) 100DH: life time factor (* guard time = life time) 100EH: node guarding identifier (default 700H + Node_ID)
Life guarding is enabled for a slave when the node guarding master checks the slave state via a Remote Transmit Request (RTR) on the Node Guarding COB_ID, and the guard time and the life time factor are nonzero: The NMT master message format is: CAN Header 111.0iii.iiii
7
CANopen description: canoproto4.doc 18/06/98
The NMT slave replies with its current state: CAN Header
Byte 1
111.0iii.iiii
tsss.ssss
iiiiiii
Node ID
t
toggle bit, has to toggle every Node guarding request (1st time zero)
sssssss
node state: 3 = Pre-Operational 4 = Prepared 5 = Operational
If the node-guarding master doesn’t receive the current state reply within the guard time, it signals a remote error for that slave to the application. If the slave doesn’t receive this request during its ‘life time’ (guard time * life time factor) then the slave will: Switch to pre-operational state. If the node-guarding master restarts, it will detect the changed operational state of the slave and signal this error to the application.
3.0 A comparison of the data communication objects in CANopen Two different mechanisms exist in CANopen for data transfer. Service Data Object (SDO) transfers are mainly used for large, low priority data transfers between devices and are transmitted asynchronously. They are typically used for configuring devices on a CANopen network. Individual parameters are addressed using a 16-bit index and an 8-bit sub-index addressing mechanism. Data transfers in this mode may be greater than 8 bytes by use of multiple CAN messages. The second mode of communication is by use of Process Data Object (PDO) transfers. Process data messages (synchronous and event/asynchronous) are mainly used for real-time transfer of data and typically have a higher priority on the CAN bus than service data messages. Data in a PDO telegram is limited to 8 bytes or less. The format and data content of the message may be fixed or dynamically configured using SDO data transfers. SDO transfers may be thought of as high load lower speed transfers and PDO transfers thought of as small load high speed transfers hence the analogy between the lorry and the sports car. 3.1 Process Data Object (PDO) transfer modes CANopen supports different modes for transfer of real-time data. One method is simply to send a PDO message on the occurrence of an event. For example, a digital I/O transmits the state of its 8
CANopen description: canoproto4.doc 18/06/98
input lines when they change state. An analogue input module might send the state of an input line once the state of that input line has changed by a pre-configured amount. Another method is by means of synchronous data transfers. In this mode, a very high priority synchronisation telegram (SYNC) is sent on a set time period. The SYNC telegram is broadcast to all devices and on reception of the telegram those devices that are configured to respond to it send data onto the bus. Data is also sent from the controlling device to those devices requiring it. Data transmitted from the device on reception of the SYNC is commonly referred to as actual data whilst data sent to the device is commonly referred to as command data. For a digital I/O module the actual data may be the state of its input lines whilst the command data would be the new state to set the outputs to. After receiving command data the device then actuates on reception of the next SYNC telegram. Thus in a network consisting of several digital output devices all outputs may be set synchronously. Command and actual data may be configured so that the transfer takes place only every Nth SYNC telegram helping to reduce bus loading. Data may also be transferred as an event but synchronously i.e. an event happens on the device and a PDO message is sent as actual data once a SYNC message has been received. Synchronous data communication is one of CANopen’s most powerful features and ensures predictable bus loading.
3.2 CANopen Process Data Objects example When, for instance, the device has one 16 bit analogue output, this value can be mapped in the first 2 bytes of a PDO. A CAN message to this device will therefore contain only two data bytes. Because a PDO transfer does not need any confirmation, setting this 16 bit analogue output just needs one CAN Message with 2 data bytes, total of 60 bits over the CAN bus. The same function with the SDO method would need 2 CAN messages with 8 data bytes, a total of 216 bits over the bus. Reading an analogue input can be done by a remote request of the PDO, these 2 CAN messages then take 104 bits over the bus. Another method is that the PDO can be transferred after a SYNC message. This could even trigger PDOs on all devices in the network. 3.3 PDO - reconfiguration If a device has multiple in- or outputs, they can be mapped into a single PDO (e.g. four 16 bits analogue inputs), as long as the PDO length doesn’t exceed 8 bytes (maximum of a single CAN message). Mapping dictionary object into a PDO is done (via the SDO) using dictionary objects 1600H or 1601H (for receive PDOs of output nodes) and 1A00H or 1A01H (for transmit PDOs of input nodes).
9
CANopen description: canoproto4.doc 18/06/98
Example of PDO mapping (analogue input 16 bits and float): Object Dictionary Mapping Value
Object
Sub Length Index (in bits)
Points to:
Object
Sub Index
1A01
1
64010110H = 6401H
01H
10H
PDO byte 1,2
1A01
2
64040120H = 6404H
01H
20H
PDO byte 3,4,5 6
These results in the following CAN message: PDO1 (tx) CAN Identifier 11bits e.g. 181H
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6
Byte 7
Byte 8
6401H/ 6401H/ 6404H/ 6404H/ 6404H/ 6404H/ not used not used LSB MSB LSB 2nd 3rd MSB
Changing the (variable) PDO mapping is only possible when the node is in its pre-operational state (see ‘Boot-up sequence’). If the node contains non-volatile memory, this is needed only once when reconfiguring is wanted. When changing the PDO mapping fails (node not preoperational, object is not mappable or PDO becomes longer then 8 bytes), the node responds with a ‘Abort domain transfer’. 3.4 PDO Transmission Type The transmission of a PDO can be initiated (triggered) is different ways, according to the PDO transmission type. One method is Asynchronous transmission The PDO can be triggered by: •
Remote request from another device
•
Device (profile) specific event
The other method is Synchronous transmission
10
CANopen description: canoproto4.doc 18/06/98
The PDO can only be triggered by the Network SYNC message, this can be done in different ways: Acyclic: •
Remote request from another device ‘pre-triggers’ the PDO.
•
A device (profile) specific event ‘pre-triggers’ the PDO.
•
The PDO is triggered periodically after every (1,2, up to 240) SYNC messages.
Cyclic:
Dictionary objects 1400H/1401H/1800H/1801H (PDO communication parameter), sub-index 2 (transmission type) determine how a PDO is triggered: PDO transmission method
transmission conditions to trigger PDO A=both needed, O=one or type both Sync 0
A
1-240
O
RTR
Event A
synchronous, acyclic synchronous, cyclic
241-251 252
reserved A
A
synchronous, after RTR
253
O
asynchronous, after RTR
254
O
O
asynchronous, manufacturer specific event
255
O
O
asynchronous, device profile specific event
The DS401 I/O device profile declares the transmission type of every PDO at 255: transmit (input) PDOs are asynchronous, event driven (change of input) or requested with a RTR. receive (output) PDOs are asynchronous. 3.5 PDO inhibit time When a PDO is triggered by an I/O event (e.g. change of digital input or reception of a RS232 character) it is possible that the PDO is triggered at such a high rate that it causes a ‘traffic jam’ on the CAN bus. To prevent this situation, a transmit PDO (on input nodes) has a PDO inhibit time parameter. This is a counter with a 100 µs resolution, which will inhibit the next PDO transmission for a period of time.
11
CANopen description: canoproto4.doc 18/06/98
References: [1] CiA DS-301, V3.0: CANopen Communication Profile, October 1996. [2] Newcastle University Robotics and Automation group http://www.ncl.ac.uk/~nrauto/canproto.htm
12
CANopen description: canoproto4.doc 18/06/98
APPENDIX A.0 Device Profile Principle The CANopen device profile contains the complete specifications of a CANopen module. These specifications include in addition to the functionality also the communication protocol of the module. Because all modules have uniform specifications, the effort for system integration and device standardisation is simplified. Modules from any manufacturer, which adhere to a CANopen profile, can be used together, even if the modules are very different. For every CAN module an Electronic Data Sheet (EDS) and possibly an implemented objects html page should be available, wherein all node objects are described according to the DS301 EDS Specification. This object dictionary is not stored in the CANopen node itself, it is defined in the Electronic Data Sheet (and on paper), so a master (application) will know the data type and size of every object. The Appendix A contains an example of a detailed device profile. The first part of the profile is common for all types: the object dictionaries for the type definitions and the communication part. The second part of the profile contains the manufacturer specific part and also the standard objects for each profile. All application parameters are stored in the object dictionary. Reading and writing a dictionary object is done via the CANopen SDO object. A dictionary object is selected by a 16-bit index. If a object is a record or array then each field is selected by a 8-bit sub-index, and the field with sub-index 0 contains a byte with the amount of fields (excluding sub-index 0 itself) of the object. The meaning of objects / object fields is defined in: •
CiA DS301 (version 3.0): Communication profile for Industrial Systems
•
CiA DSP401 (version 1.4): Device Profile for I/O Modules
•
CiA DSP404 (revision 1.11): CANopen Device Profile for Measuring Devices and Closed-Loop Controllers
13
CANopen description: canoproto4.doc 18/06/98
The object dictionary table contains the following fields:
Index Sub-Index Object Type
16 bit object selection code 8 bit field selection code (arrays, records) deftype var
single value
array
array with same types
record
record with different types
Object Name
symbolic name (used in the Electronic Data Sheet)
Data Type Attr
definition of a data type
data type for field rw
read and write access
wo
write only access
ro
read only access, value can change
con
read only access, value is constant
PDO map
Object is mappable to a PDO
Minimum
Minimum value for data type/parameter
Maximum
Maximum value for data type/parameter
Default
Factory default value for parameter
The first 256 possible entries (Index 0000 - 00FF) are placed in the object dictionary for reference purposes only, they cannot be accessed. These are the definitions of the supported data types. On output nodes objects 0001h-0008h can be mapped on a PDO for dummy PDO mapping (to scale multiple output nodes on a single PDO).
14
CANopen description: canoproto4.doc 18/06/98
A.1 Object Dictionary 0000…0FFFH / Type Definition
Index Object
Object Name Data Type
Minimum
Maximum
Details
(hex) Type 0001 deftype
Boolean
Boolean
0
1
0002 deftype
Integer8
Integer8
-128
127
0003 deftype
Integer16
Integer16
-32768
32767
0004 deftype
Integer32
Integer32
-2147483648
2147483647
0005 deftype
Unsigned8
Unsigned8
0
255
0006 deftype
Unsigned16
Unsigned16
0
65535
0007 deftype
Unsigned32
Unsigned32
0
4294967295
0008 deftype
Float
Float
-3.8 * 10E38
3.8 * 10E38
0009 deftype
Visible String
Vis String
string with ASCII codes 32-126
000A deftype
Octet String
Oct String
string with character/byte codes 0-255
15
CANopen description: canoproto4.doc 18/06/98
A.2 Object Dictionary 1000…1FFFH / Communication Objects
Index Sub- Object Object Name (hex) Index Type 1000
var
Data Type Unsigned32
Device type
Attr Details ro bit0 -bit15: CiA profile bit16: bit17: bit18: bit19:
digital inputs digital outputs analog input analog output
1001
var
error register
Unsigned8
ro The device internal errors
1002
var
manufacturer status reg.
Unsigned32
ro
1003
array pre-defined error field
1003 1003
0
var
1-8 var
Optional variable array with last 8 error
number of errors
Unsigned8
rw
standard error field
Unsigned32 ro
1004
0
var
number of PDOs supported Unsigned32 ro
1004
1
var
number of synchronous PDOs
Unsigned32 ro
1004
2
var
number of asynchronous PDOs
Unsigned32 ro
var
COB-ID SYNC message
Unsigned32 rw Device consumes SYNC,
1005
ID=128 80000080H
1008
var
manufacturer device name
Vis String
ro 4 characters, e.g. ' LMB'
1009
var
manufacturer hardware version
Vis String
ro 4 characters, e.g. '1.00'
100B
var
Node-ID
Unsigned32
ro ID=1 to 127
100C
var
guard time
Unsigned16
rw
100D
var
life time factor
Unsigned8
rw
100E
var
node guarding identifier
Unsigned32
rw
16
Node-ID +700H
CANopen description: canoproto4.doc 18/06/98
1010
array store parameters
Non volatile memory
1010
0
var
largest supported sub-index Unsigned8
ro
1010
1
var
store all parameters
Unsigned32
rw
1010
2
var
store communication parameters
Unsigned32
rw
1010
3
var
store application parameters Unsigned32
rw
1011
array restore defaults parameters
1011
0
var
largest supported sub-index Unsigned8
ro
1011
1
var
restore all default parameters
Unsigned32
rw
1011
2
var
restore communication default
Unsigned32
rw
1011
3
var
restore application default
Unsigned32
rw
1014
var
COB-ID Emergency message Unsigned32
ro
1200
array
server SDO parameter
ro default SDO
1200
0 var
number of entries
1200
1 var
COB-ID Client à Server (rx) Unsigned32
ro
Node-ID + 600H
1200
2 var
COB-ID Server à Client (tx) Unsigned32
ro
Node-ID + 580H
1400
record
Unsigned8
Node-ID + 80H
ro
rx PDO1 com. parameter
1400
0 var
number of entries
Unsigned8
ro
1400
1 var
COB-ID used by PDO1 (rx)
Unsigned32
rw
17
Node-ID + 200H
CANopen description: canoproto4.doc 18/06/98
1400
1401
2 var
record
transmission type
Unsigned8
rw PDO transmission type table
rx PDO2 com. parameter
1401
0 var
number of entries
Unsigned8
con
1401
1 var
COB-ID used by PDO2 (rx)
Unsigned32
rw
1401
2 var
transmission type
Unsigned8
rw PDO transmission type table
1600
array
Node-ID + 300H
rx PDO1 mapping
1600
0 var
number of mapped objects
Unsigned8
rw
1600
1 var
PDO mapping
Unsigned32
rw 62000108H
1600
2 var
PDO mapping
Unsigned32
rw 2nd object
1600
3 var
PDO mapping
Unsigned32
rw 3rd object
1600
4 var
PDO mapping
Unsigned32
rw 4th object
1601
array
rx PDO2 mapping
1601
0 var
number of mapped objects
Unsigned8
rw 1 if analog outputs(s)
1601
1 var
PDO mapping
Unsigned32
rw 64110110H
1601
2 var
PDO mapping
Unsigned32
rw 2nd object
1601
3 var
PDO mapping
Unsigned32
rw 3rd object
1601
4 var
PDO mapping
Unsigned32
rw 4th object
1800
record
tx PDO1 com. parameter
1800
0 var
number of entries
Unsigned8
con
1800
1 var
COB-ID used by PDO1 (tx)
Unsigned32
rw
1800
2 var
transmission type
Unsigned8
rw according to PDO transmission
Node-ID + 180H
type table
18
CANopen description: canoproto4.doc 18/06/98
1800
3 var
inhibit time
Unsigned16
rw inbit PDO transmission for n * 100 µS
1801
record tx PDO2 com. parameter
1801
0 var
number of entries
Unsigned8
con
1801
1 var
COB-ID used by PDO2 (tx)
Unsigned32
rw
1801
2 var
transmission type
Unsigned8
rw according to PDO transmission
Node-ID + 280H
type table
1801
3 var
inhibit time
Unsigned16
rw inhibit PDO transmission for n * 100 µS
1A00
array
tx PDO1 mapping
1A00 0 var
number of mapped objects
Unsigned8
rw
1A00 1 var
PDO mapping
Unsigned32
rw eg.: 60000108H
1A00 2 var
PDO mapping
Unsigned32
rw 2nd object
1A00 3 var
PDO mapping
Unsigned32
rw 3rd object
1A00 4 var
PDO mapping
Unsigned32
rw 4th object
1A01
tx PDO2 mapping
array
1A01 0 var
number of mapped objects
Unsigned8
rw
1A01 1 var
PDO mapping
Unsigned32
rw eg.: 64010110H
1A01 2 var
PDO mapping
Unsigned32
rw 2nd object
1A01 3 var
PDO mapping
Unsigned32
rw 3rd object
1A01 4 var
PDO mapping
Unsigned32
rw 4th object
19
