CANopen Implementation Guidelines
Contents
1. PDOCommPar Structure 1 PDOMapping Structure 1 A COB ID used by PDO 1st mapped Object 4 transmission type 2nd mapped Object 4 inhibit time 8rd mapped Object 4 4th mapped Object 4 5th mapped Object 4 6th mapped Object 4 PDO p 2 PDOCommPar Structure 2 PDOMapping Structure 2 1st mapped Object COB ID used by 1st mapped Object 2nd mapped Object transmission type 2nd mapped Object 3rd mapped Object inhibit time 3rd mapped Object 4th mapped Object 4 4th mapped Object 2 y 5th mapped Object nth mapped Object y 6th mapped Object PDOCommPar Structure 3 PDOMapping Structure 3 COB ID used by PDO 1st mapped Object transmission type 2nd mapped Object inhibit time 3rd mapped Object 4th mapped Object Figure 25 Switching between different static mappings 01 07 1997 31 Implguid public doc STA Reutlingen 10 Network Synchronization Besides the cyclic exchange of data many real time applications demand synchronization between different bus nodes l e axis of a kinematics have to be synchronized or I O modules have to set outputs or read inputs simultaneously like a PLC Synchronized drives expect commanded positions and send actual positions in pre defined time windows CANopen meets these requirements by introducing an optional synchronization telegram with a high priority2. 01 07 1997 Figure 2 CANopen Object Dictionary 7 Implguid_public doc STA Reutlingen Index hex Object Dictionary Section 0001 001F Static Data Types e g Boolean Integer16 0020 003F Complex Data Types e g PDOCommPar SDOParameter 0040 005F Manufacturer Specific Data Types 0060 007F Device Profile Specific Static Data Types 0080 009F Device Profile Specific Complex Data Types 1000 1FFF Communication Profile Area e g Device Type Error Register Number of PDOs supported 2000 5FFF Manufacturer Specific Profile Area 6000 9FFF Device Profile Profile Area e g DS401 Device Profile for Modules Read State 8 Input Lines Polarity 8Input Lines The CANopen device profiling provides a non manufacturer specific part with upward compatibility By defining mandatory device characteristics basic network operation is guaranteed By defining optional device features a degree of defined flexibility can be built in By leaving hooks for manufacturer Figure 3 Object Dictionary Structure specific functionality vendors will not be constrained to an out of date standard 01 07 1997 8 Implguid public doc STA Reutlingen 5 Data Types The base data types which are supported by CANopen are defined in the document DS202 3 CMS Data Types and Encoding Rules The basic data types are described next BOOLEAN The Boolean data type is
3. 4 P di A CN NC xX V yi Reutlingen CANopen Implementation Guidelines by G Gruhler Ed and Bernd Dreier STA Reutlingen Germany Version 2 3 STA Fax Contact 49 0 71 21 2 57 13 Internet http www fh reutlingen de www sta ESPRIT Project 22171 CANopen Table of Contents addgedm cnc c 3 rudi ellc 4 xNcIBer ade 5 4 CANOPEN BASICS AND 6 SIDATATY PES p TC MEE 9 6 CAL AND CANOPEN E 11 7 NETWORK MANAGEMENT IN CANOPEN ccccseecsseeeeeeeeeeeeeenseeeeeneeeeseesusaeeeeeeeeasaesesseesaeeeenseeeneas 12 7 1 START REMOTE NODE 6 14 7 2 ENTER PRE OPERATIONAL STATE 8 15 7 3 NMT STOP REMOTE P 15 NODE 0 16 7 5 RESET COMMUNICATION 11 deiak aiaa iea 16 756 NODE GUARDING 2 iiai ainan ii a iden cease en eed 17 3 SERVICE DATA OBJEGCT iret 19 9 5 5 En rne reed 28 10 NETWORK SYNCHRONIZATION 32 11T BOOT U
4. Byte 0 Byte 1 cs Node ID Figure 6 NMT message format NMT command specifier cs The command specifier is used to indicate the service At the end of this chapter an overview of all command specifiers is given Node ID The node which has to be addressed by the service If the Node ID is 0 all nodes in the network are addressed The COB ID of the NMT service is always O The following NMT services are used by a NMT master to force a NMT slave into the pre defied states described before The service primitives request and indication are used to describe the interaction between the application and the NMT service element in the application layer as follows e a request is issued by the application to the application layer to request a service e an indication is issued by the application layer to the application to indicate that a service is requested 01 07 1997 13 Implguid public doc STA Reutlingen The following table gives an overview of the used command specifiers There are additional command specifiers defined for CAL but they are not used by CANopen devices which support the state diagram for minimal capability devices Command service Specifier 1 NMT Start Remote Node NMT Stop Remote Node 128 NMT Enter Pre operational State 129 NMT Reset Node 130 NMT Reset Communication Table 3 Command specifier overview 7 1 NMT Start Remote Node 6 The NMT Start Remo
5. Byte 0 Byte 1 gt 5 129 Node ID indication indication indication Figure 10 NMT Reset Node service 7 5 NMT Reset Communication 11 The NMT Reset Communication service forces the NMT Slave into the Initialization state There it enters the Reset Application phase The protocol is executed and formatted as follows NMT Master COB ID 0 NMT Slave request Byte 0 Byte 1 gt cs 130 Node ID gt indication indication indication Figure 11 NMT Reset Communication service 01 07 1997 16 Implguid public doc STA Reutlingen 7 6 Node Guarding Node Guarding is used to detect remote errors in the network With Node Guarding the NMT master can watch its NMT slaves and the NMT slave can detect if the NMT master stops working Node guarding should be used if a slave is not polled on a regular time base by the master or if the slave does not transmit PDOs regularly If a remote error is detected the application should go in a save state The definition of a save state is strongly application dependent Generally if the NMT master detects a remote error it should force its NMT slaves into a save sate this can either be the state Disconneted if the slaves are CAL compatible or the state Prepared if the slaves are minimum capability devices If a NMT slave detects a guarding error it should inform its application and the application has to decide how to handle the error To
6. all CAN messages anyway which are on the bus and does not use the advantages of a Full CAN controller Hardware Setup In order to set up a CAN node the node ID and the baudrate must be configured before the node is accessed via the network The most suitable solution to set up the node ID and the baudrate is to use DIP switches If the CAN node is switched on or reset the application first reads the node ID and the baudrate from the DIP switches Another possibility is to create two objects in the manufacturer specific profile area in the object dictionary and store the data in the non volatile memory Then the node has to be configured first in a separate network After that the node can be integrated into the target network 01 07 1997 35 Implguid public doc STA Reutlingen 14 ID distribution in a CANopen network CANopen supports three different identifier allocation possibilities 1 Default Identifier Distribution CANopen DS 301 defines a default ID distribution that each node has to follow This means that after power up each node has identifiers available for e two receive PDOs e two transmit PDOs one SDO with two identifiers e one emergency object e one node guarding identifier simply derived from the node ID offset Of course a device only has to provide identifiers for the communication objects that it supports E g if a simple input device features one transmit PDO and no receive PDOs it only establishes one PD
7. cs in the first data byte More sophisticated devices will support the full CAL boot up including DBT services which is started with a disconnect command as all devices enter pre operational after power on It is possible to have all combinations of devices in the same network as the full boot up can be performed separately with each device supporting it whilst the minimal boot up is performed with the other devices If the network master only supports minimal boot up all slaves behave like minimal slaves This boot up concept ensures that very lean implementations are possible as all parameterisation including most of the network configuration can be done via one single CMS service the multiplexed domain protocol of the service data object If the default settings are sufficient or if the devices are capable of storing their configuration data the boot up is reduced to one single two byte message start all nodes For additional information see also section 16 01 07 1997 33 Implguid public doc STA Reutlingen 12 Emergency Message Usage The Emergency message is used to notify an internal device error to the network For instance the voltage of the device reaches a critical limit whereas the network interface is still in good working conditions For the notification of this type of errors an emergency telegram have to be generated The emergency message have to be sent only once per error event Afterwards the error has to be sto
8. e ccs 0 the server should transmit an acknowledgement telegram where scs 1 The t field should be identical to the t field of the received telegram During segmented data transfer the toggle bit t is used to ensure packets which are re transmitted are not mis interpreted i e helps maintain client server packet synchronisation The toggle bit is set to 0 for the first segment and have to alternate with successive segments 01 07 1997 22 Implguid public doc STA Reutlingen Upload Initiation Expedited Protocol Client Server COB ID 1537 Node ID 1 request Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte5 Byte 6 Byte 7 indication 7 5 4 0 Index Sub Reserved A scs 2 X Index COB ID 1409 Node ID 1 confirm Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 response 75 43 2 1 4 Index Sub Data 2 Xn Index Figure 17 Upload Initiate and Response CCS client command specifier 2 initiate upload request SCS server command specifier e transfer type S size n 2 initiate upload response 0 segmented transfer 1 data contains the data to be transferred 0 data set size is not indicated 1 data set size is indicated only valid if e 1 and s 1 if valid it contains the number of bytes which do not contain data A domain upload happens in a similar manner to the domain download sequence described above The e bit informs the client if the data transfer is
9. is downloaded with a write variable service Alternatively it is possible to use multiplexed variables with confirmed or unconfirmed services NMT configuration control services combine single parameters to structures with different access type use various variable names and priorities etc All possibilities are fully CAL compatible but obviously not interoperable unless someone specifies which object and service type has to be used for which parameter and how this parameter is to be interpreted M i P Network Master Device p Parameter 1 Parameter 2 im omain Downloa E Parameter 3 amp Parameter n Network Master Device Parameter 1 Write Parameter 1 Parameter 2 Write Parameter 2 E Parameter 3 Write Parameter 3 gt amp Parameter n Write Parameter n Figure 4 Purpose of communication profile By defining the subset and use of CAL the CANopen CAL based communication profile for industrial systems CiA DS 301 provides the missing user manual that is needed to establish open and interoperable communication with CAL Or in other words CANopen reduces CALs degrees of freedom in order to achieve interoperability lean implementations and superior performance All devices following the CANopen communication profile can interact perfectly in the same physical network if required together with generic CAL dev
10. perform the node guarding the NMT master checks the NMT slave state on a defined time base via Remote Transmit Request RTR on the Node Guarding COB ID The NMT master compares the received state to the state of its peer if the comparison fails or if the state of the NMT slave could not be retrieved the NMT master indicates that this is a remote error The Node guarding starts for the slave when the first remote transmit request for its guarding identifier is received The NMT master should request the NMT slaves with a time gap between the requests it should not request all slaves at once because the slaves response could be cause an overrun in the masters receive message queue 01 07 1997 17 Implguid public doc STA Reutlingen 01 07 1997 NMT Master Remote Node 1 State Diaaram Remole Node 2 State Diaqram Remote Node 3 State Diagram y NMT Slave 1 State Diagram NMT Slave 2 State Diagram NMT Slave 3 State Diagram Figure 12 Example Node Guarding 18 NMT Master NMT Slaves request NMT Slave1 remote transmit request RTR indication NMT Slave1 COB ID 1793 confirm NMT Slave1 7 16 0 response NMT Slave1 4 UM t 5 re
11. to enable or disable a PDO The bit determines which PDO is used in the operational state The Bits 29 and 30 may be static e g due to hardware restrictions In that case no error is signaled on the attempt to change them The sub index 2 describes the transmission character of the PDO The following table describes the usage of this entry Transmission PDO transmission cyclic acyclic sync async RTRonly 0 X X 241 251 reserved _ 252 X 253 254 Table 8 PDO transmission types mili DXX 01 07 1997 29 Implguid public doc STA Reutlingen PDO Mapping With the PDO Mapping the structure of a PDO is described Therefore a PDO Mapping data type is defined The PDOMapping data type is structured as follows Index Sub Index Field in PDOMapping Record Data Type 0021H OH number of mapped objects in PDO Unsigned8 1H 1st object to be mapped Unsigned32 2H 2nd object to be mapped Unsigned32 Table 9 PDO Mapping Structure The Sub Index 0 of the data type describes the number of entries The maximal number of entries is 64 if the granularity is 1 Granularity is defined as minimal object length in bits which can be mapped Most of the existing devices support a granularity of 8 bits which means that the objects which can be mapped are at least 1 byte and the maximal number of entries is 8 The entries from sub index 1 to the number of maximal e
12. used to mask entries in the PDO for the device This feature is useful if one PDO is used to transmit data to several devices using one PDO Symbolic mapping is useful if the data which is transmitted is described by the data itself Therefore a structure has to be defined The entries of the structure are mapped as symbolic elements into the PDO At least one entry must describe the data which is transmitted The following figure shows a multichannel device and the PDO structure In this example the channel number determines the channel of a multichannel device and the data which is transmitted is related to this channel device input 1 channel 1 input2 channel2 PDO 1 3 channel number inputX inputn_ channeln Figure 24 Symbolic mapping It is differentiated between two types of mapping the variable and the static mapping Variable mapping is useful if the entries mapped in a PDO variate dependent on the application Static mapping should be used if the entries of the PDO is fixed A mix of both types is also possible that means different static mappings are defined and they can be switched The switching can be realized by enabling or disabling the different PDOs In order to enable a PDO the PDO has be set valid in the PDOCommParam structure otherwise it has to be set not valid The following figure shows the relations between the PDO PDOCommParam structure and the PDOMapping structure
13. MS Layer Management One of the service elements of the application in the CAN Reference Model It serves to configure parameters of each layer in the CAN Reference Model Network Management One of the service elements of the application in the CAN Reference Model It performs initialisation configuration and error handling in a CAN network Process Data Object Object for process data exchange between several CANopen devices Service Data Object Peer to peer communication with access to the Object Dictionary of a CANopen device Draft Standard Draft Standard Proposal Working Draft 4 CANopen basics and overview The CANopen profile family was developed to define standardized communication mechanisms and device functionality for CAN based devices The profile family consists of a communication profile 2 and various standardized device profiles 17 19 23 The CANopen communication profile utilizes a subset of CAN Application Layer 6 16 for efficient real time communication The central concept of CANopen is the usage of an object dictionary this represents the communication and application related data To access the data two mechanisms are supported these are e Process Data Objects PDO e Service Data Objects SDO The PDO mechanism is used to transmit real time data which has to be transmitted quickly preferable without any overhead and with predefined structure This process data is either transmitted in a cycl
14. O identifier Additionally the device profiles e g DSP 401 define a default mapping for these PDOs in order to allow basic operation of the device without any parameterisation This static default identifier distribution caters for all systems with one master device controlling many slaves the Slave devices can only communicate with the master but it does not suit systems where slaves have to communicate with each other In case the slaves are to exchange data with each other it depends if they just exchange process data PDOs or if they want to communicate to each other via Service Data Objects as well In the first case the ID distribution via SDO is adequate 2 ID distribution via Service Data Object After power up a CANopen node automatically enters the state pre operational In this state a configuration master has full access to all entries of the device s object dictionary through the SDO channel that has been established by the default ID distribution This path can be used to e modify the PDO mapping if the default mapping is not suitable for the application e modify the Identifiers used for the PDOs this means one can dynamically distribute PDO ID s similar to a DBT master but in a less complicated fashion as the Slave does not have to transmit many DBT parameters already defined by CANopen in order to ask for the ID s e activate or deactivate PDOs e modify all device parameters e even modify the paramete
15. P 33 12 EMERGENCY MESSAGE 34 13 HARDWARE ASPECTS CAN CONTROLLERS MICROCONTROLLER 35 14 ID DISTRIBUTION A CANOPEN NETWORK nennen nnn annnm annt nennt 36 15 CANOPEN DEVICE PROFILES rire irruere tetra irruere ie aret anm Punico 37 16 ADDITIONAL FREQUENTLY ASKED 38 01 07 1997 2 Implguid public doc STA Reutlingen 1 Preface Since CANopen communication and device profiles are available the influence of this CAN communication standard is increasing throughout the CAN in automation arena The technology transfer center STA in Reutlingen has been strongly involved in the CANopen development from the very beginning The know how gained in many CANopen activities and implementations is the base for this document The aim of the document is e assistance for manufacturers in implementing CANopen in their devices e additional aspects for CANopen implementations e give background information e suggestions for details which are intentionally left open by the specification e answering frequently asked questions This document does not intend to replace the CANopen communication profile specification and the device profiles it will give additional information in order to clarify the CANopen c
16. VAR manufacturer status register Unsigned8 ro Unsigned32 n 003 RECORD predefined error field VAR error counter o a Unsigned32 Unsigned amp ro standard error field ARRAY number of PDOs supported Unsigned32 ro Unsigned32 ro VAR COB ID SYNC message VAR communication cycle period Unsigned32 rw Unsigned32 rw rw VAR synchronous window length Unsigned32 VAR manufacturer device name Vis String const Vis String const Vis String const VAR VAR Node ID guard time VAR manufacturer hardware version VAR manufacturer software version Unsigned32 ro Unsigned32 n VAR VAR life time factor COB ID guarding protocol w a Unsigned32 rw Unsigned32 rw RECORD 1st receive PDO communication parameter PDOComPar VAR VAR number of entries COB ID used by PDO Unsigned8 ro _Unsigned32 rw lSlslelelslslslslslsle ojojo 55 ojojo VAR CMS priority group VAR transmission type VAR inhibit time Unsigned8 rw _Unsigned16 rw rw Unsigned8 1600 ARRAY 1st receive PDO mapping parameter VAR number of mapped objects in PDO PDOMapping _Unsigned32 ro VAR 8th object to be mapped VAR 1st object to be mapped VAR nth object to be mapped Unsigned32 rw _Unsigned32 rw rw Unsigned32 1800 RECORD 1st transmit PDO co
17. aimed to operate in standard CAL networks as well you have to support the full boot up with or without DBT What kind of boot up should support on a CANopen master A As the master determines how the boot up is performed your choice is related to the features that you want to support If the CANopen specific features are sufficient a small boot up version will do CANopen ensures that you can boot all kind of CANopen slaves Q Use of SLIOs A A SLIO cannot be used as a minimum CANopen slave node A SLIO cannot provide an object dictionary thus the requirements for a CANopen node are supported furthermore it cannot be controlled by NMT services Q How is the PDO SDO allocation from the master s point of view A A master must know all its associated slaves node IDs and must be able to derive the predefined CAN identifiers from the slaves node IDs If the master does not communicate via the predefined master slave connection set it must store the identifiers in its non volatile memory Q How do I configure a master device A If a master device must be configurable it must provide an object dictionary Then the master can be configured like a CANopen slave node via its object dictionary 01 07 1997 39 Implguid public doc STA Reutlingen
18. at the standard synchronization method perfectly good at operating robot kinematics Synch Synch Telegram Telegram lt Communication Cycle y Report Command Window Window sg ORE A De Mat c2 asynchronous messa inputs and actuals commands i e outputs drive commands read at the are executed at the synch telegram next synch telegram Figure 26 CANopen Bus Timing 01 07 1997 32 Implguid public doc STA Reutlingen 11 Boot Up The CANopen boot up approach caters both for simple and sophisticated devices by defining a mandatory minimal boot up procedure that can be optionally enhanced if additional features are required The full version is equivalent to the standard CAL boot up ensuring that the whole range of CAL features is accessible However the minimal version already covers a wide range of applications The boot up procedure assumes that by default the peripheral devices do not have to know what kind of application they are operating in The network configuration takes place at one unit which can be the network management NMT master or a separate configuration tool called configuration master which remotely controls the NMT master At the boot up this master device can download the configuration data via service data objects to the configuration slaves If the slaves are capable of storing this information this only has to take place if the configuration changes CANopen defines a set of de
19. ate after power on In this state the initialization of the bus interface and a module self test can be performed There is no communication on the bus during this state The state is sub divided in 3 phases Reset Application Sets the power on values for the manufacturer specific profile area and the standardized device profile area afterwards it enters the reset communication phase Reset Communication Sets the power on values for the communication profile afterwards it enters the init phase e Init sets the default COB IDs for SDO PDO and Emergency Objects Afterwards the node automatically enters the Pre operational state Pre operational The node is now ready to communicate via the SDO channel In this state the node can be configured e g assigning PDO mapping and communication arameters set up node guarding Operational The node is fully operational The node is synchronized if required and both SDO and PDO channels are active Prepared The prepared state is used to disable a node via NMT Stop Remote Node service There is no SDO and PDO communication possible in this state The node can be set to operational state via NMT Start Remote Node service or to pre operational state via NMT Enter Pre operational state service Table 2 State diagram description The NMT services which must be supported by a minimum capability device are formatted in a pre defined structure The structure is shown in the following figure
20. ation effort e an open communication system for a wide range of manufacturers and users not dominated by only a single company less maintenance costs for protocol and software versions reduced engineering effort for system integration Q How do I configure a CANopen slave device A CANopen assumes that by default the peripheral devices do not have to know what kind of application they are operating in The devices are equipped with an object dictionary containing all parameters both communication related and application related ones For all relevant entries in this object dictionary a default value is defined in the device profile thus ensuring basic operation without any configuration need The object dictionary can be fully accessed via the Service Data Object SDO which forms a communication channel that is established between the device and the so called configuration master The configuration master can be located anywhere in a controller unit hosting the NMT master or e g in a separate configuration tool running on a standard PC The development of a Windows based configuration tool is under way Q Minimal and Extended Boot Up how does it work A The CANopen boot up approach caters both for very simple low cost devices and for sophisticated intelligent CAN nodes It allows to follow an expedited mandatory minimal boot up procedure that can be enhanced if additional features are required However the minimal version wher
21. d the sub index 0 should describe the number of entries in the structure and the following entries should store the data The following example defines a new complex data type The new data type is called information structure It is used to store the actual sensor value and status information of a multichannel closed loop controller Information Structure Index Sub Index Field Data Type number of supported entries in the Unsigned8 9 1 channel number Unsigned8 2 actual value Integer16 3 status information Unsigned8 Table 1 Information Structure 01 07 1997 10 Implguid public doc STA Reutlingen 6 CAL and CANopen CAN Application Layer CAL 6 16 was the first available open application layer specification for CAN and many users expected to get the benefits described above by simply using CAL However whilst CAL specifies a variety of data objects and services it does not intend to specify the exact use of these services but provides all elements for designing CAN communication applications One can compare CAL with a well equipped toolbox without a user manual that details which tool one has to use in order to solve a specific problem see Figure 4 Purpose of communication profile If for example a parameter set has to be downloaded to a device the entire set can be transmitted using domain transfer services or one can define each parameter to be a variable which
22. does not match length of service parameter to high Data type does not match length of service parameter to low Data cannot transferred to the application or stored Data cannot transferred to the application or stored because of local control 6 Access Error 6 Access Error 8 Other Error 8 Other Error Error Code Additional Code 2 Object non 0 existent 1 Object access 0 unsupported 1 Object access 0 unsupported 4 Invalid address 0 6 Hardware fault 0 9 Object attribute 11 inconsistent 7 Type conflict 10 7 Type conflict 7 Type conflict 0 20 0 21 Data cannot transferred to the 8 Other Error application or stored because of the resent device state 8 Other Error Object dictionary dynamic generation fails and no object dictionary is present e g object dictionary is generated from file and generation fails because of an file error Value range of parameter exceeded 9 Object attribute inconsistent 30 Value of parameter written too high inconsistent 9 Object attribute 31 Value of parameter written too low 9 Object attribute 32 inconsistent Value range of sub parameter exceeded 6 Access Error 9 Object attribute 33 inconsistent 01 07 1997 26 Implguid public doc STA Reutlingen 6 Access Error 9 Object attribute 34 inconsistent 6 Access Error 9 Object attribute 35 inconsistent Maximum value is less than minimum 6 Access Er
23. e the devices are basically switched from pre operational into operational mode and back already covers a wide range of applications In the pre operational mode the SDOs are already active enabling full access to the object dictionary of the device Synchronisation messages may already be transmitted lifeguarding may be active only the exchange of Process Data Objects is prohibited This small boot up is a subset if the extended or full boot up which is equivalent to the boot up procedure defined by CAL thus ensuring that the whole range of CAL features is accessible CANopen very carefully assures that all versions work together in the same network Any combination of master and slaves is possible e g full scale master with minimum slaves or minimum master with full scale slaves Of course a mixture of slaves is supported as well The network master determines which version of the boot up is executed as he takes his slaves through the state machine The master can take a sophisticated Slave through the full scale version whilst taking a simple device through the expedited method The slaves follow accordingly 01 07 1997 38 Implguid public doc STA Reutlingen What kind of boot up should I support on a CANopen Slave A This depends on the market segment your device is aimed at If it is aimed to operate in CANopen networks the required boot up depends on the functionality that you want to support see above If it is
24. ed request 01 07 1997 20 Implguid public doc STA Reutlingen Download Initiation Expedited Protocol Client Server COB ID 1537 Node ID 1 request Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte5 Byte 6 Byte 7 indication 7 5 43 210 Index Sub Data S 1 X n es Index COB ID 1409 Node ID 1 confirm Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 response 4 7 5 4 0 Index Sub Reserved 5 5 3 X Index Figure 15 Download Initiate and Response CCS client command specifier 1 initiate download request SCS server command specifier 3 initiate download response e transfer type 0 segmented transfer 1 expedited transfer S Size 0 data set size is not indicated 1 data set size is indicated n only valid if e 1 and s 1 if valid it contains the number of bytes which do not contain data The CCS SCS Client Command Specifier Server Command Specifier field defines the meaning of the telegram e g initiate upload download and so on The e bit informs the server if the data transfer is expedited i e that the Initiate Request also contains the relevant data A segmented download sequence is started by a client sending an Initiate Domain Download request ccs 1 e 0 s 0 If the server is willing to perform the request he should respond by transmitting an acknowledgment telegram scs 3 01 07 1997 21 Implguid public doc STA Reutlingen Download Se
25. expedited i e that the Initiate Reply also contains the relevant data no subsequent segments need to be downloaded 01 07 1997 Implguid public doc STA Reutlingen Segment Upload Client Server COB ID 1537 Node ID 1 request Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte5 Byte 6 Byte 7 indication 7 5 4 3 0 Reserved 5 5 3 t X COB ID 1409 Node ID 1 confirm Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 response P 7 5 4 8 1 0 Data ccs Ot n Figure 18 Uploading a Segment CCS client command specifier 3 upload segment request SCS server command specifier 0 upload segment response t Toggle Bit n valid bytes indicates the number of bytes in seg data which do not contain data Byte numbers 8 n 7 do not contain segment data c completion 0 more segments to be uploaded 1 no more segments to be uploaded For a segmented data transfer the client transmits the Initiate Upload request with ccs 2and the server should acknowledge the request by transmitting a response telegram with scs 2 e 0 s 1 and n number of bytes to upload The client then sends requests to the server for upload segments i e ccs 3 n 0 Note the toggle bit t of the first segment request must be zero and this bit must alternate with successive segments The server should respond to a Upload Segment request ccs 3 by transmitting a response telegram where scs 0 0 t should be identical to
26. fault identifiers which are derived from a node ID thus providing access via an SDO to the object dictionary and real time master slave communication via PDOs without any specific parameterisation Of course this default identifier distribution can be modified either by changing the appropriate parameters in the object dictionary SDO access or by employing CAL DBT services if present However applications that comprise one device that controls all others can operate sufficiently well with the default settings The minimal boot up covers only two states pre operational and operational see Figure 5 Minimum capability device state diagram After power on a device is pre operational thus giving read and write access to its object dictionary as the service communication is established using default identifiers The devices can now be configured including identifier distribution via object dictionary access if the default settings are not satisfactory With the standard CAL start remote node command then the devices are switched into operational in order to start PDO communication PDO transmission can be stopped altogether if requested by switching the device back into pre operational By using the CAL command disconnect remote node all communication parameters are reset default values e g preset identifiers are valid again All NMT commands needed for this minimal boot up use identifier 0 and are distinguished with the command specifier
27. fication February 1996 CiA DS 205 1 LMT Service Specification February 1996 CiA DS 205 2 LMT Protocol Specification February 1996 CiA DSP 401 Device Profile for Modules December 1996 CiA WD 302 Framework for Programmable Devices not yet published CiA WD 402 CAL based device Profile for Drives May 1997 CiA WD 404 Device Profile for Measuring Devices and Closed Loop Controllers not yet published CiA WD 405 CANopen Device Profile for Programmable Controllers not yet published CiA WD 406 CANopen Device Profile for Encoders May 1997 CiA WD 407 CANopen Device Profile for Public Transport not yet published 01 07 1997 4 Implguid_public doc STA Reutlingen 3 Glossary CiA CMS COB COB ID DBT LMT NMT PDO SDO DS DSP WD 01 07 1997 5 Implguid public doc STA Reutlingen CAN in Automation international users and manufacturers group e V CAN based Message Specification One of the service elements of the CAN Application Layer in the CAN Reference Model Communication Object CAN Message A unit of transportation in a CAN Network Data must be sent across a network inside a COB COB Identifier Identifies a COB uniquely in a network The identifier determines the priority of that COB in the MAC sub layer too Distributor One of the service elements of the application in the CAN Reference Model Its the responsibility of the DBT to distribute COB ID s to the COB s that are used by C
28. ger data objects The basic structure of a service data object is shown below Byte 0 Bytes 1 and2 Byte 3 Bytes 4 to 7 Initiate Command Ss a 16 bit Index 8 bit Sub Index up to 4 Bytes Profile Data expedited transfer Domain or Command 4 Bytes byte counter segmented transfer Specifier up to 7 Bytes Profile Data segmented transfer QE SSS SS Segment Command Byte 0 Bytes 1 to 7 Figure 13 Basic SDO Message Structure The multiplexor is composed of a 16bit index and a 8 bit sub index which together address a particular data object in the object dictionary of a device Note that always the client initiates the data transfer In a master slave architecture the client would be represented by the master and the server would be represented by the slave The following figure shows the differences between the expedited transfer and the segmented transfer of the multiplexed domain transfer protocol The expressions in brackets represents bits which are used by the protocol 01 07 1997 19 Implguid public doc STA Reutlingen Client Domain Download Upload Server segmented p Initiate Domain Down Upload e 0 Down Upload Domain Segment t 0 0 p Down Upload Domain Segment t 1 0 4 Down Upload Domain Segment t0 0 gt Down Upload Domain Segment tz 1 Client Domain Download Upload Server expedited lt Initiate Domain D
29. gment Protocol Client Server COB ID 1537 Node ID 1 request Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 indication 7 5 4 3 1 0 Data ccs 0 t COB ID 1409 Node ID 1 confirm Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 response 7 5 4 3 0 Reserved i P scs 1t X Figure 16 Downloading a Segment CCS client command specifier 0 download segment request SCS server command specifier 1 download segment response t toggle bit n valid bytes indicates the number of bytes in Data which do not contain data Byte numbers 8 n 7 do not contain segment data c completion 0 more segments to be downloaded 1 no more segments to be downloaded reserved Reserved for further usage x not used set to 0 Data segments are then transmitted from the client to the server with ccs 0 Domain Download Segment The n field should indicate the number of bytes in the data segment that do not contain data i e the number of filler bytes This approach is used since the domain telegram is always a fixed size CAN maximum of 8 bytes though not every byte of the remaining telegram bytes may be used for real data The c bit of the telegram sent from the client must be zero for all telegrams except the last one Setting the c bit indicates that the current telegram is the end of the current domain operation In response to the reception of a Domain Download Segment telegram i
30. ic synchronous manner or asynchronously event driven Typical data content is I O or command actual values for drives Secondly there is the parameter communication which has different requirements parameters have to be confirmed they may consist of many bytes and then have to be split in several segments parameters are typically transmitted asynchronously and the requirements towards transmission times are moderate It has to be possible to include address information in order to access a specific parameter out of a parameter list therefore the SDO mechanism is used m Process Data Object Service Data Object Used for Real Time Data Used for Non Real Time Data Synchronous Messages and Asynchronous Messages Interrupt driven Messages High Priority Identifiers Lower Priority Identifiers Optimised for High Speed Data Exchange Confirmed Services max 8 Bytes per Multi Telegram Messages Possible Format must be negotiated Uses Indexing to Reference Data between Communication Fields in Object Dictionary Partners Figure 1 Communication Mechanism All device parameters are listed in an object dictionary This object dictionary contains the description data type and structure of the parameter as well as the address The following table shows an extract of an object dictionary 01 07 1997 6 Implguid public doc STA Reutlingen Index hex Object Name VAR device type Sub Index VAR error register
31. ices Full interoperability regarding data content is achieved by employing the appropriate device profile The communication profile describes how to communicate the device profiles detail what to communicate for each type of device The following chapters are describing the CAL services used by CANopen to establish an open communication 01 07 1997 11 Implguid public doc STA Reutlingen 7 Network Management in CANopen To control the network CAL provides a complex set of services which is described in the NMT Service Specification 10 In order to simplify the network management CANopen suggested an easy to handle set of services which is described in the CANopen Communication Profile 2 The state diagram which must be supported by a minimum capability device is shown in the following figure power on 22 Pas PR 255 e 9 Initialization P Es ue 9 2 enter Precopsrational 3 3 automatically 1 E y 6 c Pre operational 2 a s Rs Nal gt Noga 3 2 m 9 Prepared 2 1 v 3 s t g pre en S OF an e My ad E enm C Operational Figure 5 Minimum capability device state diagram 01 07 1997 12 Implguid public doc STA Reutlingen The 4 states are described in the following table State Description Initialization This is the initial st
32. ined The PDOCommPar data type structured is as follows Index Sub Index Field in PDOMapping Record Data Type 0020H OH number of mapped objects in PDO Unsigned8 1H COB ID used by PDO Unsigned32 2H transmission type Unsigned32 3H inhibit time Unsigned32 4H CMS Priority Group Unsigned8 Table 6 PDO Communication Structure 01 07 1997 28 Implguid public doc STA Reutlingen The sub index 0 of the data type describes the number of entries The maximal number of entries is 4 if the device supports the identifier distribution via DBT 12 Otherwise it is 2 or 3 dependent on inhibit time supported or not The COB ID used by PDO is described by sub index 1 In order to cater for 11 bit identifiers CAN 2 0A as well as for 29 bit identifiers CAN 2 0B the entry is defined as Unsigned32 The following figure describes the format of the entry Unsigned32 bits 31 29 28 11 10 0 11 bit ID lon o 000000000000000000 11 bit Identifier 29 bit ID o1 lon li 29 bit Identifier Figure 21 Structure of PDO COB ID entry bit number value description 31 0 PDO valid 1 PDO not valid 30 0 RTR allowed on this PDO 1 no RTR allowed on this PDO 29 0 11 bit Identifier CAN 2 0A 1 29 bit Identifier CAN 2 0B 28 11 0 if bit 29 0 X if bit 29 1 bits 28 11 of 29 bit COB ID 10 0 X bits 10 0 of COB ID Table 7 Description of PDO COB ID entry The PDO valid not valid bit is used
33. mmunication parameter VAR number of entries PDOComPar _Unsigneds ro 0 1 VAR COB ID used by PDO Unsigned32 IW 2 VAR transmission type _Unsigned8 rw 3 VAR inhibit time Unsigned16 rw 4 VAR CMS priority group Unsigned amp IW 1 00 ARRAY 1st transmit PDO mapping parameter PDOMapping 0 number of mapped objects Unsigned32 1 VAR 1st object to be mapped Unsigned32 rw zu VAR nth object to be mapped Unsigned32 rw 8 VAR 8th object to be mapped Unsigned32 rw The object dictionary is organized in a communication profile specific part which contains the communication entries and in a device specific part which contains the device entries The device specific part is specified in the device profile the communication entries form the common subset of all devices therefore they are specified in the communication profile There is a range of mandatory entries in the dictionary which ensure that all CANopen devices of a particular type show the same basic behavior The object dictionary concept caters for optional device features which means a manufacturer does not have to provide certain extended functionality on his device but if he wishes to do so he must do it in a pre defined fashion Additionally there is sufficient address space for truly manufacturer specific functionality This approach ensures that the CANopen device profiles are future proof
34. ntries is shown in the following figure Byte MSB LSB index 16 bit sub index 8bit objectlength 8bit Figure 22 PDO Mapping entry The index field in the PDO Mapping entry includes the index of the object which is mapped If a record or a array is mapped the sub index field includes the sub index of the object The object length field describes the length in bits of the object which is mapped The following figure shows the relations between the objects mapped in a PDO and the object dictionary Object Dictionary Index Sub Name Index 1000h device type 1001h error register Er EE EC REGES 1800h 1 transmit PDO communication PDOComPar PDO parameter 0 number of entries 1 COB ID used by PDO Byte 0 11 3 2 transmission type 6000n 6400h ioon 3 inhibit time 4 CMS priority group Hm EE nell 1A00h 1 transmit PDO mapping parameter 0 number of mapped objects Index Sub Object Index Len 1 15 object to be mapped 6000h 1 8 2 2 object to be mapped 6400h 1 16 3 3 object to be mapped 1001h o 8 nm kane 6000h digital input PDO Mapping Structure 0 number of digital iputs 1 read 8 inputs 1H 8H 6400h analog input yj 0 number of analogue inputs 1 input 1H Figure 23 Relations between object dictionary and PDO 01 07 1997 30 Implguid public doc STA Reutlingen It is possible to perform dummy mapping or symbolic mapping by using data types Dummy mapping is
35. ode Error Code Error Class The additional Code is also broken up into the following fields Bit 15 8 7 4 3 0 Reserved Global Code Specific Code The combination of the Error Class and the Error Code explain the error which has occurred The Additional Code is necessary with some error types to give further details of the fault 01 07 1997 25 Implguid public doc STA Reutlingen Communication Protocol Errors Error Class 5 Service Error Description Toggle bit not alternated Multiplexor field or data field corrupted 5 Service Error Client server command specifier not 5 Service Error valid Time out value reached 5 Service Error Error Code Additional Code 3 Parameter 0 Inconsistent 3 Parameter 0 Inconsistent 4 Illegal 0 Parameter 4 Illegal 0 Parameter Table 4 Communication Protocol Errors Object Dictionary Access Errors Description Error Class Object does not exist in the object 6 Access Error dictionar Attempt to read a write only Object 6 Access Error Attempt to write a read only Object 6 Access Error The index value exceeds the limitations 6 Access Error of the object dictionary the index is reserved for further use index values from OOAOh OFFFh and A000h FFFFh Access failed because of an hardware error Sub index does not exist 6 Access Error 6 Access Error Data type does not match length of 6 Access Error service parameter does not match Data type
36. of general CAN hardware aspects in conjunction with CANopen Full CAN Full CAN devices contain additional hardware to provide a message server that automatically receives and transmits CAN messages without interrupting the associated microcontroller Full CAN devices carry out extensive acceptance filtering on incoming messages service simultaneous requests and generally reduce the load on the microcontroller Full CAN devices also have extended buffering capabilities Often Full CAN controllers are equipped with additional hardware witch can be used by the application e g I O Ports A good combination for a CANopen slave node is a Full CAN controller in combination with an 8 bit microcontroller where the Full CAN controller handles the communication and the microcontroller the application Basic CAN In Basic CAN configurations there is a tight link between the CAN controller and the associated microcontroller The microcontroller which will have other system related functions to administer will be interrupted to deal with every CAN message For example an interrupt is generated to check the identifier of every received message to determine if the message is relevant to the node Although the interrupts may be serviced quickly the other system loads on the microcontroller may limit the number of messages that can be processed in a given time A Basic CAN controller is suitable for a CANopen Master implementation because a master must handle
37. ommunication profile and the device profile Therefore we assume that the reader is on getting familiar with the CANopen communication profile As it is planned to improve the document comments will be appreciated and welcome by fax see cover sheet 01 07 1997 3 Implguid public doc STA Reutlingen 2 References i 2 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ISO 7498 1984 Information Processing Systems Open Systems Interconnection Basic Reference Model CiA DS 301 CANopen CAL based Communication Profile for Industrial Systems October 1996 Version 3 0 ISO DIS 11898 1992 Road Vehicles Interchange of Digital Information Controller Area Network CAN for high speed Communication Robert Bosch GmbH CAN Specification 2 0 Part B September 1991 CiA DS 102 CAN Physical Layer for Industrial Applications April 1994 CiA DS 201 CAN Reference Model February 1996 CiA DS 202 1 CMS Service Specification February 1996 CiA DS 202 2 CMS Protocol Specification February 1996 CiA DS 202 3 CMS Encoding Rules February 1996 CiA DS 203 1 NMT Service Specification February 1996 CiA DS 203 2 NMT Protocol Specification February 1996 CiA DS 204 1 DBT Service Specification February 1996 CiA DS 204 2 DBT Protocol Specification February 1996 CiA DS 207 Application Layer Naming Speci
38. or Programmable Devices 405 CANopen Device Profile for Public Transport 407 Table 12 Device profiles in preparation 01 07 1997 37 Implguid public doc STA Reutlingen 16 Additional Frequently Asked Questions Q What is the philosophy behind CANopen A CAN is a very powerful communication system that provides many advantages CANopen makes the benefits of CAN available for the user without bothering him with complex details concerning e g parameterisation of communication services identifier distribution real time tuning of CAN networks For the manufacturer of CAN components CANopen provides significant cost advantages as CANopen was designed to enable lean but powerful protocol implementations A Slave can be implemented with less than 4kByte of ROM and less than 100 Bytes of RAM The profile family provides an easy to use application interface that includes access to all device parameters and functions via procedure calls CANopen allows the realization of multi vendor systems containing a wide range of automation components Besides the excellent real time performance both with event driven and cyclic behavior the system supports the quick transmission of asynchronous data like device parameters or programs As CANopen is based on a CAL subset devices employing these profiles can operate in a CAL environment if desired CANopen was designed to provide good balance between functionality and implement
39. own Upload e 1 Figure 14 Multiplexed Domain Transfer Protocol The Service Channel provides the following services e Expedited Transfer of Data of size less than or equal to 4 bytes This transfer mechanism needs the transfer of 2 CAN messages only Initiate Request Initiate Response e Segmented Transfer of data whose size is greater than 4 bytes All data objects with more than 4 bytes in size are transferred as a sequence of Segment Commands preceded by an Initiate Command This mechanism needs the exchange of at least 4 CAN messages e Transfer of a Data Identification Set Index and Sub Index as used in device profiles with the data Feedback of Error information with the Server Reply message with optional data set identification Abort of Data transfer by either Client or Server with error feedback and optional data set identification The service primitives request indication response and confirm are used to describe the interaction between the application and the CMS service element in the application layer as follows arequest is issued by the application to the application layer to request a service an indication is issued by the application layer to the application to indicate that a service is requested aresponse is issued by the application to respond to a previous received indication e a confirm is issued by the application layer to the application to report on the result of a previously issu
40. quest Slave2 remote transmit request RTR indication NMT Slave2 GOBiDzi794 b confirm NMT Slave2 response NMT Slave2 gt 7 6 0 5 4 o t 5 E request NMT Slave3 remote transmit request RTR indication NMT Slave3 COB ID 1795 9 confirm NMT Slave3 7 16 0 response NMT Slave3 S amp 4 t A 4 o request Slave1 remote transmit request RTR indication NMT Slave1 o 5 g S mg m o E Slave2 remote transmit request RTR indication NMT Slave2 2 gt 6081021794 x o o E confirm NMT Slave2 7 60 response NMT Slave2 5 2 4 14 o 5 a request NMT Slave3 remote transmit request RTR indication NMT Slave3 x COB ID 1795 confirm Slave3 7 6 0 response NMT Slave3 5 S lt 77 o i t S S R J aaa 2 9 lt remote error Slave 1 p 5 detected _ p 5 e N p N p SE 7 a 2 eee ee Implguid_public doc STA Reutlingen 8 Service Data Object The service data object uses the Multiplexed Domain Transfer Protocol 8 to access the object dictionary of each device The type of data transferred may range from a simple boolean to a large file To meet the requirements of the different data types there are two transfer mechanisms introduced by the Multiplexed Domain Transfer Protocol these are e the expedited transfer is used for all data objects up to 4 bytes length e the segmented transfer is used for lar
41. red in the object 1003h pre defined error field In this object the latest error is stored at sub index 1 The numbers of errors which occurred are stored in sub index 0 The error list can be flushed by writing O to the sub index 0 The following table gives an overview of the emergency error codes defined in the Communication Profile DS301 2 Error Code hex Meaning 00 No Error 10xx Generic Error 20xx Current 21xx Current device input side 22xx Current inside the device 23xx Current device output side 30xx Voltage 31xx Mains Voltage 32xx Voltage inside the device 33xx Output Voltage 40xx Temperature 41xx Ambient Temperature 42xx Device Temperature 50 Device Hardware 60xx Device Software 61xx Internal Software 62xx User Software 63xx Data Set 70xx Additional Modules 80xx Monitorin 81 Communication 90xx External Error FOxx Additional Functions FF xx Device specific Table 10 Emergency Error Codes The emergency telegram is formatted as follows Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Emergency Error Error Code Register Object 1001H Manufacturer specific Error Field Figure 27 Mapping Emergency Message 01 07 1997 34 Implguid public doc STA Reutlingen 13 Hardware Aspects CAN controllers Microcontroller The following chapter gives an overview
42. ror 9 Object attribute 36 value inconsistent Object cannot be mapped to the PDO 6 Access Error 4 Invalid address 41 PDO length exceeded 6 Access Error 4 Invalid address 42 General parameter incompatibility 6 Access Error 4 Invalid address 43 reason General internal incompatibility in the device Value of sub parameter written is too high Value of sub parameter written is too low 6 Access Error 4 Invalid address 44 Table 5 Object Dictionary Access Errors 01 07 1997 27 Implguid public doc STA Reutlingen 9 Process Data Object The Process Data is transmitted with the CMS Objects of the Stored Event Protocol according to the CAL specification 7 This protocol allows to use up to 8 bytes of a CAN message for process data The process data that have to be transmitted in the Process Data Objects PDO have to be defined in the PDOMapping structure The way how to transmit the data is described in the PDO communication structure server client request yes DET upto8 byte mo indication indication indication client server request remote transmit request RTR gt P indication p Byte 0 Byte 8 confirm esponse F up to 8 byte 4 resp Figure 20 Stored Event Protocol PDO Communication Parameter With the PDO Communication Parameters the transmission behavior of a PDO is described Therefore a PDO Communication data type is def
43. rs related to nodeguarding as they are included in the object dictionary of the device as well e up and download software DBT services are required in CANopen systems when there is the need to modify SDO identifiers e g to establish additional SDO channels between slaves 3 ID distribution via DBT services This follows standard CAL procedure where the NMT master may kick off DBT Slave functionality in a device by setting a parameter in the Prepare Remote Node Request during boot up CANopen supports DBT services e g by permitting to start DBT services directly from the pre operational status but only requires them when SDO identifiers have to be modified e default identifier distribution e Identifier distribution via SDO e Identifier distribution via CAL distribution DBT 01 07 1997 36 Implguid public doc STA Reutlingen 15 CANopen Device Profiles CANopen Device Profiles are used to describe a class of devices The following CANopen device profile specifications are available Device Profile for Modules 1 3 401 um Revision CiA Draft Standard Proposal 1 0 i CANopen Device Profile for Drives and Motion Controller CANopen Device Profile for Encoders 1 0 406 Table 11 Device profiles The following CANopen device profile specifications are in preparation Title CiA Work Draft CANopen Device Profile for Measuring Devices and 404 Closed Loop Controllers CANopen Device Profile f
44. te Node service forces the NMT Slave into the operational state The protocol is executed and formatted as follows NMT Master COB ID 0 NMT Slave request Byte 0 Byte 1 cs 1 Node ID _ eee indication indication gt indication Figure 7 NMT Start Remote Node service 01 07 1997 14 Implguid_public doc STA Reutlingen 7 2 NMT Enter Pre operational State 8 The NMT Enter Pre operational State service forces the NMT Slave into the Pre operational state The protocol is executed and formatted as follows NMT Master COB ID 0 NMT Slave request Byte 0 Byte 1 gt cs 128 0 gt CS MER indication indication indication Figure 8 NMT Enter Pre operational State service 7 3 NMT Stop Remote Node 7 The NMT Stop Remote Node service forces the NMT Slave into the Prepared state The protocol is executed and formatted as follows NMT Master COB ID 0 NMT Slave request Byte 0 Byte 1 2 Node ID 11 ARE indication indication indication Figure 9 NMT Stop Remote Node service 01 07 1997 15 Implguid public doc STA Reutlingen 7 4 NMT Reset Node 10 The NMT Reset Node service forces the NMT Slave into the Initialization state There it enters the Reset Communication phase The protocol is executed and formatted as follows NMT Master COB ID 0 NMT Slave request
45. the t field of the request and should be zero except for the last segment to be uploaded The n field should indicate the number of bytes not containing data in the data segment of the telegram 01 07 1997 24 Implguid public doc STA Reutlingen Abort Transfer for segmented transfer Client Server Server Client request Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte5 Byte 7 indication 7 5 4 0 Index Sub appl error codes ccs 4 n Index Figure 19 Domain Transfer Abort Protocol CCS command specifier 4 abort domain transfer appl error codes specified for CANopen devices in their individual specifications Both non expedited upload and download domain services can be aborted be either client or server by transmitting a packet of the segment protocol with the completion flag c set to one see above However this merely conveys the fact that the transmission is over it does not indicate an error occurred since this is the normal transmission termination sequence The error status along with optional Data Set Identification can be reported in the data fields of the Abort Telegram ccs 4 In case of the expedited transfer the Abort Telegram would replace the Download or Upload Initiation Response The appl error codes field is a 32 bit value composed of the following elements Error Class 1 Octet e Error Code 1 Octet e Additional Code 2 Octet Byte 4 6 7 8 Additional C
46. used to store information which attains the values TRUE and FALSE The values are encode in one byte Value Encoding TRUE FALSE 0H Integer8 The Integer8 data type is used to store one byte signed values Value Range 80H 7FH 128 127 Integer16 The Integer16 data type is used to store two byte signed values Value Range 8000H 7FFFH 32768 32767 LSB MSB Low High Byte Byte Integer32 The Integer32 data type is used to store four byte signed values Value Range 80000000 H 7FFFFFFFH 2147483648 2147483647 LSB MSB Byte 0 Byte1 Byte2 Byte3 Data Data Data Data Unsigned8 The Unsigned8 data type is used to store one byte unsigned values Value Range FFH 0 255 01 07 1997 9 Implguid public doc STA Reutlingen Unsigned16 The Unsigned16 data type is used to store two byte unsigned values Value Range OH FFFFH 0 65536 LSB MSB Low High Byte Byte Unsigned32 The Unsigned32 data type is used to store four byte unsigned values Value Range FFFFFFFFH 0 4294967295 LSB MSB Byte 0 Byte1 Byte2 Byte3 Data Data Data Data Float The Float data type is used to store four byte real values The encoding of the values is according to the IEEE 754 1985 standard New Data Type Definitions New data types have to be defined in the object dictionary section for Manufacturer Specific Data Types If a new complex data type is define
47. which divides the time axis in equidistant communication cycles see Figure 26 CANopen Bus Timing The synch message does not contain data and can be used as an interrupt by I O modules to then set outputs or read inputs Intelligent devices like drives can synchronize e g using the PLL method In the report window right after the synchronization telegram the drives send their actual and the I O modules send their input values Afterwards in the command window the commands and the output values are transmitted which are then set valid at the next synch signal As the report window directly follows on the synch signal it can be hit even by simple components without using timers Bandwidth not used inside the windows and the time between the command window and the synch telegram is available for low priority SDO messages As the synchronization telegrams are optional it is also possible to operate CANopen networks in totally asynchronous manner if desired However bus traffic and processor loading are much more predictable if bus synchronization is used For applications that require optimal synchronization the synch message may jitters slightly due to bus traffic at the synch transmission time an optional high resolution synchronization method has been specified which uses time stamping of synch messages This enhanced synchronization is especially useful for low speed networks with hard synchronization requirements However it has been shown th
Download Pdf Manuals
Related Search