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规范定义了四类标准的通信对象
- 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。