Turmgasse Ulm. Tel / Fax 0731 / frenzel + berg electronic. CANopen.

Transcription

1 Turmgasse Ulm Tel / Fax 0731 / info@frenzel-berg.de frenzel + berg CANopen guideline

2 (as used in EASY-Components by frenzel + berg ) 1 Introduction CAN is short for Controller Area Network and was originally developed by the companies Bosch and Intel as a bus system for vehicles (autobus). In the meantime, CAN also approved itself in the area of automation technology as field bus. Just as practically every field bus, CAN is also based on the OSI 7- layermodel. CAN is not only for the OSI layers 1 and 2 in ISO standardized. The missing" application layer is defined through the on CAN lying layer 7 protocols DeviceNet, SDS, CAL and the CANopen profiles. CAN-Bus is a serial bus system, in which all connected stations are equal, i.e. every control device (CAN-node) can transmit and receive. Simply expressed, the connected control devices can communicate through the conductors and exchange information. Thanks to the linear structure of the network, the bus system is further fully accessible to every station in case of a breakdown of one single station. device coupling via CAN-bus CAN CAN CAN CAN 120 Ohm CAN-bus 120 Ohm Figure 1: Device coupling through CAN-bus 1.1 Concept of data interchange In CAN-Bus-data interchange, no stations are addressed, but the content of a message is marked with a explicit numeral code (identifier). In addition to this content marking, the identifier also determines the priority of the message. If any station wants to transmit a message, it turns over the message and identifier to the CAN-Controller. This controller takes the message. If it transmits presently as the only one, or its message has highest priority, all the other CAN-Controllers in the network receive this message. Yet in the receiving CAN- Controller the selection is made, if this message is necessary for the own station. To accomplish the selection, the CAN-Controller is notified during the initialization, which messages have to be assigned to the station. If the received message is uninteresting for a station, it s CAN-Controller ignores it. The message transmission occurs one bit at a time on a differential conductor pair (CAN-high and CANlow-conductor). Thereby two conditions are differed for the bit information (dominant = 0 and recessive = 1). frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 2 von 2

3 (as used in EASY-Components by frenzel + berg ) 1.2 Layout of the CAN-telegram The number of bits in a telegram depends on the size of the data field. The information of a message is included in the identifier and in the eventual additionally transmitted data bytes. The identifier is part of the status field in the CAN-telegram and delivers the information in signals (user defined meaning), while in the data field up to 8 bytes can be sent along as variables. CAN-telegram status field control field data field protection field confirmation field end field frame Figure 2: CAN-telegram (bit-stream) In the ISO11898 standard, two telegram formats are defined, which are also supported by CAN-Open. This is the standard-format with a 11-bit identifier and the extended-format with a 29-bit identifier, which is composed from the 11-bit identifier and the 18-Bit sub index. The architecture of the telegram allows the use of both types in one network. telegram-area explanation start field start bit of the telegram status field Includes the identifier and the referring status bits (see 1.2.1) control field data field safety field confirmation field end field Figure 1: telegram structure 1 Includes among other things the number of the bytes included in the data field (see 1.2.1) Here can additional information/variables (up to 8 byte per telegram) be transmitted. (the number of data bytes are transmitted in the control field) safety field (16 bit); It includes a frame protection word for detection of eventual occurring transmission disturbances. confirmation field (2 Bit); In the confirmation field the receivers signalize the transmitters if the data transmission is correct or incorrect. The feedback signal happens through these bits being overwritten in the transmission telegram by at least one receiver. Since the transmitter is tracking its own transmission, it detects this feedback and can react according to it. (e.g. repeat telegram) end field (7 Bit); The data protocol ends through the notification in the end field. In the end field exists the last possibility to report transmission disturbances which lead to a repetition. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 3 von 3

