Technical information CANopen 1 in machines and installations

Transcription

1 CANopen is an application layer protocol based on the controller area network (CAN). Bosch designed CAN for automotive applications in the early 1980s. Its use in the automotive industry has proved its suitability in difficult environments. CAN is a serial bus system based on a publisher subscriber model. In the publisher subscriber model the publisher sends a message to the subscribers. In CAN this has been implemented using a broadcast architecture. The sender (publisher) broadcasts the message together with an identifier on the bus. The receivers monitor all traffic on the bus. If the identifier matches the filtering criteria of the subscription the client reads and processes the complete message. This turns the receiver into a subscriber. Producer Consumer(s) request payload: 0 to 8 octets indication This is the push mode of the publisher subscriber model. CAN also supports a pull mode of the publisher subscriber model. A consumer may trigger the transmission of a message with a remote transmission request. The remote transmission request (RTR) is a CAN frame with the RTR flag set. When the producer receives such a request is transmits the associated message. Producer Consumer(s) request payload: 0 octets indication response payload: 0 to 8 octets confirmation(s) A problem that normally arises with a broadcast architecture is that different network nodes may send at the same time. CAN solves this problem with two mechanisms. Firstly, a sender monitors the medium to check whether another node is already sending. If the medium is free the node starts sending. Several nodes may start sending never the less at the same time. CAN solves this with a priority scheme. Idle SOF identifier RTR IDE r0 DLC Data FCS ACK EOF IFS Idle A CAN frame starts with a start of frame (SOF) bit. Eleven identifier bits follow from the most significant bit to the least significant bit. The next bit is the remote transmission request (RTR) bit followed by five control bits and up to eight bytes payload. The control bits are the extended ID (IDE), a reserve bit, and three bits encoding the length of the payload in the data part (DLC) in bytes. A frame check sequence (FCS) follows after the payload of up to eight bytes. The sender transmits a recessive ACK bit, which will be overwritten with a dominant bit by the receivers that have received the frame without error at this point of time. The end of frame (EOF) bit signals the end of the message. 62

2 The bus must remain in recessive state for intermission frame space (IFS) bit lengths before the next frame starts. If no node is ready to send the bus will remain idle. The bit encoding on the medium has a dominant and a recessive value. If two nodes send at the same time, a listener will only see the dominant value. In the binary encoding the value '0' is dominant and the value '1' is recessive. When a node is sending it is always listening on the bus. If it is sending a recessive value and is receiving a dominant bit it stops sending and continues listening only. This simple mechanism avoids collisions on the CAN bus. The message with the lower identifier wins the bus arbitration. SOF Identifier Controlfield RTR Data (0...8 octets) Node Node Node 1 is listening only Node Node 2 is listening only CAN bus Node 1 looses arbitration Node 2 looses arbitration Arbitration phase Time CAN is a carrier sense multiple access, with collision detection and arbitration on message priority, (CSMA/CD+AMP) bus system. As the collision in true sense does not occur in CAN it is often described as CMSA/CA (carrier sense multiple access with collision avoidance). The CAN message frame described above is a basic message frame. For applications, which need a larger set of identifiers, the extended CAN message frame has been defined. The extended frame has 18 additional ID bits in the header after the control bits. This extends the range from 2 11 to 2 29 different identifiers. Both frame types can coexist on one bus. CAN has three different mechanisms to detect erroneous messages: b The frame check sequence (FCS) contains the cyclic redundancy check (CRC) of the frame. The receiver also computes the CRC of the frame and compares its own result with the FCS. If they are not equal the frame has a CRC error. b The receiver detects errors in the structure of the frame. If the frame has a faulty structure, the frame has a format error. b The receiver of a frame issues a dominant acknowledge (ACK) bit if it has received a frame without error. If the sender does not receive a dominant ACK bit, it generates an acknowledgement error. b The sender also monitors the bits on the bus. If a bit is sent and the received counterpart differs, the sender recognizes an error. b CAN uses no return to zero (NRZ) coding with bit stuffing. If the sender should transmit five equal bits in a row it introduces an additional inverted bit. This bit stuffing enables the receiver to synchronize on the bit stream. The receivers remove the stuffed bits from the transmitted frame. If more than five bits have the same value, the receiver recognizes a bit stuffing error. There are several application level protocols on top of CAN available, such as DeviceNet and CANopen, as CAN does not define an application level protocol by itself. 63

3 CANopen defines an application layer and communication profile based on CAN. CANopen defines the following communication objects (messages): b Process data object (PDO) b Service data object (SDO) b Network management object (NMT) b Special function object (SYNC, EMCY, TIME) Properties b Serial data transmission based on CAN b Up to 1 Mbps b Efficiency approx. 57 % b Up to 127 nodes (devices) b Multi master capable b Interoperability of devices from different vendors Object dictionary The object dictionary is the interface between the application program and the communication interface. Communication interface Object dictionary Application process Process data object (PDO) Process data objects are used for fast transmission of process data. A PDO can carry a payload of 8 bytes, which is the maximum payload of a CAN frame. The transmission of a PDO uses the consumer producer model of CAN extended by synchronous transfers. The synchronous transfer of PDOs relies on the transfer of SYNC messages on the CAN bus. A PDO is sent in cyclical mode after a configurable number (1 to 240) of received SYNC messages. It is also possible to wait for the availability of data from the application process and send a PDO after the next received SYNC message. This is called acyclical synchronous transfer. Service data object (SDO) Service data objects are intended for transmission of parameters. SDOs provide access to the object dictionary of remote devices. An SDO has no length restriction. If the payload does not fit into the CAN frame, it will be split over several CAN frames. Each SDO is acknowledged. SDO communication uses a peer-to-peer communication with one peer acting as server and the other acting a client. 64

