? CAN in Automation e. V.
CAN open
Application Layer and Communication Profile
CiA Draft Standard 301
Version 4.02
Date: 13 February 2002
HISTORY CANopen CiA HISTORY
Date Changes
June 1999Document completely revised;
Summary of major changes:
?Object Dictionary structure reviewed
?Object services and NMT services included (former in CiA DS-201 .. CiA DS-207
specified)
?Data type definitions included (former in CiA DS-201 .. CiA DS-207 specified) and
extended
?Boot Up Message specified
?Optional Heartbeat specified
?Additional Emergency error codes specified
?Additional SDO abort codes specified
?Timer-driven PDO transmission specified
?PDO Communication parameter enhanced
?PDO Mapping procedure clarified
?SDO Block transfer specified
?Pre-defined Identifier set extended
June 2000?correction of some typing errors
?clarification of some descriptions
?Appendix:
?Device configuration
?OS command and prompt
?Multiplexed PDOs
?Modular CANopen devices
?Error behaviour
February 2002?errata sheet included
?chapter '11.6.2. Error behaviour object' – wrong reference changed
?default value changed from 'No' to '(device profile dependent)' for inhibit time and
event timer at definition of TPDO
?chapter '9.4.4. Restricted COB-Ids' added
?default value changed from 'No' to 'disabled' for COB-ID Client -> Server and COB-
ID Server -> Client at definition of Server SDO Parameter for Index 1201h – 127Fh
?default value changed from 'No' to 'disabled' for COB-ID Client -> Server and COB-
ID Server -> Client at definition of Client SDO Parameter
?'All client SDOs are invalid by default (invalid bit – see …)' added
?'A000h – BFFFh – Standardised Interface Profile Area' added at table 1
?figure 49 changed – structure of the Initialisation state.
?annex A edited
General information on licensing and patents
CAN in AUTOMATION (CiA) calls attention to the possibility that some of the elements of this CiA specification may be subject
of patent rights. CiA shall not be responsible for identifying any or all such patent rights.
? CiA 2005-01-01
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from CiA at the address below.
CAN in Automation e. V.
Am Weichselgarten 26
DE - 91058 Erlangen, Germany
Tel.: +49-9131-69086-0
Fax: +49-9131-69086-79
Url: https://www.doczj.com/doc/8f12335582.html,
Email: headquarters@https://www.doczj.com/doc/8f12335582.html,
CONTENTS
1TABLES (6)
2FIGURES (8)
3SCOPE (10)
4REFERENCES (11)
4.1Normative references (11)
4.2Informative references (11)
5DEFINITIONS AND ABBREVIATIONS (12)
5.1Abbreviations (12)
6MODELING (14)
6.1Reference Model (14)
6.2Device Model (15)
6.2.1General (15)
6.2.2The Object Dictionary (16)
6.3Communication Model (17)
6.3.1Master/Slave relationship (18)
6.3.2Client/Server relationship (19)
6.3.3Producer/Consumer relationship - Pull/Push model (19)
7PHYSICAL LAYER (20)
7.1Transceiver (20)
7.2Bit rates and timing (20)
8DATA LINK LAYER (22)
8.1CAN Frame Type (22)
9APPLICATION LAYER (23)
9.1Data Types and Encoding Rules (23)
9.1.1General Description of Data Types and Encoding Rules (23)
9.1.2Data Type Definitions (23)
9.1.3Bit Sequences (24)
9.1.6Extended Data Types (28)
9.2Communication Objects (29)
9.2.1Process Data Object (PDO) (29)
9.2.2Service Data Object (SDO) (33)
9.2.3Synchronisation Object (SYNC) (58)
9.2.4Time Stamp Object (TIME) (59)
9.2.5Emergency Object (EMCY) (60)
9.2.6Network Management Objects (63)
9.3Synchronisation of the SYNC Consumer (71)
9.3.1Transmission of Synchronous PDO Messages (71)
9.3.2Optional High Resolution Synchronisation Protocol (72)
9.4Network Initialisation and System Boot-Up (74)
9.4.1Initialisation Procedure (74)
9.4.2NMT State Machine (74)
9.4.3Pre-Defined Connection Set (77)
9.5Object Dictionary (79)
9.5.1General Structure of the Object Dictionary (79)
9.5.2Dictionary Components (80)
9.5.3Data Type Entry Specification (80)
9.5.4Specification of Predefined Complex Data Types (82)
9.6Communication Profile Specification (84)
9.6.1Detailed Object Specification (84)
9.6.2Overview Object Dictionary Entries for Communication (84)
9.6.3Detailed Specification of Communication Profile specific Objects (86)
10IMPLEMENTATION RECOMMENDATIONS (114)
11ANNEX A (NORMATIVE) (115)
11.1Additional object dictionary entries (116)
11.2Device configuration (117)
11.2.1Boot-up configuration process (117)
11.3.1OS command (120)
11.3.2OS debugger interface (122)
11.3.3OS prompt (124)
11.4Multiplexed PDOs (126)
11.4.1MPDO Protocol (126)
11.4.2Object dictionary entries (127)
11.4.3Implementing MPDOs (129)
11.4.4Groups, security and network configuration tools (129)
11.4.5Indication of MPDO capability in the EDS (129)
11.5Additional functionality for modular CANopen devices (130)
11.5.1Background (130)
11.5.2Modular Devices (130)
11.6Additional communication objects (132)
11.6.1Emergency consumer object (132)
11.6.2Error behaviour object (133)
12INDEX (135)
1 TABLES
Table 1: Object Dictionary Structure (16)
Table 2: Recommended Bit Timing Settings (20)
Table 3: Write PDO (31)
Table 4: Read PDO (31)
Table 5: SDO Download (35)
Table 6: Initiate SDO Download (35)
Table 7: Download SDO Segment (36)
Table 8: SDO Upload (36)
Table 9: Initiate SDO Upload (37)
Table 10: Upload SDO Segment (37)
Table 11: Abort SDO Transfer (37)
Table 12: SDO Block Download (38)
Table 13: Initiate SDO Block Download (38)
Table 14: Download SDO Block (39)
Table 15: End SDO Block Download (39)
Table 16: SDO Block Upload (40)
Table 17: Initiate SDO Block Upload (40)
Table 18: Upload SDO Block (41)
Table 19: End SDO Block Upload (41)
Table 20: SDO abort codes (48)
Table 21: Emergency Error Codes (60)
Table 22: Start Remote Node (63)
Table 23: Stop Remote Node (63)
Table 24: Enter Pre-Operational (63)
Table 25: Reset Node (64)
Table 26: Reset Communication (64)
Table 27: Node Guarding Event (65)
Table 28: Life Guarding Event (65)
Table 29: Heartbeat Event (65)
Table 30: Bootup Event (65)
Table 31: Trigger for State Transition (75)
Table 32: States and Communication Objects (77)
Table 33: Broadcast Objects of the Pre-defined Connection Set (78)
Table 34: Peer-to-Peer Objects of the Pre-defined Connection Set (78)
Table 35: Restricted COB-IDs (78)
Table 36: Format of Object Dictionary Headings (79)
Table 37: Object Dictionary Object Definitions (79)
Table 38: Access Attributes for Data Objects (80)
Table 39: Object Dictionary Data Types (80)
Table 40: complex data type example (82)
Table 41: PDO Communication Parameter Record (83)
Table 42: PDO Mapping Parameter Record (83)
Table 43: SDO Parameter Record (83)
Table 44: Identity Record (83)
Table 45: Format of an Object Description (84)
Table 46: Object Value Description Format (84)
Table 47: Standard Objects (84)
Table 48: Structure of the Error Register (87)
Table 49: Description of SYNC COB-ID entry (89)
Table 50: Structure of read access (93)
Table 51: Structure of restore read access (96)
Table 52: Description of TIME COB-ID entry (97)
Table 53: Description of EMCY COB-ID entry (99)
Table 54: Description of SDO COB-ID entry (103)
Table 55: Description of PDO COB-ID entry (106)
Table 56: Description of transmission type (106)
2 FIGURES
Figure 1: Reference Model (14)
Figure 2: Service Types (15)
Figure 3: Device Model (16)
Figure 4: Unconfirmed Master Slave Communication (18)
Figure 5: Confirmed Master Slave Communication (18)
Figure 6: Client/Server Communication (19)
Figure 7: Push model (19)
Figure 8: Pull model (19)
Figure 9: Transfer Syntax for Bit Sequences (25)
Figure 10: Transfer syntax for data type UNSIGNEDn (26)
Figure 11: Transfer syntax for data type INTEGERn (26)
Figure 12: Transfer syntax of data type REAL32 (27)
Figure 13: Synchronous and Asynchronous Transmission (30)
Figure 14: Write PDO Protocol (32)
Figure 15: Read PDO Protocol (32)
Figure 16: Download SDO Protocol (42)
Figure 17: Initiate SDO Download Protocol (43)
Figure 18: Download SDO Segment Protocol (44)
Figure 19: Upload SDO Protocol (45)
Figure 20: Initiate SDO Upload Protocol (46)
Figure 21: Upload SDO Segment Protocol (47)
Figure 22: Abort SDO Transfer Protocol (48)
Figure 23: SDO Block Download Protocol (50)
Figure 24: Initiate SDO Block Download Protocol (51)
Figure 25: Download SDO Block Segment (52)
Figure 26: End SDO Block Download Protocol (53)
Figure 27: Upload SDO Block Protocol (54)
Figure 28: Initiate SDO Block Upload Protocol (55)
Figure 29: Upload SDO Block Segment Protocol (56)
Figure 30: End SDO Block Upload Protocol (57)
Figure 31: SYNC Protocol (58)
Figure 32: TIME Protocol (59)
Figure 33: Emergency State Transition Diagram (61)
Figure 34: Emergency Object Data (61)
Figure 35: Emergency Object Protocol (62)
Figure 36: Start Remote Node Protocol (66)
Figure 37: Stop Remote Node Protocol (66)
Figure 38: Enter Pre-Operational Protocol (67)
Figure 39: Reset Node Protocol (67)
Figure 40: Reset Communication Protocol (68)
Figure 41: Node Guarding Protocol (69)
Figure 42: Heartbeat Protocol (70)
Figure 43: Bootup Protocol (71)
Figure 44: Bus Synchronisation and Actuation (72)
Figure 45: Bus Synchronisation and Sampling (72)
Figure 46: Optional High Resolution Synchronisation Protocol (73)
Figure 47: Flow Chart of the Network Initialisation Process (74)
Figure 48: State Diagram of a Device (75)
Figure 49: Structure of the Initialisation state (76)
Figure 50: Identifier allocation scheme for the pre-defined connection set (78)
Figure 51: structure sub-index FFh (82)
Figure 52: Structure of the Device Type Parameter (86)
Figure 53: Structure of the pre-defined error field (88)
Figure 54: Structure of SYNC COB-ID entry (89)
Figure 55: Storage write access signature (93)
Figure 56: Storage read access structure (93)
Figure 57: Restoring write access signature (95)
Figure 58: restore procedure (95)
Figure 59: Restoring default values read access structure (95)
Figure 60: Structure of TIME COB-ID entry (97)
Figure 61: Structure of the EMCY Identifier entry (98)
Figure 62: Structure of Consumer Heartbeat Time entry (100)
Figure 63: Structure of Revision number (101)
Figure 64: Structure of SDO COB-ID entry (103)
Figure 65: Structure of PDO COB-ID entry (106)
Figure 66: Structure of PDO Mapping Entry (109)
Figure 67: Principle of PDO mapping (110)
SCOPE CANopen CiA 3 SCOPE
This Part of EN 50325 specifies the following particular requirements for CANopen:
(1) Requirements for interfaces between controllers and switching elements;
(2) Normal service conditions for devices;
(3) Constructional and performance requirements.
REFERENCES CANopen CiA 4 REFERENCES
references
4.1 Normative
EN 50325-1: 2002Industrial communications subsystem based on ISO 11898 (CAN) for
controller-device interfaces
Part 1: General requirements
EN 61131-3: 1993Programmable controllers
Part 3: Programming languages
ISO 7498-1: 1994Information technology - Open Systems Interconnection - Basic Reference
Model: The Basic Model
ISO 8859: 1998Information technology - 8-bit single-byte coded graphic character sets
ISO 11898: 1993Road vehicles - Interchange of digital information - Controller area network
(CAN) for high-speed communication
ISO 646: 1991Information technology - ISO 7-bit coded character set for information
interchange
references
4.2 Informative
IEEE 754: 1985Standard for binary floating-point arithmetic
5 DEFINITIONS AND ABBREVIATIONS
5.1 Abbreviations
ARQ:
Automatic Repeat Request.
CAN:
Controller Area Network is an internally standardized serial bus system..
COB:
Communication Object. A unit of transportation in a CAN network. Data must be sent across a CAN Network inside a COB. There are 2048 different COB's in a CAN network. A COB can contain at most 8 bytes of data.
COB-ID:
Each COB is uniquely identified in a CAN network by a number called the COB Identifier (COB-ID). The COB-ID determines the priority of that COB for the MAC sub-layer.
Remote COB:
A CO
B whose transmission can be requested by another device.
CRC:
Cyclic Redundancy Check.
CSDO:
Client SDO.
LLC:
Logical Link Control. One of the sub-layers of the Data Link Layer in the CAN Reference Model that gives the user an interface that is independent from the underlying MAC layer.
MAC:
Medium Access Control. One of the sub-layers of the Data Link Layer in the CAN Reference Model that controls who gets access to the medium to send a message.
MDI:
Medium Dependent Interface. One of the sub-layers of the Physical Layer in the CAN Reference Model that specifies the mechanical and electrical interface between the medium and a module. NMT:
Network Management. One of the service elements of the application layer in the CAN Reference Model. The NMT serves to configure, initialise, and handle errors in a CAN network.
Node-ID:
The Node-ID of the NMT Slave has to be assigned uniquely, or 0. If 0, the protocol addresses all NMT Slaves.
OSI:
Open Systems Interconnection.
PDO:
Process Data Object.
PLS:
Physical Layer Signalling. One of the sub-layers of the Physical Layer in the CAN Reference Model that specifies the bit representation, timing and synchronisation.
PMA:
Physical Medium Attachment. One of the sub-layers of the Physical Layer in the CAN Reference Model that specifies the functional circuitry for bus line transmission/reception and may provide means for failure detection.
RPDO:
Receive PDO.
SDO:
Service Data Object. SSDO:
Server SDO.
SYNC: Synchronisation Object. TPDO:
Transmit PDO.
6 M ODELING
CAN-based networks use the following reference model, device model, and communication model.6.1 Reference M odel
Figure 1: Reference Model
The communication concept can be described similar to the ISO-OSI Reference Model (left side of figure).
Application Layer:
The Application Layer comprises a concept to configure and communicate real-time-data as well as the mechanisms for synchronization between devices. The functionality the application layer offers to an application is logically divided over different service objects in the application layer. A service object offers a specific functionality and all the related services. These services are described in the Service Specification of that service object.
Applications interact by invoking services of a service object in the application layer. To realize these services, this object exchanges data via the CAN Network with (a) peer service object(s) via a protocol. This protocol is described in the Protocol Specification of that service object.Service Primitives:
Service primitives are the means by which the application and the application layer interact. There are four different primitives:
? a request 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 report an internal event detected by the application layer or indicate that a service is requested
? a response is issued by the application to the application layer to respond to a previous received indication
?
a confirmation is issued by the application layer to the application to report the result of a previously issued request.
Application Layer Service Types
Application X
request
Local Service
Application X
indication
Provider Initiated
Service
Application X indication Unconfirmed Service
Application Y, Z, ..
indication indication
Application X
indication
Confirmed Service
Application Y
response
confirmation request
Figure 2: Service Types
A service type defines the primitives that are exchanged between the application layer and the co-operating applications for a particular service of a service object.
? A local service involves only the local service object. The application issues a request to its local
service object that executes the requested service without communicating with (a) peer service object(s).?
An unconfirmed service involves one or more peer service objects. The application issues a request to its local service object. This request is transferred to the peer service object(s) that each pass it to their application as an indication. The result is not confirmed back.
?
A confirmed service can involve only one peer service object. The application issues a request to its local service object. This request is transferred to the peer service object that passes it to the other application as an indication. The other application issues a response that is transferred to the originating service object that passes it as a confirmation to the requesting application.?
A provider initiated service involves only the local service object. The service object (being the service provider) detects an event not solicited by a requested service. This event is then indicated to the application.Unconfirmed and confirmed services are collectively called remote services .6.2
Device Model
6.2.1 General
A device is structured like the following (see Figure 3):
? Communication – This function unit provides the communication objects and the appropriate
functionality to transport data items via the underlying network structure.
? Object Dictionary – The Object Dictionary is a collection of all the data items which have an
influence on the behavior of the application objects, the communication objects and the state machine used on this device.
? Application – The application comprises the functionality of the device with respect to the
interaction with the process environment.
Thus the Object Dictionary serves as an interface between the communication and the application.The complete description of a device’s application with respect to the data items in the Object Dictionary is named device profile .
Figure 3: Device Model
6.2.2
The Object Dictionary
The most important part of a device profile is the Object Dictionary description. The Object Dictionary is essentially a grouping of objects accessible via the network in an ordered pre-defined fashion. Each object within the dictionary is addressed using a 16-bit index.
The overall layout of the standard Object Dictionary is shown below. This layout closely conforms with other industrial serial bus system concepts:
Table 1: Object Dictionary Structure
Index (hex)Object 0000not used
0001-001F Static Data Types 0020-003F Complex Data Types
0040-005F Manufacturer Specific Complex Data Types 0060-007F Device Profile Specific Static Data Types 0080-009F Device Profile Specific Complex Data Types 00A0-0FFF Reserved for further use 1000-1FFF Communication Profile Area 2000-5FFF Manufacturer Specific Profile Area 6000-9FFF Standardised Device Profile Area A000-BFFF Standardised Interface Profile Area C000-FFFF
Reserved for further use
The Object Dictionary may contain a maximum of 65536 entries which are addressed through a 16-bit index.
Process
Bus system
The Static Data Types at indices 0001h through 001Fh contain type definitions for standard data types like BOOLEAN, INTEGER, floating point, string, etc. These entries are included for reference only,
they cannot be read or written.
Complex Data Types at indices 0020h through 003Fh are pre-defined structures that are composed of standard data types and are common to all devices.
Manufacturer Specific Complex Data Types at indices 0040h through 005Fh are structures composed
of standard data types but are specific to a particular device.
Device Profiles may define additional data types specific to their device type. The static data types defined by the device profile are listed at indices 0060h - 007Fh, the complex ones at indices 0080h -009Fh.
A device may optionally provide the structure of the supported complex data types (indices 0020h -
005Fh and 0080h - 009Fh) at read access to the corresponding index. Sub-index 0 then provides the number of entries at this index, and the following sub-indices contain the data type encoded as UNSIGNED16 according to Table 39.
The Communication Profile Area at indices 1000h through 1FFFh contains the communication specific parameters for the CAN network. These entries are common to all devices.
The standardised device profile area at indices 6000h through 9FFFh contains all data objects common to a class of devices that can be read or written via the network. The device profiles may use entries from 6000h to 9FFFh to describe the device parameters and the device functionality. Within
this range up to 8 different devices can be described. In such a case the devices are denominated Multiple Device Modules. Multiple Device Modules are composed of up to 8 device profile segments.
By this feature it is possible to build devices with multiple functionality. The different device profile entries are shifted with 800h.
For Multiple Device Modules the object range 6000h to 67FF h is shifted as follows:
6000h to 67FFh device 0
6800h to 6FFFh device 1
7000h to 77FFh device 2
7800h to 7FFFh device 3
8000h to 87FFh device 4
8800h to 8FFFh device 5
9000h to 97FFh device 6
9800h to 9FFFh device 7
The PDO distribution shall be used for every segment of a Multiple Device Module with an offset of 64,
e.g. the first PDO of the second segment gets the number 65. In this way a system with a maximum of
8 segments is supported.
The Object Dictionary concept caters for optional device features which means a manufacturer does
not have to provide certain extended functionality on his devices but if he wishes to do so he must do
it in a pre-defined fashion.
Space is left in the Object Dictionary at indices 2000h through 5FFFh for truly manufacturer-specific functionality.
6.2.2.1 Index and Sub-Index Usage
A 16-bit index is used to address all entries within the Object Dictionary. In case of a simple variable
the index references the value of this variable directly. In case of records and arrays however, the
index addresses the whole data structure.
To allow individual elements of structures of data to be accessed via the network a sub-index is defined. For single Object Dictionary entries such as an UNSIGNED8, BOOLEAN, INTEGER32 etc. the value for the sub-index is always zero. For complex Object Dictionary entries such as arrays or records with multiple data fields the sub-index references fields within a data-structure pointed to by the main index. The fields accessed by the sub-index can be of differing data types.
6.3 Communication Model
The communication model specifies the different communication objects and services and the available modes of message transmission triggering.
The communication model supports the transmission of synchronous and asynchronous messages.
By means of synchronous message transmission a network wide coordinated data acquisition and actuation is possible. The synchronous transmission of messages is supported by pre-defined communication objects (Sync message, time stamp message). Synchronous messages are transmitted with respect to a pre-defined synchronization message, asynchronous message may be transmitted at any time.
Due to the event character of the underlying communication mechanism it is possible to define inhibit times for the communication. To guarantee that no starvation on the network occurs for data objects with low priorities, data objects can be assigned an inhibit time. The inhibit-time of a data object
defines the minimum time that has to elapse between two consecutive invocations of a transmission service for that data object. Inhibit-times can be assigned by the application.
With respect to their functionality, three types of communication relationships are distinguished ? Master/Slave relationship (Figure 4 and Figure 5)? Client/Server relationship (Figure 6)
? Producer/Consumer relationship (Figure 7 and Figure 8)6.3.1 M aster/Slave relationship
At any time there is exactly one device in the network serving as a master for a specific functionality.All other devices in the network are considered as slaves. The master issues a request and the addressed slave(s) respond(s) if the protocol requires this behavior.
Figure 4: Unconfirmed Master Slave Communication
Figure 5: Confirmed Master Slave Communication
6.3.2 Client/Server relationship
This is a relationship between a single client and a single server. A client issues a request
(upload/download) thus triggering the server to perform a certain task. After finishing the task the server answers the request.
Figure 6: Client/Server Communication
6.3.3
Producer/Consumer relationship - Pull/Push model
The producer/consumer relationship model involves a producer and zero or more consumer(s). The push model is characterized by an unconfirmed service requested by the producer. The pull model is characterized by a confirmed service requested by the consumer.
Figure 7: Push model
Figure 8: Pull model
7 PHYSICAL LAYER
The physical medium for devices is a differentially driven two-wire bus line with common return according to high-speed transmission specification in ISO 11898.
7.1 Transceiver
Using the high-speed transceiver according to ISO 11898 the maximum rating for V CAN_H and V CAN_L shall be +16V. Galvanic isolation between bus nodes is optional. It is recommended to use a transceiver that is capable of sustaining mis-connection of any of the wires of the connector including the optional V+ voltages of up to 30V.
7.2 Bit rates and timing
The recommended bit rates and corresponding bit timing recommendations(4) are listed in Table 2. One of these bit rates has to be supported.
Table 2: Recommended Bit Timing Settings
Bit rate Bus length (1)Nominal
bit time
t b
Number of
time quanta
per bit
Length of
time
quantum t q
Location of
sample
point
1 Mbit/s 25 m 1 μs8125 ns 6 t q
(750 ns)
800 kbit/s 50 m 1,25 μs10125 ns8 t q
(1 μs)
500 kbit/s 100 m 2 μs16125 ns14 t q
(1,75 μs)
250 kbit/s 250 m (2)4 μs16250 ns14 t q
(3,5 μs)
125 kbit/s 500 m (2)8 μs16500 ns14 t q
(7 μs)
50 kbit/s 1000 m (3)20 μs161,25 μs14 t q
(17,5 μs)
20 kbit/s 2500 m (3)50 μs163,125 μs14 t q
(43,75 μs)
10 kbit/s 5000 m (3)100 μs166,25 μs14 t q
(87,5 μs)
The table entries are an example based on the follow acceptance:
Oscillator frequency16 MHz +/-0.1% (1000 ppm)
Sampling mode Single sampling SAM = 0
Synchronisation mode Recessive to dominant edges only SYNC = 0
Synchronisation jump width 1 * t q SJW = 0
Phase Segment 2 2 * t q TSEG2 = 1 Note 1:Rounded bus length estimation (worst case) on basis 5 ns/m propagation delay and a total effective device internal in-out delay as follows:
1M - 800 kbit/s:210 ns
500 - 250 kbit/s:300 ns (includes 2 * 40 ns for optocouplers)
125 kbit/s:450 ns (includes 2 * 100 ns for optocouplers)
50 - 10 kbit/s:1,5 t q; Effective delay = delay recessive to dominant plus
dominant to recessive divided by two.
Note 2:For bus length greater than about 200 m the use of optocouplers is
recommended. If optocouplers are placed between CAN controller and
transceiver this affects the maximum bus length depending upon the propagation
delay of the optocouplers i.e. -4m per 10 ns propagation delay of employed
optocoupler type.
Note 3:For bus length greater than about 1 km bridge or repeater devices may be needed.