4 (as used in EASY-Components by frenzel + berg ) CAN-identifier and control field standard format (11-bit identifier) status field control field SOF: start bit 11Bit ID: message-index RTR: remote transmission request IDE: Iientifier extension bit r0: reserved DLC: data length code (4Bit) byte Figure 3: CAN-telegram in standard format 11-bit ID Therewith a minimum telegram length of 44 bit at 0 data byte information volume is given extended format (29-bit Identifier) status field control field SOF: start bit 11Bit ID: message identifier (node-id) SSR: substitute remote request IDE: identifier extension bit 18Bit ID: ID-extension RTR: remote transmission request r1, r0: reserved DLC: data length code (4Bit) byte Figure 4: CAN-telegram in standard format 29-bit ID Therewith a minimum telegram length of 62 bit at 0 data byte information volume is given bits SOF 11-bit-ID 18-bit-ID IDE RTR SRR r0, r1 DLC explanation start bit of telegram identifier as 11-bit value. The smallest value has the highest priority identifier expansion as 18-bit value. With the same 11-Bit-ID the smallest value has the highest priority. Indicates, if the telegram has a 11- or 29-bit identifier (dominating with 11-Bit-ID). Indicates, if the telegram is a data telegram or a specification frame. confirmation field (2 bit). In the confirmation field the receivers signalize the transmitters, that they received the data protocol correctly. If an error is recognized, the transmitter is notified. The transmitter repeats the transmission. reserved data length code (4 bit). The DLC includes the number of data bytes in the telegram frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 4 von 4

5 (as used in EASY-Components by frenzel + berg ) Figure 2: telegram structure 2 Therewith the CAN-Bus is a universal transmission media for any data, in which the protocol and the data protection method of the controller are strongly minimizing transmission. 1.3 The arbitrating in the CAN-network The CAN-Bus is a network with multimaster functionality. All participants are in principle equal. From sides of the bus-conception a Question/Answer behavior is not intended. In fact every participant ought to initiate its data transmission itself. The arbitrating ought to occur within a message and without destroying it. On the bus, the levels are designated active according a 0 in the CAN-telegram as dominating, and passive according a 1 in the CAN-telegram as recessive. Thereby a dominating level overwrites a recessive bus condition in general. That means, that a small CAN-node which tries to transmit a recessive level to the bus, is being overwritten by a dominant transmitting node. Every CAN-node is overhearing the bus on principle. A transmission may only be started, if the bus is presently not occupied by a CAN-telegram. During transmission the current bus condition is always being compared with the own transmission frame. If multiple controllers start a transmission simultaneously, the first dominant bit on the conductor determines over the prioritization (dominance has preference) of the message. If a CAN-node, which intended to write a recessive level to the bus, recognizes the bus possessing a dominant level, the own transmission will be aborted and attempted again later. The more important message (message with the smallest identifier) remains thereby accurate on the bus. As sample point about ¾ of one bit time is used. Thereby, following requirements result: 1) Because in the CAN-telegram a 0 represents the dominant level o the bus, the CANidentifiers are prioritized higher with lower numbers. So, the more important a bus message, the lower the used identifier has to be chosen. 2) The prioritization always occurs within one half bit. Consequential every participant in the network has to lie within a power delay of 1 bit time (accurate ¾). This refers to the way forth and back of the signal. 3) Because the arbitrating has to occur within the identifier, every identifier may only have one transmitter. This transmitter, however, may be received by multiple nodes. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 5 von 5

6 (as used in EASY-Components by frenzel + berg ) 1.4 Bus length The following bus lengths approximately result from the requirements of the arbitrating. The values serve as clues and can differ, depending on the used bus transceivers or galvanic isolation, especially worsen. bitrate bus length nominal bit time 1 Mbit/sec 30 m 1 usec 800 kbit/sec 50 m 1,25 usec 500 kbit/sec 100 m 2 usec 250 kbit/sec 250 m 4 usec 125 kbit/sec 500 m 8 usec 50 kbit/sec 1000 m 20 usec 20 kbit/sec 2500 m 50 usec 10 kbit/sec 5000 m 100 usec The bus lengths are rough clues in use of ISO11898 compliant drivers, standard bus conductors without regard of optocouplers. These especially occur in high transfer rates. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 6 von 6