4 CANopen 1 Initialization Pre-operational node id: boot-up Network management objects (NMT) The network management objects (NMT) change the state, or monitor the status, of a CANopen device. A NMT message is a message with CAN identifier 0. This gives the NMT messages the highest possible priority. The NMT message always consists of two bytes payload in the CAN frame. The second byte contains the node ID of the addressed node. It is possible to address all devices with one NMT message with the reserved node ID 0. The first byte encodes the NMT command. Operational Stopped A CANopen device starts in the Initialization state after switching the power on. Then the device performs its initialization. When the device has completed its initialization it issues a boot-up NMT object to notify the master. The heartbeat protocol for monitoring the device status is implemented with NMT objects. Special function objects (SYNC, EMCY, TIME) CANopen may have a SYNC producer to synchronize the actions of the CANopen nodes. A SYNC producer issues (periodically) the SYNC object. The SYNC object has the CAN identifier 128. This may introduce some jitter due to the priority of this message. A device internal error may trigger an emergency (EMCY) object. The reaction of the EMCY consumers depends on the application. The CANopen standard defines several emergency codes. The EMCY object is transmitted in a single CAN frame with eight bytes. A CAN frame with the CAN ID 256 with six bytes payload can be used to transmit the time of day to several CANopen nodes. This time stamp (TIME) object contains the daytime value in the Time-Of-Day data type. Watchdog mechanisms CANopen supports two methods of monitoring the status of devices. A network manager may poll each device regularly in configurable time intervals. This is called node guarding. Node guarding is, however, bandwidth consuming. Another mechanism is that each device regularly sends a heartbeat message. This saves bandwidth compared to the node guarding protocol. Network length and bit rate The length is restricted by the bit rate due to the bit arbitration process. Bit rate (kbps) Max length (m) In documents about CANopen, you will find often 40 m as a maximum length at 1Mbit/s. This length is calculated without electrical isolation as used in the Schneider Electric CANopen devices. With the electrical isolation, the minimum network length calculated is 4 m at 1 Mbps. However, the experience shows that 20 m are the pratical length that could be shorten by stubs or other influences. Length limitations concerning stubs Length limitations concerning stubs have to be taken into account and are fixed by the following parameters. Baud rate (kbps) Lmax.(m) (1) 0, ΣL max.(m) local star (2) 0, Interval min. (m) 3, ,6 x ΣL local(3) ΣL max.(m) on all bus (4) 1, (1) L max.: Maximum length for one stub. (2) ΣL max. local star: Maximum cumulative length of stubsin the same point when using a multi-port TAP creating a local star. (3) Interval min.: minimun distance between two TAPs. Value for a maximum length of derivation in the same point. Could be computed case by case for each derivation: Interval min. between two derivation is 60 % of the cumulative length of derivations at the same point. (4) ΣL max. on all bus: Maximum cumulative length of stubs on the all bus. 65

5 Conformance classes Schneider Electric has defined conformance classes for slave and master devices. The conformance classes define, which features a device supports. Characteristics Conformance classes M10 M20 M30 Layer settings Slave ID Data rate kbps 125, 250, 500 M , 1000 M20 +10, 20, 800 LSS Master Devices supported NMT (Network Management object) NMT Master NMT Master, according to DS301 CANopen Manager NMT master, according to DS301. Configuration Manager according to DSP302. Boot-up procedure according to DSP302 Time stamp Producer Auto configuration support SDO (Service Data Object) SDO Client SDO Server 1 1 SDO Manager 1 SDO data transfer Expedited, segment transfer Expedited, segment block transfer PDO (Process Data Object) COB-ID ReadOnly Read/Write Read/Write PDO TT 254, 255 M10 +0, PDO Inhibit Time TPDO s (Read/Write) PDO Event Timer TPDO s (Read/Write) RPDO s & TPDO s (Read/Write) SYNC SYNC producer producer/consumer TRIGGER producer EMCY consumer producer/consumer HEALTH Heartbeat 16 consumers 63 consumers Node guarding no yes yes Parameters Store parameters no yes yes 126 consumers Conformance classes S10 S20 S30 Layer settings Slave ID Data rate kbps 125, 250, 500 S , 1000 S20 +10, 20, 800 LSS Slave Diagnostic devices Diagnostic local LED or display NMT (Network Management object) NMT slave b Start remote node b Stop remote node b Enter pre-operational b Reset node b Reset communication Time stamp consumer SDO (Service Data Object) SDO Client 1 SDO Server 1 2 SDO data transfert Expedited, segment transfer Expedited, segment, block transfer PDO (Process Data Object) COB-ID ReadOnly Read/Write Read/Write PDO TT 254, 255 S10 +0, PDO mapping parameters FIX (Read) Connection set Predefined connection set Free PDO Inhibit Time TPDO s (Read/Write) PDO Event Timer TPDO s (Read/Write) RPDO s & TPDO s (Read/Write) SYNC SYNC consumer producer/consumer TRIGGER consumer EMCY producer producer consumer/producer HEALTH Heartbeat 1 consumer Node guarding no yes yes Parameters Store parameters no no no Nota : S00 and M00 are for products not 100% compliant to the conformance class. 66