CiA 304 DS V1.0.1 CANopen framework safety-relevant communication(IGCO_304_v01000101)
CANopen使用手册(V1.00)
CAN open使用手册ProNet伺服驱动器ESTUN修订记录日期修订版本描述作者2009/4/25 1.00 初稿完成移振华2009/9/22 1.00 增加第8章移振华—— 目录 ——1、概述 (5)1.1 CAN 主要相关文档 (5)1.2 本手册使用的术语和缩语 (5)1.3 CANopen概述 (6)2、接线和连接 (7)3、CANopen通讯 (8)3.1 CAN标识符分配表 (9)3.2 服务数据对象SDO (10)3.3 过程数据对象PDO (12)3.3.1 PDO参数 (14)3.4 SYNC报文 (20)3.5 Emergency报文 (21)3.6 HEARTBEAT报文 (23)3.7网络管理（NMT） (24)4、单位换算单元（Factor Group） (26)4.1 单位换算相关参数 (27)4.1.1 position factor (27)4.1.2 velocity factor (29)4.1.3 acceleration factor (30)5、位置控制功能 (31)5.1 位置控制相关参数 (33)6、设备控制 (35)6.1 控制状态机 (35)6.2 设备控制相关参数 (36)6.2.1 controlword (37)6.2.2 statusword (38)6.2.3 shutdown_option_code (39)6.2.4 disable_operation_option_code (40)6.2.5 quick_stop_option_code (40)6.2.6 halt_option_code (41)6.2.7 fault_reaction_option_code (41)7、控制模式 (42)7.1 控制模式相关参数 (42)7.1.1 modes_of_operation (42)7.1.2 modes_of_operation_display (43)7.2 回零模式（HOMING MODE） (44)7.2.1 回零模式的控制字 (44)7.2.2 回零模式的状态字 (44)7.2.3 回零模式相关参数 (45)7.2.4 回零方法 (47)7.3 速度控制模式（PROFILE VELOCITY MODE） (49)7.3.1速度模式的控制字 (49)7.3.2 速度模式的状态字 (49)7.3.3 速度控制模式相关参数 (49)7.4 位置控制模式（PROFILE POSITION MODE） (53)7.4.1 位置模式的控制字 (53)7.4.2 位置模式的状态字 (53)7.4.3 位置控制相关参数 (54)7.4.4 功能描述 (56)8、CAN通讯相关参数 (58)附录对象字典表 (59)1、概述1.1 CAN 主要相关文档Document Name Source 3014.01: CiAVDSCiACANopen Communication Profilefor Industrial Systems - based on CALCiA DSP 402 V 2.0: CiACANopen Device Profile1.2 本手册使用的术语和缩语CAN控制器局域网CiA在自动化国际用户和制造商协会中的 CAN。
CANopen用户手册：线性传感器说明书
Content1CANopen 2 1.1EDS Files 2 1.2Support 2 1.3Features 2 1.3.1Basic information 2 1.3.2Basics based on CiA DS-301, V4.2.0 2 1.3.3Basics based on CiA DSP-406, V3.2 3 1.3.4Basics SDO communication 3 1.3.5Basics PDO communication based on CiA 301, V4.2.0 3 1.4Object Library 4 1.4.1Communication Profile Area based on DS 301 V4.2.0 4 1.4.2Device Profile Area 6 1.4.3Manufacturer specific Area 8 1.5Explanations to Object Library 9 1.5.1Object 0x6300 Encoder Cams 9 1.5.2Cam state registers 9 1.5.3Object 0x6400 Work Area 9 1.5.3.1Work Area Supervision 9 1.5.3.2Work Area State 9 1.6LSS / Layer Setting Service 9 1.6.1Configuration of Node-ID 10 1.6.2Configuration of Bit Rate 10 1.6.3Store Configuration Data 11 1.7SDO Services 11 1.7.1SDO Download 11 1.7.2SDO Upload 12 1.7.3SDO Abort 12 1.8Process Data PDO 12 1.8.1PDO Default Setting 12 1.8.2PDO Parameter Setting 12 1.9Error Handling 14 1.9.1Emergency Messages 14 1.10Error Objects 15 1.10.1Manufacturer-specific Status 15 1.11Non-Volatile Storage and Data Restoration 16 1.12Abbreviations 17 1.13Document Changes 171 CANopenThis document reflects the Novotechnik sensor protocol implementation of the standard CANopen protocol.A basic knowledge of the CAN Bus is required for a proper understanding of this document.Most of the definitions made are according to the following CiA Standard specifications.For making use of all the features that these specifications offer, a knowledge about them is absolutely necessary. The sensor supports the CANopen Communication profile DS-301, V4.2.0, Encoder profile DSP-406, V3.2 and Layer Setting Services (LSS) DSP-305, V1.1.2.1.1 EDS FilesFor integration in a common CANopen projecting tool, electronic data sheet (*.eds) files are provided.These files can be downloaded from the Novotechnik Web Site, see Downloads/Operating manualswhere also this document can be found.Electric data sheet see file Product series_CANopen.1.2 SupportIfyouhaveanyquestions,******************************************************.Electronic data sheets or user manuals for previous software versions are available on request.1.3 Features1.3.1 Basic informationVendor ID: 386 = 0x0182 (Novotechnik)Product code: TP1: 04035 = 0x0FC3, TH1: 04042 = 0x0FCA, TM1: 04228 = 0x1084, TF1: 04052 = 0x0FD4 Rev.-No.: f.e 196613 = 0x30005Serial No.: see product label, “YYMMxxxx”1.3.2 Basics based on CiA DS-301, V4.2.01.3.3 Basics based on CiA DSP-406, V3.21.3.4 Basics SDO communication1.3.5 Basics PDO communication based on CiA 301, V4.2.01.4 Object Library1.4.1 Communication Profile Area based on DS 301 V4.2.01) for 1 position marker2) for 2 position markers1.4.2 Device Profile Area* for 1 position marker: default value 0x01** for 1 position marker and product series TM1 / TF1: not available 1.4.3 Manufacturer specific Area1.5 Explanations to Object Library1.5.1 Object 0x6300 Encoder CamsEncoder cams are used to indicate if a position falls below or exceeds a defined value.1.5.2 Cam state registersCam active: the current position value is between the higher and lower cam-limitCam inactive: the current position value is not between the higher and lower cam-limit.The values for low limit (0x631x) and high limit (0x632x) regard the values for preset (0x6010) and measuring steps (0x6005). The value of hysteresis (0x633x) is added in direction of motion.Note: the cam high limit value can have a lower value than the cam low limitA change in cam state causes an EMCY message.The cam state objects (0x6300) are able to be mapped to the TPDOs.1.5.3 Object 0x6400 Work AreaIt is possible for encoders to define a so-called user defined working area.The main purpose for a work area is to get a high-priority information (via EMCY message) when the transducer’s p o-sition leaves its predefined working area.The actual work area information with work area low limit and work area high limit may be stored in object 0x6401 and 0x6402. This way, the area state object (0x6400) may also be used as software limit switches.1.5.3.1 Work Area SupervisionEach work area channel is fixedly linked to a position channel:1.5.3.2 Work Area StateThe values for low limit (0x6401) and high limit (0x6402) regard the values for preset (0x6010) and scaling (0x6501, 0x6502).A change in work area state causes an EMCY message.The work area state objects (0x6400) are able to be mapped to the TPDOs.1.6 LSS / Layer Setting ServiceTo configure the encoder via the LSS(according CiA DS 305) the encoder is handled as a slave, thePLC must have a LSS master functionality.A LSS-message is composed as follows:This applies to the COB-ID:• LSS-Master ⇒ LSS-Slave: 2021 (0x7E5)• LSS-Slave ⇒ LSS-Master: 2020 (0x7E4)LSS can only be used when the encoder is in the stopped status or pre-operational status.The NMT command for setting the encoder in stopped status is:To program via LSS the sensor has to be switched to LSS configuration state.There are two possible ways to do so:• Switch Mode Selective:only the addressed CANopen device is switched to the LSS configuration stateLSS requires data content in the following objects:Example:Vendor-ID (see index 1018/1) 0x0182 LSS-Command 0x40 Product code (see index 1018/2) 0x0BE0 LSS-Command 0x41 Rev.No. (see index 1018/3) 0x10003 LSS-Command 0x42 Serial-No. (see index 1018/4) 0x12345678 LSS-Command 0x43 After receiving the identification objects, the encoder answers with LSS-Command 0x44.• Switch Mode Global: all CANopen devices supporting LSS are switched to the LSS configuration stateWhen the CAN devices are in configuration state the Node-ID and/or the bit rate can be changed. 1.6.1 Configuration of Node-IDThe Node-ID can be programmed with the LSS-Command 0x11N ID: new Node-ID in the range of 1 (127)Err Code: 0: protocol successfully completed / 1: Node-ID out of rangeChange of Node-ID will cause:•Automatic alteration of COB-ID’s for SDO1, EMCY and Heartbeat and TPDOs.•Non-volatile Node-ID storage through …Store Configuration“ in the LSS mode configur ation.1.6.2 Configuration of Bit RateThe Bit Rate can be programmed with LSS-Command 0x13Table Index: 0x07: 20 kBaud0x06: 50 kBaud0x04: 125 kBaud0x03: 250 kBaud0x02: 500 kBaud0x01: 800 kBaud0x00: 1000 kBaudErr Code: 0: protocol successfully completed 1: Bit timing not supportedChange of Bit rate will cause:•The bit rate gets active•Non-volatile CAN bit rate storage through …Store Configuration“ in the LSS mode configuration1.6.3 Store Configuration DataThe LSS configuration data (Node-ID and Bit Rate) are stored to the non-volatile memory of the sen-sor using LSS-Command 0x17Err Code: 0: protocol successfully completed 2: storage media access error1.7 SDO ServicesService Data Objects SDO (according to CiA DS 301) manage the parameter data exchange, e.g. thenon-cyclical execution of the preset function.Parameters of device object library (object index/subindex see chapter 1.4 Object Library) can beread, written or stored by means of SDO.1.7.1 SDO DownloadThe SDO download service is used to configure the parameters.Command 0x2_: 0x22 write command, parameter to encoder0x23 write command, 4 Byte parameter to encoder0x27 write command, 3 Byte parameter to encoder0x2B write command, 2 Byte parameter to encoder0x2F write command, 1 Byte parameter to encoderCommand 0x60: confirmation: parameter receivedNODE-IDUsing writing to object 0x2000, non-volatile storage has to be done by w riting the“save”- signature (0x65766173) on object 0x1010/1 (TP1/TH1) or 0x1010/4 (TF1). These changes will become effective after a communication restart or a power up.Changing the Node-ID will affect all COB-IDs according to the “predefined co nnection s et”.Example: COB-ID TPDO1 = 0x180 + (Node-ID)BIT-RATEUsing writing to object 0x2001; non-volatile storage has to be done by writing the“save”- signature (0x65766173) on ob-ject 0x1010/1 (TP1/TH1) or 0x1010/4 (TF1). These changes will become effective after a communication restart or a power up.1.7.2 SDO UploadThe SDO upload service is used to read the parameters.Command 0x40: read command, parameters from encoderCommand 0x4_: 0x42 read command, parameter to encoder0x43 read command, 4 Byte parameter to encoder0x47 read command, 3 Byte parameter to encoder0x4B read command, 2 Byte parameter to encoder0x4F read command, 1 Byte parameter to encoder1.7.3 SDO AbortIf the SDO download or SDO upload service fails for any reason, the sensor responds with a SDO abort protocol. Abort Code: 0x06090011 subindex does not exist0x06090030 value exceeded0x06020000 object does not exist0x06010001 object is write only0x06010002 object is read only0x06060000 access error0x08000020 data transport error0x08000000 general error0x08000022 wrong state1.8 Process Data PDOProcess Data Objects (according CiA DS 301)manage the process data exchange, f.e the cyclical transmission of the position value. The process data exchange with the CANopen PDOs is a very slim process without protocol overhead.1.8.1 PDO Default Setting2 Transmit PDOs (TPDO) with each max. 8 bytes are provided:0x1800 TPDO1: default: Event-driven with event timer switched off (changeable to synchronous)0x1801 TPDO2: default: synchronous1.8.2 PDO Parameter SettingThe contents of the encoder-specific TPDOs can be configured by variable mapping according to cus-tomer´s requirements. This mapping has to be performed for the encoder as well as for the receiver.The PDO is limited to a maximum size of 8 bytes and 5 mappings per each PDO.Step 1: For changing of mapping, the sensor must be in properational mode and the MSB of PDOCOB-ID has to be set to 1 to deactivate it.Step 2: Clearing entries in mapping table of PDO1 (PDO2) => subindex 0x0 of object 1A00 (1A01)has to be set to 0x00.Step 3: Mapping of objects into PDOExample:A PDO shall be mapped in a way that the "current position", the "current speed" and the "current chiptemperature" are transmitted in one PDO .Mapping #1 “current position”:Mapping #2 “current speed”:Mapping #3: “current chip temperature”.Step 4: Setting entries in mapping table => subindex 0x0 of object 1A00 has to be set to the numbers of mapping en-tries (e.g. 0x03)Step 5: For re-activating the PDO, the MSB of PDO COB-ID has to be set to 0.Note:TPDO1 value for Event Timer must always be higher than the value for Inhibit Time (except for value 0).Failed sending of TPDOs can occur if:•more TPDOs shall be sent than the CANbus may accept due to insufficient CAN bit rate compared to TPDO/Event Timer •excessive bus load or unfavourable setting of COB-ID in the CANopen network prevents TPDOsending•Object 0x1800/5- event timer- is set to 0.1.9 Error HandlingDepending on the type of error occured, the sensor will react accordingly:* according to DS-301, see chapter 1.7 SDO Services** details see chapter 1.9.1 Emergency Messages1.9.1 Emergency MessagesCOB-ID EMCY in object 0x1014.Error-Register in object 0x1001.0x50xx Device Hardware 0x60xx Device Software 0x80xx Monitoring 0x90xx External Error1.10 Error Objects1.10.1 Manufacturer-specific StatusThe object 0x1002 shows the sensor status bit code and is used for internal process control purposes. For servicing this information can be requested via SDO (see chapter 1.7 SDO Services).Bit Definition (if bit value = 1)2 CAN Bus-Off Timer started0-1 NMT Condition of Sensor%11 stopped%10 operational%01 pro-operational%00 initialisation1.11 Non-Volatile Storage and Data RestorationDefault values for all data objects are stored in the non-volatile program memory.Data encryption to the non-volatile memory is only admitted in the pre-operational status.• Storage via LSS:Data must be stored through the LSS Service Configuration/Store while in LSS Configuration Mode (see chapter 1.6 LSS / Layer Setting Service)• Storage via SDO:Object 0x1010:Data is stored in the non-volatile memory during encryption of object 0x1010 with …save“ signature (0x65766173).Object 0x1011:Encryption of object 0x1011 with the sig nature …load“ (0x64616F6C) will upload data from the non-volatile memory. Default settings are being restored (see chapter 1.7 SDO Services).CAUTION: In case of custom programmed parameters like node-ID, averaging, bit rate etc. these will be reset to default in case of the corresponding reset command below (default values see chapter 1.4 Object Library).Object 0x1010 Object 0x1011 Subindex /1AllSubindex /2CommunicationSubindex /3ApplicationSubindex /4ManufacturerCOB-ID SyncGuard Time X XLife Time Factor X XHeartbeat Timer X XTPDO COB-ID D XTPDO Trans Typ X XTPDA Inhibit Time X XTPDO Event Timer X XTPDO Mapping X XNMT Startup X XNode-ID X (TP1/TH1) X (TF1) BitRate X (TP1/TH1) X (TF1) Number of position markers (only TP1 / TH1) XCustom (only TP1 / TH1) X Operating Parameters X XLinear Encoder Measuring Step Settings X XPreset Value X XCAM Enable X XCAM Polarity X XCAM Low Limit X XCAM High Limit X XCAM Hysterese XWork Area Low Limit XWork Area High Limit XX: data saved or restoredD: data set to default value• Delete via SDO Object 0x1010:Additionally to the functionality defined in CiA standard DS-301, CANopen library offers the possibility to delete data inthe non-volatile memory. Del ete process is initiated by sending the signature “kill” (0x6C6C696B) to object 0x1010.• Manufacturing Mode Object 0x1010▪Only TM1 series:If the sensor is out of function and the signature “boot” 0x746F6F62 in object 0x1000 (device type) is active, the sensor is in manufacturing mode. This mode can be left by power off-on or via the operationalcommand.1.12 AbbreviationsCAN Controller Area Networkch channelCOB-ID Communication Object Identifierconst constant parameter, only readableDLC Data Length CodeDS Draft StandardEMCY Emergency ServiceNMT Network-ManagementPDO Process Data ObjectPos Position (value)ro read only, parameter can changerw read/writeRx Novotechnik sensor is consumer of the CAN data frameRTR Remote Transmission RequestSDO Service Data ObjectSYNC Synchronisation messageTPDO Transmit Process Data ObjectTx Novotechnik sensor is producer of the CAN data frame1.13 Document ChangesRevision Changes Date WhoV00 First edition 16.07.14 VM/mm V07 1.2.5 / 1.3.1 object 1801x2: event driven transmission deleted for TPDO2. 1.3.1 objects:TPDO1 and TPDO2: name modified. 1.3.object 1800/2 and 1801/2 comment: synchronous1...240 instead 1...239, TPDO off: 0 added01.04.20 VM/mmV08 1.3.1 object 1010/4 user parameter data instead of manufacturer defined parameters.1.3.1 1010/5 added (Manufacturer data parameter). 1.10. signature kill 6C6C696B insteadof 6B696C6C, comment regarding manufacturing mode added21.01.21 VM/mmV09 1.2 Support added, all further chapter numbers changed1.8.3 Textual modifications 07.09.2117.11.22VM/mm。
DS302
© CAN in Automation e. V.Framework for Programmable CANopen DevicesCiA Draft Standard Proposal 302Not recommended for implementationMay be changed without notificationVersion 3.1.1Date: 10.05.2002HistoryDate Version Changes05.03.1998 1.0Initial revision27.11.1998 2.0• New chapter for NMT Master related objects• Extension of Configuration Manager• Groups / Multiplexor PDO: Clarification and new objects for con-figuration29.06.2000 3.0• Introduced definition of the boot-up procedure• Renamed chapter Slave Assignment to Network List• New objects for the network list• Clarification of existing objects according to DS-301 V4• Moved chapter Configuration Master behind chapter NMT Mas-ter• New objects for the Configuration Manager• Adaptation of Client/Server relationships to Producer/Consumermodel according to DS-301 V4. Removed references to CAL.• Network variables may have access type rww• Removed duplicated example in section 8.3• Moved data type declaration 23H to 25H due to overlap with DS-301 V4• Moved objects 1020H Verify Configuration, 1021H/1022H EDSStorage to appendix of DS-301• Moved chapter OS Command and Prompt to appendix of DS-301• Moved chapter Groups to appendix of DS-301• Change of SDO Manager Mechanisms07.03.2002 3.1• Definition of CANopen Manager includes now the case NMTMaster + Configuration Manager• Self-starting devices• Flying Master taken over from SIG Maritime with some changes• Updated references• Object 1F81H, Bit 1 has become obsolete by the defined proc-esses; removed• Clarification of object attribute M/O• Editorial changes• Added Error Codes08.05.2002 3.1.1• Bug fixes and clarificationsTable of Contents1Scope (1)2References (1)3CANopen Manager, Terms and Definitions (2)4Boot-Up Procedure (3)5NMT Master (16)5.1NMT Start-up (16)5.2Network List (18)5.3Error Control (20)5.4Request NMT (22)5.5Flying Master (24)6Configuration Manager (34)6.1DCF storage (34)6.2Concise configuration storage (35)6.3Check configuration process (36)6.4Request Configuration (36)6.5EDS storage (37)7Dynamic Establishment of SDO Connections (38)7.1Basic mechanism (38)7.2Specification (40)8Input/Output of a Programmable Device (47)8.1Basics (47)8.2Dynamic Index Assignment (47)8.3EDS (48)8.4DCF (49)9Program Download (50)10Summary of object dictionary extensions (52)FiguresFigure 1: CANopen boot-up procedure main flow, part 1 (3)Figure 2: CANopen boot-up procedure main flow, part 2 (5)Figure 3 : Start Boot Slave Process (6)Figure 4:Boot slave predefined process, part 1 (7)Figure 5:Boot slave predefined process, part 2 (optional) (9)Figure 6:Check node state -predefined process (10)Figure 7:Check and update software version -predefined process (11)Figure 8 :Boot slave predefined process, part 3 (12)Figure 9:Check configuration -predefined process (13)Figure 10:Simplest possible NMT Boot Process (15)Figure 11:Start Error Control Service -predefined process (21)Figure 12:Error Handler (22)Figure 13:Flying Master Process Overview (25)Figure 14:Detection of Active NMT Master Protocol (26)Figure 15:NMT Master Negotiation Protocol (27)Figure 16:Waiting Period after Reception of the Trigger Time Slot Command (28)Figure 17:Forcing a New NMT Master Negotiation Protocol (28)Figure 18:Detection of NMT Master Capable Devices (29)1 ScopeThe CANopen Communication Profile (DS-301) defines the basic communication mechanisms for exchanging data via a CANopen-based networks. This includes the structure of the object diction-ary, the network management and boot-up as well as communication objects like PDO, SDO, SYNC and time stamp. The object dictionary provides a standard interface for accessing of com-munication parameters as well as process data. The part of the object dictionary which describes the general device and communication parameters is common for all devices types.Application specific functionalities which are provided by certain device types are detailed in specific device profiles (DS-4xx). A device profile is always based upon the definitions in the communication profile.In general the mechanisms which are specified in the communication profile are sufficient for the definition of profiles for devices which, on the application level, provide some kind of I/O functional-ity. Example devices include I/O modules, drives and regulators. These devices whilst they may be complex are not termed ‘intelligent’ as they do not run an application level program.For the description and operation of intelligent devices further mechanisms are necessary which are specified in DS-302. DS-302 has to be regarded as a framework for the definition of device profiles for intelligent or programmable devices in form of an extension to the communication profile DS-301. The additional mechanisms specified in DS-302 are useful especially for intelligent devices like PLCs, HMIs or CANopen tools.DS-302 comprises the following mechanisms and definitions:• The term CANopen Manager is introduced to specify more clearly the network functionality of a network controlling device.• Definition of the Boot-Up process and the related objects.• A possibility for configuration of unconfigured nodes during system boot-up by means of a Con-figuration Manager.• The dynamic establishment of SDO connections between devices. Dynamic SDO connections are handled by the SDO Manager.• The definition of dynamically allocated entries in an object dictionary which can be used for the representation of I/O data e.g. on programmable nodes like PLCs.• A general mechanism for downloading program data and functions for the control of programs on a device.Some of these new mechanisms are also useful not only for intelligent or programmable devices.2 References/1/CiA DS 301, CANopen - Communication Profile for Industrial Systems, v 4.01, June 2000/2/CiA DSP-305, CANopen Layer Setting Services and Protocols (LSS), v1.0, May 2000/3/CiA DSP-306, Electronic Data Sheet Specification, v1.1, June 2001/4/CiA DSP-405, Device Profile for IEC1131 Programmable Devices, v2.0, December 20003 CANopen Manager, Terms and DefinitionsBesides the application process several different additional functionalities can exist in a CANopen system. These functionalities are referred to by different terms. This chapter is intended to clarify these terms.Within a distributed system the application process is divided into several parts running on different nodes. From the applications point of view usually one node is responsible for the control of the system. This node is called application master (e.g. a PLC).From the network’s point of view there are several additional functionalities which not directly deal with the application but provide application supporting functions. These additional functionalities are based on a master / slave, client / server or producer / consumer relationship.•NMT MasterThe network management (NMT) provides services for controlling the network behaviour of nodes as defined in /1/ DS-301. All nodes of a network referred to as NMT Slaves are controlled by services provided by an NMT master and which have to be executed by an NMT master ap-plication. Usually the NMT master application is also part of the application master.•SDO ManagerThe SDO Manager is an optional functionality responsible for handling of the dynamic estab-lishment of SDO connections as defined in chapter 7. If an SDO Manager is present in a system it must reside together with the NMT Master on the same node.•Configuration ManagerThe Configuration Manager is an optional functionality which provides mechanisms for configu-ration of nodes in a system during boot-up as defined in chapter 6. The mechanisms are called Configuration Management CMT. The Configuration Manager must reside on the same node to-gether with the NMT Master and SDO Manager.•SYNC ProducerThe SYNC Producer is an optional functionality which is responsible for transmitting the SYNC object. It may reside on any one node in a CANopen system.•TIME ProducerThe TIME Producer is an optional functionality which is responsible for transmitting the TIME STAMP object. It may reside on any one node in a CANopen system.•LSS MasterThe layer specification services (LSS) provides services for configuring layer 2 (bit timing) and NMT (Node-ID) via CAN as defined in /2/ DS-305. All nodes in a network which support LSS services are LSS Slaves. The services are provided by the LSS Master and used by a LSS Con-figuration Application.B ecause it is usual to combine several of the additional functionalities on one node an additional term is introduced: the CANopen Manager.A node is referred to as a CANopen Manager when the functionality of an NMT Master is provided by the node and at least one of the functionalities SDO Manager or Configuration Manager.B asically all objects in this document are optional. If denoted as mandatory, this is valid if the con-cerned functionality is provided by the device (e.g. SDO Manager). Some objects consist of a set of bits, specifying several kinds of behaviour (as e.g. 1F80H). Only those bits have to be implemented that correspond to a supported behaviour. If not implemented, the bit has to be 0.4 Boot-Up ProcedureWhen the CANopen Manager starts after Power-On, it will perform the state machine according to DS-301. Before switching the state from Pre-Operational to Operational it has the task of booting all assigned slaves. The overall process is shown in the following two flow charts. The flow charts show the process with the most complete set of implemented features. Refer also Figure 10.Figure 1: CANopen boot-up procedure main flow, part 1.Predefined process 'Execute LSS' is not given in this document.The Boot-Up main flow consists of the following basic steps:1. If the Flying Master process shall be executed, this finds out the active NMT Master. The proc-ess itself is described in chapter 5.5. The process can directly lead to Slave Mode.2. Bit 0 of the object 1F80h is checked to decide upon whether this node is assigned to be theNMT Master or not. If not, the node will enter a slave mode if supported.3. For systems that require setting of Node-IDs or baudrate CANopen defines the LSS. If neces-sary, this has to be performed (perhaps even before step 1). The block in the flow chart is onlya place holder. It is not the scope of this document to specify the concrete entry point for LSSactions.4. The Master starts with the service NMT Reset Communication All Nodes, except if any of thenodes is forbidden to be reset without state check. In some applications some of the slave nodes may enter a special mode (like manual mode) in case of CANopen manager sudden drop-out. If the continuous state is the safe state, it may not be tolerable to send NMT Reset Communication -command for such a node if the state of the node is initially Operational. Bit 4 in the object 1F81h (see chapter 5.2) is provided to force a state check prior to sending NMT Reset Communication -command. In case the Bit 4 of the object 1F81h in any of the sub-indexes is non-zero, NMT Reset Communication All Nodes must not be sent, but the nodes are reset individually.The Reset Communication shall not apply for the Master itself.This step allows to put the slaves in a state, where the settings of all parameters are well-defined. In the case, that the Master detected a booting slave later on, it uses the service only for the individual node.The main flow resumes in Figure 2 .Figure 2: CANopen boot-up procedure main flow, part 2.5. The main flow resumes with the Start Boot Slave Process as illustrated in Figure 3. This will tryto boot all optional slaves at least once and will boot all mandatory slaves.6. If an error occurs on booting a mandatory slave the main flow forces a halt of the boot-up pro-cedure.7. Start Remote NodeAfter all mandatory nodes are started, the Master will enter state Operational according to NMT Start-up configuration bit 2 in object 1F80H (refer to chapter 5.1).If the bit 3 of object 1F80h (see chapter 5.1) allows, perform the service NMT Start Remote Node (= 'Enter Operational') – either individually after finishing the configuration or by broadcast command after all nodes have been configured. Whether the NMT Start Remote node should be sent individually or globally is configured in bit 1 of the object 1F81h (refer to chapter 5.2).The Start Boot Slave Process is given by Figure 3.Figure 3 : Start Boot Slave ProcessThe steps of the Start Boot Slave Process are as follows:1. Start parallel Process2. Wait for a signal, that a boot was successful or at least was tried onceThe parallel process will1. Perform the process Boot Slave2. Create Signal for a Boot Slave try3. If Boot Slave returned with status OK finish the process. For optional slaves the process runsendlessly until the slave is found. The recommended cycle time for Baudrates above 125 kBit/sec is 1 second. This will stop only, if the slave is found or the application removes the slave from the network list. The loop will stop also if the slave is mandatory and the predefined timeout (object 1F89h) occurs. In that case the Boot slave -process ends with an error status.The application and error specific error handler may then give a warning to the operator and may resume with other nodes in a 'limb mode'. If none of the loop end conditions above is sat-isfied, the slave poll loop will run endlessly. The check is done asynchronously. That means, that other processes will run in parallel.The “Boot Slave” -process is given by the following three flow charts:Figure 4:Boot slave predefined process, part 1.The steps of the Boot slave -process are as follows:1. Attempt to read slave’s index 1000H to check if the node is present.If the slave does not answer the read request, the Boot slave -process ends with an error status.2. IdentificationIf the Device Type Identification value for the slave in Network List object 1F84H (refer to 5.2) is not 0x0000 (“don’t care”) compare it to the actual value.If the configured Vendor ID in Network List object 1F85H is not 0x0000 (“don’t care”), read slave’s Index 1018H, Sub-Index 1 and compare it to the actual value. The same happens with ProductCode, RevisionNumber and SerialNumber with the according objects 1F86H-1F88H.On identification failure, the process continues with error handler (whose reaction is application specific).The Boot slave -process continues with an optional part (Part 2, see Figure 5), which introduces two optional boot-up features: keeping alive initially operational slave nodes and controlling application software versions including automatic update of the slave software.The Keep alive -feature is used in situations where a slave node is already in Operational state when the CANopen manager starts up. This situation may happen for example in case of sudden drop-out and restart of the CANopen manager. In some cases it is not tolerable to reset the slave node, because the slave node may have entered a special mode (e.g. manual operation mode) in case it notices a drop-out of the CANopen manager. This type of mode is needed if the continuous state of the sub-process controlled by the slave is the safe state. The slave node notices the restart of the CANopen manager from the 'NMT Start Remote Node' -indication and may resume its nor-mal operation mode.The software version control is used in situations where it is important to check the application soft-ware version prior to starting of the remote node. The 'Check and update software version' -predefined process includes also possibility to download the application software automatically if the software version is not correct. In case of a checksum error during slave start-up self diagnostics, the slave may also respond deliberately with a wrong version information (like zero date and zero time) to force the CANopen manager to download the application software. Automatic download requires a file system to exist on the CANopen manager to store the application software of the slave nodes that are configured to join the automatic software download process.Both or only one of the two features may be implemented optionally.Figure 5:Boot slave predefined process, part 2 (optional).3. Keeping alive initially operational slavesIf the Keep alive -bit (bit 4 of object 1F81h, see chapter 5.2) is set the state of the slave has to be checked to verify whether the slave is in Operational state or not. If the node state was not received the process is resumed by the application and error specific error handler. In case the state information is received and is noticed to be 'Operational', the process resumes from con-nection point D in Figure 8. In practice this means that software version checking and configu-ration version checking steps are skipped. If the state was not 'Operational', the NMT Mastersends 'NMT Reset Communication' -command to this node. Note that in case the slave sup-ports Node Guarding protocol, the Check node -process sends a single RTR to request the Node Guard response. Hence, the slave is unintentionally fooled to start its local Error Control process. Therefore, it is recommended to keep the time between sending of the RTR and sending the 'NMT Reset Communication' -command less than Node Life Time in order to pre-vent the slave from generating a Life Guarding Event. However, in most cases it may cause no harm if the Life Guarding Event nevertheless occurs, as the 'NMT Reset Communication' -indication occurs subsequently anyway. In case the slave is already Operational and the next RTR is delayed more than Node Life Time, succeeding Life Guarding Event will not cause problems, because the slave had already got the Life Guarding Event due to CANopen man-ager drop-out. The slave must not resume its normal operation as a consequence of receiving RTR but only after receiving NMT Start Remote Node -command.Check node state -predefined process is illustrated in Figure 6Figure 6:Check node state -predefined process.(needed only if the optional part of the Boot slave -process is implemented).4. Application software version controlSetting Bit 5 of the object 1F81h (see chapter 5.2) forces application software version verifica-tion. The software version is checked and if automatic software update is allowed for the node, the software is downloaded in case of version inconsistency. In case of errors during version checking or software download, the process is resumed by the error handler.Check and update software version -predefined process is illustrated in Figure 7.Figure 7:Check and update software version -predefined process(needed only if the optional part of the Boot slave -process is implemented).Download program code -predefined process is not illustrated in this context.For objects 1F52h to 1F54h refer to chapter 9; for bit 6 of object 1F81h refer tochapter 5.2.The Boot slave -process continues with part 3 (see Figure 8). This part is mandatory.Figure 8 :Boot slave predefined process, part 35. Check configurationThe Configuration Management (CMT) is described in detail in chapter 6. It will check the con-figured value of the Network List object 1F26H and 1F27H. If both values are not 0, it will read the slave’s object 1020H Verify Configuration. If the read access fails or the actual values are not equal to the configured values or the objects 1F26H, 1F27H are not implemented, the CMT will start the CMT Download process.If the CMT Download process fails, the boot-up process continues with the error handler (whose reaction is application specific).The process flow may skip the Check configuration -step in case Keep alive -feature is imple-mented and the slave is noticed to be initially Operational. In that case, the flow resumes from connection point D. If the flow resumes from connection point D the situation is informed to the application by returning from the Boot slave -process with an error code. The error code is used by the error handler to give a warning 'Slave X was initially Operational' to the operator.Check configuration -predefined process is illustrated in Figure 9.Figure 9:Check configuration -predefined process.Download configuration -predefined process is not illustrated in this context.6. Start Error Control ServiceThe procedure shall support DS-301 V3 devices as well as V4 devices. For this the Master in-spects it’s configured values in object Consumer Heartbeat Time 1016H and Slave Assignment 1F81H and proceeds as described in chapter 5.2. If the Start Error Control Service -process fails, the boot-up continues with error handler (whose reaction is to restart the Boot Slave Proc-ess and further application specific behaviour).Start Error Control Service -predefined process is illustrated in Figure 11 in chapter 5.3.7. Starting individual slavesIf the bit 3 of object 1F80h (see chapter 5.1) allows and if the bit 1 of object 1F80h is configured zero (0), the slave has to be started individually.In Normal Operation, after the end of the initial boot-up procedure, the NMT master will not perform anymore the "NMT Start all node" command that may be required according object 1F80h Bit 1. In that case the Boot Slave process has to start individually the node if the NMT master is allowed to start a node. The test whether then NMT master's node is OPERATIONAL allows to know if the initial boot-up procedure has reached its end or not. This case happens when the process is started by the Error Handler (see chapter 5.3) or by the Boot-Up handler (see chapter 5.4) for an optional node with a late boot-up or a new device replacing a defunct one.Descriptions of the Error status codes showing up in the boot-up procedure flow charts: Error status DescriptionA The slave no longer exists in the Network listB No response on access to Actual Device Type (object 1000h) receivedC Actual Device Type (object 1000h) of the slave node did not match with the ex-pected DeviceTypeIdentification in object 1F84hD Actual Vendor ID (object 1018h) of the slave node did not match with the ex-pected Vendor ID in object 1F85hE Slave node did not respond with its state during Check node state -process.Slave is a heartbeat producerF Slave node did not respond with its state during Check node state -process.Slave is a Node Guard slave (NMT slave)G It was requested to verify the application software version, but the expected ver-sion date and time values were not configured in objects 1F53h and 1F54h re-spectivelyH Actual application software version Date or Time (object 1F52h) did not matchwith the expected date and time values in objects 1F53h and 1F54h respectively.Automatic software update was not allowedI Actual application software version Date or Time (object 1027h) did not matchwith the expected date and time values in objects 1F53h and 1F54h respectivelyand automatic software update failedJ Automatic configuration download failedK The slave node did not send its heartbeat message during Start Error Control Service although it was reported to be a heartbeat producer (Note! This errorsituation is illustrated in Figure 11 in chapter 5.3)L Slave was initially operational. (CANopen manager may resume operation with other nodes)M Actual ProductCode (object 1018h) of the slave node did not match with the ex-pected Product Code in object 1F86HN Actual RevisionNumber (object 1018h) of the slave node did not match with the expected RevisionNumber in object 1F87HO Actual SerialNumber (object 1018h) of the slave node did not match with the expected SerialNumber in object 1F88HApplication notes:In principle parameters are just written and not read afterwards; the correct implementation of the SDO protocol must be trusted. This may be changed for safety critical parameters or applications. It is allowed to boot one device after another or all in parallel.The defined process gives an overview on the Boot-Up, it shall not define specific API for NMT or other concrete instances. The main purpose is to have some common rules for Master Code and to give Slave Devices the knowledge, what they have to expect on Boot-Up.The same process will be used, if a slave has to be booted while the rest of the system is already running, e.g. after a Reset or Error Control Event. In that case the NMT Start Node may always be sent individually.Since nearly all objects and features in this document are optional it is possible to implement very basic NMT Master, which could make sense for some kinds of applications. The most simple boot-up process possible besides self-starting devices is shown in Figure 10.Figure 10:Simplest possible NMT Boot Process5 NMT MasterThe NMT Master provides services for controlling the network behaviour of nodes as defined in DS-301. Only one NMT Master can exist in a CANopen Network. Since there may be several devices that are able to perform the task of an NMT Master, it is necessary to configure this functionality. 5.1 NMT Start-upIndex Object Name Type Attr.M/O1F80H VAR NMTStartup Unsigned32RW OThis object configures the start-up behaviour of a device that is able to perform the NMT. The value has the following interpretation:Bit 0= 0Device is NOT the NMT Master. The objects of the Network Listhave to be ignored. All other bits have to be ignored. Exceptionfor Autostart 0001000b, 0000010b see below.= 1Device is the NMT Master.Bit 1= 0Start only explicitly assigned slaves (if Bit 3=0).= 1After boot-up perform the service NMT Start Remote Node AllNodes (if Bit 3=0)Bit 2= 0Enter myself automatically Operational= 1Do not enter myself Operational automatically. Application willdecide, when to enter the state Operational.Bit 3= 0Allow to start up the slaves (i.e. to send NMT Start Remote Node-command)= 1Do not allow to send NMT Start Remote Node -command; theapplication may start the SlavesBit 4= 0On Error Control Event of a mandatory slave treat the slave indi-vidually.= 1On Error Control Event of a mandatory slave perform NMT Re-set all Nodes (including self). Refer to Bit 6 and 1F81H, Bit 3 Bit 5= 0Do not participate Flying Manager Process= 1Participate the Flying Manager ProcessBit 6= 0On Error Control Event of a mandatory slave treat the slave ac-cording to Bit 4= 1On Error Control Event of a mandatory slave send NMT Stop allNodes (including self). Ignore Bit 4.Bit 7-31Reserved by CiA, always 0Bits that control a feature that is not supported by the implementation are RO.Object 1F80H is a configuration object. Internal state transitions must not change this object.The system integrator has the responsibility to combine the bits appropriately. The following combi-nations for configuration have a standardised behaviour:- NMT Master, Flying Master not supportedB it0123456V alue1X X X X0XT his is the standard case for CANopen Managers without performing a Flying Master Process.The device performs the Boot-Up as a described with evaluating all the other bits.- NMT Master supporting Flying Master ProcessB it0123456V alue1X X X X1XT he Bit 0 stays 1 even if the device looses the Flying Master Process. In that case Bit 2 Autostart feature is not evaluated. The device has to store the information that it currently is not the NMT Master internally. If the device gets the Mastership it continues the Boot-Up as a de-scribed with evaluating all the other bits.- Start-up capable Device, Autostart feature onlyB it0123456V alue0001000D evices that are not implementing an NMT Master, but shall enter Operational mode automati-cally, shall implement object 1F80H. This feature can be configured with setting Bit 2 to 0 whilst Bit 0,1 are set to 0. Bit 3 is 1 due to the not implemented NMT. Bit 4 is ignored.- Start-up capable Device, NMT Start command implementedB it0123456V alue0100000D evices that are not implementing a complete NMT Master, but shall enter Operational modeautomatically and shall transmit the 'NMT Start all Nodes' command, shall implement object 1F80H. This feature can be configured with setting Bit 2 to 0 whilst Bit 0,3 are set to 0 and Bit 1 to 1. Bit 4 is ignored.。
CANopen综合开发方案
CANopen协议综合开发方案（V3.1）中国单片机公共实验室2006年7月关于CANopenCANopen协议集定义了基于CAN的分布式工业自动化系统的应用标准以及CAN应用层通信标准。
CANopen是CAN-in-Automation(CiA)定义的标准之一，并且在发布后不久就获得了广泛的承认。
尤其是在欧洲，CANopen被认为是在基于CAN的工业系统中占领导地位的标准。
CANopen协议集基于所谓的“通信子集”，该子集规定了基本的通信机制及其特性。
大多数重要的设备类型，例如数字和模拟的输入输出模块，驱动设备，操作设备，控制器，可编程控制器或编码器，都在称为“设备子集”的协议中进行描述。
设备子集定义了不同类型的标准设备及其相应的功能。
依靠CANopen协议集的支持，可以对不同厂商的设备通过总线进行配置和系统重构。
CANopen标准最核心的部分是通过对象字典（Object Dictionary）对设备功能进行描述。
对象字典分为两部分，第一部分包括基本的设备信息，例如设备ID，制造商，通信参数等等。
第二部分描述了特殊的设备功能。
一个16位的索引和一个8位的子索引唯一确定了对象字典的入口。
通过对象字典的入口可以对设备的“应用对象”进行基本网络访问，设备的“应用对象”可以是输入输出信号，设备参数，设备功能和网络变量等等。
CANopen设备的功能及特性以电子数据单（EDS）的形式描述，EDS采用ASCII格式，可以将EDS理解成某种形式的表格。
实际的设备设置通过所谓的设备配置文件（DCF）进行描述。
EDS和DCF都可以从Internet上下载，并可以存储在设备之中。
象其他知名的现场总线系统一样，CANopen也分为两种基本的数据传输机制：通过进程数据对象（PDO）对小型的数据进行高速数据交换以及通过服务数据对象（SDO）对对象字典进行访问。
后者主要用于在设备配置过程中传输参数以及传输大数据块。
进程数据对象通常采用事件触发、循环或请求方式发送，作为广播对象，它的上层并没有附加协议。
CANopen绝对值编码器
CANopen绝对值编码器
佚名
【期刊名称】《《现代制造》》
【年(卷),期】2009(000)029
【摘要】CANopen绝对值编码器采用高速CANopen总线协议，最高可达1M
的位速率；符合CiA DS301协议及DS406编码器专用协议，向下兼容CAN接口底层协议支持NMT节点保护（Node Guarding）或心跳报文（Heartbeat），NMT主节点可以检查每个节点当前的状态，关闭错误节；点支持LSS层设置（CIA DSP305），方便更改位速率和节点号；多主兼容系统，冗余的控制器备份，防止意外发生；强悍的纠错能力，系统稳定运行的保障；
【总页数】1页(P60)
【正文语种】中文
【中图分类】TP336
【相关文献】
1.CANopen芯片安全性应用CANopen安全性芯片CSC01和CSC02 [J],
2.风电变流器设备CANopen通信的快速实现——基于CANopen协议的XGate-COP10应用 [J],
3.倾角传感器CANopen通信的快速实现——基于CANopen协议的XGate-COP10应用 [J],
4.轨道交通CANopen通信的快速实现——基于CANopen协议的XGate-
COP10应用 [J],
5.基于CAN总线的CANopen协议讲座(12) 如何快速实现CANopen网络的组建与配置——基于CANopen协议的通信网络 [J],
因版权原因，仅展示原文概要，查看原文内容请购买。
CANopen协议应用指南
Protocol Layer Interactions
协议层交互
发送设备
CANopen Application
Layer
CAN Data Link Layer
CAN Physical Layer
Object at Index
ID + Data ... ID + data
CAN_L CAN_H CAN_L
Mini Style Connector
5-pin Mini Style Connector : ANSI/B93.55M-1981
male 3
female 3
4
22
4
5
11
5
If 5-pin Mini Style Connectors are used the following pinning applies:
Data Link Layer and High-Speed Transceiver (ISO 11898)
BBiti-t-TTimimininggaannddCCoonnnneecctotorrPPinin--AAssssigignnmmeenntt
bus lines
Ó CiA
CANopen通讯概念可以类似ISO Open Systems Interconnection (OSI) Reference Model描述. CANopen描述了一种标准化应用层和通讯协议。用于可编程设备的可选框架规定了额外的通讯功 能。
Open Style Connector
Open Style Connector
female
male 12345
123 4 5
If Open Style Connectors are used the following pinning is recommended:
零差云控 eDriver CANopen 通信应用手册说明书
CAN及CANOPEN协议解析
CAN及 CANOPEN协议
zspking
目录
CAN与CANopen协议介绍； ❖ CAN协议简单介绍； ❖ CANopen协议介绍； ❖ CANopen对象词典； ❖ CANopen通讯机制； ❖ CANopen通讯对象；
❖
CAN与CANopen协议介绍
CAN及CANopen简介
CAN（Controller Area Network ）， 1986年 由Robert Bosch 公司 （德国博世）推出的一 种现场总线。包含物理层与数据链路层。 ❖ CANopen，CANopen是由Bosch公司提出并 规范化，最后移交给CIA组织并在1995年发 表，规定了CAN应用层。定义CAN报文中的 11/29位标识符、8字节数据的使用。
索引对象0x0000未使用0x00010x001f标准数据类型booleaninteger8等0x00200x003f复杂数据类型pdo通讯参数映射参数等结构体0x00400x005f制造商规定的复杂数据类型0x00600x007f设备子协议规定的标准数据类型0x00800x009f设备子协议规定的复杂数据类型0x00a00x0fff保留0x10000x1fff通讯子协议区域同步pdosdo描述等cia301中规定的内容0x20000x5fff制造商特定子协议区域0x60000x9fff设备子协议区域cia401cia402等设备子协议中的参数描述0xa0000xffff保留对象词典具体语法结构可参考ds306举例1003subnumber2parameternamepredefinederrorfieldobjecttype81003sub0parameternamenumbererrorsobjecttype0x7datatype0x0005accesstyperodefaultvalue0x1pdomapping01003sub1parameternamestandarderrorfieldobjecttype0x7datatype0x0007accesstyperodefaultvalue0x0pdomapping0返回canopen通讯机制具体通讯描述canopen网络的通信和管理都是通过不同的通信对象来完成的为了能够实现通信网络管理紧急情况处理等功能canopen规范定义了四类标准的通信对象
基于CAN总线的冗余系统方案
基于CAN总线的冗余系统方案 (1)1.冗余CAN总线系统的基本方案 (1)2.CiA 304:安全相关通信的CANopen框架 (2)2.1 简介 (2)2.2 安全相关通信机制 (3)2.3 硬件结构 (4)3.CiA 307:海事电子的CANopen框架 (5)3.1 简介 (5)3.2 硬件结构 (5)3.3 软件架构 (7)3.4 Flying NMT master (7)3.5 冗余通信机制 (8)4.CANaerospace: CAN在航电系统的应用层协议 (10)4.1 简介 (10)4.2 冗余消息ID分配 (10)4.3 系统冗余 (11)5.结论 (12)6.参考文献 (12)基于CAN 总线的冗余系统方案潘凯, 2007-03-01作为工业现场总线的一种，与其他的通信总线相比，CAN 总线具有突出的可靠性、实时性和灵活性。
目前，CAN 总线不仅在汽车领域，而且在电梯、消费电子、船舶、工程机械等自动化领域，甚至是航空航天领域得到了广泛的应用。
在某些领域，对安全性要求比较高，系统是安全相关（safety related ）的。
为了满足一定的安全级别，需要使用系统冗余机制。
由于CAN 总线一开始并不是针对安全领域开发的，它对系统冗余的支持具有一定的不足。
为了在安全相关系统中使用CAN 总线，就必须建立相应的对系统冗余的支持机制。
本文研究了几种支持系统冗余的CAN 总线高层协议（CANopen CiA 304，CiA 307，CANaerospace ），介绍了这些高层协议实现CAN 冗余的主要原理，总结了在CAN 总线网络中实现系统冗余的基本方案。
1. 冗余CAN 总线系统的基本方案(1). 软件冗余 (2). 硬件冗余 (3). 总线冗余图1 几种冗余CAN 总线系统的拓扑结构在CAN 总线系统中实现冗余有三种基本方案。
方案一为软件冗余。
该方案在不改变CAN 节点任何硬件结构的条件下即可实现，如图1-(1)所示。
嵌入式网络Canopen协议
由于其高可靠性和实时性的特点,CAN总线能够满足系统高性能的要求,已经深入到各个行业,例如专业车辆、工业控制、医辽器械、海事应用等。
CAN的标准协议 CAN2.0协议和国际标准 ISO11898是设计 CAN 应用系统的基本依据,但它们只是定义了物理层和数据链路层,没有对应用层进一步规范,本身并不完善,需要一个更开放的、标准化的高层协议来定义 CAN报文中的标识符和字节数据。
在此背景下,由 CiA(CANin Automation)组织监督开发了CANOpen高层协议。
在 2002年,已经形成欧洲标准 EN50325-4。
CANOpen的最大优点之一就是实现较为简单。
CANOpen协议是基于 CAN串行总线系统和应用层 CAL的高层协议,也是一种针对于行业的标准化的协议。
CANOpen协议为分布式控制及嵌入式系统的应用提供了必要的实现方法,主要提供:(1)不同 CAN设备间的互操作性、互换性。
(2)标准化、统一的系统通讯模式。
(3)设备描述方式和网络功能。
(4)网络节点功能的任意扩展。
CANOpen协议以通讯规范 CiA DS-301为基础,规定了一系列的设备规范,如 CiA DSP-401,CiA DSP-404等,从而提供了配置通讯参数和数据的方王俊波:博士研究生本工作得到国家自然科学基金重点项目(60334010),国家自然科学基金项目(60474047)高等学校博士学科点专项基金项目(20030561013)以及广东省自然科学基金项目(31406)的资助法,规定了设备间的通讯及特定设备间的特定行为(如数字 I/O、模拟 I/O、RS485通讯等),并定义了标准化的应用对象、基本功能以及网络功能。
CANOpen协议采用对象字典(OD)、电子数据文档(EDS)等一系列概念来描述设备和协议的相关信息,还规定了服务数据对象(SDO)、过程数据对象 PDO、网络管理等多种通讯机制。
在本文中,主要是对对象字典、服务数据对象(SDO)、过程数据对象(PDO)进行了简要的分析。
CANopen芯片_uChip
CANopen µChip – Fact sheetOverviewThe CANopen µChip is a tiny yet cost effective single Chip CANopen IO. The CANopen µChip features various IO configurations including digital and analogue inputs and outputs.All inputs and outputs are accessible via the CANopen protocol, which is implemented in the pre-programmed firmware of the module. Thus the CANopen µChip can be used in a wide field of application.The CANopen µChip implements a CANopen slave device according CANopen device profile DS401 and CANopen communication profile DS301 V4.02.Two LED-ports indicate the device state according to DR-303-3 V1.0. CANopen features: • Communication profile according to CiA standard DS301 in version V4.02• Device profile according to CiA standard DSP401• State indicators according to CiA standard DR-303-3 V1.0• Layer Setting Service (LSS) according to CiA standard DSP305 • 4 TPDO and 4 RPDO• Dynamic PDO-Linking and –Mapping • 2 SDO-Server• Life guarding, Node guarding, Heartbeat • 5 Heartbeat Consumers • Emergency Producer• Minimum Boot Up capability• Manufacturer extension for usage as NMT-boot masterDevice specification: • Operating voltage: 5V ±10%• Current consumption: typically 30mA• storage of configuration data on Non-volatile memory (provided by customer)• predefined pins for easy configuration of node ID, baud rate and IO configuration (e.g. by a DIP-switch)• Seven different IO configurations on 28 IO pins, selectable via portpins and Object Dictionary • Digital outputs:GND < L-level < 0.4V 4.5V < H-level < VCC • Digital inputs:GND – 0.3V < L-level < 0.8V0.8 • VCC < H-level < VCC + 0.3V • Analogue inputs: Input voltage: VAGND … VREFLogical resolution: 15-bit signed (OD value) Physical resolution: 10-bit (see manual) Input capacity: 10.7pFReference voltage: +2.7V ... VCC • PWM outputs:See digital outputs for detailsPWM frequency: max. 21kHz (CAN>10kBit) PWM frequency: max. 11,5kHz (CAN=10kBit) • CAN-bus baud rate: 10kBit/s to 1Mbit/s • Operating temperature: -40°C to +85°C • Storage temperature: -40°C to +90°C • Package: 64-pin Plastic LQFPpredefined Pins for Chip-configuration4 bit Node ID:Allows for configuration of node ID from 40H ... 4EH The node ID is derived from the pin setting by: 40H + 1*DIP1 + 2*DIP2 + 4*DIP3 + 8*DIP4Setting the value 0xF causes a reset to factory settings when the modules get reset. The full range of node ID is configurable via LSS only.2 bit Baud rate:Selectable via pins: 0 = 125kBit/s 1 = 20kBit/s 2 = 500kBit/s 3 = 1000kBit/sThe full range of baud rate is configurable via LSS only.2 bit IO configuration:Selectable via pins is IO configuration 0 to 3.Additionally all IO configurations are selectable via OD entry on index 2000H in manufacturer specific section.Device pinout and IO configurationsPin 0 1 2 3 4 5 6 Configuration DI DO AI PWM1 VAGND ground signal for reference voltage 0 14 82 42 VREF reference voltage des AD-Wandlers 1 8 8 8 43 DI 0 AI 2 DI 2 DI 2 AI 2 DI 2 AI 2 2 16 8 - 44 DI 1 AI 3 DI 3 DI 3 AI 3 DI 3 AI 3 3 8 16 - 45 DI 2 AI 4 DI 4 DI 4 AI 4 DI 4 DI 2 4 16 - 8 46 DI 3 AI 5 DI 5 DI 5 AI 5 DI 5 DI 3 5 24 - - 47 DI 4 AI 6 DI 6 DI 6 AI 6 DI 6 DI 4 6 16 4 4 48 DI 13 AI 7 DI 7 DI 7 AI 7 DI 7 DI 59 DI 12 DO 4 DO 4 DO 4 DI 8 DI 16 DI 1410 DI 11 DO 5 DO 5 DO 5 DI 9 DI 17 DI 1511 DI 6 DO 6 DO 6 DO 6 DI 10 DI 18 DO 212 DI 5 DO 7 DO 7 DO 7 DI 11 DI 19 DO 313 MRST EEPROM14 MTSR EEPROM15 SCLK EEPROM16 RxDC receive signal of internal CAN-controllers, TTL-level17 TxDC transmit signal of internal CAN-controllers, TTL-level18 GND ground signal for VCC19 reserved20 reserved21 MD222 MD123 MD024 nc25 nc26 reserved27 reserved28 pin 0 for node ID29 pin 1 for node ID30 pin 2 for node ID31 pin 3 for node ID32 CS EEPROM33 reserved34 DO 4 DO 0 DO 0 DO 0 DI 12 DI 20 DI 035 DO 5 DO 1 DO 1 DO 1 DI 13 DI 21 DI 136 pin 0 for baudrate37 pin 1 for baudrate38 pin 0 for IO configuration39 pin 1 for IO configuration40 PWM 0 PWM 0 PWM 0 PWM 0 PWM 0 PWM 0 PWM 041 PWM 1 PWM 1 PWM 1 PWM 1 PWM 1 PWM 1 PWM 142 PWM 2 PWM 2 PWM 2 PWM 2 PWM 2 PWM 2 PWM 243 PWM 3 PWM 3 PWM 3 PWM 3 PWM 3 PWM 3 PWM 344 LED green45 /RESET Reset input46 XTAL147 XTAL248 GND ground signal for VCC49 VCC power supply, +5VDC50 C51 LED red52 DO 6 DO 2 DO 2 DO 2 DI 14 DI 22 DO 053 DO 7 DO 3 DO 3 DO 3 DI 15 DI 23 DO 154 DI 10 DI 0 DI 8 DO 8 DI 0 DI 8 DI 655 DI 9 DI 1 DI 9 DO 9 DI 1 DI 9 DI 756 DI 8 DI 2 DI 10 DO 10 DI 2 DI 10 DI 857 DI 7 DI 3 DI 11 DO 11 DI 3 DI 11 DI 958 DO 3 DI 4 DI 12 DO 12 DI 4 DI 12 DI 1059 DO 2 DI 5 DI 13 DO 13 DI 5 DI 13 DI 1160 DO 1 DI 6 DI 14 DO 14 DI 6 DI 14 DI 1261 DO 0 DI 7 DI 15 DO 15 DI 7 DI 15 DI 13 DI Digital Input62 AI 0 AI 0 DI 0 DI 0 AI 0 DI 0 AI 0 DO Digital Output63 AI 1 AI 1 DI 1 DI 1 AI 1 DI 1 AI 1 AI Analogue Input64 AVCC power supply, +5VDC PWM PWM OutputPDO MappingThe following table show the default PDO-mapping of the CANopen ChipF40 for each IO configuration.Due to the different IO signals available, the available PDO depends on IO configuration. Thus, some PDO might be set invalid if not used. The PDO-mapping and linking can be changed dynamically by use of a standatd CANopen configuration tool. The configuration can be saved to non-volatile memory and thus is available after restart.ID Lengh BYTE 0 BYTE 1 BYTE 2 BYTE 3 BYTE 4 BYTE 5 BYTE 6 BYTE 7 configuration 01. RPDO 200H+NodeID 1 DO0_76200H/13. RPDO 400H+NodeID 8 Pulse PWM06500H/1Pulse PWM16500H/2Pulse PWM26500H/3Pulse PWM36500H/41. TPDO 180H+NodeID 2 DI0_76000H/1DI8_156000H/22. TPDO 280H+NodeID 4 AI06401H/1AI16401H/2configuration 11. RPDO 200H+NodeID 1 DO0_76200H/13. RPDO 400H+NodeID 8 Pulse PWM06500H/1Pulse PWM16500H/2Pulse PWM26500H/3Pulse PWM36500H/41. TPDO 180H+NodeID 1 DI0_76000H/12. TPDO 280H+NodeID 8 AI06401H/1AI16401H/2AI26401H/3AI36401H/43. TPDO 380H+NodeID 8 AI46401H/5AI56401H/6AI66401H/7AI76401H/8configuration 21. RPDO 200H+NodeID 1 DO0_76200H/13. RPDO 400H+NodeID 8 Pulse PWM06500H/1Pulse PWM16500H/2Pulse PWM26500H/3Pulse PWM36500H/41. TPDO 180H+NodeID 2 DI0_76000H/1DI8_156000H/2configuration 31. RPDO 200H+NodeID 2 DO0_76200H/1DO8_156200H/23. RPDO 400H+NodeID 8 Pulse PWM06500H/1Pulse PWM16500H/2Pulse PWM26500H/3Pulse PWM36500H/41. TPDO 180H+NodeID 1 DI0_76000H/1Konfiguration 43. RPDO 400H+NodeID 8 Pulse PWM06500H/1Pulse PWM16500H/2Pulse PWM26500H/3Pulse PWM36500H/41. TPDO 180H+NodeID 2 DI0_76000H/1DI8_156000H/22. TPDO 280H+NodeID 8 AI06401H/1AI16401H/2AI26401H/3AI36401H/43. TPDO 380H+NodeID 8 AI46401H/5AI56401H/6AI66401H/7AI76401H/8configuration 53. RPDO 400H+NodeID 8 Pulse PWM06500H/1Pulse PWM16500H/2Pulse PWM26500H/3Pulse PWM36500H/41. TPDO 180H+NodeID 3 DI0_76000H/1DI8_156000H/2DI16_236000H/3configuration 61. RPDO 200H+NodeID 1 DO0_76200H/13. RPDO 400H+NodeID 8 Pulse PWM06500H/1Pulse PWM16500H/2Pulse PWM26500H/3Pulse PWM36500H/41. TPDO 180H+NodeID 2 DI0_76000H/1DI8_156000H/22. TPDO 280H+NodeID 8 AI06401H/1AI16401H/2AI26401H/3AI36401H/4Object DictionaryIndex Object NameData type Object is mappableObject gets saved via 1010H Object gets Restored via 1011H1000H Var Device type number Unsigned32 - - - 1001H Var Error Register Unsigned8 - - - 1003H Array Error MeldungUnsigned32 - auto w 0 auf Sub0 1005H Var Identifier SYNC-Message Unsigned32 - x x 1007H Var SYNC window length Unsigned32 - x x 1008H Var Device description String - - - 1009H Var Hardware Version String - - - 100AH Var Software Version String- - - 100CH Var Guard Time Unsigned16 - x x 100DH Var Life Time Factor Unsigned8 - x x 1010H Array User-Parameter save Unsigned32 - - - 1011H Array Default-Parameter reload Unsigned32 - - - 1014H Var Identifier EmergencyUnsigned32 - x x 1016H Array Consumer Heartbeat Time Unsigned32 - x x 1017H Var Producer Heartbeat Time Unsigned16 - x x 1018H Record Identity Object Identity - - - 1029H Array Error BehaviourUnsigned8 - x x 1200H Record 1st Server SDO Parameter SDO Parameter - - - 1201H Record 2nd Server SDO ParameterSDO Parameter - x x 1400H Record RPDO1 Communication parameter PDOComPar - x x 1401H Record RPDO2 Communication parameter PDOComPar - x x 1402H Record RPDO3 Communication parameter PDOComPar - x x 1403H Record RPDO4 Communication parameter PDOComPar - x x 1600H Record RPDO1 Mapping parameter PDOMapping - x x 1601H Record RPDO2 Mapping parameter PDOMapping - x x 1602H Record RPDO3 Mapping parameter PDOMapping - x x 1603H Record RPDO4 Mapping parameterPDOMapping - x x 1800H Record TPDO1 Communication parameter PDOComPar - x x 1801H Record TPDO2 Communication parameter PDOComPar - x x 1802H Record TPDO3 Communication parameter PDOComPar - x x 1803H Record TPDO4 Communication parameter PDOComPar - x x 1A00H Record TPD01 Mapping parameter PDOMapping - x x 1A01H Record TPD02 Mapping parameter PDOMapping - x x 1A02H Record TPD03 Mapping parameter PDOMapping - x x 1A03H Record TPD04 Mapping parameter PDOMapping - x x 2000H Var I/O ConfigurationUnsigned8 - auto Zugriff DIP 0FH 2001H Var NMT-Boot-Configuration Unsigned8 - auto Zugriff DIP 0FH6000H Array PDO Digital Input 1 Unsigned8 x - - 6200H Array PDO Digital Output 1Unsigned8 x - - 6206H Array Error Mode Digital Output 1 Unsigned8 - x x 6207H Array Error State Digital Output 1 Unsigned8 - x x 6401H Record PDO Analog Input 1Integer16 x - - 6421H Array Interrupt Trigger Selection 1 Unsigned8 - x x 6422H Array Interrupt Source 1Unsigned32 x - - 6423H Var Global Interrupt Enable 1 Boolean - x x 6424H Array Interrupt upper Limit 1 Integer32 - x x 6425H Array Interrupt lower Limit 1 Integer32 - x x 6426H Record Input Interrupt Delta 1 Unsigned32 - x x 6500H Array PWM Pulse Unsigned16 x - - 6510H Array PWM PeriodUnsigned16 x x x 6543H Array PWM Output Error Mode Unsigned8 - x x 6544HArrayPWM Output Error ValueUnsigned16-x x1Availability of this object depends on IO configuration selectedSample schematics:Important!All inputs not used needs to drawn to a defined signal such as GND to avoid any flicker on these inputs and the unwanted transmission of PDO.Delivery contents / order number Manual and corresponding EDS-file. 3301001 CANopen µChipAlso available: MM-215-Y CANopen Chip164 MM-217-Y CANopen ChipF40 MM-217-V3Y CANopen ChipF40 compatible to MM-215-Y4002003 Developmentboard for CANopen ChipF40KMM-217-Y Development Kit CANopen ChipF40。
CANOpen协议家族
CANOpen协议族入门学习笔记CANOPEN 2010-11-07 16:52:57当我们使用CANOpen时，首先要明确我们CANOPEN能干什么?要用canopen干什么？怎么用canopen来干活？ CANOPEN能干什么?首先需要明确canopen各个协议的功能，兄弟我最近在学习中大概总结了一些提纲如下：canopen分为两种协议类型：1)基础题，应用层和通信层规范，主要是3xx系列的规范2)解应用题，相当于用基础科目解应用题的一些套路，4xx系列规范一般来讲，CANopen协议集定义了基于CAN的分布式工业自动化系统的应用标准以及CAN应用层通信标准。
CANopen是CAN-in-Automation(CiA)定义的标准之一，并且在发布后不久就获得了广泛的承认。
尤其是在欧洲，CANopen被认为是在基于CAN的工业系统中占领导地位的标准。
CANopen协议集基于所谓的"通信子集"，该子集规定了基本的通信机制及其特性。
cAN物理层和数据链路层协议最初开发用作客车的车载网络。
基于CAN的高层协议定义了如何根据特定的应用要求来使用CAN数据链路协议。
除专用的基于CAN的高层协议外，还有多个国际标准化协议：用于嵌入式控制系统的CANopen、用于工厂自动化的DeviceNet、用于卡车和其它车辆的基于J1939的解决方案(J1939-71、Isobus、ISO 11992、CiA 501/2)、用于客车诊断的ISO 15765。
分解学习CANOPEN基础题类的3xx，等效于课本和字典，看个大概，用的时候再翻查也不迟，反正是开卷考试。
最重要的莫过于301这个协议了，所有的应用题都是在这个基础题上的变化，国内的资料基本上都是讲解这部分，出于偷懒，我就不多讲了。
应用题类：既然是应用题，我把cia中文网站上的一些资料copy过来，作为我的纲要CiA 401: 针对通用I/O模块的设备规范CiA 402: 针对驱动装置和运动控制装置(伺服控制器、步进式电机控制器、变频器)的设备规范CiA 404: 针对测量设备和闭环回路控制器的设备规范CiA 406: 针对编码器(旋转和线性)的设备规范CiA 408: 针对比例阀和液压传动装置的设备规范CiA 410: 针对倾斜仪的设备规范CiA 412: 针对医疗设备(例如，准直仪、剂量计)的设备规范集CiA 413: 针对卡车网关的设备规范集CiA 414: 针对织机(例如，进料器)的设备规范集CiA 415: 针对筑路机械传感器的应用规范CiA 416: 针对建筑门控制系统的应用规范CiA 417: 针对电梯控制系统的应用规范CiA 418: 针对蓄电池模块的设备规范CiA 419: 针对蓄电池充电器的设备规范CiA 420: 针对挤压机下游设备的设备规范集CiA 421: 针对列车车辆控制网络(车辆子级的集成平台)的应用规范CiA 422: 针对市政车辆(例如，垃圾车)的应用规范CiA 423: 针对动力驱动系统(例如，柴油机)的应用规范CiA 424: 针对轨道车辆车门控制系统的应用规范CiA 425: 针对医疗附加设备(例如，造影剂注射器)的设备规范集CiA 426: 针对外部轨道车辆照明装置的应用规范CiA 430: 针对辅助轨道车辆设备(例如，冷却风扇、发动机预热装置)的应用规范CiA 433: 针对内部轨道车辆照明装置的应用规范CiA 444: 针对起重机附加设备(例如，延伸器)的设备规范集CiA 445: 针对RFID阅读器的设备规范CiA 446: 针对As-i网关的接口规范看来对于解决“要用canopen干什么？”和“怎么用canopen来干活？”就需要根据具体的应用题来选择这些套路了。
值得收藏：德国工程师的CANopen备忘录
值得收藏：德国工程师的CANopen备忘录摘要CiA国际用户与制造商联合组织聚集多年经验及专业知识，将CANopen协议的核心重点集于一张图表，帮助工程师在写协议和现场调试时，可以一目了然，抓住重点。
广州致远电子股份有限公司作为CIA会员，获CiA唯一授权，出版中文版CANopen图表。
德国的CAN-bus总线工程师为了方便学习和记忆CANopen协议，随身携带一本“CANopen 备忘录”，在研发和现场测试时快速查找。
春节期间，广州致远电子股份有限公司将其翻译成中文，推动国内CANopen发展。
值得收藏！1.1 Object dictionary(OD)对象字典1.1.1 Overview概述1.1.2 Communication profile area通讯对象子协议区1.1.3 General communication objects通用通讯对象1.2 Pre-defined CAN-IDs预定义CAN标识符1.3 Network management(NMT)网络管理1.4 Service data object(SDO)服务数据对象1.4.1 communication principle(通讯原则)1.4.2 Expedited SDO protocol(快速SDO协议)1.4.3 Normal SDO protocol(普通SDO协议)1. 下载协议download protocol2. 上传协议upload protocol1.5 Process data object(PDO)过程数据对象RPDO通讯参数1400h to 15FF h映射参数1600h to 17FF h数据存放为2000h之后厂商自定义TPDO通讯参数1800h to 19FF h映射参数1A00h to 1BFF h数据存放为2000h之后厂商自定义CAN transmission( CAN发送报文)TPDO1（CAN-ID see 1800h 01h） Data field：数据域1.6 Special protocols（特殊协议）1.6.1 同步协议Sync protocol1.6.2 Time-stamp protocol（时间戳协议）1.6.3 Emergency protocol（紧急报文协议）1.6.4 Emergency error codes（紧急报文错误代码）。
canopen和devicenet比较
CAN总线以其成本低廉、通信实时性好、纠错能力强等优点而被汽车工业、电力系统变电站自动化、智能大厦等系统广泛采用。
作为一种通信协议，CAN本身并未指出流量控制、节点地址分配、通信建立、设备连接标准等具体的细则。
后来在CAN总线协议的基础上，产生了DeviceNET和CANopen协议标准。
1 CANopen简介1.1 CANopen由来1993年，Bosch公司领导的CAN-BUS协会开始研究CAN-BUS通讯、系统、管理方面的细则，以后逐步完善，由此发展成为CANopen协议，它是CAL(CAN Application Layer)协议基础上开发的，使用了CAL通信和服务协议子集，它在保证网络节点互用性的同时允许节点的功能随意扩展，定义了基于CAN的分布式工业自动化系统的应用标准以及CAN应用层通信标准。
CANopen协议是一个开放性的协议，对于开发者来说它是完全免费的。
CANopen在发布后不久就获得了广泛的承认，后来，有CiA(CAN in Automation)协会管理、维护、和发展。
到2001年，CANopen协议已经成为全欧洲的嵌入式网络标准。
1.2 CANopen协议剖析1.2.1 网络模型CANopen协议的物理层和数据链路层延用了CAL(CAN Application Layer)协议标准，一个网段上最多支持127个节点，采用CAN 收发器芯片，支持CAN2.0和CAN2.0B帧格式收发。
并在CiA DS303-1指出了电缆和接点标准，在CiA DS-304中指出了接点保护的规范，即总线要有安全开关、光电隔离、紧急开关、电源保护等。
CANopen把CAN的11位标识符分成2部分，及4位功能码和7个操作数据类型，如图1所示。
具体分配如表1所示。
图1 canopen COB-ID表1 CANopen标识符的分配表功能段地址段0000 NMT 系统管理0001 SYNC同步标记0011 PD0(tx)过程数据对象发送包0100 PD0(rx)过程数据对象接收包1011 SDO(tx)服务数据的发送包1100 SD0(rx)服务数据的接收包如果是29位的标识符机制，可以把现有的11标识符的定义映射到29位的COB-ID的高11位，使表中的C0B-ID的范围变的更大。
CANopen概念_080321_cia
第一部分CAN和CANopen的概念一、CAN和CANopen简介CAN总线全称为Controller Area Network 即控制器局域网是国际上应用最广泛的现场总线之一，已经在汽车制造、机械制造、包装机械、烟草等行业得到了广泛的应用。
CAN总线是德国BOSCH公司从80年代初为解决现代汽车中众多的控制与测试仪器之间的数据交换而开发的一种串行数据通信协议，它是一种多主总线，通信介质可以是双绞线、同轴电缆或光导纤维。
通信速率可达1MBPS。
CAN总线通信接口中集成了CAN 协议的物理层和数据链路层功能，可完成对通信数据的成帧处理，包括位填充、数据块编码、循环冗余检验、优先级判别等项工作。
CAN协议的一个最大特点是废除了传统的站地址编码，而代之以对通信数据块进行编码。
采用这种方法的优点可使网络内的节点个数在理论上不受限制，数据块的标识码可由11位或29位二进制数组成，因此可以定义211或229个不同的数据块，这种按数据块编码的方式，还可使不同的节点同时接收到相同的数据，这一点在分布式控制系统中非常有用。
数据段长度最多为8个字节，可满足通常工业领域中控制命令、工作状态及测试数据的一般要求。
同时，8个字节不会占用总线时间过长，从而保证了通信的实时性。
CAN协议采用CRC检验并可提供相应的错误处理功能，保证了数据通信的可靠性。
CAN卓越的特性、极高的可靠性和独特的设计，特别适合工业过程监控设备的互连，因此，越来越受到工业界的重视，并已公认为最有前途的现场总线之一。
另外，CAN总线采用了多主竞争式总线结构，具有多主站运行和分散仲裁的串行总线以及广播通信的特点。
CAN总线上任意节点可在任意时刻主动地向网络上其它节点发送信息而不分主次，因此可在各节点之间实现自由通信。
CAN总线协议已被国际标准化组织认证，技术比较成熟，控制的芯片已经商品化，性价比高，特别适用于分布式测控系统之间的数通讯。
CAN总线插卡可以任意插在PC、AT、XT兼容机上，方便地构成分布式监控系统。
CANopen
CANopenoverviewCANopen is a CAN-based higher layer protocol. It was developed as a standardized embedded network with highly flexible configuration capabilities. CANopen was designed for motion-oriented machine control networks, such as handling systems. By now it is used in many various fields, such as medical equipment, off-road vehicles, maritime electronics, public transportation, building automation, etc.CANopen was pre-developed in an Esprit project under the chairmanship of Bosch. In 1995, the CANopen specification was handed over to the CAN in Automation (CiA) international users′ and manufacturers ′ group. Originally, the CANopen communication profile was based on the CAN Application Layer (CAL) protocol. Version 4 of CANopen (CiA DS 301) is standardized as EN 50325-4.The CANopen specifications cover application layer and communication profile (CiA DS 301), as well as a framework for programmable devices (CiA 302), recommendations for cables and connectors (CiA 303-1) and SI units and prefix representations (CiA 303-2). The application-layer as well as the CAN-based profiles are implemented in software.Standardized profiles (device, interface and application profiles) developed by CiA members simplify the system designer job of integrating a CANopen network system. Off-the-shelf devices, tools, and protocol stacks are widely available at reasonable prices. For system designers, it is very important to reuse application software. This requires not only communication compatibility, but also interoperability and interchangeability of devices. In the CANopen device and interface profiles, defined application objects exist to achieve the interchangeability of CANopen devices. CANopen is flexible and open enough to enable manufacturer-specific functionality in devices, which can be added to the generic functionality described in the profiles.CANopen unburdens the developer from dealing with CAN-specific details such as bit-timing and implementation-specific functions. It provides standardized communication objects for real-time data (Process Data Objects, PDO), configuration data (Service Data Objects, SDO), and special functions (Time Stamp, Sync message, and Emergency message) as well as network management data (Boot-up message, NMT message, and Error Control).The CANopen specifications, frameworks, and profiles can be downloaded. CiA provides some CANopen specifications free-of-charge for the public. This includes all specifications with the status ?draft standard (DS)?. The CANopen specifications with the status ?draft standard proposal (DSP)? or ?work draft (WD)? are available only for CiA members. The responsible CANopen Special Interest Group (SIG) decides, when the specification will be handed over to the CANopen Interest Group (IG) for publication.In order to download a DSP or WD, you have to become a member of CAN in Automation. Members contribute to the development of specifications by their active participation and their membership fee,without which the non-profit international user and manufacturer group would not exist. Thus member receive the priviledge of influencing technical data of specifications and have a time advantage over non-members when implementing them.CANopen Communication Conceptz CANopen Reference Modelz Protocol Layer InteractionsReference ModelThe CANopen communication concept can be described similar to the ISO Open Systems Interconnection (OSI) Reference Model. CANopen represents a standardized application layer and communication profile. The optional framework for programmable devices specifies additional communication functionality. CANopen is based on the CAN data link layer and high-speed transceiver as specified in ISO 11898, part 1 and part 2. In addition, CANopen specifies bit-timing and recommends pin-assignments for some connectors.The standardized device profiles, interface profiles, and application profiles describes the default behavior and the optional functionality of devices, interfaces, and applications.Protocol Layer InteractionsThe protocol layer interactions describe the communication on the different layers. On the CANopen application layer the devices exchanges communication and application objects. All these objects are accessible via a 16-bit index and ′8-bit sub-index.These communication objects (COB) are mapped to one or more CAN frames with pre-defined or configured Identifiers. The CAN physical layer specifies the bit level including the bit-timing.CANopen Timingz Bit-Timing Specificationz Bit-Timing (2)Bit-Timing SpecificationAt a bitrate of 1 Mbit/s the bit consists out of 8 time quanta, at 800 kbit/s out of 10 time quanta and from 500 kbit/s to 10 kbit/s out of 16 time quanta. CANopen uses single sampling mode only.Bit-Timing (2)Every module has to support one of the specified bit rates. The rounded bus length estimation (worst case) on basis 5 ns/m propagation delay and a total effective device-internal in-out delay is as follows:1M - 800 kbit/s: 210 ns500 - 200 kbit/s: 300 ns (includes 2 x 40 ns for optocouplers)125 kbit/s: 450 ns (includes 2 x 100 ns for optocouplers)50 - 10 kbit/s: 1,5 time quanta; effective delay = delayrecessive to dominant plus dominant to recessive divided by two.For bus length greater than about 200 m the use of optocouplers is recommended. For bus length greater than about 1 km bridge or repeater devices may be needed.CANopen Physical Layer Definitionz Pin Assignmentz Mini Style connectorz Open Style connectorPin AssignmentThe physical medium for CANopen devices is a differentially driven two-wire bus line with common return according to ISO 11898.The CiA DRP-303-1 CANopen recommendation defines the pinning of the 9-pin D-sub connector (DIN 41652 or corresponding international standard), the 5-pin mini style connector, the open style connector, the multi-pole connector, and other connectors. The 9-pin D-Sub connector pinning complies to CiA DS-102.Device ModelA CANopen device can be divided into three parts:communication interface and protocol softwareobject dictionaryprocess interface and application programThe communication interface and protocol software provide services to transmit and to receive communication objects over the bus. The object dictionary describes all data types, communication objects and application objects used in this device. It is the interface to the application software. The application program provides the internal control functionality as well as the interface to the process hardware interfaces.Object Dictionary LayoutThe most important part of a CANopen device is the object dictionary. The object dictionary is essentially a grouping of objects accessible via the network in an ordered pre-defined fashion. Each object within the dictionary is addressed using a 16-bit index and an 8-bit sub-index.The overall layout of the standard object dictionary conforms with other industrial fieldbus concepts.The object dictionary concept caters for optional device features, which means a manufacturer does not have to provide certain extended functionality on his devices but if he wishes to do so he must do it in a pre-defined fashion.By defining object dictionary entries for anticipated increased functionality in an optional category manufacturers wishing to implement enhanced functionality will all do so in the same way.Data Types (1)The static data types are placed in the object dictionary for definition purposes. Data of basic type BOOLEAN attains the values TRUE or FALSE. Data of basic type INTEGERn has values in the integers. The value range is -2n-1, ..., 2n-1-1 (bit sequences of length n). Data of basic type UNSIGNEDn has values in the non-negative integers. The value range is 0, ..., 2n-1-1 (bit sequences of length n). Data of basic type FLOAT has values in the real numbers.The data type VISIBLE STRING is described in the following syntax of data and data type definitions: Unsigmed8 - Visible Char, Array of Visible Char - Visible String. The admissible values of data of typeVisible Char are 0h and the range from 20h to 7Eh.The data type OCTET STRING is described in the following syntax of data and data type definitions: Array of Unsigned8 - Octet String.The data type DATE is defined as bit sequences of length 56 including ms, min, hour, standard or summer time, day of month, day of week, month, year and some reserved values.The data type TIME OF DAY represents absolute time including time in ms after midnight and number of days since January 1st, 1984.The data type TIME DIFFERENCS represents a time difference as sum of days and ms.Data Types (2)CANopen specifies some predefined complex data types for PDO and SDO parameters. In addition, the object dictionary reserves entries for device-specific standard and complex data types. For devices or device profiles that provide Multiple Device Modules like multiple axis controllers each virtual devicemay use its own data types.Object DescriptionThe Object Code must be one of those defined by the CANopen specification. For simple variables the attribute description appears once without the sub-index field and entry category. For complex data types the attribute description must be defined for each element (sub-index).Entry DescriptionObject Dictionary EntryA 16-bit index is used to address all entries within the object dictionary. In case of a simple variable this references the value of this variable directly. In case of records and arrays however, the index addresses the whole data structure.For complex object dictionary entries such as arrays or records with multiple data fields the sub-index references fields within a data-structure pointed to by the main index.For example on a single channel RS-232 interface module there may exist a data-structure at index 6092h which defines the communication parameters for that module. This structure may contain fields for baud-rate, number of data bits, number of stop bits and parity type. The sub-index concept can be used to access these individual fields as shown above. To allow individual elements of structures of data to be accessed via the network a sub-index has been defined. The value for the sub-index is always zero.Communication ObjectsError RegisterIf a bit is set to 1 the specified error has occurred. The only mandatory error that has to be signaled is the generic error. The generic error is signaled at any error situation.The object 1001h is an error register for the device. The device can map internal errors in this byte. This entry is mandatory for all devices. It is a part of the Emergency object.Identity ObjectThe mandatory Identity Object at index 1018h contains general information about the virtual device. The Vendor ID is a numeric value of type Unsigned32 and will consist of a unique number for each registered company and may be a unique number for each department of that company (only if required). The allocation of the Vendor ID is handled by CiA Headquarters. Both parts of the Vendor ID must be registered by CiA and will cause an administrative costs of 128 EUR + German V AT. For Cia Members this service is free of charge.The manufacturer-specific Product code identifies a specific device version. The manufacturer-specific Revision number consists of a major revision number (identifies a specific CANopen behavior) and a minor revision number (identifies different versions of the same CANopen behavior). If the CANopen functionality is expanded, the major revision number has to be increased.Communication ProtocolsProcess Data Objects (PDO) ProtocolService Data Object (SDO) ProtocolsSpecial Object Protocols:Synchronization (SYNC) ProtocolTime Stamp ProtocolEmergency (EMCY) ProtocolNetwork Management Protocols:NMT Message ProtocolBoot-Up ProtocolError Control ProtocolCANopen communication objects transmitted via the CAN network are described by the services and protocols. They are classified as follows:The real-time data transfer is performed by the Process Data Objects (PDOs) protocol.With Service Data Objects (SDOs) protocols the read and write access to entries of a device object dictionary is provided.Special Function Object protocols provide application-specific network synchronization, time stamping and emergency message transmissions.The Network Management (NMT) protocols provide services for network initialization, error control and device status control.Producer/Consumer ModelThe Producer/Consumer model describes perfectly the CAN broadcast communication capability. Each station of the network can listen to the messages of the transmitting station. After receiving the message it is the task of every node to decide if the message has to be accepted or not. So Acceptance Filtering has to be implemented in a CAN node.The CAN broadcast communication is similar with a radio station transmitting information about traffic jam for vehicle drivers. Every driver has to decide if the messages are important for him depending on the direction he wants to go.The Producer/Consumer model allows to services: to transmit a messages (push model) or to request a message (pull model).Client/Server ModelIn the classical Client/Server model the client transmits a messages, which will be responded by the server, so that the client get a confirmation. That is like to give an order, which must be confirmed, so that you know the order was understood.The Client/Server model is used to transfer data longer than 8 byte. Therefore the original data to be transmitted is segmented and sent segment for segment on the same identifier. Each or a group of segments or the total message will be confirmed by the receiver. So this is a peer-to-peer communication. The services on this client/server transmission may include up- and download as well as transfer abort.Master/Slave ModelThe Master/Slave model allows only a communication initiated by the master, The slave has always to wait for the master′s communication requests. This is like in the army: the soldier will get orders and he has only to speak after permission.In CAN-based networks master/slave communication can be implemented by an appropriate identifier allocation. Unconfirmed Master/slave communication allows also broadcasting.Process Data ObjectPDO communication can be described by the producer/consumer model. Process data can be transmitted from one device (producer) to one another device (consumer) or to many other devices (broadcasting). PDOs are transmitted in a non-confirmed mode.The producer sends a Transmit-PDO (T_P.DO) with a specific identifier, which corresponds to the identifier of the Receive-PDO (R_PDO) of one or more consumers.PDO ProtocolThere are two PDO services: to write a PDO and to read a PDO.The Write-PDO is mapped to a single CAN Data frame. The Read-PDO is mapped to CAN Remote Frame, which will be responded by the corresponding CAN Data Frame. Read-PDOs are optional and depending on the device capability.The complete data field of up to 8 byte may contain process data. Number and length of PDOs of a device are application-specific and have to be specified in the device profile.The PDOs correspond to entries in the Object Dictionary and provide the interface to application objects. Data type and mapping of application objects into a PDO is determined by a corresponding default PDO mapping structure within the Object Dictionary. This structure is defined in the entries 1600h for the 1st R_PDO and 1A00h for the first T_PDO. In one CANopen network there can be used up to 512 T_PDOs and 512 R_PDOs.PDO Scheduling ModesThe CANopen communication profile distinguishes three message triggering modes:1.Message transmission is triggered by the occurrence of an object specific-event specified in thedevice profile. Periodically transmitting nodes are triggered additionally by elapsed timer even if no event has occurred.2.The transmission of asynchronous PDOs may be initiated on receipt of a remote request initiated byanother device.3.Synchronous PDOs are triggered by the expiration of a specified transmission period synchronized bythe reception of the SYNC object.Synchronous PDOCANopen distinguishes the following transmission modes:synchronous transmission,asynchronous transmission.Synchronous PDOs are transmitted within the synchronous window after the Sync Object. The priority of synchronous PDOs should be higher than the priority of asynchronous PDOs.Asynchronous PDOs and SDOs can be transmitted at every time with respect to their priority. So they could also be transmitted within the synchronous window.Cyclic and Acyclic PDOsThe transmission of synchronous PDOs can be subdivided into cyclic and acyclic transmission mode.Synchronous cyclic PDOs are transmitted within the synchronous window. The number of the transmission type (1 to 240) indicates the number of Sync objects between two PDO transmissions. Acyclically transmitted synchronous PDOs are triggered by an application specific event. The message shall be transmitted synchronously with the Sync object but not periodically.PDO Transmission TypesSynchronous (transmission types 0-240 and 252) means that the transmission of the PDO shall be related to the SYNC object.Acyclic (transmission type 0) means that the message shall be transmitted synchronously with the SYNC object but not periodically.Preferably the devices use the SYNC as a trigger to output or actuate based on the previous synchronous Receive-PDO respectively to update the data transmitted at the following synchronous Transmit-PDO. Details of this mechanism depend on the device type and are defined in the device profile if applicable.The transmission type of a PDO is defined in the PDO communication parameter index (1400h for the 1st R_PDO or 1800h for the 1st T_PDO).PDO Parameter 'Inhibit Time'To guarantee that no starvation on the network occurs for communication objects with low priorities, PDOs can be assigned an inhibit time. The inhibit-time defines the minimum time that has to elapse between two consecutive invocations of a PDOs service.In the example above PDO 1 has got a higher priority than PDO 2 and PDO 3. The inhibit-time allows the second and the third PDO to get bus access although having lower priority than the first PDO.PDO Parameter SetsCommunication ParameterThe communication parameters describe the communication behavior of a PDO. The communication parameter set is defined by index 20h in the object dictionary.PDO MappingThe PDO Mapping Parameter defines the content of the Process Data Objects. In the CANopen Device Profiles may be specified a default PDO mapping.Optionally a variable PDO mapping may be supported. If a device supports variable mapping PDO transfer can be optimized application-specificly.Mapping ParameterThe mapping parameter set described in 21h specifies, which application objects are mapped into a PDO. In maximum, there may be mapped up to 64 objects.Service Data ObjectWith Service Data Objects (SDO) the access to entries of a device object dictionary is provided. One SDO uses two CAN Data Frames with different identifiers, because the communication is confirmed.By means of a SDO a peer-to-peer communication channel between two devices may be established. The owner of the accessed object dictionary is the server of the SDO. A device may support more than one SDO. One supported SDO is mandatory and the default case.Segmented TransferSDOs allow to transfer data of any size. They are transferred as a sequence of segments. For transmission of messages with data length less than 5 bytes an ?expedited′transfer may be performed by means ofthe ?Initiate Domain Down/Upload′protocols. With these protocols the data transmission is performed within the initiate protocol.The transfer of messages of more than 4 data bytes has to be performed by means of the segmented transfer. This permits transfer of data of any length since the data can be split up over several CAN messages. All segments after the SDO′s first CAN message may each contain seven bytes of useful data. The last segment may contain an end indicator.An SDO is transferred in ?&confirmed′mode that is the reception of each segment is acknowledged by a corresponding CAN message. It is always the client that takes the initiative for a transfer. The owner of the accessed Object Dictionary is the server of the SDO. Both client and server can take the initiative to abort the transfer of a domain.Optionally a SDO can be transferred as a sequence of blocks. Each block is a sequence of up to 127 segments containing a sequence number and the data, but is confirmed by only one message.Object Dictionary AccessRead and write access to the CANopen object dictionary is performed by SDOs. The Client/Server Command Specifier contains the following information:download/upload,request/response,segmented/block/expedited transfer,number of data bytes,end indicator,alternating toggle bit for each subsequent segment.SDOs are described by the communication parameter. The default Server-SDO (S_SDO) is defined in the entry 1200h, and the first Client-SDO is specified in the entry 1280h.In one CANopen network there may be used up to 256 SDO channels requiring two CAN identifiers each.Initiate SDO DownloadWhen reading or writing to the Object Dictionary of the Server device, the service Initiate SDO Down-/Upload is the first to be invoked.It is important to note that the data bytes are transmitted with the most significant bit first.Download SDO SegmentFor each SDO segment up-/downloaded, two CAN Data Frames are exchanged between Client and Server. The request carries the segment of data, as well as segmentation control information. The response acknowledges the reception of each segment.Bit t is a toggle bit and it is toggled on successive Domain Segment telegrams. For the first segment it has an initial value of zero.Abort SDO TransferThe Abort SDO Transfer is used to notify either the Client or the Server of SDO transfer errors.The reason for the invocation of this service is indicated as a set of error codes, stored in the fields Error Class, Error Code and Additional Code.SDO Block TransferThe SDO Down-/Upload Block Protocol is initiated by the Initiate SDO Block Down-/Upload messages followed by a SDO Down-/Upload Block sequence.The protocol is terminated by the End SDO Block Down-/Upload messages.Download SDO BlockThe Download SDO Block is a sequence of up to 127 segments confirmed by one message. If in the confirmation message the c-bit is set to 1, the block download sequence was received successfully. Unsuccessful completion is indicated by an Abort SDO Transfer request/indication.End SDO Block DownloadTo verify the correctness of a SDO Block down-/upload client and server calculating a CRC which is exchanged and verified during the End SDO Block Down-/Upload messages. The check polynominal has the formula x^16 + x^15 + x^5 + 1.The CRC generator has to be initialized to 0 before calculating the checksum. The checksum can becalculated or a polynome table can be used.SDO Parameter SetSDO Parameter RecordSynchronization ObjectThe Sync-Producer provides the synchronization-signal for the Sync-Consumer. When the Sync-Consumer receive the signal they start carrying out their synchronous tasks. In general the fixing of the transmission time of synchronous PDO messages coupled with the periodicity of transmission of the Sync Object guarantees that sensor devices may arrange to sample process variables and that actuator devices may apply their actuation in a coordinated fashion. The identifier of the Sync Object is available at index 1005h.Sync ProtocolThe Sync Object is implemented with the synchronization device acting as the producer of that object. In order to guarantee timely access to the CAN bus the Sync Object is given a very high priority identifier. CANopen suggests the identifier 128 which is a value of the highest priority group used in the pre-defined connection set. Within the Sync object no application data are transported. By default, the Sync Object does not carry any data.Sync Time DefinitionsSynchronous transmission of a PDO means that the transmission is fixed in time with respect to the transmission of the Sync Object. The synchronous PDO is transmitted within a given time window ?synchronous window length′ with respect to the Sync transmission, and at most once for every period of the Sync. The time period between the Sync objects is specified by the parameter ?communication cycle period′. The ?synchronous window length′ (1007h) and the ?communication cycle period′ (1006h) are specified in the Object Dictionary, which may be written by a configuration tool to the application devices during the boot-up process. There can be a time jitter in transmission by the Sync-Producer corresponding approximately to the latency due to another message being transmitted just before the Sync Object. You also have to consider the case, that the Sync is transmitted twice.Synchronous OperationsThe cyclically transmitted Sync telegram may cause the CANopen devices that support this function to store the actual values of the inputs quasi-simultaneously. They are then transferred to all interested devices in the following time frame. In the following time frame, the CANopen devices transmit the output values to the actuators. However, these values are not valid until the next Sync message is received.Time StampUsually the Time-Stamp object represents an absolute time in ms after midnight and the number of days since January 1, 1984. This is a bit sequence of length 48 (6 byte). Some time critical applications especially in large networks with reduced transmission rates require very accurate synchronization; it may be necessary to synchronize the local clocks with an accuracy in the order of microseconds. This is achieved by using the optional high resolution synchronization protocol which employs a special form of time stamp message to adjust the inevitable drift of the local clocks. The high-resolution time-stamp is encoded as unsigned32 with a resolution of 1 microsecond which means that the time counter restarts every 72 minutes. It is configured by mapping the high resolution time-stamp (object 1013h) into a PDO.Time-Stamp ProtocolThe Time-Stamp object is implemented with the transmitting device acting as the producer and the receiving devices acting as consumers of the event. For the Time Stamp Message identifier 256 is suggested.Emergency ObjectEmergency messages are triggered by the occurrence of a device internal fatal error situation and are transmitted from the concerned application device to the other devices with high priority. This makes them suitable for interrupt type error alerts. An Emergency Telegram may be sent only once per ?error event′, i.e. the emergency messages must not be repeated. As long as no new errors occur on a device no further emergency message must be sent. By means of CANopen Communication Profile defined emergency error codes, the error register anddevice specific additional information are specified in the device profiles.Emergency ProtocolThe Emergency Object is optional. If a device supports this object, it has to support at least the two error codes 00xx (error reset or no error) and 11xx (generic error). The Emergency Object contains 8 data bytes and is confirmed transmitted.Emergency Error Code。
CANopen协议讲解
根据DS301的内容进行介绍1、CAN总线CAN标准报文2、CANopen应用层协议CANopen 协议不针对某种特别的应用对象，具有较高的配置灵活性，高数据传输能力，较低的实现复杂度。
同时，CANopen 完全基于CAN 标准报文格式，而无需扩展报文的支持，最多支持127个节点，并且协议开源。
一个标准的CANopen 节点（下图），在数据链路层之上，添加了应用层。
该应用层一般由软件实现，和控制算法共同运行在实时处理单元内。
一个标准的CANopen 节点CANopen 应用层协议细化了CAN 总线协议中关于标识符的定义。
定义标准报文的11 比特标识符中高4 比特为功能码，后7 比特为节点号，重命名为通讯对象标识符（COB-ID）。
功能码将所有的报文分为7个优先级，按照优先级从高至低依次为：网络命令报文（NMT）同步报文（SYNC）紧急报文（EMERGENCY）时间戳（TIME）过程数据对象（PDO）服务数据对象（SDO）节点状态报文（NMT Err Control）7 位的节点号则表明CANopen 网络最多可支持127个节点共存（0 号节点为主站）。
下表给出了各报文的COB-ID 范围。
NMT 命令为最高优先级报文，由CANopen 主站发出，用以更改从节点的运行状态。
SYNC 报文定期由CANopen 主站发出，所有的同步PDO 根据SYNC报文发送。
EMERGENCY报文由出现紧急状态的从节点发出，任何具备紧急事件监控与处理能力的节点会接收并处理紧急报文。
TIME 报文由CANopen 主站发出，用于同步所有从站的内部时钟。
PDO 分为4 对发送和接收PDO，每一个节点默认拥有4对发送PDO 和接收PDO，用于过程数据的传递。
SDO 分为发送SDO 和接收SDO，用于读写对象字典。
MT Error Control报文由从节点发出，用以监测从节点的运行状态。
状态机CANopen 的每一个节点都维护了一个状态机。
CANopen源代码
CANopen协议栈源代码
SYS TEC CANopen源代码完全符合CiA 301 V4.x标准草案。CANopen 源代码支持快 速开发所需的CANopen master或slave 设备，例如，NMT Master（Network Management），LSS Master（Layer Setting Service）和SDO Client。 直观的基于事件的应用层信号机制保证了较高的运行性能。CANopen 源码包含相应 的功能用于在操作系统中进行简单的集成。良好设计的API接口使您可以很容易的 在自己的应用中集成CANopen协议栈。 软件包中大量的范例程序和文档将帮助你更 好地应用协议栈源代码。 我们提供两种主要的源代码包，包含工业应用的主要部 分。另外，其它特殊的功能用附加包提供。
CANopen协议栈源代码
主要特点:
·支持多实例-可以在一个物理设 备上实现多个CANopen逻辑设备 ·一年免费的软件维护和技术支持 ·完整的用于实施CANopen master和slave服务的库(特点比 较) ·附带完整的一系列CANopen工具 ·带有PC端工具用于配置对象字典 和自动的源代码生成工具，EDS编 辑器可以带有导入导出功能。 ·标准的ANSI-C源代码，模块化的 软件架构，易于移植到目标平台。 同时我们将提供灵活的代码适配服 务。 ·通用的OS API可用于和各种实时 操作系统进行集成 ·支持全部的CANopen 设备标准 规范 ·包含适用于各种系统的CAN驱动 源代码 ·全部支持的CAN接口都具有一致 的API接口 ·支持CiA 304标准的CANopen安 全协议扩展 (可选组件) ·支持CiA 302标准的CANopen管 理器源代码 ·支持CiA 402标准的设备定义用 于支持运动控制和驱动(可选组件) ·多路PDO用于CiA 417标准兼容 的设备(CANopen Lift)(可选组件 ) ·SDO 网关用于CANopen sub-networking（可选组件） ·高精度时间戳 (可选组件)
CANopen协议介绍(精辟准确)
1.CANopen协议简介从OSI 网络模型的角度来看，CAN总线只定义了OSI网络模型的第一层（物理层） 和第二层（数据链路层），而在实际设计中，这两层完全由硬件实现，设计人员无需再为此开发相关软件或固件。
同时，CAN只定义物理层和数据链路层，没有规定应用层，本身并不完整，因此需要一个高层协议来定义CAN报文中的11/29位标识符和8字节数据的使用。
而且，基于C AN总线的工业自动化应用中，越来越需要一个开放的、标准化的高层协议：这个协议支持各种CAN厂商设备的互用性、互换性，能够实现在CAN网络中提供标准的、统一的系统通讯模式，提供设备功能描述方式，执行网络管理功能。
CANopen协议是CAN-in-Automation(CiA)定义的标准之一，并且在发布后不久就获得了广泛的承认。
尤其是在欧洲， CANopen 协议被认为是在基于CAN 的工业系统中占领导地位的标准。
大多数重要的设备类型，例如数字和模拟的输入输出模块、驱动设备、操作设备、控制器、可编程控制器或编码器，都在称为“设备描述”的协议中进行描述；“设备描述”定义了不同类型的标准设备及其相应的功能。
依靠CANopen协议的支持，可以对不同厂商的设备通过总线进行配置。
在OSI 模型中， CAN标准、CANopen协议之间的关系如图 1-1所示。
图1-1 CAN标准、CANopen协议在OSI网络模型中的位置框图CANopen和CAN报文的关系如图 1-2所示。
图1-2 CANopen和CAN报文的关系如所示。
CAN 报文由7个不同的位域组成，而CANopen就是规定其中的仲裁域(11 位标识符)和数据域(8 字节数据) 的使用情况。
2.CANopen设备结构CANopen是一个基于CAN串行总线系统和CAL（CAN应用层）的高层协议。
CANopen的核心概念是设备对象字典（OD： ObjectDictionary），CANopen通讯通过对象字典（OD）能够访问驱动器的所有参数。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
CiA Draft Standard 304CAN open Framework for safety-relevant communicationVersion 1.0.101 January 2005© CAN in Automation (CiA) e. V.HistoryDate Version Changes2001-01-01 1.0 Release as Draft Standard Proposal2005-01-01 1.0.1 Publication as Draft Standard•Editorial corrections•Inclusion of errata•Harmonization of terminologyGeneral information on licensing and patentsCAN in AUTOMATION (CiA) calls attention to the possibility that some of the elements of this CiA specification may be subject of patent rights. CiA shall not be responsible for identifying any or all such patent rights.Because this specification is licensed free of charge, there is no warranty for this specifica-tion, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holder and/or other parties provide this specification “as is” without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of mer-chantability and fitness for a particular purpose. The entire risk as to the correctness and completeness of the specification is with you. Should this specification prove failures, you assume the cost of all necessary servicing, repair or correction.© CiA 2008All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or util-ized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from CiA at the address below.CAN in Automation e. V.Kontumazgarten 3DE - 90429 Nuremberg, GermanyTel.: +49-911-928819-0Fax: +49-911-928819-79Url: Email: headquarters@2 © CiA 2008 – All rights reservedContents1Scope (5)2References (6)2.1Normative references (6)2.2Informative references (6)3Abbreviations and definitions (7)3.1Abbreviations (7)3.2Definitions (7)4Operating principle (8)4.1Theory of safe operation (8)4.2Standard CANopen functions (8)4.3Safety-relevant communication (9)4.3.1Introduction (9)4.3.2Timing requirements (9)5SRDO definition (11)5.1SRDO services (11)5.1.1General (11)5.1.2Write SRDO (11)5.1.3Read SRDO (11)5.2SRDO protocol (11)5.2.1Write SRDO protocol (11)6Global fail-safe command (13)6.1GFC usage (13)6.2GFC service (13)6.2.1Write GFC (13)6.3GFC protocol (13)6.3.1Write GFC (13)7Network initialisation and system boot-up (14)7.1Initialisation procedure for safety networks (14)7.2NMT states for safety devices (15)7.2.1General (15)7.2.2Pre-operational (15)7.2.3Operational (15)7.2.4Stopped (15)7.2.5Relation of NMT states and COBs (15)8Pre-defined connection set (16)© CiA 2008 – All rights reserved 39Object dictionary (17)9.1Complex data type (17)9.1.1SRDO communication parameter record (17)9.2Object dictionary specifications (17)9.2.1Object 1300h: Global fail-safe command parameter (17)9.2.2Object 1301h to 1340h: SRDO communication parameter (17)9.2.3Object 1381h to 13C0h: SRDO mapping parameter (21)9.2.4Object 13FE h: Configuration valid (22)9.2.5Object 13FF h: Safety configuration checksum (23)10Annex A (informative) (25)10.1Hardware architecture (25)10.2Configuration mechanism (25)10.3Mathematical analysis of CANopen safety (26)10.4Limits and recommendations (26)10.5Rules of implementation (26)11Annex B (informative) (27)11.1Overview on objects for safety communication (27)4 © CiA 2008 – All rights reserved1 ScopeThe services and protocols defined in this document are intended to be an add-on to the CANopen application layer and communication profile.Safety-relevant communication is an additional property of such devices. The manufacturer and the system integrator shall take care, that the safety requirements are allocated to safe communication objects, that the hardware and software of the device support the safety function and that the device is operated within its safe limits.This specification describes only the data transport mechanism on a CANopen network, that allows the exchange of safety-relevant data.Due to CANopen compatibility communication is limited to 64 safe communication objects, so up to 64 suppliers of safety-relevant objects can operate in a CANopen network. The number of consumers of the safety-relevant objects is not defined (at least one receiver is necessary).© CiA 2008 – All rights reserved 52 References2.1 Normative references/CiA301/ C iA DS 301, CANopen application layer and communication profile/EN954-1/ E N 954-1, Safety related parts of control systems - Part 1: General principles of design/IEC61508/ I EC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems/DIN801/ DIN V VDE 0801, Grundsätze für Rechner in Systemen mit Sicherheitsauf-gaben2.2 Informative references/CHAR/ C harzinsiki:1991, Bewertung der Fehlersicherungsverfahren im CAN-Protokoll, Universität Stuttgart/FAET/ G rundsatz für die Prüfung und Zertifizierung von “Bussystemen für die Über-tragung sicherheitsrelevanter Nachrichten”, Fachausschuss Elektrotechnik,Köln, Ausgabe 05.02, GS-ET-266 © CiA 2008 – All rights reserved3 Abbreviations and definitions3.1 AbbreviationsAK Anforderungsklassen - requirement classesBIA Berufsgenossenschaftliches Institut für Arbeitssicherheit - Institute for occupa-tional safety of accident insurance institutionsCAN Controller area networkCAN-ID CAN identifierCOB Communication objectCOB-ID COB identifierGFC Global failsafe commandNMT Network managementPLC Programmable logic controllerRTR Remote transmission requestSCT Safeguard cycle timeSIL Safety integrity levelSRDO Safety-relevant data objectSRVT Safety-relevant object validation timeTÜV Technischer Überwachungsverein - German association for technical inspection 3.2 DefinitionsThe definitions given in /CiA301/ apply for this framework, too.Safety controllerdevice that consumes safety-relevant data© CiA 2008 – All rights reserved 74 Operating principle4.1 Theory of safe operationIt is absolutely essential for a safe system, that there is a safe state. A reaction to an emergency command, an alarm or an error, the safe-state is entered.It is also important, that the functionality of the safeguard measures is regularly checked. A single defect in a safety-relevant communication shall not override the safety circuitry! If such an error oc-curs, it shall be detected within a short period of time in which a second error is unlikely to happen.All the systems, especially the safety-relevant circuitry shall have a high reliability in order to extend the time-span between the safety-tests and minimize the down-time of the whole system (e.g. if one of redundant components fails, the system shall be shut-off). So the need for safety decreases the avail-ability of a system.The idea of safety in CAN communication is not to ensure, that there are absolutely no errors and faults. This would be rather hard to proof - anyway. The goal is to detect all possible errors and react in a predictable (safe) way.In a safe CAN system there are sources of safe information (e.g. safety switches, light barriers, emer-gency stop buttons) and consumers of such information (e.g. relay, valve or drive controlling a possi-bly dangerous movement, safety PLC). As the "consumers" control the possible dangerous situation it is responsible for entering the safe-state after any safety-relevant interference. It also shall check the data integrity of the safety-relevant communication.As the sources (safety inputs) are the origin of safe communication objects (SRDOs), their number is limited to 64. The number of safety controllers is not limited in theory, as CAN allows many consumers to listen to the same SRDO(s), i.e. many actuator devices use the same information.As the safety controllers are responsible for the data integrity and actuality, every safety-relevant out-put device shall to survey all corresponding sources of safety-relevant data.4.2 Standard CANopen functionsIt is intended, that the additional safe communication is not affecting the normal operation and serv-ices on a CANopen network. Safe communication is not related to a special class of devices, so no special device profile is required.Nx Normal NodeDx Drive ControllFigure 1: Example of a CANopen network with safety-relevant devices8 © CiA 2008 – All rights reservedTo ensure compatibility, the usage of identifiers and pre-defined objects shall be coordinated with the CANopen standard and existing device profiles. As there is no use of data bits in the safe communica-tion method, it is compatible with existing device profiles.In a CANopen network the data interface to the application program within a certain node is only via the CANopen object dictionary. The application itself shall transfer data correct, in time and in se-quence to the CANopen kernel. In case of SRDO reception, the application shall collect and check SRDO data so frequently, that the time expectation is fulfilled.4.3 Safety-relevant communication4.3.1 IntroductionThe safety-relevant data transfer is performed by means of SRDO.An SRDO shall consist of two CAN data frames with identifiers, which shall be different in at least two bit positions. The user data in both transmissions is redundant, i.e. the meaning of the data is the same, but the data on the 2nd transmission is inverted bitwise.SRDOs shall be transmitted periodically. If required, SRDOs may also be transmitted event-driven, e.g. to ensure fast reaction after a safety critical change on the input. RTR shall not be possible; SRDOs shall be only allowed in the NMT state operational.An SRDO shall be only valid, if both CAN frames are received properly (without failure and in time). The redundant transmission is sent after the first transmission to the CAN controller with minimum delay.There are two kinds of use for SRDOs. The first is data transmission and the second data reception. It is distinguished by the information direction. Devices where the information direction is set to trans-mit (tx) are SRDO producer and devices where the information direction is set to receive (rx) are called SRDO consumer. SRDOs are described by the SRDO communication parameter (26h) and the SRDO mapping parameter. The structure of this data type is explained in chapter 9.1.1. The SRDO commu-nication parameter describes the communication capabilities of the SRDO. The SRDO mapping pa-rameter contains information about the content of the SRDOs (variables). The indices of the corre-sponding object dictionary entries are computed by the following formulas:SRDO communication parameter index = 1300h + SRDO-numberSRDO mapping parameter index = 1380h + SRDO-numberFor each SRDO the pair of communication and mapping parameter is mandatory. These parameter objects are described in chapter 9.2.2 and 9.2.3.4.3.2 Timing requirementsIn order to test the correct function of the periodical SRDO transmission on the CAN network, the safety controller shall be assigned with the SCT. If the SCT expires, the safety controller shall transit to the safe state.SRDO SRDOSRDOFigure 2: Example for SCT timing© CiA 2008 – All rights reserved 9A second test determines, if there is sufficient network capacity for a safety system. Both CAN frames that make an SRDO shall be received correctly within the given SRVT. Normally both CAN frames are transmitted with minimum delay. If the 2nd CAN frame is not being received within SRVT, the network may have reduced transmission capabilities. The reaction time on a safety-relevant event is enlarged. If the SRVT expires, the safety controller shall transit to the safe state.SRDOSRDO SRDO SRDO?SRVT SRVTSRVT SRVT SRVT expiredFigure 3: Example for SRVT timing10 © CiA 2008 – All rights reserved5 SRDO definition5.1 SRDO services5.1.1 GeneralSRDO transmission follows the producer/consumer relationship in /CiA301/ and consists of two CAN data frames.Attributes:•SRDO number: SRDO number [1..64] for every user type on the local device•user type: one of the values {consumer, producer}•data type: according to the SRDO mapping•refresh-time: n*1 ms, n > 0•validation-time: n*1 ms, n > 05.1.2 Write SRDOFor the write SRDO service the push model shall be used. There shall be one or more consumers of an SRDO. An SRDO shall have exactly one producer.Through this service the producer of an SRDO shall send the data of the mapped application object to the consumer(s).Table 1: Write SRDOParameter Request / IndicationArgument SRDO number Data Mandatory Mandatory Mandatory5.1.3 Read SRDOThe read SRDO service shall be not allowed.5.2 SRDO protocol5.2.1 Write SRDO protocolThe service for an SRDO write request shall be unconfirmed. The SRDO producer shall send the process data within an SRDO to the network. There may be 1 to an SRDO consumers. At the SRDO consumer(s) the reception of a valid SRDO shall be indicated.© CiA 2008 – All rights reserved 1112 © CiA 2008 – All rights reservedFigure 4: Write SRDO protocolProcess-data: up to L bytes of application data according to the SRDO mapping.If L exceeds the number 'n' defined by the actual SRDO mapping length, only the first 'n' bytes shall be used by the consumer. If L is less than 'n' the data of the received SRDO shall be not processed and an Emergency message with error code 8210h shall be produced if Emergency is supported. An SRDO shall not be requested by RTR.)6 Global fail-safe command6.1 GFC usageIn order to speed up the system reaction time, the GFC may be used.If one transmission at least have been received, the GFC shall be already valid. It allows only one reaction in a CAN network. For that reason, the usage of the GFC is optional. It is event-driven only and not safe (no periodic time expectation).Example: After a safety-relevant change at a device input, the GFC may be transmitted first (optional), then the corresponding SRDO shall follow to maintain safety.6.2 GFC service6.2.1 Write GFCThe GFC transmission shall follow the producer/consumer push model as described in /CiA301/. The service shall be unconfirmed; the corresponding SRDO shall follow.Attributes:•user type: one of the values {consumer, producer}•data type: nil6.3 GFC protocol6.3.1 Write GFCFigure 5: Write GFC protocol© CiA 2008 – All rights reserved 1314 © CiA 2008 – All rights reserved7 Network initialisation and system boot-up 7.1Initialisation procedure for safety networksThe network initialisation process is controlled by the NMT master application or configuration applica-tion.Figure 6: Flow chart of the network initialisation process for safety networksIn step A the devices shall be in the NMT state pre-operational, which is entered automatically after power-on. In this state, the devices are accessible via their default SDO using CAN-IDs that are been assigned according to the pre-defined connection set. In this step, the configuration of device parame-ters take place on all devices, which support parameter configuration. Some configuration data are safety-relevant. So additional measures shall be taken, to ensure the safety function in the network. This is done from a configuration application or tool, which resides on the device that is the client for the default SDOs. For devices that support these features the selection and/or configuration of PDOs, the mapping of application objects (PDO mapping), the selection and/or configuration of SRDOs, the mapping of application objects (SRDO mapping), the configuration of additional SDOs and optionally the setting of COB-IDs may be performed via the default SDO objects.In many cases, a configuration is not necessary as default values are defined for all application and communication parameters.If the application requires the synchronisation of all or some nodes in the network, the appropriate mechanisms may be initiated in the optional step B. It may be used to ensure that all devices except safety nodes are synchronised by the SYNC object before entering the NMT state operational in step E. The first transmission of SYNC object starts within 1 sync cycle after entering the NMT state pre-operational.In step C node guarding may be activated (if supported) using the guarding parameters configured in step A.ABCDEIn step D there shall be a method performed for the check of the authenticity of the configuration data. It covers the following safety relevant configuration objects:•SRDO numbers(s) used•Time expectation (refresh time, SCT, and the SRVT)•Information direction•Mapping parameterThe checksum of the respective configuration entries shall be defined, that the safe application may check if a safety configuration tool has been used and that the content of the configuration entries has not been changed in state operational In case of mismatch, the safety node shall not transmit SRDOs; the safety controller shall enter (or shall stay in) the safe state.7.2 NMT states for safety devices7.2.1 GeneralThe "safe state" of a device is not a CANopen communication state and falls not in the scope of this framework.7.2.2 Pre-operationalIn the NMT state pre-operational, communication via SDOs is possible, however SRDO and PDO communication shall be not allowed. Configuration of SRDOs, PDOs, device parameters and also the allocation of application objects (PDO mapping) may be performed by a configuration application. The device may be switched into the NMT state operational directly by sending a Start_Remote_Node request. In the NMT state pre-operational the application is in the safe-state.7.2.3 OperationalIn the NMT state pre-operational, SRDO and PDO communication are active, however SDO write access shall be is not possible. For the safe application this is the only working state (e.g. motor on). Safety communication is only supported in this state.7.2.4 StoppedBy switching a safety device in the NMT state stopped limits the communication to NMT messages. The application shall be in the safe state.7.2.5 Relation of NMT states and COBsTable 2 shows the relation between NMT states and COBs. Services on the listed COBs shall only be executed if the device is in one of the appropriate NMT states.Table 2: States and communication objectsINITIALISING PRE-OPERATIONAL OPERATIONAL STOPPED PDO AllowedSDO Allowed Allowed1SRDO AllowedSynchronization object Allowed AllowedTime stamp object Allowed AllowedEmergency object Allowed AllowedBoot-up object AllowedNMT object Allowed Allowed Allowed 1Writing to a safety object in the NMT state operational shall lead to an abort message (abort code: 0800 0022h). Reading of a safety entry in the NMT state operational is allowed.© CiA 2008 – All rights reserved 1516 © CiA 2008 – All rights reserved8Pre-defined connection setIn order to reduce configuration effort for simple networks, a mandatory default identifier allocation scheme is defined in /CiA301/.This pre-defined connection set is extended to support one SRDOs for every safety device with a node-ID between 1 and 64. Devices with a node-ID, which is higher than 64, shall not have pre-defined CAN-ID assigned for SRDOs.Table 3: Broadcast objects of the pre-defined connection setObject Function codeResulting CAN-IDsGFC0000b1 (001h )Table 4: Peer-to-peer objects of the pre-defined connection setResulting CAN-IDs Object Function code Normal data Complement data Communication parameters at index Channeldirection SRDO(node-ID 1 to 32) 0010b 257d to 319d (1)(101h to 13F h ) 258d to 320d (1)(102h to 140h ) 1301h to 1340h tx SRDO(node-ID 33 to 64)0010b321d to 383d (1) (141h to 17F h )322d to 384d (1) (142h to 180h )1301h to 1340hrx(1)Every second CAN-ID is used.9 Object dictionary9.1 Complex data type9.1.1 SRDO communication parameter recordIndex Sub-Index Description Data type00h Highest sub-index supported UNSIGNED80026h01h Information direction UNSIGNED802h Refresh-time/SCT UNSIGNED1603h SRVT UNSIGNED804h Transmission type UNSIGNED805h COB-ID 1 UNSIGNED3206h COB-ID 2 UNSIGNED329.2 Object dictionary specifications9.2.1 Object 1300h: Global fail-safe command parameterVALUE DEFINITION00h: GFC is not valid01h: GFC is valid02h to FF h: reservedOBJECT DESCRIPTIONINDEX 1300hName Global failsafe command parameterObject code VARData type UNSIGNED8Category OptionalENTRY DESCRIPTIONAccess rwPDO mapping NoValue range See value definitionDefault value 00h9.2.2 Object 1301h to 1340h: SRDO communication parameterThese objects shall contain the communication parameters for the SRDOs the device is able to re-ceive or to transmit. The type of the SRDO communication parameter (26h) is described in 9.1.1.The sub-index 00h shall contain the number of highest entry within the communication record.At sub-index 01h shall reside the information direction of the SRDO. The SRDO information direction allows to select if it is used as a receive SRDO or as a transmit SRDO in the operational state. There may be SRDOs fully configured (e.g. by default) but not used, and therefore set to "not valid" (de-© CiA 2008 – All rights reserved 17leted). The feature is necessary for devices supporting more than one SRDO, because each device with a node-ID in the range from 1 to 64 has only default identifiers for the first SRDO. It is not allowed to change the COB-ID 1 or COB-ID 2 while the SRDO exists (value unequal to 0).Sub-index 02h shall contain the refresh-time or the SCT depending on the information direction (see 4.3.2).Sub-index 03h shall contain the SRDO validation time, if it is an SRDO with rx direction (see 4.3.2). The transmission type (sub-index 4h) defines the transmissionreception character of the SRDO. It is defined as type 254 /CiA301/ describes the usage of this entry. On an attempt to change the value of the transmission type an abort message (abort code: 0609 0030h) is generated.At sub-index 05h and sub-index 06h shall reside the two COB-IDs of the SRDO. These entries were defined as UNSIGNED32 for compatibility reasons to the COB-ID definitions in /CiA301/. The CAN-IDs may only be changed in the range from 101h to 180h. Every SRDO uses two following CAN-IDs from this range, where the first CAN-ID is odd and the second CAN-ID is even.VALUE DEFINITIONSub-index 01h:Value Description00h Does not exist / is not valid01h Exists / is valid for transmit (ts)02h Exists / is valid for receive (rx)03h to FF h ReservedSub-index 02h:The refresh-time and SCT shall be given in ms. Value 0 shall be not used.Sub-index 03h:The SVT shall be given in ms. Value 0 shall be not used.Sub-index 04h:See PDO communication parameters (transmission type) in /CiA301/.Sub-index 05h and 06h:31 11 10 0reserved (0) CAN-IDMSB LSB18 © CiA 2008 – All rights reservedOBJECT DESCRIPTIONINDEX 1301h to 1340hName SRDO communication parameterObject code RECORDData type SRDO parameterCategory Mandatory for each supported SRDO ENTRY DESCRIPTIONSub-index 00hDescription Highest sub-index supportedEntry category MandatoryAccess roPDO mapping NoValue range 06hDefault value 06hSub-index 01hDescription Information directionEntry category MandatoryAccess rw (only in NMT state pre-operational)PDO mapping NoValue range see value definitionDefault value 1301h: manufacturer-specific 1302h to 1340h: 00hSub-index 02hDescription tx: refresh-timerx: SCTEntry category MandatoryAccess rw (only in NMT state pre-operational)PDO mapping NoValue range UNSIGNED16Default value 25d (if information direction is tx)50d (if information direction is rx)© CiA 2008 – All rights reserved 19Sub-index 03hDescription not used (if information direction is tx)SVT (if information direction is rx)Entry category Conditional (if information direction is rx)Access rw (only in NMT state pre-operational)PDO mapping NoValue range UNSIGNED16Default value 20dSub-index 04hDescription Transmission typeEntry category MandatoryAccess roPDO mapping NoValue range 254dDefault value 254dSub-index 05hDescription COB-ID 1Entry category MandatoryAccess rw (only in NMT state pre-operational)PDO mapping NoValue range Odd values only: 257d to 383dDefault value 1301h: 0000 00FF h + (2 x node-ID)1302h to 1340h: manufacturer-specificSub-index 06hDescription COB-ID 2Entry category MandatoryAccess rw (only in NMT state pre-operational)PDO mapping NoValue range Even values only: 258d to 384dDefault value 1301h: 0000 0100h + (2 x node-ID)1302h to 1340h: manufacturer-specific20 © CiA 2008 – All rights reserved9.2.3 Object 1381h to 13C0h: SRDO mapping parameterThese objects shall contain the mapping parameters for the SRDOs the device is able to receive or transmit. The type of the SRDO mapping parameter is an array of type UNSIGNED32. The sub-index 00h contains the number of valid entries within the mapping array. This half of the number of entries is also the number of the application variables, which shall be received/transmitted with the correspond-ing SRDO. The sub-indices from 01h to number of entries contain the information about the mapped application variables. The structure and the procedure for the mapping is described in /CiA301/. For changing the SRDO mapping first the SRDO shall be deleted.VALUE DEFINITIONSub-index 00h:00h: mapping not valid02h, 04h to 80h (only even values): mapping valid01h, 03h to 7F h (only odd values): reservedSub-index 01h to 80h:See PDO mapping parameters in /CiA301/.OBJECT DESCRIPTIONINDEX 1381h to 13C0hName SRDO mapping parameterObject code ARRAYData type UNSIGNED32Category Mandatory for each supported SRDOENTRY DESCRIPTIONSub-index 00hDescription Highest sub-index supportedEntry category MandatoryAccess ro or rw (only in NMT state pre-operational, and if variable mapping issupported)PDO mapping NoValue range See value definitionDefault value (Device profile dependent)© CiA 2008 – All rights reserved 21Sub-index 01h, 03h, 05h to 7F h (only odd indices)Description SRDO mapping for the n-th applicationobject to be mapped (data not inverted)Entry category Conditional; depends on number of ob-jects to be mappedAccess rwPDO mapping NoValue range UNSIGNED32Default value (Device profile dependent)Sub-index 02h, 04h, 06h to 80h (only even indices)Description SRDO mapping for the n-th applicationobject to be mapped (data inverted)Entry category Conditional; depends on number of ob-jects to be mappedAccess rwPDO mapping NoValue range UNSIGNED32Default value (Device profile dependent)9.2.4 Object 13FE h: Configuration validThis object shall contain an acknowledgement flag for a valid configuration. After write access to any of the safety-relevant parameter, this object shall be automatically set to invalid configuration (00h). If the configuration is finished, the user writes the “valid” value to this object.VALUE DEFINITIONA5h: Configuration validAll other values shall indicate an invalid configuration.OBJECT DESCRIPTIONINDEX 13FE hName Configuration validObject code VARData type UNSIGNED8Category Mandatory22 © CiA 2008 – All rights reserved。