7 (as used in EASY-Components by frenzel + berg ) 2 CANopen Like practically every field bus, CAN is also based on the OSI 7-layer model. CANopen structure CANopen device profile CiA / DS40x ISO/OSI layer 7: application layer communication profile CiA / DS30x ISO/OSI layer 2: data link layer ISO/OSI layer 1: physical layer CAN standard ISO CAN Figure 5: structure model of CANopen CANopen is the open protocol standard for CAN in the field of automation technology and has been standardized by the association CAN in Automation (CiA). The protocol is using the CAN-bus for transmission and is setting up the basic structures for network management, the use of CAN-identifiers (message address), the chronological behavior on the bus, the type of data transfer, and application related profiles. This is ought to grant CANopen-components of different manufacturers to be combined (for the devices communicating with the same language). CANopen defines the application layer (die OSI-layer 7) as a communication profile, which was standardised by the CiA in the standard DS30x for all applications equally. It assigns, how the communication is ought occur. Like with some other field buses the parameter data is differed from the real time data. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 7 von 7

8 (as used in EASY-Components by frenzel + berg ) CANopen describes the properties of devices in so called device profiles. These are in principle defined variable sentences. According to the device type, specific data or parameters (declared in CANopen as objects) are strictly defined. The device profiles have been described by the CiA in the DS40x standards. device profiles (CiA) DS 401 DS 402 DS 403 DS 404 DS 405 DS 406 DS for the device types digital and analog I/O engines operate an observe sensors / regulators programmable devices encoder (further device types) Figure 3: Example DS40x device profiles 2.1 Object directory The object directory is the composition of all variables and parameters (objects) of one CANopen device. Thereby the data obtains the process image and with parameters the function behavior of a CANopen device can be influenced. An object directory is structured, that parameters of all devices in this category are necessarily instructed and others may be free defined and used. The objects gain primarily a number (index), which are used to explicitly identify and address them. The objects can be realized as easy data types like bytes, integers, longs or even strings. For more complex structures like arrays and structures, the single elements are addressed by creating a sub index. The object directory s structure, the allocation of the index numbers just as some liability entry s are specified in the device profiles. For the user, the object directory is saved as EDS-file ( data sheet). In the EDS-file all objects are saved wit index, sub index, name, data type, default value, minimum, maximum and access possibilities (read/write, transfer only via SDO or even via PDO etc.). Thereby, using the EDS-file, the whole functionality of a CANopen device is described. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 8 von 8

9 (as used in EASY-Components by frenzel + berg ) Principal declaration of object index numbers object index (hex) object 0000 not used F static data types F complex data types F manufacturer specific complex data types F device profile specific static data types F device profile specific complex data types 00A0-0FFF reserved for further use FFF communication profile area FFF manufacturer specific profile area FFF standardized device profile area A000 - FFFF reserved for further use Figure 4: generic structure of a CANopen object directory Example for a object directory: cut out from the directory of the CANopen chip index sub-index name Acc. PDO-mapping dummy 8 ro Yes dummy 16 ro Yes 100B - node ID ro - 100C - guard time rw - 100D - life time factor rw - 100E - COB-ID guard rw store parameters *1) wo reload default parameter *1) wo COB ID emergency rw inhibit time emergency rw producer heartbeat time rw identity object 0 (no. of subentries) ro - 1 vendor ID ro - 2 product code ro - 3 revision number ro device manufacturer *3) ro new node ID *4) rw system configuration ro to n read digital input 8-bit ro Yes to n polarity input 8-bit rw to n filter constant enable 8-bit rw global interrupt enable rw to n Interrupt mask: any change rw to n Interrupt mask rising edge rw - frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 9 von 9

10 (as used in EASY-Components by frenzel + berg ) CANopen communication The data exchange in CANopen occurs with telegrams, used to transmit reference data. Thereby, service data objects, used for transmission of service data from and to the object directory, and process data objects, attended for exchange of current process condition, are differed. Additionally telegrams for network management and error messages are being defined. In principle all entries of the object directory can be accessed using SDOs. In practice, SDOs are mostly used only for initialization during the boot process. Inside a SDO only one object can be accessed. SDOs are principally answered. PDOs are principally a summarization of objects (variables or parameters) from the object directory. In one PDO, maximal 8 bytes can exist, which can be put together from different objects. Roughly speaking, the objects are mapped into a PDO. PDO (process data object) SDO (service data object) - real time data - telegram is unanswered (fast transmission) - high priority identifier - max. 8 bytes / telegram - pre-declared data - system - parameter - telegram is answered (slow transmission) - low priority identifier - data split to multiple telegrams - index addressable data Figure 5: communication types in CANopen In favor of network management, CANopen resigns the multimaster ability of the CAN-bus and introduces a CAN-master, which assumes the tasks of the network management. Every further CAN-node is implemented as so called slave assemblies. For network management and error messages there are pre defined logic communication channels like - communication objects for the boot-up of the net start, stop, reset of a node etc. - communication objects for dynamic identifier distribution according to DBT - communication objects for nodeguarding and lifeguarding thereby an observation of the network is possible - a communication object for synchronization - communication objects for emergency messages These are strictly defined in CANopen and possess a global news character (broadcast) frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 10 von 10

11 (as used in EASY-Components by frenzel + berg ) 2.3 default identifier allocation A default identifier allocation saves configuration effort. Thereby the node number is embedded in the identifier. The default identifier allocation is defined in CAN open as followed: identifier 11- bit (binär) identifier (dezimal) identifier (hexadezimal) function network management h synchronization 0001xxxxxxxx h - FFh emergency 0011xxxxxxxx h - 1FFh PDO1 (tx) 0100xxxxxxxx h - 27Fh PDO1 (rx) 0101xxxxxxxx h - 2FFh PDO2 (tx) 0110xxxxxxxx h - 37Fh PDO2 (rx) 0111xxxxxxxx h - 3FFh PDO3 (tx) 1000xxxxxxxx h - 47Fh PDO3 (rx) 1001xxxxxxxx h - 4FFh PDO4 (tx) 1010xxxxxxxx h - 57Fh PDO4 (rx) 1011xxxxxxxx h - 5FFh SDO send 1100xxxxxxxx h - 67Fh SDO receive 1110xxxxxxxx h - 77Fh NMT error control xxxxxxxx = node number Figure6: default-identifier CANopen offers a complete free configuration of identifiers. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 11 von 11

12 (as used in EASY-Components by frenzel + berg ) The service data object SDO All CANopen assemblies have a so called object directory, through which all parameters provided by the assembly can be accessed. As per object directory rendered, object data offers a 16-bit index, through which a parameter can be chosen directly. Additionally every index has a 8-bit-sub-index, which allows a further partitioning within an index. Therefor a service data telegram has to possess a protocol structure, which determines exactly which parameter is addressed and what occurs to the parameter. A service data object adds up from a domain protocol (8-bit), the index (16-bit), the sub-index (8-bit) and up to 4 data bytes together. Thereby the domain protocol includes the action, which has to follow the parameter, referred with index and sub index. If parameters shall obtain new values, these can be transmitted within the data bytes. - upload - download - data length - expedited transfer - segmented transfer - abort - toggle bit The 8 bytes of the SDOs (as displayed above) are placed within the data range of the CAN-message. The node s addressing occurs via the SDO in the message identifier. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 12 von 12

13 (as used in EASY-Components by frenzel + berg ) SDO transfers always comprise at least two telegrams. SDO Download Protocol Byte 0 Byte 1+2 Byte 3 Byte 4-7 Request Confim Byte 0 Byte 1+2 Byte 3 Byte 4-7 Indication Response SDO Upload Protocol Byte 0 Byte 1+2 Byte 3 Byte 4-7 Request Confim Byte 0 Byte 1+2 Byte 3 Byte 4-7 Indication Response 2.2 The process data object PDO The process data exchange via CANopen is purely CAN-bus, i.e. without protocol overhead. The broadcast feature of CAN-bus is completely persistent. Thereby, a message can be received and analyzed by all nodes (producer-consumer model). The fixed master/slave principle is thereby in use of data exchange via PDOs abolished. Because the protocol structure is missing within the telegram, it is necessary that the participants at the bus, for which these data is determined, know, how the information is embedded in the PDO s data range (which bit/byte is which value). Therefor, this declaration occurs in advance during the initialization of the network with the so called PDO-mapping, which grants to place the desired information at a specific position in the PDO s data range. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 13 von 13

14 (as used in EASY-Components by frenzel + berg ) PDO-Mapping To grant a variable configuration of the PDO data, the mapping itself is accomplished in a special mapping object. In principle this is a sheet, in which the objects are entered to be mapped. The exchange of process data can happen through different types, which can occur in a network simultaneously (in various types) Event controlled Data transfer In event controlled data transfer, the data of a node is being sent as message, as soon as a change occurs at the previous status. 1) If for example the level changes at a digital input of a CAN-I/O-device, this will cause the transmission of the assigned message (PDO). 2) For instance, if a node holds thresholds for an analog value, and the swell is reached, also the assigned message is being sent (PDO). frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 14 von 14

15 (as used in EASY-Components by frenzel + berg ) Polling with remote frames In remote frame polling, the CAN-node functioning as master in the network is generally requiring the desired information through request (via remote frame). The node holding this information (or the required data) then answers by transmitting the requested data. Because in CANopen the message identifier also holds the device addressing (a part of the ID is specified as node number), the query normally is targeted at a specific device. All other CAN-controllers in the network are ignoring the query. 1) For instance the master possesses a visual process data display on which the menu for the speed indicator servo drive 2 has just been opened. Because the speed of the drive isn t required for the rest of the process, the master can query via remote frame cyclic as long as the display menu is opened Synchronized mode CANopen allows simultaneous query of different participants inputs and states, and change outputs or states simultaneously. This is what the synchronization telegram is for (SYNC). The sync-telegram is a broadcast to all bus participants with high priority and without included data. The sync-telegram is being sent cyclic in fixed intervals (communication cycle) by a bus participant (most likely the master). Devices not working in synchronized mode, are reading their inputs (actual status) when they receive the sync-message and send the data subsequently, as soon as the bus allows this. Raw data (via bus instructed status variation) are written (or executed) not until the next sync-telegram. Figure 6: synchronization in CANopen frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 15 von 15

16 (as used in EASY-Components by frenzel + berg ) The clearance between two sync telegrams is nominal partitioned in message window, command window and free window. However, the length of the message window is not being monitored. Thereby it is possible to put through input data of one device to the outputs of another even in synchronized mode. As it can be easily seen in the previous description, this mode leads to an enormous strain of the bus, if every participant begins its data transfer after every sync telegram. In fact, however, not every participant will have to react to every sync message. Therefor, two procedures have been defined: Event controlled synchronization As in event controlled data transfer, no message is being sent, as long as the status of the parameter (inputs in I/O-modules) is unmodified. I.e. it is compared, when a sync telegram is received, if a change of the own parameters/data occurred since the last update. If not, no data is being sent. However, if changes are registered, these are being sent after reception of the sync message Separated (timer-) synchronization In timer-synchronization the participant holds a constant n, which determines at which sync telegram the data has to be refreshed. (If n = 3, an update occurs every third SYNC). This may be adjustable by the manufacturer in the device, or in the object directory Time controlled transmission In time controlled transmission, the transmission of a PDO is initiated through the expiration of a adjustable time. frenzel + berg GmbH & Co.KG * Turmgasse 4 * Ulm Seite 16 von 16