Can in Automation (Cia) : Higher Layer Protocols (HLP) Can The Bus Cia Members Only

CAN in Automation (CiA) - Controller Area Network (CAN)
CAN
HLP
Members only
Map
home
CAN in Automation (CiA)

international users and manufacturers group Founded in March 1992, CiA provides technical, product and marketing information with the aim of fostering Controller Area Networks image and providing a path for future developments of the CAN protocol. The non-profit trade association with a persistently increasing number of members develops and supports various CAN-based higher layer protocols: CAN Application Layer (CAL), CAN Kingdom, CANopen, DeviceNet. CAN Information in Dutch
Higher layer protocols (HLP)

- General introduction - CANopen - Devicenet - CAN Kingdom
CAN the bus

- General introduction - Specifications - Controller - Applications
CiA members only

- CiA specifications - Technical info - Marketing info
Events Literature
Standardization Download
Products News
CiA
phone +49-9131-69086-0 fax +49-9131-69086-79 email:headquarters@can-cia.de
http://www.can-cia.de/ [14.11.1999 12:45:51]
CAN in Automation
Higher Layer Protocols DeviceNet

General introduction Technical introduction Specifications Conformance test FAQs
HLP
CANopen
General introduction Technical introduction Specifications Conformance test FAQs Vendor list
CAN Application Layer CAN Kingdom

General introduction Technical introduction Specifications General introduction Technical introduction Specifications
CAN in Automation last update: 1999-07-26
http://www.can-cia.de/hg.htm [14.11.1999 12:46:07]
CAN in Automation
General introduction
Page contents: Features and functionality First information Features and functionality Network Size Network Length Up to 64 nodes Selectable end-to-end network distance varies with speed
DeviceNet
More:
Technical introduction Specifications Conformance test FAQs
Page contents:
Baud Rate 125 Kbps 250 Kbps 500 Kbps 0-8 bytes Distance 500 m (1,640 ft) 250 m (820 ft) 100 m (328 ft)
Top Features and functionality First information
Data Packets Bus Topology Bus Addressing System Features
Linear (trunkline/dropline); power and signal on the same network cable Peer-to-Peer with Multi-Cast (one-to-many); Multi-Master and Master/Slave special case; polled or change-of-state (exception-based) Removal and replacement of devices from the network under power
More:
First information DeviceNet is a low-cost communications link to connect industrial devices (such as limit switches, photoelectric sensors, valve manifolds, motor starters, process sensors, bar code readers, variable frequency drives, panel displays and operator interfaces) to a network and eliminate expensive hardwiring. The direct connectivity provides improved communication between devices as well as important device-level diagnostics not easily accessible or available through hardwired I/O interfaces. DeviceNet is a simple, networking solution that reduces the cost and time to wire and install industrial automation devices, while providing interchangeability of "like" components from multiple vendors. DeviceNet is an open network standard. The specification and
Page contents:
http://www.can-cia.de/hdg.htm (1 von 2) [14.11.1999 12:46:16]
CAN in Automation
protocol are open; vendors are not required to purchase hardware, software or licensing rights to connect devices to a system. Anyone may obtain the DeviceNet Specification from the Open DeviceNet Vendor Association, Inc. (ODVA) for a nominal reproduction charge. Any company that manufactures (or intends to manufacture) DeviceNet products may join ODVA and participate in technical working groups that are developing enhancements to the DeviceNet Specification. Buyers of the DeviceNet Specification receive an unlimited, royalty-free license to develop DeviceNet products. Companies looking for assistance may purchase sample code that eases their implementation, development toolkits, and development services from many sources. The key hardware components are available from the largest worldwide suppliers of semiconductors. Why the DeviceNet Communication Link? For years the process industry has been attempting to develop a single, open standard to address all kinds of field devices. The original scope of their standards effort was aimed at replacing the 4-20 mA standard with a single digital standard. As the scope increased to address complex and sophisticated services (such as high data rate communications between controllers, time synchronization of large numbers of devices scanning at very high speeds), the development of a single standard became delayed. At the same time, the cost of communication technology has dropped considerably in recent years, making it cost-effective to connect simple devices never considered for SP50 fieldbus directly to a network. Such a standard for simple devices requires the same level of interchange-ability as exists for 120/220 VAC and 24 VDC discrete, hardwired I/O. DeviceNet allows the interchangeability of simple devices while making interconnectivity of more complex devices possible. In addition to reading the state of discrete devices, DeviceNet provides the capability to report temperatures, to read the load current in a motor starter, to change the deceleration rate of drives, or to count the number of packages that have passed on a conveyor in the previous hour.
ODVA - The Open DeviceNet's Vendor Association
More:
Page contents:
More:
Page contents:
http://www.can-cia.de/hdg.htm (2 von 2) [14.11.1999 12:46:16]
CAN in Automation
Technical introduction
Page contents: Physical Layer and Media Indicators and Configuration Switches Communication Protocol and Application The Object Model Messaging Predefined Master/Slave Connection Set Device Profiles Physical Layer and Media Chapter 9, Volume 1 in the DeviceNet Specifications defines the allowable Topologies and components. The variety of Topologies that are possible is shown in Figure 2. The specification also deals with system grounding, mixing thick and thin media, termination, and power distribution. The basic trunkline-dropline Topology provides separate twisted pair busses for both signal and power distribution. Thick or thin cable can be used for either trunklines or droplines. End-to-end network distance varies with data rate and cable size. Data Rates Thick Trunk Length Thin Trunk Length Maximum Drop Length Cumulative Drop Length 125 Kbps 250 Kbps 500 Kbps 500 m 250 m 100 m (1,640 ft) (820 ft) (328 ft) 100 m 100 m 100 m (328 ft) (328 ft) (328 ft) 6m 6m 6m (20 ft) (20 ft) (20 ft) 156 m 78 m 39 m (512 ft) (256 ft) (128 ft)
DeviceNet
More:
General introduction Specifications Conformance test FAQs
Page contents:
Top Physical Layer and Media Indicators and Configuaration Switches Communication Protocol and Application The Object Model Messaging Predefined Master/Slave Connection Set Device Profiles
More:
The end-to-end network distance varies with data rate and cable thickness. Devices can be powered directly from the bus and communicate with each other using the same cable. Nodes can be removed or inserted from the network without powering-down the network. Power taps can be added at any point the network, which makes redundant power supplies possible. The trunkline current rating is 8 amps. An opto-isolated design option allows externally powered
http://www.can-cia.de/hdt.htm (1 von 15) [14.11.1999 12:47:01]
CAN in Automation
devices (e.g. AC Drives starters and solenoid valves) to share the same bus cable. Other CAN-based networks allow only a single power supply (if at all) for the entire network.
Page contents:
More:
Page contents:
CAN in Automation
More:
Page contents:
A simplified block diagram of transceivers with both isolated and non-isolated physical layers is shown in figure 3 and figure 4. The DeviceNet Specifications contain additional information concerning component requirements, protection from mis-wiring, and examples.
More:
Figure 5. Open and Sealed Connectors are available on DeviceNet
Several different connector types can be used on DeviceNet (see figure 5). Both sealed and unsealed connectors are available. Large (mini-style) and small (micro-style) sizes of pluggable, sealed connectors are available. For products, which do not require sealed connectors, open-style connectors can be used. Screw or clamp connections can be made directly to the cable if a pluggable connection is not required. The DeviceNet Specification also
CAN in Automation
contains information on how to use these cable and connector components to construct single and multi-port taps. Indicators and Configuration Switches Although DeviceNet does not require a product to have indicators, if a product does have indicators, it must adhere to the DeviceNet Specification. It is recommended that either a Module Status LED and a Network Status LED, or the combined Module Status/Network Status LED be included. The indicator(s) consist of bi-color (green/red) LEDs, which can have combinations of on, off or flashing. The Module Status LED indicates whether or not the device has power and is operating properly. The Network Status LED indicates the status of the communication link. Communication Protocol and Application Chapters 3, 4 and 5, Volume 1 of the DeviceNet Specification defines the DeviceNet Communication Protocol. These chapters deal with connections, messaging protocol, and the communications related objects respectively. Applications using DeviceNet combine standard or application specific objects together into what is called a Device Profile. The Device Profile fully defines the device as viewed from the network. A library of objects is contained in Chapter 6, Volume II of the DeviceNet Specifications. A library of Device Profiles is contained in Chapter 3, Volume II of the DeviceNet Specifications. ODVA coordinates the work of industry experts in the development of both new Object and Device Profile Specifications. This is done through Special Interest Groups (SIG). DeviceNet supports strobed, polled, cyclic, change-of-state and application-triggered data movement. The user can choose master/slave, multi-master and peer-to-peer or a combination configuration depending on device capability and application requirements. The choice of data movement can significantly speed up system response time. One popular application for DeviceNet is to use a standard, pre-defined set of connections, which allow devices to operate in a Master/Slave Connection Set. Connections The DeviceNet Communication Protocol is based on the idea of connections. You must establish a connection with a device in order to exchange information with it.
Page contents:
More:
Page contents:
CAN in Automation
To establish a connection, each DeviceNet product will implement either an Unconnected Message Manager (UCMM) or an Unconnected Port. Both perform their function by reserving some of the available CAN identifiers. The UCMM is described in detail in Chapter 4, Volume 1 of the DeviceNet Specification, and the Unconnected Port is described in Chapter 7, Volume 1. When either the UCMM or the Unconnected Port is used to establish an Explicit Messaging Connection, that connection is then used to move information from one node to the other, or to establish additional I/O Connections. Once connections have been established, I/O data may be moved among devices on the network. At this point, all the protocol of the DeviceNet I/O message is contained within the 11-bit CAN identifier. Everything else is data. The 11-bit CAN identifier is used to define the connection ID. DeviceNet divides the 11-bit CAN identifier into four groups. The first three defined groups contain two fields, one 6-bit field for MAC ID and the other for Message ID. The combined fields define the connection ID. Figure 7 shows message groups definitions. Group four messages are used for offline communications. Devices may be Clients or Servers or both. Clients and Servers may be producers, consumers or both. In a typical Client device, its connection would produce requests and consume responses. In a typical Server device, its connections would consume requests and produce responses. DeviceNet provides for several variations on this model. Some connections in either a Client or a Server may only consume messages. These connections would be the destination for Cyclic or Change-of-State messages. Similarly, some connections in either a Client or Server may only produce messages. These connections would be the source for Cyclic or Change-of-State messages. The use of Cyclic and Change-of-State connections can substantially reduce bandwidth requirements. By design, nodes in a DeviceNet system are responsible for managing their own identifiers. These identifiers are interleaved (distributed) throughout the entire range. All nodes have a full range of message priorities available to them regardless of their MAC ID. Through the duplicate MAC ID algorithm, the uniqueness of CAN identifiers is guaranteed without the need for a central tool or record for each network. A related issue is detection of duplicate nodes. Because DeviceNet uses a device address inside the CAN Identifier Field, it presents a mechanism for detecting duplicate addressed devices. Preventing duplicate addresses is better than trying to locate them after they occur - something not taken into account in other CAN-based
More:
Page contents:
More:
CAN in Automation
networks. Another key benefit to nodes managing their identifiers is that a user can add and delete nodes and/or add additional peer-to-peer messages among existing nodes at any time without having knowledge of the existing set-up. No centralized record must be located or reconstructed. Since nodes know, which IDs are already in use, a tool simply has to request an I/O connection be added between the two devices, specifying priority level, the data path (class, instance, attribute) and the production trigger (cyclic, poll, or change-of-state). Identifier Bits 10 9 8 0 7 6 54 3 2 1 Group 1 Message ID Hex Identity 0 Range Usage 000 3ff 400 5ff 600 7bf Message Group 1 Message Group 2 Message Group 3 Message Group 4 Invalid CAN Identifiers
Page contents:
Source MAC ID Group 2 Message ID
1 0
MAC ID
More:
Group 3 1 1 Message ID 1 1 1 1
Source MAC ID
Group 4 Message 7c0 1 ID 7ef (0 - 2f) 1 11X X X X 6 54 4 3 2 1 7f0 7ff 0
Page contents:
1 1 1 10 9 8
1 7
Figure 7 DeviceNet has 4 defined groups
The Object Model The Object Model provides a template for organizing and implementing the Attributes (data), Services (methods or procedures) and Behaviors of the components of a DeviceNet product (see figure 8). The model provides an addressing scheme for each attribute consisting of four numbers. They are the Node Address (MAC ID), the Object Class Identifier, the Instance Number, and the Attribute Number. This four-level address is used in conjuction with an Explicit Messaging Connection to move data from one place to
CAN in Automation
another on a DeviceNet network. The ranges of the four addressing components are shown in the following table: Address Node Class Instance Attribute Lowest 0 1 0 1 Highest 63 65535 65535 255
More:
Page contents:
Typical object classes found in a DeviceNet Product Object Class Number 1 2 3 4 5 6 Object Class Name Identity Message Router DeviceNet Assembly Connection Parameter Specification Reference Vol II, Rel 1.2, page 6-3 Vol II, Rel 1.2, page 6-17 Vol I, Rel 1.3, page 5-50 Vol II, Rel 1.2, page 6-25 Vol I, Rel 1.3, page 5-6 Vol II, Rel 1.2, page 6-95
More:
Identity Object - Vol II, Rel 1.2, page 6-3 A DeviceNet product will typically have a single instance (Instance #1) of the Identity Object. This instance will have as attributes a
CAN in Automation
VendorID, a Device Type, a Product code, a revision, a status, a serial number, a productname, and a state. The required services would be Get_Attribute_Single and a Reset. Message Router Object - Vol II, Rel 1.2, page 6-17 A DeviceNet product will typically have a single instance (Instance #1) of the Message Router Object. The Message Router Object is the component of a product that passes Explicit Messages to the other Objects. It Generally does not have any external visibility over the DeviceNet network. DeviceNet Object - Vol I, Rel 1.3, page 5-50 A DeviceNet product will typically have a single instance (Instance #1) of the DeviceNet Object. This instance would have as attributes: Node Address or MAC ID, baudrate, Bus-Off action, Bus-Off counter, the allocation choice, and the master's MAC ID. The only required service is Get_Attribute_Single. Assembly Object(s) - Vol II, Rel 1.2, page 6-25 A DeviceNet product will typical have one or more optional Assembly Objects. The primary purpose of these objects is to group different attributes (data) from different application objects into a single attribute, which can be moved with a single message. Connection Objects - Vol I, Rel 1.3, page 5-6 A DeviceNet product will typically have at least two connection objects. Each connection object represents one end point of a virtual connection between two nodes on a DeviceNet network. These two types of connections are called Explicit Messaging and I/O Messaging. Explicit Messages contain Attribute addressing, Attribute values and a Service Code describing the desired action. I/O messages contain nothing but data. In an I/O message, all the information about what to do with the data is contained in the Connection Object associated with that I/O message. Parameter Object - Vol II, Rel 1.2, page 6-95 The optional Parameter object would be used in devices with configurable parameters. One instance would be present for each configurable parameter. The parameter object provides a standard way for a configuration tool to access all parameters. Configuration options, which are attributes of the Parameter object could include values, ranges, text strings, and limits. Application Objects Usually at least one application object besides those from the Assembly or Parameter Class will be present in a device. There are a number of standard objects in the DeviceNet Object Library in Chapter 6, Volume II.
Page contents:
More:
Page contents:
CAN in Automation
Messaging The DeviceNet application layer defines how identifiers are assigned (thus controlling priorities), and how the CAN data field is used to specify services, move data, and determine its meaning. The way information flows on a communication network is critical. Older communication technology consisted of messages that were constructed with a specific source and destination. Instead of a traditional source-destination approach, DeviceNet uses a more efficient Producer-Consumer Model, which requires a packet to have identifier fields for the data. The identifier provides the means for multiple priority levels (used in arbitration), more efficient transfer of I/O data, and multiple consumers. The device with data produces the data on the network with the proper identifier. All devices who need data listen for messages. When devices recognized the appropriate identifier, they consume the data. With the producer-consumer model, the message is no longer specific to a particular source or destination. A single message from one controller can be used by multiple motor starters using less bandwidth. DeviceNet defines two different types of messaging. They are called I/O Messaging and Explicit Messaging. I/O messages are for time-critical, control-oriented data. They provide a dedicated, special-purpose communication path between a producing application and one or more consuming applications. They are exchanged across single or multi-cast connections and typically use high priority identifiers. I/O messages contain no protocol in the 8-byte data field. The only exception is for fragmented I/O messages where one byte is used for fragmentation protocol. The meaning of the message is implied by the connection ID (CAN identifier). Before messages are sent using these IDs, both the device sending and receiving must be configured. The configuration contains the source and destination object attribute addresses for the producer and consumer of the data. Explicit messages provide multi-purpose, point-to-point communication paths between two devices. They provide the typical request/response-oriented network communications used to perform node configuration and problem diagnosis. Explicit messages typically use low priority identifiers and contain the specific meaning of the message right in the data field. This includes the service to be performed and the specific object attribute address. Fragmentation services are provided for messages that are longer than 8 bytes. Each I/O Message fragment incurs only a single byte of
More:
Page contents:
More:
CAN in Automation
protocol overhead. There is no limit on the number of fragments. Fragmentation is also defined for explicit messaging. This flexibility assures that as more sophisticated devices are introduced and more capabilities are designed into devices, they can be added to existing DeviceNet networks. With its object-oriented design and addressing scheme, DeviceNet is unlimited in its ability to be expanded without having to alter the basic protocol and connection model. On the other end of the spectrum, a simple slave device application with two message connections (one I/O and one explicit) can be handled in less than 4K ROM and 175 bytes of RAM (Motorola 68HCO5X4, a CPU with a built-in CAN interface). The General format for I/O messages is shown in figures 9-12
Page contents:
More:
Page contents:
CAN in Automation
More:
Page contents:
Predefined Master/Slave Connection Set While DeviceNet provides a powerful Application Layer Protocol that allows dynamic configuring of connections between devices. It has been recognized that some devices will have neither the need nor the resources to use this powerful capability. For this reason, a set of connection identifiers known as the Predefined Master/Slave Connection Set has been specificed to simplify the movement of I/O and configuration-type data typically seen in a Master/Slave architecture. Many sensors and actuators are designed to perform some predetermined function (sense pressure, start motor, etc.) and the type and amount of data the device will produce and/or consume is known at power-up. Typically these devices provide input data or require output data and configuration data. The Predefined Master/Slave Connection Set meets these needs by providing connection objects that are almost entirely configured at the time the device powers-up. The only remaining step necessary to begin the flow of data is for a master device to claim ownership of this predefined connection set within its slave(s). Message Group 2 is used for the definition of these identifiers (refer back to figure 7). One noticeable difference in Group 2 is that the MAC ID is not specified as Source MAC ID. This allows the use of Destination ID. There are strict rules about the use of this kind of connection to prevent duplicate CAN identifiers on the bus. The use of Destination ID allows devices, which are centralized and which must communicate with many nodes (a master) to borrow identifiers from those nodes. In addition, the MAC ID and Message ID fields are reversed. This allows the Group ID and MAC ID to fall within the most significant 8 bits of the CAN identifier. This is important because many low-cost, 8-bit CAN chips can hardware filter only the first 8 bits. The exclusive use of Destination MAC ID further allows
More:
CAN in Automation
devices to take advantage of hardware filtering. Another important benefit is that the establishment of connections from the Predefined Set is simplified considerably. Only a few messages are required to have I/O connections up and running. The Predefined Set contains one explicit messaging connection and allows several different I/O connections including Bit Strobed Command/Response, Change-of-State and Cyclic. Chapter 7, Volume I contains detailed information about the Predefined Master/Slave Connection Set. Change-of-State and Cyclic Transmission With change-of-state, a device produces its data only when it changes. To be sure the consuming device knows that the producer is still alive and active, DeviceNet provides an adjustable, background heartbeat rate. Devices send data whenever it changes or the heartbeat timer expires. This serves to keep the connection alive and let the consumer know his data source has not faulted in some way. The minimum time on the heartbeat prevents inherently noisy nodes from dominating the network. By having the device generate the heartbeat, the controller is not burdened with having to send a nuisance request periodically just to make sure it is still there. This becomes even more efficient in the multicast case. The cyclic option can reduce unnecessary traffic and packet processing. Instead of a temperature or analog input block being scanned dozens of times every second, it can be set up to report its data on a regular basis consistent with the rate of change it can detect. A temperature sensor on a slow PID loop with a 500 ms update time could have its cyclic rate set to 500 ms. Not only would this preserve bandwidth for more rapidly changing critical I/O data, it would also be more accurate as well. For example, it might be scanned once every 30 ms as part of a large scan list with many bytes of data per node on a heavily loaded master. This means that data used in a PID calculation might have been sampled anywhere from 470 to 530 ms. With cyclic production you know that the data samples will be at precisely 500 ms. By default, both change of state and cyclic are acknowledged exchanges (ACKs) so that the producer knows its intended consumer(s) received the data. For applications where changes of state or cyclic rates are extremely fast, it makes no sense to clutter up the network with ACK packets. Unnecessary ACKs can be suppressed with the Acknowledge Handler Object (Chapter 6, Volume II, Rel 1.2, pages 6-252 to 6-272). Now, even simple slave nodes can be set up to report at the most appropriate interval, whether that be cyclic or change-of-state. With the ACK Handler Object it is possible to have multiple consumers of the slaves' data, not just the master. This multicast is especially
Page contents:
More:
Page contents:
Top Physical Layer and Media Indicators and Configuration Switches Communication Protocol and Application The Object Model Messaging Predefined Master/Slave Connection Set Device Profiles
CAN in Automation
useful for operator interface (OI) devices, which can just listen for the data they need, whether it is for display, alarm monitoring or data logging. For alarm monitoring, it is important that a change-of-state not be missed, so the OI device would be included in the device's ACK list, assuring a retry (or several retries) if for some reason the OI missed the message. On the other hand, if it was primarily a data collection device logging values every 5 seconds (and the node is producing values every 300 ms for control purposes), you would not have the logger set to ACK. If the logger misses a value, it can grab the next one 300 ms later. Cyclic and change-of-state from the master is defined and selectable on a per node basis. Device Profiles The DeviceNet specification goes beyond a physical connection protocol specification. It promotes interoperability by defining standard device models. All devices of the same model must support common identity and communication status data. Device-specific data is contained in device profiles that are defined for various device types. Simple devices (e.g. push buttons, motor starters, photocells, pneumatic valve actuators) from multiple vendors that comply with their device type profile will be logically interchangeable. A device profile will contain the following sections: q Definition of the device's object model This often contains a drawing like the one shown in the object model (figure 8). Usually there are tables, which list all of the object classes present in the device, the number of instances in each class, how each object effects behavior, and the public interfaces to each object. q Definintion of the device's I/O data format This usually includes definition of Assembly Object definition, which contains the address (class, instance, and attribute) of the desired data components. q Definition of the device's configurable parameters and public interfaces to those parameters. This information is also often contained in an Electronic Data Sheet (EDS), which could be included with the device's user documentation. As an example, a photoelectric sensor (Device Type 6) would contain the following objects: Identity Object 1
More:
Page contents:
More:
CAN in Automation
Message Router DeviceNet Connection Assembly Parameter Presence Sensing
1 1 2 (one explicit, one I/O) 1 1 (optional) 1
Page contents:
The DeviceNet specification defines an Electronic Data Sheet (EDS), which is a simple file format that allows product-specific information to be made available by vendors for all other vendors. This makes possible user-friendly configuration tools that can be easily updated without having to constantly revise the configuration software tool. In order not to restrict enhancements, a means is also provided for addition of vendor specific, value-add options. The DeviceNet specification has public classes, services and attributes, which are defined in the DeviceNet specification and vendor-specific classes, services and attributes, which can be added by individual vendors. This allows vendors to provide additional functions to their customers that are not covered in the specification. As vendor-specific items become more popular or commonplace, the mechanism to transition them to public items will be provided.
More:
Page contents:
CAN in Automation
More:
Page contents:
CAN in Automation
CAN related standards

Page contents: DS 102 V2.0 DS 150 V1.1 DeviceNet CAN Kingdom CAN Physical Layer for Industrial Applications DS 102 V2.0 The scope of this document is, to define the content of the physical layer and the basic characteristics of the physical medium, for communication according to the Controller Area Network protocol specification (CAN) between different types of electronic modules in general industrial applications. CAN is a serial communication protocol supporting distributed real-time control and multiplexing. This part refers to using a differentially driven two-wire bus line with common return as physical medium. Power Management Layer Specification DS 150 V1.1 members only This document specifies facilities and services of an Power Management Layer protocol entity on the CAN bus allowing significant reduction of power consumption in CAN networks by the introduction of the so-called network standby capability. The power reduction facilities of current CAN controller hardware designs by using the sleep mode, which can be recognized as a de-facto standard; are supported for usage under all higher layer protocols during an internal Power Management Layer IDLE state. WARNING: This CAN Power Management Layer deals with reliable communication on CAN networks with power reduction capability. There is very little relationship to the ISO/OSI Power Management Layer otherwise. The main features of the CAN Power Management Layer are q standby capability supports CAN sleep mode for usage under all CAN higher-layer protocols, i.e. functional LLC interface remains virtually the same although time behaviour may change,
CiA Standards
More:
CAN Standards CAL Standards CANopen Standards Literature Order Form
Page contents:
Top DS 102 V2.0 DS 150 V1.1 DeviceNet CAN Kingdom
More:
http://www.can-cia.de/lsm.htm (1 von 3) [14.11.1999 12:47:19]
CAN in Automation
full compatibility with CAN multi-master decentralized network architecture, easy hardware implementation/integration into CAN peripherial controllers, coexistance of nodes with and without Power Management Layer support is possible.
DeviceNet DeviceNet is a low-cost communications link to connect industrial devices (such as limit switches, photoelectric sensors, valve manifolds, motor starters, process sensors, bar code readers, variable frequency drives, panel displays and operator interfaces) to a network and eliminate expensive hardwiring. The direct connectivity provides improved communication between devices as well as important device-level diagnostics not easily accessible or available through hardwired I/O interfaces. DeviceNet is an open network standard. The specification and protocol are open; vendors are not required to purchase hardware, software or licensing rights to connect devices to a system. Anyone may obtain the DeviceNet Specification from the Open DeviceNet Vendor Association, Inc. (ODVA) for a nominal reproduction charge (currently $250 USD + postage). Any company that manufactures (or intends to manufacture) DeviceNet products may join ODVA and participate in technical working groups that are developing enhancements to the DeviceNet Specification. Buyers of the DeviceNet Specification receive an unlimited, royalty-free license to develop DeviceNet products. Companies looking for assistance may purchase sample code that eases their implementation, development toolkits, and development services from many sources. The key hardware components are available from the largest worldwide suppliers of semiconductors. CAN Kingdom (external link to Kvaser) The CAN protocol has a great hidden power that is not obvious until you have penetrated the problems around designing distributed embedded control systems where independently developed modules will be integrated into the system. CAN Kingdom is especially developed for such
Page contents:
More:
CAN in Automation
systems. Most networks provide services for connected modules. In control networks however, connected modules serve the network. CAN Kingdom takes advantage of this fact, making separation of module and system development not only possible but even simple. In fact, most papers written on the subject of Controller Area Network design are, in my opinion, misleading as they are built upon the OSI model. The OSI model was developed for communication networks. Such networks are intended to be accessed by users, unknown at the design phase, during runtime. In a controller area network, where real-time features are essential, all communication needs have to be known at the design phase. CAN Kingdom is open only during this phase. At runtime a CAN Kingdom network works exactly in the way the network designer has decided.
Page contents:
CAN in Automation
CAN
Page contents: CAN 2.0 Part A CAN 2.0 Part B CAN 2.0 Addendum CAN Standard The acceptance and introduction of serial communication to more and more applications has led to requirements that the assignment of message identifiers to communication functions be standardized for certain applications. These applications can be realized with CAN more comfortably, if the dress range that originally has been defined by 11 identifier bits is enlarged. Therefore a second message format ('extended format') is introduced that provides a larger address range defined by 29 bits. This will relieve the system designer from compromizes with respect to defining well-structured naming schemes. Users of CAN who do not need the identifer range offered by the extended format, can rely on the conventional 11 bit identifier range ('standard format') further on. In this case they can make use of the CAN implementations that are already available on the market, or of new controllers that implement both formats. In order to distinguish standard and extended format the first reserved bit of the CAN message format, as it is defined in CAN Specification 1.2, is used. This is done in such a way that the message format in CAN Specification 1.2 is equivalent to the standard format and therefore is still valid. Furthermore, the extended format has been defined so that messages in standard format and extended format can coexist within the same network. This CAN Specification 2.0 consists of two parts, with
q
CiA Standards
More:
CAL Standards CANopen Standards Related Standards
Page contents:
Top CAN 2.0 Part A CAN 2.0 Part B CAN 2.0 Addendum
More:
CAL Standards CANopen Standards Related Standards
Page contents:
Top CAN 2.0 Part A CAN 2.0 Part B CAN 2.0 Addendum
CAN 2.0 Part A

describing the CAN message format as it is defined in CAN Specification 1.2;
http://www.can-cia.de/lsc.htm (1 von 2) [14.11.1999 12:47:29]
CAN in Automation
CAN 2.0 Part B

describing both standard and extended message formats.
In order to be compatible with this CAN Specification 2.0 it is required that a CAN implementation be compatible with either Part A or Part B.
CAN 2.0 Addendum

Implementation Guide for the CAN Protocol The Controller Area Network protocol specification document describes the function of the network on the whole. Additionally, Bosch provides a Reference CAN Model to the CAN licensees, supporting the protocols implementation into the licensees CAN controller nodes.
http://www.can-cia.de/lsc.htm (2 von 2) [14.11.1999 12:47:29]
CAN in Automation
CAN Application layer

All specifications can be ordered Page contents: DS 201 V1.1 - CAN in the OSI Reference Model DS 202 V1.1 - CAN based Message Specification (CMS) DS 203 V1.1 - Network Managment (NMT) DS 204 V1.1 - Distributor (DBT) DS 205 V1.1 - Layer Managment (LMT) DS 206 V1.1 - Recommended Standard CAL Module Data Sheet DS 207 V1.1 - Application Layer Naming Conventions CAN Application Layer (CAL) for Industrial Applications The Controller Area Network (CAN) is a data communication network designed to fit distributed real-time control applications. It was originally developed and applied by the automotive industry to solve the cabling problem inside vehicles. However CAN also provides good properties as a control network for industrial applications. CAN in the OSI Reference Model DS 201 V1.1 members only This document contains a description of the CAN Reference Model. This document is part of a set of documents that standardize the CAN Application Layer for Industrial Applications. The purpose of the CAN Reference Model and its related service- and protocol specifications is to make CAN an open network where modules from different suppliers can cooperate in distributed applications. CAN based Message Specification (CMS) DS 202 V1.1 This document contains the service and protocol specification and the data types and encoding rules of the CAN based Message Specification (CMS). CMS is part of the CAN Application Layer. This document is part of a set of documents that standardize the CAN Application Layer for Industrial Applications.
CiA Standards
More:
CAN Standards CANopen Standards Related Standards Literature Order Form
Page contents:
Top DS 201 V1.1 DS 202 V1.1 DS 203 V1.1 DS 204 V1.1 DS 205 V1.1 DS 206 V1.1 DS 207 V1.1
More:
http://www.can-cia.de/lsa.htm (1 von 5) [14.11.1999 12:48:02]
CAN in Automation
These three parts are in the different documents: q DS 202-1 V1.1: CMS Service Specification members only q DS 202-2 V1.1: CMS Protocol Specification members only q DS 202-3 V1.1: CMS Data Types and Encoding Rules members only CMS is one of the application layer service entities of the CAN Reference Model. CMS is a language to specify what Communication Objects a module uses and how they are formatted. CMS can describe all CAN layer 2 features. This means also that existing applications can be described in CMS. Furthermore CMS offers the application a possibility to model its behaviour in the form of objects and remote services on these objects. This allows other applications to cooperate with it by executing these services that CMS supports on these objects. Network Management (NMT) DS 203 V1.1 This document contains the service and protocol specification of the Network Management (NMT). NMT is part of the CAN Application Layer. This document is part of a set of documents that standardize the CAN Application Layer for Industrial Applications. These two parts are in the different documents: q DS 203-1 V1.1: NMT Service Specification members only q DS 203-2 V1.1: NMT Protocol Specification members only NMT is one of the application layer entities in the CAN Reference Model. The NMT aids in the development of distributed applications. Due to the fact that an application is distributed, certain events have to be handles (e.g. failures of parts of the application) that would not occure if the same application had not been distributed. The application has to deal with these network management aspects, although they have nothing to do with goal of the application (e.g. controlling a process). These aspects are the
Page contents:
More:
Page contents:
CAN in Automation
consequence of building a distributed application and must be compared to the advantages of building a distributed application. Distributor (DBT) DS 204 V1.1 This document contains the service and protocol specification of the Distributor (DBT). DBT is part of the CAN Application Layer. This document is part of a set of documents that standardize the CAN Application Layer for Industrial Applications. These two parts are in the different documents: q DS 204-1 V1.1: DBT Service Specification members only q DS 204-2 V1.1: DBT Protocol Specification members only The essential issue in creating an open system where modules from independent suppliers can cooperate via CAN, is how the identifiers and inhibit-times are assigned to the Communication Objects that a module uses. Identifiers are used by the Data Link Layer and inhibit-times are defined by the CMS service element of the CAN Application Layer. The DBT is a service element of the CAN Application Layer that offers dynamic distribution of identifiers and inhibit-times to the Communication Objects that a module uses. The dynamic distribution does not necessarily take place every time the module is 'powered on'. Depending on the facilities of the module, distribution may only be required once e.g. when the module is installed to the network. Layer Management (LMT) DS 205 V1.1 This document contains the service and protocol specification of the Layer Management (LMT). LMT is part of the CAN Application Layer. This document is part of a set of documents that standardize the CAN Application Layer for Industrial Applications. These two parts are in the different documents: q DS 205-1 V1.1: LMT Service Specification members only q DS 205-2 V1.1: LMT Protocol Specification
More:
Page contents:
More:
Page contents:
CAN in Automation
members only LMT is one of the application layer entities in the CAN Reference Model. LMT offers the possibility to inquire and change the settings of certain parameters of the local layers on a CAN module with LMT Slave capabilities by a CAN module with LMT Master capabilities via the CAN Network. The following parameters can be inquired and/or changed by the use of LMT: q NMT-address of the NMT Service Element, q bit timing parameters of the physical layer, q LMT address. By using LMT,a LMT Slave can be configured for a CAN network without using any devices like DIP-switches for setting the parameters. There are several solutions available for LMT Slaves with and without a unique LMT-address or non-volatile storage. Recommended Standard CAL Module Data Sheet DS 206 V1.1 members only This document contains a description of a recommended standard for a CAL module data sheet. The purpose of the recommended standard module data sheet is the provision of a standard description format for the complete specification of CAL-based modules in non-standardized-profile (proprietary) applications. The recommended Module Data Sheet consists of three parts and shall specify the functionality of a module as accessible from the bus. This means that not only the communication interface has to be specified but also the application specific functionality. Application Layer Naming Conventions DS 207 V1.1 members only This document contains the naming conventions that apply to instances of the objects that are defined by the service elements of the CAN Application Layer. This document is a part of a set of documents that standardize the CAN Application Layer for Industrial Applications.
More:
Page contents:
CAN in Automation
The CAN Application Layer offers an open CAN network where modules from different suppliers cooperate in a distributed application. To this purpose, the service elements of the CAN Application Layer model their functionality through the use of objects. Applications can create instances of those objects identified by a name. These names have a network-wide scope. Applications that want to execute remote services via the network on such an object must know its name and this name must identify the object.
CAN in Automation
CANopen
All specifications can be ordered. Page contents: DS 301 V4.0 - Application Layer and Communication Profile DSP 302 V2.0 - Framework for Programmable CANopen Devices DSP 401 V1.4 - Device Profile for I/O Modules DSP 402 V1.1 - Device Profile Drives and Motion Control DSP 403 V1.0 - Device Profile Human Machine Interfaces DSP 405 V1.0 - Device Profile for IEC 1131 Programmable Devices DSP 406 V2.0 - Device Profile for Encoders Application Layer and Communication Profile for Industrial Systems DS 301 V4.0 members only This document contains the description of the CANopen Application Layer and Communication Profile for Industrial Applications using CAN as their installation bus. The CANopen Application Layer defines the services and objects that are necessary to form a open communication for Industrial Applications on a CAN network. The CANopen Communication Profile forms the interface between the CANopen Application Layer and the CANopen Device Profiles. It includes the real-time communication model and the protocols which are common to all devices in the network. Device Profiles, on the other hand, are a common means to describe device specific functionality. An introduction to CANopen Device Profiles is given in this document as well, however, the specification of full device profiles does not fall within the scope of this document. Framework for Programmable CANopen Devices DSP 302 V2.0 members only In general the mechanisms which are specified in the communication profile are sufficient for the definition of profiles for devices which, on the application level, provide some kind of I/O functionality. Example devices include I/O modules, drives and regulators. These devices whilst they may be complex are not termed intelligent as they do not run an application level program.
http://www.can-cia.de/lso.htm (1 von 6) [14.11.1999 12:49:58]
CiA Standards
More:
CAN Standards CAL Standards Related Standards Literature Order Form
Page contents:
Top DS 301 V4.0 DSP 302 V2.0 DSP 401 V1.4 DSP 402 V1.1 DSP 403 V1.0 DSP 405 V1.0 DSP 406 V2.0
CAN in Automation
For the description and operation of intelligent devices further mechanisms are necessary which are specified in this document. This document has to be regarded as a framework for the definition of device profiles for intelligent or programmable devices in form of an extension to the CANopen Communication Profile. The additional mechanisms specified in this document are useful especially for intelligent devices like PLCs, HMIs or CANopen tools. This document comprises the following mechanisms and definitions: q The dynamic establishment of SDO connections between devices. Dynamic SDO connections are handled by the SDO Manager. q The term CANopen Manager is introduced to specify more clearly the network functionality of a network controlling device. q The definition of dynamically allocated entries in an object dictionary, which can be used for the representation of I/O data e.g. on programmable nodes like PLCs. q A general mechanism for downloading program data and functions for the control of programs on a device. q A possibility for detecting and configuration of unconfigured nodes during system boot-up by means of a Configuration Manager. q A debugging mechanism in the form of an OS command and prompt. q A multiplexed PDO, which allows to write data of object dictionary entries on a group of nodes simultaneously. The multiplexed PDO also has non-group applications. Some of these new mechanisms are also useful not only for intelligent or programmable devices. Therefore it is expected, that these probably will be included in a future revision of the CANopen Communication Profile. Device Profile for I/O Modules DSP 401 V1.4 members only This document represents the CANopen device profiles for digital and analogue Input and Output modules. All the above devices use communication techniques, which conform to those described in the CANopen Application Layer and Communication Profile. This document should be consulted in parallel to this profile.
More:
Page contents:
CAN in Automation
The purpose of the I/O modules is to connect sensors and actors to the CAN bus. They can receive configuration information via the service data objects such as I/O configurations, conversion parameters for converting data into meaningful measurements and so on. At run time, data can be read from the sensor over the CAN bus by either a request or interrupt (event) mechanism. The I/O modules also have a process data object mapping, which may be configured over a service data object for real time operation. Data can also be sent via the CAN bus to those I/O modules that have output capabilities. Output data can be sent to an I/O module via service data objects or process data objects. The I/O modules themselves are controlled by either the configuration master or put as remote modules for an Intelligent Peripheral Device. Device Profile Drives and Motion Control DSP 402 V1.1 members only This document represents the standardized CANopen Device Profile for digital controlled motion products like servo controllers, frequency converters or stepper motors. All the above devices use communication techniques, which conform to those described in the CANopen Application Layer and Communication Profile. This document should be consulted in parallel to this profile. The starting and sTopping of the drive and several mode specific commands are executed by the statemachine. The operation mode defines the behaviour of the drive. The following modes are defined in this profile:
q
More:
Page contents:
Homing Mode This mode describes the various methods to find a home position (also: reference point, datum, zero point).
Profile Position Mode The positioning of the drive is defined in this mode. Speed, position and acceleration can be limited and profiled moves using a Trajectory Generator are possible as well.
CAN in Automation
Interpolated Position Mode This mode describes the time interpolation of single axles and the spatial interpolation of coordinated axles. Synchronisation mechanisms and interpolation data buffers are covered by this mode.
Profile Velocity Mode The Profile Velocity Mode is used to control the velocity of the drive with no special regard of the position. It supplies limit functions and trajectory generation.
More:
Profile Torque Mode In this mode the torque control with all related parameters is described.
Velocity Mode Many frequency inverters use this simple mode to control the velocity of the drive with limits and ramp functions.
Page contents:
The Velocity Mode is rather separated from the other modes and does not interfere with them so much. For this reason, the naming of object dictionary entries differs a little bit from the other modes. The manufacturer commits in the manual which modes are supported by his device. If more than one mode is supported, then the manufacturer also defines whether the change of operation mode is allowed while the drive is moving or only when the drive is sTopped. Device Profile Human Machine Interfaces DSP 403 V1.0 members only This document represents the device profiles for Human Machine Interfaces (HMI). HMI devices use communication techniques, which conform to
CAN in Automation
those described in the CANopen Application Layer and Communication Profile. In general the mechanisms, which are specified in the communication profile are sufficient for the definition of profiles for devices, which, on the application level, provide some kind of I/O functionality. Example devices include I/O modules, drives and regulators. These devices, while they may be complex, are not termed intelligent as they do not run an application level program. For the description and operation of intelligent devices further mechanisms are necessary, which are specified in the Framework for Programmable CANopen Devices. This specification has to be regarded as a framework for the definition of device profiles for intelligent or programmable devices in form of an extension to the CANopen Application Layer and Communication Profile. The additional mechanisms specified in the framework are useful especially for devices such as PLCs, very intelligent HMI or CANopen tools. These documents should be consulted in parallel to this profile. The purpose of the device profile for a Human Machine Interface (HMI) is to support simple HMI devices as well as intelligent and very intelligent HMI devices. The profile defines display functions and user functions. This device profile is based upon the definitions in the CANopen Communication Profile. The definitions of simple HMI, intelligent HMI and very intelligent HMI refers to the kind of the implemented CANopen Communication Profile. Device Profile for IEC1131 Programmable Devices DSP 405 V1.0 members only This document represents the standardized CANopen Device Profile for IEC1131 programmable devices like PLCs. All the above devices use communication techniques, which conform to those described in the CANopen Application Layer and Communication Profile and the Framework for Programmable CANopen Devices. These documents should be consulted in parallel to this profile. This paper covers 1. the access to a CANopen communication system from within an IEC1131 program
More:
Page contents:
CAN in Automation
. based on variables, i.e. access to elementary IEC1131 variable objects, b. based on calls to function block. 2. utility functions for debugging, monitoring and network management With respect to integrating tools for CANopen configuration and IEC1131 programming and debugging, this paper defines two different kinds of integration: 1. The network-centric approach, in which IEC1131 programming is assumed to be done after CANopen configuration, being logically below configuration 2. The PLC-centric approach, in which CANopen configuration is assumed to be done after IEC1131 programming, being logically only one part of the configuration of the complex PLC system Device Profile for Encoders DSP 406 V2.0 members only This document represents the CANopen device profiles for incremental and absolute, linear and rotary encoders. Besides position and velocity output possibility complete cam functionality is covered. In addition it is possible to handle multi sensors through one CANopen device. All the above devices use communication techniques, which conform to those described in the CANopen Application Layer and Communication Profile. This document should be consulted in parallel to this profile. The purpose of encoders is to detect positions of any kind of machine tools. Encoders detect positions and transmit the position values across the CAN network. They can receive configuration information via the service data objects, conversion parameters for calculating a - to the application adapted - position value. In the operational status, the position value can be read from the encoder by Remote Transmission Request telegrams or Sync Telegrams. Additionally, the encoders can transmit cyclic the position values.
CAN in Automation
Literature Order Form CiA Standards (in English):

CAN Presentations download here CiA Draft Standard 102 (Version 2.0) CAN Physical Layer For Industrial Applications (4 pages, free of charge) Download as PDF File CiA Draft Standard 150 (Version 1.2) CAN Power Management Layer (23 pages, 15 EUR + German VAT) CiA Draft Standard 201...207 (Version 1.1) CAN Application Layer For Industrial Applications (150 pages, 65 EUR + German VAT) CiA Draft Standard 301 (Version 4.0) CANopen Communication Profile For Industrial Systems ( 65 EUR+ German VAT) CiA Draft Standard Proposal 302 (Version 2.0) Framework for Programmable CANopen Devices (30 pages, 35 EUR + German VAT) CiA Draft Standard Proposal 401 (Version 1.4) CANopen Device Profile For I/0 Modules (115 pages, 49 EUR + German VAT) CiA Draft Standard Proposal 402 (Version 1.0) CANopen Device Profile For Drives and Motion Control (200 pages, 65 EUR + German VAT) CiA Draft Standard Proposal 403 (Version 1.0) CANopen Device Profile For for Human Machine Interfaces (52 pages, 49 EUR + German VAT) CiA Draft Standard Proposal 405 (Version 1.0) CANopen Device Profile For IEC 1131 Programmable Devices (32 pages, 35 EUR + German VAT)
CiA
More:
Downloads CAN Newsletter
More:
More:
http://www.can-cia.de/Lo.htm (1 von 4) [14.11.1999 12:50:33]
CAN in Automation
CiA Draft Standard Proposal 406 (Version 2.0) CANopen Device Profile For Encoders (111 pages, 49 EUR + German VAT) All CAN + CANopen Standards CD-Version (150 Euro + German VAT)
More:
Standards (in English)
CAN Kingdom 3.0 to download go to Volume 1 and 2, Release 2.0 DeviceNet (paper version: 260 EUR + German VAT + postage) Volume 1 and 2, Release 2.0 DeviceNet (CD-ROM: 260 EUR + German VAT + postage) Volume 1 and 2, Release 2.0 DeviceNet (paper and CD-ROM version: 320 EUR + German VAT + postage)
More:
Proceedings (in English)

2nd international CAN Conference 1995 (340 pages, free of charge) 3rd international CAN Conference 1996 (360 pages, 21 EUR) 4th international CAN Conference 1997 (360 pages 41 EUR 5th international CAN Conference 1998 (302+ pages 61 EUR
More:
CAN in Automation
CAN Literature (in German)

Prof. Konrad Etschberger CAN 2nd edition, available September 1999
More:
Prof. Wolfhard Lawrenz CAN 3nd edition, (500 Seiten 85,90 EUR) Sonderheft Controller Area Network Vogel Verlag (100 Seiten 16 EUR) Downloads CAN Newsletter
CAN Literature (in English)

Prof. Dr. Wolfhard Lawrenz CAN System Engineering 1st edition, (468 pages 60,33 EUR or 69,95 $ )
CAN Literature (in Franais)

Le Bus CAN Dominic Paret, 277 pages (250 FF) Le Bus Can Applications Dominic Paret, 340 pages (250 FF) Magazines (in English): published quarterly in March, June, September, December
More:
CAN in Automation
CAN Newsletter 1-year subscription (4 issues) (15 EUR in Europe, 26 EUR in Overseas)
More:
Name: Company: Street: ZIP: City: Country: Phone: Fax: E-Mail:

Send Order
CAN in Automation
Download Presentations:
Download
More:
Physical Layer Data Link Layer Implementations Applications CANopen Download for members
Page contents:
top Presentations Specifications Orderforms
Specifications:
CAN Specification 2.0 consists of two parts, with CAN 2.0 Part A describing the CAN message format as it is defined in CAN Specification 1.2; CAN 2.0 Part B describing both standard and extended message formats. In order to be compatible with this CAN Specification 2.0 it is required that a CAN implementation be compatible with either Part A or Part B. CAN 2.0 Addendum ...
More:
Download for members
Page contents:
CAN Physical Layer for Industrial Applications DS 102 V2.0
CANopen Cabling and Connector Pin Assignment DR 303-1 V1.0
CANopen Representation of SI Units and Prefixes DR 303-2 V1.0
http://www.can-cia.de/d.htm (1 von 2) [14.11.1999 12:51:23]
CAN in Automation
Orderforms:
Training & Education iCC iCC Conference iCC Seminars & Workshops Fairs & Exibitions
CAN in Automation last update:1999-10-13
More:
Download for members
Page contents:
http://www.can-cia.de/d.htm (2 von 2) [14.11.1999 12:51:23]
CAN in Automation
General introduction
Page contents: Advantages & features First information Advantages
r
CANopen
More:
Features
r
Open and vendor independent Supports inter-operability of different devices High speed real-time capability Modular - covers simple to complex devices User-friendly - wide variety of support tools available
Auto configuration of the network Easy access to all device parameters Device synchronisation Cyclic and event-driven data transfer Synchronous reading or setting of inputs, outputs or parameters
Technical introduction Specifications Conformance test FAQs Vendor list Vendor ID registration Presentation: CANopen
Page contents:
Top Advantages & features First information
First Information CANopen is a networking system based on the serial bus Controller Area Network (CAN). The CANopen Communication Profile (CiA DS-301) supports both direct access to device parameters and time-critical process data communication. CANopen device profiles (CiA DS-40x) define standards for basic device functionality while providing ample scope for additional vendor-specific device features. CANopen unleashes the full power of CAN by allowing direct peer-to-peer data exchange between nodes in an organized and, if necessary, deterministic manner. The network management functions specified in CANopen simplify project design, implementation and diagnosis by providing standard mechanisms for network start-up and error management. CANopen supports both-cyclic and event-driven communication. This makes it possible to reduce the bus load to a minimum but still maintaining extremely short reaction times. High communication performance can be achieved at relatively low baud rates, thus reducing EMC problems and minimizing cable costs.
http://www.can-cia.de/hog.htm (1 von 2) [14.11.1999 12:52:04]
CAN in Automation
CANopen is the ideal networking system for all types of automated machinery. One of the distinguishing features of CANopen is its support for data exchange at the supervisory control level as well as accommodating the integration of very small sensors and actuators on the same physical network. This avoids the unnecessary expense of gateways linking sensor/actuator bus systems with higher communication networks and makes CANopen particularly attractive to original equipment manufacturers.
More:
Technical introduction Specifications Conformance test FAQs Vendor list Vendor ID registration presentation: CANopen
Page contents:
http://www.can-cia.de/hog.htm (2 von 2) [14.11.1999 12:52:04]
CAN in Automation
Technical introduction
Page Content : Built on standards Application layer and communication profile Communication model Network initialization and management Data transfer mechanisms Service data objects Process data objects Events Synchronization Polling PDO mapping Device profiles Object dictionary Object dictionary - example CANopen development Built on Standards Open fieldbus systems enable the construction of machines by connecting components from multiple vendors while minimizing the effort required for interfacing. To achieve an open networking system, it is necessary to standardize the various layers of communication used. CANopen uses the international CAN standard, ISO 11898 as the basis for communication. This standard covers the lower two layers of communication specified by the OSI model. Building on this, the CANopen profile family specifies standardized communication mechanisms and device functionality for CAN-based systems. The profile family, which is available and maintained by CAN in Automation (CiA) consists of the Application layer and communication profile (DS 301), various frameworks and recommendations (CiA DS-30x) and various device profiles (CiA DS-40x). Application Layer and Communication Profile The CANopen Application Layer and Communication Profile (CiA DS 301) defines how data should be exchanged between devices and describes the interface to the underlying communication medium. To realize open interoperable
http://www.can-cia.de/hot.htm (1 von 9) [14.11.1999 12:52:55]
CANopen
More:
General introduction Specifications Conformance test FAQs Vendor list Vendor ID registration Presentation: CANopen
Page contents:
Top Built on standards Application layer and communication profile Communication model Network initialization and management Data transfer mechanisms Service data objects Process data objects Events Synchronization Polling PDO mapping Device profiles Object dictionary Object dictionary example CANopen development
CAN in Automation
systems based on CAN, it is necessary to define, which data have to be transmitted and with which services. CANopen provides one such definition, which is especially suitable for real-time industrial automation. Development of the Application layer and communication profile started with the following objectives: q Clear and concise structure to ease implementation and maintenance q Use existing international standards as far as possible q Support for CAN chips with acceptance filtering and message storage capabilities (FullCAN) to allow implementation in simple devices q Use smallest possible number of communication objects (CAN identifiers) q Easily scalable from simple to complex functionality to cover the wide range of devices found in automated machinery q Provide reliable and deterministic network behaviour With these objectives in mind, CANopen was developed using only a small number of communication services necessary for machine automation, resulting in low processor and memory overhead. Considering the data flow requirements of automation systems led to the definition of the following Communication model. Communication Model The CANopen protocol defines several methods for transmission and reception of messages over the CAN bus. These messages are referred to as communication objects. Synchronous data transfers allow network wide coordinated data acquisition and actuation. Synchronous transfers are supported by predefined communication objects i.e. Sync Objects transmitted on a cyclic time period and Time Stamp Objects. Asynchronous or event messages may be sent at any time and allow a device to immediately notify another device without having to wait for a synchronous data transfer to take place. The content of both synchronous and event telegrams (Process Data Objects) may be dynamically configured at boot up by the machine controller. Although CAN is restricted to transfers of a maximum of 8 data bytes within one telegram, data transfers larger than 8 bytes are also provided for by the protocol (Service Data Objects).
More:
Page contents:
CAN in Automation
CANopen defines four types of messages (communication objects): q Network administration messages such as Layer Management (LMT) and Network Management (NMT) q Service Data Objects (SDO) q Process Data Objects (PDO) q Predefined messages such as the Sync Object, Time Stamp Object and Emergency Object Network Initialisation and Management Network management services are used to control the operating state of devices in a CANopen network. Using network management the following functionality is available: q Dynamic or static distribution of CAN identifiers for SDO/PDO communication and error services q Control over node operating states and communication modes for individual or multiple nodes q Periodic Polling of nodes to detect nodes that are no longer alive or functioning correctly q Instead of Polling every device produce a message that he is still alive and other devices can "hear" to this messages Data Transfer Mechanisms CANopen defines two Data transfer mechanisms, which have very different characteristics and are intended to cover the full range of requirements found in automation applications. Service Data Object (SDO) transfers are acyclic and are typically used for configuring devices on a CANopen network with low priority. Individual parameters are addressed using a 16 bit index and an 8 bit sub-index addressing mechanism. Data transfers in this mode may be greater than 8 bytes by use of multiple CAN telegrams. Process Data Object (PDO) transfers are typically used for high speed, high priority data. Data in a PDO telegram is limited to 8 bytes or less. The format and data content of the message may be fixed or dynamically configured using SDO data transfers. Service Data Objects Service Data Objects (SDOs) are normally used for device configuration such as setting device parameters or
More:
Page contents:
CAN in Automation
downloading programs. They are also used to define the type and format of information communicated using the Process Data Objects. Service Data Objects provide the following functionality: q Transmit data of any size (boolean to large files) q Confirmed services (request/response) for read and write of any data q Expedited transfer of data less than or equal to 4 bytes total length q Segmented transfer of data greater than 4 bytes total length q Abort of data transfer by either Client or Server with optional error feedback In CANopen devices, all parameters and variables, which are to be accessible via CAN are clearly arranged in an object dictionary, which is described in more detail later. All the objects in the object dictionary can be read and/or written via SDO. Process Data Objects The Process Data Objects (PDO) do not contain any explicit protocol overhead and this allows very fast and flexible exchange of data between applications running on each node. PDOs can be transmitted directly from any device on the network simultaneously to any number of other devices. This multicast capability is one of the unique features of CAN and is exploited to the full by CANopen. Events CANopen supports different modes for transfer of real-time data. One mode is simply to send a PDO telegram on the occurrence of an event. For example, a digital I/O transmits the state of its input lines when they change state. An analogue input module might send the state of an input line once this state has exceeded a pre-configured value. This mode allows the bus load to be reduced to a minimum and a high communication performance can be realized with relatively low bit rates. It also allows the reaction time to changing data, which is the critical factor in many applications, to be kept very short. Synchronization
More:
Page contents:
CAN in Automation
The synchronized mode allows devices on the network to be tightly synchronized to a master clock. This is essential in some motion control applications or in applications where remote inputs and outputs have to be read or written simultaneously. This mode is particularly useful where control loops are closed over the bus necessitating synchronous sampling of Process data. As well as the cycle time, the protocol also allows many other parameters to be changed. For instance, it is possible to transmit some of the data only every n-th cycle. Synchronous and event-driven objects may be mixed freely on the network.
More:
Page contents:
Polling Finally it is also possible to read Process data from other nodes by Polling. A PDO can be used to poll a particular set of data at any time using the CAN remote frame mechanism. PDO Mapping A special feature of CANopen is that the data contained in PDOs may either be predefined by the device manufacturer or it may be configured by the application. Thus it is possible to optimize real-time data transfer for a particular application. It is even possible, by means of a place holder mapping, to serve several nodes with data in the same message. Device Profiles CANopen uses the concept of device profiles, which aids systems integration and device standardization. By conforming to the guidelines contained in a CANopen device profile two
CAN in Automation
independent manufacturers can produce standardized devices. The advantages of this approach are numerous and perhaps, most importantly it allows a system integrator to decouple himself from a specific device manufacturer. This allows networks of devices from independent manufacturers to be constructed without having to write specific software for networking each device together. Both optional and manufacturer specific functionality can also be defined for a device using the CANopen profiling mechanism, making CANopen device profiles future proof. By defining mandatory device characteristics, basic network operation is guaranteed. By defining mechanisms for both optional and manufacturer specific functionality future CANopen devices will not be constrained by an out of date standard. CANopen device profiles are being defined for a whole range of different device types including digital and analogue I/O modules, drives, motion controllers, encoders and operator displays. Object Dictionary All device parameters are listed in the standardiZed CANopen Object Dictionary and each entry is assigned a 16 bit index, which is used to access the data. The Object Dictionary contains the description, data type and structure of each parameter. The CANopen Object Dictionary is organized in several sections comprising a data type area, a communication profile area, a device profile area and a manufacturer specific area. The structure is shown in the table below: Index 0001-001F 0020-003F 0040-005F 0060-009F 1000-1FFF 2000-5FFF 6000-9FFF Object Dictionary Section Static Data Types (e.g. Boolean, Integer 16) Complex Data Types (e.g. PDO CommPar, SDO Parameter) Manufacturer Specific Data Types Device Profile Specific Data Types Communication Profile Area Manufacturer Specific Area Device Profile Area (as defined in the CANopen Device Profiles)
More:
Page contents:
Object Dictionary - Example
CAN in Automation
Many different data types are supported from simple bit values to complex structures and these are defined in the object dictionary. Manufacturer specific data types may also be defined. The communication profile area contains information about the communication as well as some basic data about the device. The data mapping for PDO messages is also defined here. The device profile area contains device specific parameters. There is a range of mandatory entries in the dictionary which ensures that all CANopen devices of a particular type show the same basic behaviour. Some extended device features are defined as optional. This means that a manufacturer is not obliged to provide all 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. An extract from a sample object dictionary is shown below.
Index Sub-Index Object Name Type Attribute Default Value 1000 00 VAR device type unsigned const 00 03 01 91H 32 1001 00 VAR error register unsigned ro 00H 8 1002 00 VAR manufacturer unsigned ro 00 00 00 00H status 32 register 1003 ARRAY error register 00 number of unsigned ro 01H entries 8 01 error value unsigned ro 00H 32 1008 00 VAR manufacturer vis-string const CiA_Product device name 1009 00 VAR manufacturer vis-string const V1.1 hardware version 100A 00 VAR manufacturer vis-string const V2.4 software version 1018 RECORD identity object 00 VAR number of unsigned const 01H entries 8 01 VAR Vendor-ID unsigned const 01H 32 1400 RECORD 1st receive PDO parameter
More:
Page contents:
CAN in Automation
00 01 02 6000 00
VAR VAR VAR ARRAY VAR
number of entries receive PDO COB-ID PDO type read 8 input lines number of input lines in groups of 8 read state of 8 input lines
unsigned ro 8 unsigned rw 32 unsigned rw 8
02H
More:
General introduction Specifications Conformance test FAQs Vendor list Vendor ID registration Presentation:
FFH
unsigned ro 8 unsigned ro 8
01H
01
VAR
CANopen Development The CANopen Specifications are maintained by the Interest Group CANopen and related Special Interest Groups within the international CAN users and manufacturers group, CAN in Automation (CiA). The work is coordinated by the CiA Interest Group CANopen and associated Special Interest Groups. All of these groups are completely open to any member of CiA.
CANopen
Page contents:
CAN in Automation
More:
Page contents:
Top Built on standards Application layer and communication profile Communication model Network initialization and management Data transfer mechanisms Service data objects Process data objects Events Synchronization Polling PDO mapping device profiles object dictionary object dictionary example CANopen development
CAN in Automation
Frequently asked questions

Please send your questions to headquarters@can-cia.de
CANopen
More:
coming soon
General introduction Technical introduction Specifications Conformance test Vendor list Vendor ID registration Presentation: CANopen
http://www.can-cia.de/hof.htm [14.11.1999 12:53:02]
CAN in Automation
Conformance test
Page contents: Introduction test procedure Test tool Certified companies FAQs & design hints members only Introduction The growing CANopen market is shared by more and more manufacturers of CANopen devices. All of them implemented a software covering communication services of higher protocol layers basing on the CANopen Communication Profile. To guarantee Conformance of the implementations to the CANopen Communication Profile as base for correct functionality and possible interoperability of CANopen devices CiA now offers a standardized test procedure. The certificate, that you will get after the passed test procedure, can also be used for marketing activities.
CANopen
More:
Technical Introduction Specifications Conformance test FAQs Vendor list Vendor ID registration Presentation: CANopen
Page contents:
Top Introduction Test procedure Test tool Certified companies FAQs & design hints members only
Test Procedure The CANopen devices are tested with respect to the CANopen Communication Profile CiA DS-301, Version 3.0, not to a special device profile. The Test Description for CANopen Devices Revision 1.1 includes a static test where timing requirements are not taken into consideration. For every test a test report will be generated listing all steps of the test and all errors that have occured during the test. In a first step the EDS (Electronic Data Sheet) of the CANopen device is tested. By means of a EDS a CANopen device can be described with respect to the contents of its object dictionary. The following requirements shall be fulfilled by the contents of the EDS: Correct value ranges, support of mandatory entries, references pointing to existing entries and consistency of the EDS. In a second step the physical CANopen device is tested. This part includes the test of the Communication Protocol, the test of the EDS against the object dictionary and the verification of
http://www.can-cia.de/hoc.htm (1 von 3) [14.11.1999 12:53:13]
More:
CAN in Automation
network states and transitions. Test procedure at CiA CAN in Automation offers the service of an official test laboratory where CANopen devices can be certified. Please contact CiA headquarters for arranging a date for the test. Within one session many devices can be tested. For a second test of a device, which failed in the first session no new basic rate has to be paid. The CANopen device has to be equipped with 9-pole Sub-D, connector inclusive wiring for the power supply and a power supply. The certificate describes the hardware of the device (CAN controller, microcontroller) and the versions of the CANopen implementation and the EDS file. One certificate can be given for a number of devices. The certified devices will be presented on our Internet Websites. Basic Rate per Test Session Rate per hour Certificate * Prices don't include German VAT.
Please contact CiA headquarters for arranging a date.
Page contents:
More:
non-members members 260.- EURO 130.- EURO 80.- EURO 100.- EURO 50.- EURO
Page contents:
Test Tool The CANopen Conformance Test Suite, which is also used for CANopen certification at CiA headquarters is now available for every Vendor and buyer of CANopen devices. So everybody can check conformance to the standards and prepare the devices to pass the certification process. The Conformance Test (CT) Suite, which was implemented by National Instruments consists of a PC software and a CAN interface card. The following kits are available: Software Kit 1**: CT Software Kit 2**: CT Software Hardware AT-CAN one port board (driver for W95 only) Price 1.325.- EURO* 1.530.- EURO*
CAN in Automation
Kit 3**: CT Software Kit 4**: CT Software
PCI-CAN one port board 1.685.- EURO* (drivers for W95 and Win-NT) PCMCIA-CAN one port board 1.735.- EURO* (drivers for W95 and Win-NT)
More:
* Prices don't include German VAT. ** Kits for Compact PCI/PXI and CAN two port boards are available on request. The Conformance Test Suite Updates with Bug Fixes are available free of charge from the National Instruments server. The updates can be found at the N.I. ftp-server as exe-files for downloading. Please note that only Bug Fixes are free of charge, a version update with increased functionality is not free of charge. Contact Address for Test Suite Orders: 1. National Instruments Germany GmbH Konrad-Celtis-Str. 79 D-81369 Mnchen phone: +49-89-7413130 fax: +49-7146035 Email: ni.germany@natinst.com 2. CAN in Automation (CiA) e.V. International Headquarters Am Weichselgarten 26 D-91058 Erlangen phone: +49-9131-690 86-0 fax: +49-9131-690 86-79 Email: headquarters@can-cia.de
Page contents:
CAN in Automation
Vendor list
CANopen
More:
General introduction Technical introduction Specifications Conformance test FAQs Vendor ID registration Presentation: CANopen
members can download this list as a comma seperated text file (.csv)
Company Antal Electronic Applicom International Arteco SpA Ascom Autelca AG bebro electronic GmbH Beckhoff Automation GmbH Brand Innovators BV CiA CMZ Comap s.r.o. Computechnic AG Danfoss Fluid Power A/S Datamicro Co. LTD Elrest GmbH EMS Dr. Thomas Wnsche Epec Oy Epis-Microcomputer ERL GmbH esd electronic system design gmbh ESR Dipl.-Ing. Pollmeier GmbH Festo AG & Co. F-Tron Elektronik GmbH G.A.S. Gesellschaft fr Antriebs- und Steuerungstechnik mbH Graf-Syteco Gustav Wurm GmbH & Co. OV-M MH-TME
Department
Vendor-ID 0000001A 00000020 00000006 00000025 00000027 00000002 00000038
Headquarters
00000001 0000000A 0000002F 00000037 00000019 00000026 00000032 0000002B 00000030 0000001C 00000029 00000017 0000000F 0000001D 00000011 00000010 0000002D 0000000B
http://www.can-cia.de/hov.htm (1 von 3) [14.11.1999 12:53:23]
CAN in Automation
Hengstler GmbH HMS Indutron Industrieelektronik IMT GmbH Isel-Automation Ixxat Automation GmbH / STZP Janz Computer AG KEB Antriebstechnik Klaschka GmbH & Co. Kbler GmbH Lawicel HB Lust Antriebstechnik GmbH McLennan Servo Supplies Ltd. MEN Mikro Elektronik GmbH MicroControl GmbH & Co. KG Micro-key bv MOOG Novotron GmbH Port GmbH ProControl AG Robert Bosch GmbH Sevcon Ltd. SIG Positec Automation GmbH SMH Automation Softing GmbH Techno-Matic ApS Technoteam GmbH Tetra Pak R&D TU Bergakademie Freiberg Vector Informatik GmbH WAGO Kontakttechnik GmbH Weidmller ConneXt GmbH & Co. Electronicc Verkehrstechnik Automation Institut fr Automatisierungstechnik Technologie + Integration (TI) Power and Motion Control Automationstechnik Germany
00000008 0000001B 00000035 00000031 00000004 00000007 00000014 0000002A 00000013 00000033 00000016 00000012 004D454E 0000000E 00000022 00000028 0000001F 00000034 0000000C 00000024 0000001E 0000002E 00000009 0000000D 00000023 00000018 0000002C 00000015 00000005 00000021 00000003
More:
General introduction Technical introduction Specifications Conformance test FAQs Vendor ID registration Presentation: CANopen
CAN in Automation
Zrcher Hochschule Winterthur (ZHW)
Institut fr Mechatronische Systeme (IMS)
00000036
CAN in Automation
News
CAN Newsletter
Hardware + Software + Tools + Engineering published by pz marketing Simon-Schoeffel-Str. 21 D-90427 Nuernberg Fax +49-911-3067283 Email: hz@can-cia.de
This unique magazine updating its readers with technology, product and other information related to Controller Area Network is published quarterly (March, June, September, and December).
More:
Hot News CiA News Press Release Standardization
Page contents:
top VHDL model Management Frameworks Interfacing the 82527 other topics
View into September 1999 issue View into June 1999 issue View into March 1999 issue Preview to the December issue: Synthesizable VHDL model for CAN Protocol The synthesizable VHDL model has been developed at the Institute for Computer Aided Circuit Design, University of Erlangen-Nuremberg. The function of this implementation is to interface CPUs with the serial 2-wire CAN bus with regard to the CAN protocol specified in ISO 11898-1 (11-bit and 29-bit frames). Special attention has been given to the configuration of the device by parameters, an important factor for its reusability. One of the major values of a reusable component is the ease of reuse in different design environments. The more flexible it is the more often it is possible to use it. For this it is important to be able to tailor the architecture and the interfaces to the specific needs of a design. In our approach this is done by carefully analyzing the possible requirements of a component and using a supermodel concept implementing all reasonable and necessary functionality. An important feature is the possibility to configure a component during operation. For this case it is necessary to implement additional control registers which can be modified and influence the components functionality.
More:
http://www.can-cia.de/NN.htm (1 von 3) [14.11.1999 12:56:37]
CAN in Automation
Mapping of CAN Devices to WWW based Management Frameworks The mapping of the management functions of a CAN device requires an appropriate description of the communication objects and of the functionality the module provides. These descriptions can be derived from communication and device profiles (standardized communication objects), and from the device documentation (vendor-specific objects and functions). Both types of information are used to design the user interface that will be embedded into hypertext pages. The CANopen application layer protocol and CANopen Device Profiles define the communication objects implemented in the networked modules. These objects have been mapped to variables in scripts. The scripts are used as control instances for ActiveX-objects that the management functionality of the modules is mapped to. The interconnection to the CAN network is performed by an OLE Automation driver for CAN. The scripts pass data from this driver object to the controls in a web page. In addition, DCOM-enabled software components have been implemented for a mapping of the management functions. These DCOM components can be embedded into or accessed from hypertext documents. They perform a transparent data exchange with a DCOM server across the LAN. The DCOM server is implemented in the gateway. The problem of re-using description information in different context (e.g. definition, management, visualization, application development) was addressed by creating XML descriptions for fieldbus components. Based on an appropriate Document Type Definition (DTD), an XML description of a CANopen Device Profile was created. This description holds all information necessary to generate the associated document in HTML format (Fig. 6). An XSL style sheet with formatting and filtering instructions supports the generation of the document. This style sheet has to be developed once, and it can be re-used for other profile descriptions. In addition, more generalized DTD and style-sheet allow an easy porting of the device profile to other fieldbusses. The XML Document Object Model (DOM) allows access to XML files from a Script or a high-level programming language. So, based on the same XML file, specific style sheets and scripts can be used to create input files for other management tasks. For example, a Script can create the CANopen-specific Electronic Data Sheet (EDS), or Device Configuration File (DCF) files.
Page contents:
More:
Page contents:
CAN in Automation
Interfacing the 82527 to 68HC11 The CAN controller from Intel provides six modes to interface a microcontroller. For the 68HC11 microcontroller from Motorola, an 8-bit non-Intel multiplexed interface (mode 2) should be used. The 82527 matches the AS, R/W#, E and AD7 to AD0 signals with microcontroller pin-for-pin (see fig. 1). The INT# pin of the CAN chip is tied to the 68HC11 IRQ# pin, and the Reset# pin is tied to a microcontroller pin or reset circuit (RC network). The Reset# pin must be asserted to V_Il or less for a minimum of 1 ms after V_CC in the operation range in order to guarantee a proper device reset. The CS# signal may be generated by a PAL decoding the upper address bits from the microcontroller. The signal must be generated 131 ns after a valid address is given on the bus, when the baudrate is 1 Mbit/s. The 82527 requires the CS# signal to be valid 20 ns before AS goes low. The microcontroller sends a valid address 151 ns prior to AS falling. Other Topics + Business News + Semiconductor News + Device News + Software News + Tool News Annual subscription prices: 16 EUR for Europe 26 EUR for Overseas Advertising rates
More:
Page contents:
CAN in Automation
Hot News
Page contents: CANopen Recommendations iCC in Torino ODVA in Korea Distributor as ODVA Members CAN Chip Sales Figures Reviewed CAN Specification Safety Communication for CANopen CAN in the German Army CANopen Recommendations Erlangen, October 1999. CAN in Automation (CiA) has published the CANopen Draft Recommendation (DR) for Cabling and Connector Pin Assignment (CiA DR-303-1) as well as for SI Unit and Prefix Representation (CiA DR-303-2). The CiA DR-303-1 gives some general guidelines and rules of thumb regarding the cabling of CANopen networks. In addition, a number of pin assignments for different connectors is specified. In the CiA DR-303-2 there is a coding of dimensions (SI unit and prefix) defined that should be used by the CANopen device profiles. With the standardized coding of dimensions even simple human machine interface devices can easily display the actual dimension of an application object. More information iCC in Torino Erlangen, September 1999. CAN in Automation has started the registration for the international CAN Conference (iCC) in Torino (2nd to 4th November). The early birds rate is valid by October, 15th. You also may now register for the workshops (English language) and seminars (Italian language). More information ODVA in Korea Erlangen, September 1999. In July, a Korean ODVA meeting was held in Seoul. More than 25 companies participated in the creation and development of DeviceNet in Korea, including representatives from Samsung, Rockwell, Turck, Pepperl+Fuchs, Festo, Eurotherm
http://www.can-cia.de/N.htm (1 von 3) [14.11.1999 12:56:53]
News
More:
CiA News Press Release Newsletter Standardization
Page contents:
Recommendations iCC in Torino ODVA in Korea Distributor Sales Figures CAN Review Safety on CANopen CAN in the German Army
More:
CiA News Press Release Newsletter Standardization
CAN in Automation
and Danfoss. ODVA Korea will act as the marketing and training arm for all DeviceNet-related activities. The Korea Instrumentation and Controls Association (KICA) supported by the Korean government is promoting DeviceNet training. More information Distributor as ODVA Member Erlangen, September 1999. ODVA is inviting distributors to join the DeviceNet association. A new ODVA member category for distributors was created. "This is a logical and high-value progression ODVA," said Executive Director Bill Moss. "Distributor members provide unparalleled insight into the needs of the end user and will be an invaluable partner in our effort to promote the adoption of DeviceNet." The standard distributor membership is $500 per year. The initial membership drive is limited to North American distributors. More information CAN Chip Sales Figures Erlangen, August 1999. CAN in Automation (CiA) has accumulated the CAN chip sales figures from most of the CAN controller manufacturers. The total number of sold CAN nodes in 1998 is about 97 millions. About 7 millions were stand-alone controllers. According to the market survey there were sold 31.8 millions 8-bit microcontrollers with integrated CAN modules. About 58.3 million CAN nodes implement 16-bit microcontrollers with on-chip CAN. More information Reviewed CAN Specification Frankfurt, July 1999. The reviewed CAN Standard has been handed over to the responsible ISO Working Group (TC22 SC3 WG1). The ISO 11898 document has been divided in two parts: part 1 deals with the CAN data link layer protocol and the medium access control specification, and part 2 describes the CAN high-speed physical layer. In addition to some clarification, the CAN protocol was enhanced by some optional features such as time-triggered communication and silent mode. First silicon implementing all the new options will be available by end of this year.
Page contents:
Recommendations iCC in Torino ODVA in Korea Distributor Sales Figures CAN Review Safety on CANopen CAN in the German Army
CAN in Automation
More information Safety Communication for CANopen Erlangen, July 1999. The CANopen Special Interest Group (SIG) Safety has released a first version of the Communication Profile for Safety Relevant Data Communication as CiA Work Draft 304. This document is available for CiA internal discussions only and will be passed to the German authorities for approval in Fall 1999. After approval it will be published as CiA DSP-304. More information CAN in the German Army Trier, June 1999. The German armed forces have established a group discussing the use of CAN in vehicles. In the meetings several vehicle manufacturers and suppliers are participating. In parallel, an European working group of the armed forces discusses the use of CAN. Particularly the standardization of higher-layer protocols will be discussed: mainly CANopen versus J1939.
CAN in Automation
CiA News
Page contents: ASAM on CANopen CANopen in Off-road Vehicles CiA Study Group Avionics CANopen Communication Profile for Safety Communication CANopen Recommendations for Cabling and Connector Pin Assignment CANopen Recommendations for SI Units and Prefixes CANopen Device Profile for Generic I/O Modules CANopen Device Profile for Door Control CANopen Application Profile for Integrated Operating Theater CANopen Framework for Maritime Applications ASAM on CANopen Erlangen, 1999-09-09. ASAM e.V. and CiA e.V. will establish the joint working group "ASAM on CANopen. ASAM specifications are widely used in testing automobiles. In order to interconnect ASAM-compliant sub-systems via CANopen, there is a need for specific CANopen interface profiles to map ASAM objects into the CANopen object dictionary. The joint working group should specify the requirements on such an interface profile. CANopen and ASAM experts will write the interface profile, which will be given for review to the joint working group. The inaugural meeting of this joint WG is scheduled on October, 14th in Wolfsburg at Volkswagen facilities. Please mail your registration to headquarters@can-cia.de CANopen in Off-road Vehicles Erlangen, 1999-09-09. CANopen networks are increasingly used in off-road vehicles. In order to develop and review CANopen devices profiles for these application fields (road construction machines, agriculture and forestry machines, truck-based cranes and aircraft washing robots, etc.), CiA is calling for an inaugural meeting of the CANopen SIG "Off-road Vehicles. Some of the already developed device profiles such as for proportional hydraulic valves can be used also for off-road vehicles. Other profiles pre-developed by the University of Magdeburg only have to be reviewed, and others may be developed from the scratch. The inaugural meeting will be on the 27th of October at the University of Magdeburg.
http://www.can-cia.de/NC.htm (1 von 5) [14.11.1999 12:57:23]
News
More:
Hot News Press Release Newsletter Standardization
Page contents:
top ASAM on CANopen Off-road Vehicles Avionics Safety Communication Cabling and Connectors SI Units and Prefixes I/O Modules Door Control Medical Maritime
CAN in Automation
Please mail your registration to headquarters@can-cia.de CiA Study Group Avionics Erlangen, 1999-07-12. CiA has called for an avionics study group. In the first meeting nine companies participated and discussed the state of aerospace projects using CAN technology. There are three different application fields addressed: Flight-critical control systems, auxiliary systems (e.g. air-condition), and flight-simulators. The next meeting is scheduled on November, 3rd in Torino. Topics will be specific requirements for CAN physical layer as well as discussion on higher-layer protocols, in particular, CANaerospace and CANopen. Interested parties in the CiA Study group Avionics can contact CiA Headquarters (headquarters@can-cia.de). CANopen Communication Profile for Safety Communication Erlangen, 1999-07-10. The CANopen Communication Profile for Safety-Relevant Data Transmission (CiA WD-304) is intended to be an add-on to the CANopen Application Layer and Communication Profile (CiA DS-301), which is already submitted for European standardization. The CiA WD-304 document describes only the data transport mechanism on CANopen network that allows the exchange of safety-relevant data. Due to CANopen compatibility, communication is limited to 64 safe communication objects, so up to 64 producers of safety-relevant objects can operate in a single CANopen network. The number of consumers of safety-relevant objects is not defined (at least one receiver is necessary). The additional safety-relevant communication shall not affect the normal operation and services on a CANopen network. Safety-relevant communication is not related to a special class of devices, so that no special device profile has to be used. To ensure compatibility, the usage of identifiers and predefined objects has to be coordinated with the CANopen standard and existing device profiles. As there is no use of data bits in the safe communication method, it is compatible with already published device profiles. In a CANopen network the data interface to the application program within a certain node is only via the CANopen object table. So the application itself has no access to the data sequence and the time behavior of the CAN bus. The safety tests due to timing conformance has to be done in the safety CAN interface.
More:
Page contents:
More:
CAN in Automation
SRDOs (safety relevant data objects) shall distribute safety-relevant data. A standard PDO or SDO is not sufficient for hard safety requirements. So with the SRDOs different measures (e.g. redundancy, cyclic transmission etc.) are taken to ensure safety. An identifier range not currently in use for CANopen has been used for the SRDO transmissions. An SRDO consists of two CAN data frames with different identifiers. The user data in both transmissions is redundant, i.e. the meaning of the data is the same, but the data on the 2nd transmission is inverted bit by bit. SRDOs must be transmitted periodically. If required, SRDOs can also be transmitted event driven, e.g. to ensure fast reaction after a safety critical change on the input. RTR must not be used for SRDOs; SRDO communication is only allowed in the network-state "operational". SRDOs are only valid, if both CAN frames are received properly (without failure and in time). The redundant transmission is sent after the first transmission to the CAN controller with minimum delay. More information (members-only section) CANopen Recommendations for Cabling and Connector Pin Assignment Erlangen, 1999-07-10. The CiA DRP-303-1 document specifies naming conventions as well as AC and DC parameters for CANopen networks. The major part of this recommendation deals with the pin assignments for general-purpose, industrial, and special-purpose connectors. This document is under final revision and will be published in Fall 1999. CiA Members may send comments by July, 20th. More information (members-only section) CANopen Recommendations for SI Units and Prefixes Erlangen, 1999-07-10. The CiA DRP-303-2 document specifies the representation of SI units and prefixes to be used in CANopen device, interface, and application profiles. This recommendation is already used in the CANopen device profile for proportional valves (CiA WD-408). The recommendation is under final revision and will be published in Fall 1999. CiA Members are asked to send comments by July, 20th. More information (members-only section) CANopen Device Profile for Generic I/O Modules
Page contents:
More:
Page contents:
CAN in Automation
Erlangen, 1999-07-10. The already published CANopen device profile (CiA DSP-401 Version 1.4) is under review. The new version will be mainly compatible to the predecessor, however, some minor objects have been changed. The reviewed document will be in accordance to the CiA DS-301 Version 4.0 CANopen specification. The proposed changes are documented in the CiA WDP-401. CiA Members may send commends by August, 1st. This reviewed device profile will be published as CiA DS-401 Version 2.0, and will be the base for interoperability tests for CANopen I/O modules. More information (members-only section) CANopen Device Profile for Door Control Erlangen, 1999-07-10. The Task Force Door Control of the CANopen Special Interest Group (SIG) Railways has released for CiA internal discussion the CANopen Profile Door Control (CiA WD-409). The device profile is based on UIC specifications by means of using the same data types as TCN. This device profile will be part of the CANopen application profile for railways. CANopen is already implemented in the British cargo-sprinter manufactured by Windhoff. The next generation of the German cargo-sprinter will also make use of CANopen networks. Other CANopen applications in railways are under development, e. g. in some Czech, Italian, and Swiss railways. Interested parties in the CANopen profiles for railways can contact CiA Headquarters (headquarters@can-cia.de). More information (members-only section) CANopen Application Profile for Integrated Operating Theater Erlangen, 1999-07-10. The CANopen Special Interest Group (SIG) Medical is going to specify an application profile for integrated operating theaters. This specification will define hot-swapping functionality and automatic configuration capability in order to ensure that the medical have not to deal with network or device configuration. This profile was pre-developed by Siemens and will be reviewed by the SIG Medical. Interested parties in the CANopen device and application profile for medical equipment can contact CiA Headquarters (headquarters@can-cia.de). CANopen Framework for Maritime Applications Erlangen, 1999-07-10. The CANopen Special Interest Group
More:
Page contents:
CAN in Automation
(SIG) Maritime Electronics has been established to define a framework, which meets the requirements of the related authorities. Kongsberg Norcontrol already uses CANopen, and other CiA Members such as MTU like to implement CANopen bridges and interface to reduce system integration efforts. Interested parties in the CANopen framework for maritime electronics can contact CiA Headquarters (headquarters@can-cia.de).
CAN in Automation
Overview
Literature just released CiA Compact Disc All published CiA Specifications are available on CD including all CANopen profiles. 6th iCC Proceedings The proceedings of the 6th international CAN Conference includes all 36 presentations. CANopen Recommendations The CANopen Draft Recommendations (CiA DR-303) for cabeling and connector pin assignments as well as representation of SI units and prefixes. More literature CAN Bibliography: Overview on books, magazines, proceedings, etc. Literature order form: Literature provided by CiA Headquarters CiA Standards: List of all published CiA specifications
Literature
More:
Literature order form Downloads CAN Newsletter
http://www.can-cia.de/L.htm [14.11.1999 12:58:56]
CAN in Automation
CiA Standards
CAN in Automation offers different Standards, which can be ordered.
More:
CAN Standards CANopen Standards CAL Standards Related Standards Literature Order Form
q q q q
Standards for CAN Standards for CAN Application Layer Standards for CANopen Other related CAN Standards
http://www.can-cia.de/ls.htm [14.11.1999 12:59:12]
CAN in Automation
iCC Programme 6th international CAN Conference '99

2nd - 4th November Turin (Italy), Lingotto Conference Center
Events
General information Conference programme Workshop and seminar programme Programme committee Registration information Conference registration form Workshop and seminar registration form Table-top exhibition General information Sponsored by NEC Electronics Hitachi Europe Infineon Technologies Jackson Group (Automazione Oggi, Elettronica Oggi and Fieldbus and Networks) Mitsubishi Motorola Organized by CAN in Automation e. V. iCC`99 programme Conference registration form
Tuesday, 1999-11-2 9.00 - 10.30 Session I: Transceiver Chairman: Viktor Schiffer (Rockwell Automation) Heinrich Gschll (Infineon Technologies): A Comparison of the different CAN Physical Layers and their CAN-Transceiver Solutions
http://www.can-cia.de/EiCC.htm (1 von 6) [14.11.1999 12:59:38]
CAN in Automation
Richard J. Baird (Delphi Automotive Systems), Christopher A. Lupini (Delphi Automotive Systems). Single Wire CAN Physical Layer Mohammad A. Livani (University Ulm): A Transparent Approach to Fault-tolerant Broadcast in CAN 11.00 - 12.30 Session II: Physical Layer Chairman: Robert Hugel (Robert Bosch GmbH) Prof. Dr. H. Beikirch (University Rostock): CAN Physical Layer for Special Applications Dr. Lutz Rauchhaupt (Ifak e.V. Magdeburg): Wireless CAN Extensions Bob Lounsbury (Rockwell Automation): Designing an Industrial Network with unshielded Cable and IDC Connectors 9.00 - 10.30 Session III: Application Modeling Chairman: Alfred Krappel (Hitachi Europe GmbH) Daniel Berglund (Kvaser AB): Using UML for Modeling CAN Systems Dr. Martin Wollschlger (Otto v. Guericke Univ. Magdeburg): CANopen Device Descriptions Using General Purpose Modeling Languages Dr. Hayon A. Thompson (Rolls-Royce University): A CAN-Bus-Based Safety-Critical Distributed Aero-Engine Control Systems Architecture Demonstrator 11.00 - 12.30 Session IV: System Modeling Chairman: Prof. Dr. Gerhard Gruhler (STA Reutlingen) Markus Weseloh, Prof. Roland Rdiger (FH BS/WF): Applying Modern Software Design Principles: A CAN Tool based on Extensibility Wolfgang Wiewesiek, Volker Nieten (NEC Electronics Germany): Micro-Controller Simulator with CAN Functionality Sofiane Ouni, Farouk Kamoun (ENSI): Efficient Protocol for Hard Real Time Communication on Control Area Network (CAN) Wednesday, 1999-11-3 9.00 - 10.30 Session V: Timing Chairman: Lars-Berno Fredriksson (Kvaser) Jose Alberto Fonseca, Pedro Fonseca (University of Aveiro): Scheduling and Synchronisation in CAN based Distibuted Systems Gianluca Cena, Adriano Valenzano (Cens-CNR Politecnico Torino): Enhancing the Efficiency of Controller Area Networks Florian Hartwich, Armin Bassemir (Robert Bosch GmbH). The Configuration of the CAN Bit Timing 11.00 - 12.30 Session VI: Gateway Technology Chairman: Lars-Berno Fredriksson (Kvaser) Gerd Nusser (FH Reutlingen), Prof. Dr. G. Gruhler (STA Reutlingen): Teleservice of CAN Systems Via Internet Donal Heffernan, Paul Conway (PEI Technologies): CAN and the new IEEE 1451 Standard Transducer Interface Kim Hiong Ang (University of Warwick), Bennet Levine (Contemporary Control System): Device Net over TCP / IP Gateway 9.00 - 10.30 Session VII: Industrial Application Chairman: Joanne Dunn (Motorola) Paolo Ursino (Automata S.p.A.), Christoph Melzer (Automata GmbH): Injection Moulding Machines: A Distributed Control Approach
CAN in Automation
Francesco Riti (Eurosicma), Ferdinando Pozzi (Oasys srl): CAN in packaging and plaster machines Eric Mdan (NSi.): CAN Bus to 6000m down in Oil Prospecting 11.00 - 12.30 Session VIII: Transport Application Chairman: Andrea Borin (Magneti Marelli S.p.A.) Ulrich Dreher, Hans-Joachim Aupperle (Smart Electronic Development GmbH): CAN Applications in Vehicles William B. Vlcek (Ascent Technologies Inc.), Steven N. Ernest (Jacobs Vehicle Systems): Implementing the CAN Calibration Protocol (CCP) in an SAE J1939 Application Stefano Vitturi (PST Galileo): Implementation of a CANopen Interface for the Remote Control of an Elevator System Thursday, 1999-11-4 9.00 - 11.30 Session IX: Implementation Chairman: Klaus Turski (NEC Electronics Germany) Alfred Krappel, Naoyuki Hirayama (Hitachi Europe GmbH): Automotive Microcontrollers with On-Chip CAN Avi Ginsberg (Motorola Israel): Flex-CAN Communication Module for Embedded Microcontrollers Peter Hank (Philips Semiconductors): New Generation of CAN Controller Supporting Higher Layer Protocols 11.00 - 12.30 Session X: Bridge Technology Chairman: Viktor Schiffer (Rockwell Automation) Adriano Tamagnone (Six Tau S.p.A.): DSS - Distributed Diagnostic Systems Mahmut Tenruh (University of Sussex): Design and Implementation of a CAN / CAN Cut-through Bridge Florian Bogenberger (Motorola GmbH), Ulf Warschat (Audi AG): High Level Performance Analysis of a quadruple CAN Gateway 9.00 - 10.30 Session XI: Physical Layer Testing Chairman: Robert Hugel (Robert Bosch GmbH) Kiah Hion Tang, Richard McLaughlin (Warwick Manufacturing Group): DeviceNet Physical Layer Design and Conformance Testin Jiri Pinker, Jiri Skala ( University of West Bohemia): Monitoring CAN Performance in Installations with High Level of Interference Dr. Marcus Rimen, Dr. Jrgen Christmansson (CR & T AB): CAN Fault Injection 11.00 - 12.30 Session XII: Design Tools Chairman: Wouter Linneman (Infineon Technologies) Norya Lavorel (NSI): Conformity Certification Tools and Methods in a Multiplexed Architecture Alexander Semjonov ( Motorola Research Lab.): The Development of the Embedded Network Software based upon the Layer Model by Means of Static Configuration Tool Alberto Bonastre, Rafael Ors (University of Valencia): A CAN application layer protocol for the implementation of distributed expert systems
iCC workshops (English language) and iCC seminars (Italian
CAN in Automation
language) Workshop and seminar registration form Tuesday, 1999-11-2 Time 14.00-16.00 16.00-18.00 Workshop 1 + 1a CANopen (CiA) Seminars (Italian language) CAN (V-Systems) 1 DeviceNet (Rockwell) 2
Wednesday, 1999-11-3 Time 14.00-16.00 16.00-18.00 CAN Kingdom (Kvaser) Workshop 2 Seminars (Italian language) CANopen (V-Systems) 3 I livelli Applicativi CAL, DeviceNet and SDS per il Protocollo CAN (Prof. S. Cavalieri, Univ. di Catania) 4
Thursday, 1999-11-4 Time 14.00-18.00 Workshop 3 Measurement and calibration of ECUs (Vector) Workshop 4 DeviceNet (Rockwell)
Programme committee
Andrea Borin (Magneti Marelli) Lars-Berno Fredriksson (Kvaser) Prof. Dr. Gerhard Gruhler (STA Reutlingen) Robert Hugel (Robert Bosch) Prof. Dr. Wolfhard Lawrenz (FH Braunschweig/Wolfenbttel) Viktor Schiffer (Rockwell Automation) Klaus Turski (NEC) Tobias Wenzel (Infineon Technologies) Holger Zeltwanger (CAN in Automation)
Registration information
Registration fee Includes a copy of the CAN Conference proceedings respectively the workshop or seminar hand-outs. Registrations for the workshops or seminars are not valid for the CAN Conference nor vice versa!
CAN in Automation
Remark: Co-speakers are not registered automatically! The Table-top exhibition, poster presentations, and product presentations, however, may be visited by everybody free of charge. Confirmation Will be sent only to early registered attendees (upto 15th October 1999). Cancellations Received by 15th October will be refunded after the Conference less a 50 Euro handling fee. For cancellations after 15th October 1999 no refunds will be made. Conference registration starts on Tuesday 2nd November at 7.30 a. m. at the registration desk. You are strictly recommended to register early and to please use the advance registration form. Conference language Conference and Workshops are held in English language. The seminars are held in Italian language. Hotel accommodation Participants will book their hotel rooms directly. A hotel list will be given with the confirmation.
Please return your registration form(s) to: CAN in Automation (CiA) e. V. Am Weichselgarten 26 D-91058 Erlangen (Germany) Fax +49-9131-69086-79 E-mail: headquarters@can-cia.de Table-Top Exhibition After several years, in which we had the accompanying exhibitions not under the cover of CiA, which caused different problems, we finally are organizing the usual table-top exhibition again. The conditions and benefits for table-top exhibitors have been changed a little and are most interesting for you all! Beside the sponsoring companies the following companies have ordered one or two (or even four!) tables to present themselves and their products and services: Applicom (1), Arteco (1), Automata (1), Beckhoff (1), Dearborn (1), EMS Dr. Thomas Wuensche (1), esd (2), Fujitsu (1), i+ME Actia (1), Ixxat Automation (2), Janz Computer (2), Kvaser (1), Lumberg (1), MEN (1), Microtask (1), NSI (1), port (1), Rockwell Automation (4), Softing (3), Special Electronic Design (1), Toshiba (1), Warwick Manufacturing Group (1),
CAN in Automation
Weidmller (2). Product Presentations The following companies will give one or more presentations on their products and services. Each presentation will take 15 minutes. The product presentations will start at 2 p. m. each day in room Lisboa and are also free of charge for everyone. Applicom, Arteco, Automata, Beckhoff, Dearborn, EMS, esd, Fujitsu, Hitachi, i+ME Actia, Infineon, Janz, Kvaser, Lumberg, Microtask, Mitsubishi, Motorola, NEC, NSI, port, Rockwell, Softing, Toshiba, Weidmller. Poster Presentations The third opportunity to get the newest information on CAN products are the poster presentations. Beside the sponsors and table-top exhibitors Milan Vukoje of Vickers, Casella (Italy) and Herbert Braisz of University of Erlangen (Germany) will give a poster presentation.
CAN in Automation
CAN bibliography
Page contents: Books Magazines iCC Proceedings Articles and application notes Books Konrad Etschberger: CAN - Controller Area Network. Hanser-Verlag, Mnchen 1996. 400 pages. ISBN. The first part of the book introduces the CAN data link layer and the CAN high-speed physical layer. The second part describes the CAN Application Layer (CAL). All CMS, DBT, NMT, and LMT services and protocols are discussed. In the third part, there is given a CAL application including program examples. (The book is not more available, the new edition will be published by end of 1999) Wolfhard Lawrenz: CAN - Grundlagen und Praxis. 3rd Edition. 457 pages. Huethig-Verlag, Heidelberg 1999. ISBN 3-7785-2734-7. The book describes the CAN data link layer and physical layer options in detail including implementations. In addition, there are some chapters introducing higher-layer protocols, but do not discuss them in depth. Other chapters describes some applications and products. The last chapter explains development and test strategies. Wolfhard Lawrenz: CAN System Engineering - From Theory to Practical Applications. 468 pages. Springer-Verlag, New York, 1997. ISBN 0-387-94939-9. The book describes the CAN data link layer and physical layer options in detail. It is based on the 2nd Edition of the CAN-Book published in German language. Dominique Paret: Le bus CAN - De la thorie la pratique. 277 pages. Dunod, Paris 1995. ISBN 2-10003164-3 The book introduces into CAN data link layer and physical layer. It describes in detail the CAN protocol and some CAN controller. Higher-layer protocols and software tools are introduced briefly.
http://www.can-cia.de/LB.htm (1 von 2) [14.11.1999 13:00:06]
Literature
More:
Page contents:
Books Magazines iCC Proceedings Articles
More:
Page contents:
CAN in Automation
All available books can be ordered by CiA Magazines CAN Newsletter: Hardware + Software + Tools + Engineering Quarterly published magazine reporting market, product and technology news and articles on CAN technology. The magazine is published since June 1992. The CAN Newsletter can be subscribed via CiA iCC Proceedings The annual international CAN Conference is the most important event for the CAN community. 1st iCC Proceedings. CAN in Automation, Erlangen 1994. 2nd iCC Proceedings. CAN in Automation, Erlangen 1995. 3rd iCC Proceedings. CAN in Automation, Erlangen 1996. 4th iCC Proceedings. CAN in Automation, Erlangen 1997. 5th iCC Proceedings. CAN in Automation, Erlangen 1998. 6th iCC Proceedings. CAN in Automation, Erlangen 1999. Articles and application notes CAN controller and transceiver chip specific articles are available by the semiconductor providers. You can contact the related web pages via the product surveys on CAN controller and CAN high-speed transceivers Go to application notes from Infineon Go to application notes from Intel Go to application notes from National Semiconductors Go to application notes from Motorola (Software driver) or (Bit-timing) Go to application notes from Philips Seminconductors
More:
Page contents:
http://www.can-cia.de/LB.htm (2 von 2) [14.11.1999 13:00:06]
Error
The address you are searching for could not be found or is not available any more. Please check the URL you typed in.
Siemens Semiconductors is now Infineon Technologies. Check out our site at
www.infineon.com
http://www.infineon.com/redirection/error_404b.htm [14.11.1999 13:00:53]
Controller Area Network Application Notes
Controller Area Network Application Notes

AP-722 Interfacing an Intel 82527 Serial Communications Controller to a 68HC11 AP-723 Interfacing an Intel 82527 Serial Communications Controller to a 68332 AP-724, Interfacing an MCS(R) 51 Microcontroller to an 82527 CAN Controller Interfacing a 20 MHz 8xC196 to an 82527 Serial Communications Controller
Application Notes Datasheets Architecture Overview Specification Update
Development Tools Price Quote & Ordering Product Selector
Commercial Flash Memory Commercial Microcontrollers * Legal Information 1999 Intel Corporation
http://developer.intel.com/design/auto/can/applnots/INDEX.HTM [14.11.1999 13:02:32]
AN464
AN464: Software Driver Routines for the Motorola MC68HC05 CAN Module
The Controller Area Network (CAN) protocol describes a serial communications protocol for interrupt-driven, real-time control applications, primarily in the automotive sector. This note describes driver routines which provide an interface between application software in the MCU ROM and the CAN module. The routines allow for the initialisation of the module, the transmission of messages previously stored in RAM, and the automatic handling of received messages. They have been written to run on the MC68HC05X4 but can easily be adapted to run on any M68HC05 MCU supporting the CAN protocol.
Copyright 1994,1999 Motorola, Inc. All rights reserved. Please Read Our Copyright and Disclaimer Notice
Fri Jan 24 16:11:59 MST 1997
http://www.mot-sps.com/lit/html/an464.html [14.11.1999 13:05:58]
AN1798
AN1798: CAN Bit Timing Requirements

Controller Area Network (CAN) is a serial, asynchronous multi-master communication protocol for connecting electronic control modules in automotive and industrial applications. Paper examines the relationship and constraints between the bit timing parameters, the reference oscillator tolerance, and the various signla propagation delays in the system.
Copyright 1994,1999 Motorola, Inc. All rights reserved. Please Read Our Copyright and Disclaimer Notice
http://www.mot-sps.com/lit/html/an1798.html [14.11.1999 13:06:33]
Philips Semiconductors - CAN Bus; Support and tools;
Support & tools

CAN products & systems CAN news & events About CAN CAN support & tools Sales contacts Sales Contacts Application notes AN457, 80C51 External Memory Interfacing AN91014, Application of the P8xC592 microcontroller with CAN-interface AN92002, Extended Frame Format - A New Option of the CAN Protocol AN95092, How to Handle Data Overrun Conditions of the 82C200, 8xC592 and 8xCE598 AN96116, PCA82C250/PCA82C251 CAN Transceiver AN97046, Determination of Bit Timing Parameters for the CAN Controller SJA1000 AN97076, SJA1000 Stand-alone CAN controller Upgrading Note, 82C200 to SJA1000
Sales Contacts Industrial applications Automotive applications Application notes 80C51 External Memory Interfacing The 80C51 family is arguably the most popular 8-bit embedded controller line-up thanks to an efficient yet powerful architecture, multi-sourcing by the world's top semiconductor companies and unprecedented third-party tool support. This application note looks in detail at the external memory interfacing for 80C51 devices. Download the full application note. Application of the P8xC592 microcontroller with CAN-interface The P8xC592 covers the complete CAN specification, offering important features such as multi-master serial communication capability with a high number of participating network nodes, programmable data transmission rates up to 1 Mbits/s and powerful error handling. This application note provides a simple circuit example for a CAN module using the P8xC592. Flowcharts are included which familiarize the reader with the software aspects of CAN communication. A practical example shows that there is very little CPU load for the control of CAN communication. Download the full paper. Extended Frame Format - A New Option of the CAN Protocol In addition to the CAN 'standard frame format', which is specified with an 11-bit identifier, in 1991 Bosch introduced the CAN 'extended frame format', which operates with a 29-bit identifier. This paper contains a description and a comparison of both frame formats. Both have their own advantages: the extended frame format provides more message types and a much higher number of unique
http://www-eu2.semiconductors.com/can/support/ (1 von 3) [14.11.1999 13:08:06]
identifiers, while the standard frame format offers lower bus access times, higher bus throughput and greater commercial availability of products. Download the full paper. How to Handle Data Overrun Conditions of the 82C200, 8xC592 and 8xCE598 Data overrun conditions may occur in CAN bus systems, if received messages cannot be read fast enough from the receive buffer by a CPU. Normally the controller software for a CAN bus system should be designed so the receive buffer is serviced without resulting in an overrun condition. This application note gives a recommendation on how to handle those rare occasions when a data overrun does occur. Download the full application note. PCA82C250/251 CAN Transceiver The PCA82C250 and PCA82C251 are advanced transceivers for use in automotive and general industrial applications, offering transfer rates up to 1 Mbits/s. They support the differential bus signal representation described in the international standard for high-speed in-vehicle CAN applications (ISO 11898). This application note provides information on how to use the PCA82C250/251 transceivers and discusses several topics of interest such as slope control mode, stand-by mode, bus length and maximum number of bus nodes per network. Download the full application note. Determination of Bit Timing Parameters for the CAN Controller SJA1000 The CAN protocol provides for programming of the bit-rate, and the number and location of data samples in a bit period. Optimization of these parameters guarantees message synchronization and proper error detection at the extremes of oscillator tolerance and propagation delay. A step-by-step method for calculating optimum CAN bit timing parameters for a given set of system constraints is presented. Support is given for adjustment of Philips Semiconductors' SJA1000 and PCx82C200 CAN controllers. Detailed examples are also included. Download the full application note. SJA1000 Stand-alone CAN controller With the SJA1000, Philips Semiconductors provides a stand-alone CAN controller which is more than a simple replacement of the PCA82C200. This CAN 2.0B-compliant controller offers a number of additional features, implemented for a wide range of applications, supporting system optimization, diagnosis and maintenance. Download the full application note. Upgrading Note - 82C200 to SJA1000 The SJA1000 is the successor product for the PCx82C200 Stand-alone CAN Controller. It is pin-compatible to the 82C200 design. As the SJA1000 is a completely new design with a range of additional features including full CAN 2.0B, the following notes give a short overview of what hardware and software designers should consider when migrating from the 82C200 to the SJA1000 in existing designs. Download the full upgrading note.
Copyright 1999 Royal Philips Electronics All rights reserved. Terms and conditions.
CAN in Automation
Products
News
More:
Product Data Base CAN chip Transceiver chip CAN Newsletter DeviceNet Catalog
CAN Product Information

There is an enormous number of CAN products available. In general, CAN products can be classified in chip-level and device-level modules, software, and tools. CiA provides several services to find CAN products. CiA Members may entry their products and services in the CiA PRODUCT DATABASE. More specific product information regarding embedded networking is available in CiA's EMBEDDED CAN DIRECTORY, and CANopen products are advertised in the CANopen PRODUCT GUIDE. Both are available free of charge, and will be send on request (send email). CAN protocol controller chips are listed in the CAN DATA LINK LAYER SURVEY, and CAN transceiver chips are listed in the CAN HIGH-SPEED TRANSCEIVER SURVEY. Transport Layer in Silicon Hamburg (Germany), October 1999. At the 6th iCC in Torino (Italy), Philips Semiconductors will officially announce the XA-3C 16-bit microcontroller with CAN module and micro-coded transport layer for CANopen, DeviceNet, and OSEK/Com/NM. The hardware support of object segmentation and re-assembling will unburden the microcontroller from processing of interrupts. The CAN data link layer module provides the same features as the SJA1000 stand-alone controller. More information at iCC FlexCAN with up to 64 Message Buffers Tel Aviv (Israel), October 1999. At the 6th iCC in Torino (Italy), Motorola will present the FlexCAN implementation, which is based on the TouCAN implementation. FlexCAN provides up to 64 message buffers. This CAN module will be implemented on several microcontroller families from Motorola including PowerPC and Mcore. It is intended to offer also two CAN modules on one chip. More information at iCC
More:
http://www.can-cia.de/P.htm (1 von 4) [14.11.1999 13:08:20]
CAN in Automation
Stand-Alone CAN Controller re-designed Munich (Germany), September 1999. Infineon has redesigned its SAB80C90/91 family of stand-alone CAN controllers. All known failures and problems are solved. More information www.infineon.com/us/micro/can/content.html 8051-based Microcontroller featuring CAN San Jose (USA), September 1999. At the Embedded Systems Conference in San Jose (California) Philips Semiconductors has announced the P8xC591 microcontroller with an on-chip CAN module supporting Standard and Extended frame formats (2.0 B active). The CAN module is the very same as in the SJA 1000 stand-alone CAN controller. It provides PeliCAN (Philips Extended Library CAN) functionality, including listen-only mode and self-test mode, error interrupts and arbitration lost capture. Enhanced PeliCAN features include four independently configurable identifier filters (screeners) that each include a 32-bit match and a 32-bit mask. The four 32-bit masks will allow designers to specify a unique group address per screener. Other P8xC591 features include 16 Kbyte of internal program memory that is expandable externally to 64 Kbyte, three 16-bit timers/counters, and 32 digital I/O port pins. The microcontroller also features a 10-bit A/D converter with 6 multiplexed analog inputs and a fast 8-bit conversion option, a 16-bit capture/compare unit, an 8-bit Pulse Width Modulated (PWM) unit with two output channels as well as an UART and I2C interface. More information www-us.semiconductors.philips.com/can/products/ 8051-based Microcontroller with two CAN Modules San Jose (USA), September 1999. At the Embedded Systems Conference in San Jose (California) Dallas Semiconductors has launched the DS80C390 dual CAN microcontroller running at 40 MHz clock rates. The microcontroller can address up to 4 Mbyte of external data memory and up to 4 Mbyte of external program memory. It comes in 64-pin LQFP or 68-pin PLCC packaging. Currently in full production, the microcontroller with additional three timers/counters, serial port, and eight digital I/O ports is available at a cost of $ 7.40 in quantities of 25,000. The chip has on-chip 4 Kbyte SRAM.
More:
CAN in Automation
Both integrated CAN modules support data rates up to 1 Mbit/s. Each CAN module has 15 message buffers, 14 are programmable in either transmit or receive mode. The last one is a receive-only message buffer featuring capacity to store two CAN messages in order to prevent message loss. More information www.dallas.com Complete Transceiver Product Line Munich (Germany), September 1999. At the 6th iCC in Torino (Italy), Infineon will announce CAN high-speed transceivers compliant to ISO 11898 and several CAN fault-tolerant transceivers. In addition, a CAN single-wire transceiver will be released. More information at iCC Single-wire CAN Transceiver Sunnyvale (USA), September 1999. Philips Semiconductors and Infineon have developed Single-wire CAN transceiver chips. The AU5790 from Philips supports data rates up to 30 kbit/s. The transceiver provides sleep and wake-up functions along with a network active signal. In high-speed mode the transceiver supports the bus signal levels as specified for the CAN_H output of the fault-tolerant CAN transceiver TJA 1053 from Philips Semiconductors. More information www-us.semiconductors.philips.com/can/products/ CAN Controller with Group Message Function Duesseldorf (Germany), July 1999. The MSM9225 from OKI is stand-alone CAN controller, which is supporting 11-bit and 29-bit identifier frames. The chip comes in a 44-pin plastic QFP package and is specified for a temperature range of -40 to +115 C. Each of the 16 implemented message buffers can individually configured as transmit or receive buffer. If the group message function is used, a part of an identifier can be masked. This can increase the number of receivable identifiers. To use the group message function, set the message number of the target message to set the group message function at the GMR register. Then set the bits to be masked at the GMSK register. Depending on the location of
CAN in Automation
bits to be masked, another identifier being set at the message memory may be received. In this case, the priority of identifiers being set on the message is calculated and the identifier having the highest priority is received. The received data is written to the message memory indicated by the message for which the identifier with the highest priority is set. The CAN controller can support two message groups. MIPS3000-based Processor for Telematik Hamburg (Germany), July 1999. Philips Semiconductors has introduced the SAF3100 processor featuring MIPS3000-based 32-bit core, 12-channel GPS base-band module, UART modem, Dead Reckoning unit, and CAN module. In addition, the chip provides memory and real-time clock. Flash-based DSP with CAN Freising (Germany), June 1999. Texas Instruments has announced the availability of its TMS320F241 and TMS320F243 digital signal processors with on-chip CAN controller. Both DSPs are optimized for digital motor-control applications such as industrial drives and automotive. With the Flash-based versions (8 Kbyte), motor controller designers can program quickly o Flash memory then transfer that code to a more cost-effective ROM-based DSP for volume production. The DSPs operate at 20 million instructions per second (MIPS), and feature serial peripheral interface (SPI), A/D converter, and a CAN interface. The F241 comes in a 68-pin plastic leaded chip carrier (PLCC) or a 64-pin plastic quad flatpack (PQFP). The F243 is packaged in a 144-pin thin quad flatpack (TQFP). http://www.ti.com/sc/docs/products/dsp/tms320f241.htm Further product information
Welcome to CAN in Automation e.V.
Product Class
CAN Silicon
Product Categories
No HLP-Support with this class
CiA Database Usage Product Search: 1. First select the Product Class you like to search. Thereupon the appropriate Product-Category-Options and HLP-Support-Options appear (HLP=Higher Layer Protocol). 2. Select at least one Product-Category-Option or HLP-Support-Option. To choose several options use the SHIFT-Key. 3. Press the Search Database button and you will receive a list of products matching with your selection. 4. Leave the CiA Database by clicking the Exit button.
http://www.can-cia.de/pdb.htm [14.11.1999 13:08:26]
CAN Contoller
CAN Contoller Website (Data Sheet and Application Notes) Company CAN Microcontroller Version 2x 2.0B Object Storage Capacity 14 Tx/Rx buffers + 1 double Rx buffer Acceptance Filtering Bridge Samples Volume Capability 14 Tx/Rx buffers + 1 double Rx buffer Remarks 4kB SRAM, 256 x 16 RAM, 40 MHz clock rate, 16/32-bit math coprocessor 128KB Mask ROM, 4K RAM, UARTx2, A/D, Ext Bus Interface, QFP100. 256KB Mask ROM, 6K RAM, UARTx3, A/D, 4 Stepper Motor Drivers, QFP100. 128KB Mask ROM, 4K RAM, UARTx2, A/D, 4 Stepper Motor Drivers, QFP100. 64K Flash, 2K RAM, UART, A/D, QFP64. 128KB Flash, 6K RAM, UARTx2, A/D, Ext Bus Interface, QFP100. 128KB Flash, 4K RAM, UARTx2, A/D, Ext Bus Interface, QFP100. 256KB Flash, 6K RAM, UARTx2, A/D, Ext Bus Interface, QFP100. 384KB Flash 8K RAM, UARTx3, A/D, 4 Stepper Motor Drivers, QFP100. 256KB Flash 6K RAM, UARTx3, A/D, 4 Stepper Motor Drivers, QFP100. 128KB Flash, 4K RAM, UARTx2, A/D, 4 Stepper Motor Drivers, QFP100.
DS80C390
www.dalsemi.com
Dallas
8-bit
possible now
1Q00
MB90548
www.fujitsu-fme.com/index4.html?/products/micro/can/start.html
Fujitsu
1x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
16 full-bit masks + 2 global masks
No
1Q00
2Q00
MB90594
Fujitsu
2x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
n.a.
now
MB90598
Fujitsu
1x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
1Q00
1Q00
MB90F497
Fujitsu
1x 2.0B
16-bit (FFMC16LX)
8 Tx/Rx buffers
No
4Q99
1Q00
MB90F543
Fujitsu
2x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
n.a.
now
MB90F548
Fujitsu
1x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
1Q00
2Q00
MB90F549
Fujitsu
1x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
4Q99
1Q00
MB90F591
Fujitsu
2x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
now
now
MB90F594A
Fujitsu
2x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
n.a.
now
MB90F598
Fujitsu
1x 2.0B
16-bit (FFMC16LX)
16 Tx / Rx buffers
No
n.a.
now
http://www.can-cia.de/pc.htm (1 von 6) [14.11.1999 13:08:48]
CAN Contoller
512KB Flash, 16K RAM, UARTx3, A/D, 4 Stepper Motor Drivers, 64MHz, LQFP208 ASIC solution currently dedicated automotive customers only (open market support 3Q99
MB91F361
Fujitsu
3x 2.0B
32-bit (FR)
16 Tx / Rx buffers
No
now
4Q99
H8/300H
semiconductor.hitachi.com/h8/?adjump=frontpage_products-section
Hitachi
2.0B
16-bit
15 Tx/Rx buffers + 1 Rx buffer
15 full-bit masks + 1 global mask
no
n.a.
n.a.
H8S/2623
semiconductor.hitachi.com/h8/?adjump=frontpage_products-section
Hitachi
2.0B
16-bit
30 Tx/Rx buffers + 2 Rx buffers
no
n.a.
n.a.
SH7055 SuperH
semiconductor.hitachi.com/superh/?adjump=frontpage_products-section Hitachi semiconductor.hitachi.com/superh/?adjump=frontpage_products-section Hitachi
2.0B 2.0B
32-bit 32-bit
30 Tx/Rx buffers + 2 Rx buffers 15 Tx/Rx buffers + 1 Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 16 Tx/Rx buffers
30 full-bit masks + 2 global masks 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 16 full-bit masks
no no
n.a. n.a.
n.a. n.a. ASIC solution 256k flash, 10k RAM, I2C, 2 x ASC, 2 x SSC, RTC 64k OTP, 6 x PWM, RTC ROMless-, 32k or 128k ROM-, flash 128k flash, 4k X-flash, 11k RAM, 24 analog inputs 32k OTP, ROM less, 16k or 32k ROM, 4 x PWM 64k OTP, 4 x PWM 2 x 8-bit I/O ports technology independend functions for chip integrations
C161CI
www.infineon.com/us/micro/can/content.html
Infineon
2.0B
16-bit
no
now
now
C164CI C167CR
www.infineon.com/us/micro/can/content.html www.infineon.com/us/micro/can/content.html
Infineon Infineon
2.0B 2.0B
16-bit 16-bit
no no
now now
now now
C167CS
www.infineon.com/us/micro/can/content.html
Infineon
2.0B
16-bit
no
now
now
C505C/CA C515C SAE81C90/91 IniCAN
www.infineon.com/us/micro/can/content.html www.infineon.com/us/micro/can/content.html www.infineon.com/us/micro/can/content.html www.inicore.com
Infineon Infineon Infineon Inicore
2.0B 2.0B 2.0Bp 2.0B
8-bit 8-bit none 8-bit or DSP
no no no
now now now
now now now n.a.
implemenation-specific implemention-specific 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 3 Tx buffers + 2 Rx buffers 16 Tx/Rx buffers 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 6 full-bit masks + 2 global masks 16 full-bit masks + 1 global mask
possible n.a.
AN82527 AN87C196CA AN87C196CB AS82527 AS87C196CB MCP2510 CCU3010E
developer.intel.com/design/auto/network.htm developer.intel.com/design/auto/network.htm developer.intel.com/design/auto/network.htm developer.intel.com/design/auto/network.htm developer.intel.com/design/auto/network.htm www.microchip.com www.intermetall.de/docu.html
Intel Intel Intel Intel Intel Microchip Micronas Intermetall
2.0B 2.0B 2.0B 2.0B 2.0B 2.0B 2.0B
none 16-bit 16-bit none 16-bit none 8-bit flash
no no no no no no no
now now now now now n.a. now
now now now now now SPI Interface, PDIP/SOIC18, TSSOP20 on 32k Flash, 16 request time-stamps n.a.
CAN Contoller
CDC-1 www.intermetall.de/docu.html Micronas Intermetall 3x 2.0B 16-bit flash 16 Tx/Rx buffers 16 full-bit masks + 1 global mask yes now 3 indepemdemt on CAN-Modules, request 256k Flash, 16 time-stamps 2 independent on-chip CAN now modules, 3 phase motor controllers now now now now now now now 64-pin packaging (32 KROM) 28-pin packaging (4K ROM) 64-pin packaging (60K flash) 64-pin packaging (16K ROM) 100-pin packaging (ROM less) 64-pin packaging (16K ROM) 64-pin packaging (24K ROM) 64-pin packaging (32K ROM) 80-pin packaging (32K flash) 112-pin packaging (60K flash) 2 independent on-chip CAN modules, 112-pin packaging (128K flash) time-stamp, flash memory time-stamp, flash memory 2 independent on-chip CAN modules, time-stamp, flash memory 8-byte frames can be handles up to 125 kbit/s
M306NOMCT-xxxFP www.mitsubishichips.com
Mitsubishi
2x 2.0B 2.0B 2.0B 2.0A 2.0A 2.0B 2.0A 2.0B
16-bit
16 Tx/Rx buffers 1 Tx buffer + 2 Rx buffers 1 Tx buffer + 2 Rx buffers 1 Tx buffer + 2 Rx buffers 1 Tx buffer + 2 Rx buffers 3 Tx buffers + 2 Rx buffers 1 Tx buffer + 2 Rx buffers 3 Tx buffers + 2 Rx buffers 3 Tx buffers + 2 Rx buffers 3 Tx buffers + 2 Rx buffers 3 Tx buffers + 2 Rx buffers 3 Tx buffers + 2 Rx buffers 3 Tx buffers + 2 Rx buffers
16 full-bit masks + 3 global masks 1 full-bit mask + 1 global mask 1 full-bit mask + 1 global mask 1 global 8-bit mask 1 global 8-bit mask 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 1 global 8-bit mask 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 1 global 32-bit or 2 global 16-bit or 4 global 8-bit masks 16 full-bit masks + 3 global masks 16 full-bit masks + 3 global masks 16 full-bit masks + 3 global masks
yes
now
M37630M4-xxxFP M37632MF-xxxFP 68HC(7)05X32 68HC(7)05X4 68HC(9)08AZ60 68HC05X16 68HC08AZ0
www.mitsubishichips.com www.mitsubishichips.com www.mot.sps.com/csic/techdata/appnote www.mot.sps.com/csic/techdata/appnote www.mot.sps.com/csic/techdata/appnote www.mot.sps.com/csic/techdata/appnote www.mot.sps.com/csic/techdata/appnote
Mitsubishi Mitsubishi Motorola Motorola Motorola Motorola Motorola
8-bit 8-bit 8-bit 8-bit 8-bit 8-bit 8-bit
no no no no no no no
now now now now now now now
68HC08AZ16
www.mot.sps.com/csic/techdata/appnote
Motorola
2.0B
8-bit
no
n.a.
now
68HC08AZ24
Motorola
2.0B
8-bit
no
n.a.
now
68HC08AZ32
Motorola
2.0B
8-bit
no
n.a.
now
68HC912BC32
Motorola
2.0B
16-bit
no
now
now
68HC912D60
Motorola
2.0B
16-bit
no
now
now
68HC912DG128
Motorola
2x 2.0B
16-bit
3 Tx buffers + 2 Rx buffers
yes
now
now
MC68376 MC68F396
www.mot.sps.com/csic/techdata/appnote www.mot.sps.com/csic/techdata/appnote
Motorola Motorola
2.0B 2.0B
32-bit 32-bit
16 Tx/Rx buffers 16 Tx/Rx buffers
no no
now now
now now
MPC555
Motorola
2x 2.0B
32-bit
16 Tx/Rx buffers
yes
now
4Q99
COP684BC
www.national.com/appinfo/mcu/0,1755,48,00.html
NatSem
2.0Bp
8-bit
1 Tx 2-byte buffer + 2 Rx 2-byte buffers
1 global 8-bit mask
no
now
now
CAN Contoller
COP688/89EB www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit 1 Tx 2-byte buffer + 2 Rx 2-byte buffers 1 Tx 2-byte buffer + 2 Rx 2-byte buffers 1 Tx 2-byte buffer + 2 Rx 2-byte buffers 1 Tx 2-byte buffer + 2 Rx 2-byte buffers 1 Tx 2-byte buffer + 2 Rx 2-byte buffers 15 Tx/Rx buffers + 1 Rx buffer 32 Tx/Rx buffers 1 global 8-bit mask no now now 8-byte frames can be handles up to 125 kbit/s 8-byte frames can be handles up to 125 kbit/s 8-byte frames can be handles up to 125 kbit/s 8-byte frames can be handles up to 125 kbit/s 8-byte frames can be handles up to 125 kbit/s flash memory 128k Flash, QFP144, LCD, CAN Time System, 2x FCAN 256k Flash, QFP144, LCD, CAN Time System, 3x FCAN 256k Flash, QFP144, LCD, CAN Time System, 3x FCAN 32/48k, QFP64, EEPROM, CAN Time System 32/48k, QFP80, LCD, EEPROM, Stepper motor driver, CAN Time System 60k, QFP100, LCD, CAN Time System D780948 + EEPROM 16k, SSOP30, CAN Time System D78081X with 60k Flash D78082X with 60k Flash 60k Flash, QFP100, LCD, CAN Time System D78F0948 + EEPROM 16k Flash, SSOP30, CAN Time System
COP87/L88/89EB
NatSem
2.0Bp
8-bit
1 global 8-bit mask
no
now
now
COP87L84BC
NatSem
2.0Bp
8-bit
1 global 8-bit mask
no
now
now
COP888/89EB
NatSem
2.0Bp
8-bit
1 global 8-bit mask
no
now
now
COP8884BC CR16MCS9
www.national.com/appinfo/mcu/0,1755,48,00.html www.national.com/appinfo/mcu/0,1755,48,00.html
NatSem NatSem
2.0Bp 2.0B 2x 2.0B
8-bit 16-bit
1 global 8-bit mask 14 full-bit masks + 1 global mask
no no
now now
now now
ATOMIC - D703121 www.nec.de
NEC
32-bit RISC
32 full-bit masks + 34 possible 4Q00 29-bit masks
1Q01
ATOMIC - D703123 www.nec.de
NEC
3x 2.0B
32-bit RISC
64 Tx/Rx buffers
64 full-bit masks + 34 possible 1Q00 29-bit masks
3Q00
ATOMIC PD 70F3123
www.nec.de
NEC
3x 2.0B
32-bit RISC Flash
64 Tx/Rx buffers
64 full-bit masks + 34 possible 4Q99 29-bit masks 16 full-bit masks + 2 global 29-bit masks
3Q00
PD 780814/6
www.nec.de
NEC
2.0B
8-bit
no
1Q00
4Q00
PD 780824/6
www.nec.de
NEC
2.0B
8-bit
16 full-bit masks + 2 global 29-bit masks
no
now
1Q00
PD 780948 PD 780949 PD 789850 PD 78F0818 PD 78F0828
www.nec.de www.nec.de www.nec.de www.nec.de www.nec.de
NEC NEC NEC NEC NEC
2.0B 2.0B 2.0B 2.0B 2.0B
8-bit 8-bit 8-bit 8-bit Flash 8-bit Flash
2 Tx buffers + 16 Rx buffers 2 Tx buffers + 16 Rx buffers 2 Tx buffers + 14 Rx buffers 2 Tx buffers + 16 Rx buffers 2 Tx buffers + 16 Rx buffers 2 Tx buffers + 16 Rx buffers 2 Tx buffers + 16 Rx buffers 2 Tx buffers + 14 Rx buffers
16 full-bit masks + 2 global 29-bit masks 16 full-bit masks + 2 global 29-bit masks 14 full-bit masks + 2 global 29-bit masks 16 full-bit masks + 2 global 29-bit masks 16 full-bit masks + 2 global 29-bit masks 16 full-bit masks + 2 global 29-bit masks 16 full-bit masks + 2 global 29-bit masks 14 full-bit masks + 2 global 29-bit masks
no no no no no
now now 1Q00 now now
now 2Q00 4Q00 3Q00 2Q00
PD 78F0948
www.nec.de
NEC
2.0B
8-bit Flash
no
now
now
PD 78F0949 PD 78F9850
www.nec.de www.nec.de
NEC NEC
2.0B 2.0B
8-bit Flash 8-bit Flash
no no
now 1Q00
2Q00 4Q00
CAN Contoller
MSM9225 P82C150 P8XC591 P8XC592/8 P8XC59X SJA1000 www.oki-europe.de www-us.semiconductors.philips.com/can/products/ www-us.semiconductors.philips.com/can/products/ www-us.semiconductors.philips.com/can/products/ www-us.semiconductors.philips.com/can/products/ www-us.semiconductors.philips.com/can/products/ OKI Electric Philips Philips Philips Philips Philips 2.0B 2.0Bp 2.0B 2.0A 2.0B 2.0B none SLIO 8-bit 8-bit 8-bit none 16 Tx/Rx buffers n.a. 1 Tx buffer + 64 Rx FIFO 1 Tx buffer + 2 Rx buffers to be defined 1 Tx buffer + 64 Rx FIFO 32 Tx/Rx buffers 16 full-bit masks n. a. no no now now now now 2Q00 now now now 1Q00 now 3Q00 now will replace P8x592/8 replaces 82C200 CANopen, DeviceNet and OSEK transport layer hardwired CAN Core, VHDL- and Verilog Model for ASIC and FPGA 40V SuperSmartPower, OTP, ROM versions (2Q00) 128 kbyte flash, 32k or ROMless 16k, TQFP64 in maintenance state, not for new desing-ins
1 global 32-bit mask or no 2 global 16-bit masks 1 global 8-bit mask to be defined no no
1 global 32-bit mask or no 2 global 16-bit masks 32 full-bit masks + global masks no
XA-C3
www-us.semiconductors.philips.com/can/products/
Philips
2.0B
16-bit
4Q99
1Q00
CAN Core
www.sican.com
Sican
2.0B
optional
implementation-specific implementation-specific possible now
now
L9942/ST6
www.st.com/stonline/books/index.html
ST-Microelectronics 2.0A
8-bit
1 Tx buffer + 1 Rx buffer 14 Tx/Rx buffers + 1 double Rx buffer 3 Tx/Rx buffers
1 global 11-bit mask 14 Tx/Rx buffers + 1 double Rx buffer 2 global 11-bit masks
no
now
4Q99
ST10F1167 ST72511R4
www.st.com/stonline/books/index.html www.st.com/stonline/books/index.html
ST-Microelectronics 2.0B ST-Microelectronics 2.0Bp
16-bit 8-bit
no no
now now
now now (ROM 1Q00) now (ROM 1Q00) now (ROM 1Q00) now (ROM 1Q00) 2Q00 (ROM 3Q00) 2Q00 (ROM 3Q00) now (ROM 3Q00) 4Q99
ST72511R6
ST-Microelectronics 2.0Bp
8-bit
3 Tx/Rx buffers
2 global 11-bit masks
no
now
32k, TQFP64
ST72511R7
8-bit
3 Tx/Rx buffers
no
now
48k, TQFP64
ST72511R9
8-bit
3 Tx/Rx buffers
no
now
60k, TQFP64 16k, 256EE, TQFP44 16k, 256EE, SO34 16k, 256EE, TQFP64 40V SuperSmartPower, OTP, ROM versions (2Q00) 8k x 16 flash, 544 x 16 RAM, 10-bit A/D, 8 x PWM, QEP, SCI, SPI
ST72532J4
8-bit
3 Tx/Rx buffers
no
1Q00
ST72532K4
8-bit
3 Tx/Rx buffers
no
1Q00
ST72532R4
8-bit
3 Tx/Rx buffers
no
now
UD05
8-bit
3 Tx/Rx buffers
no
now
TMS320C241
www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm
Texas Instruments
2.0B
16-bit DSP
6 Tx/Rx buffers
2 full-bit masks + 1 global mask
no
not now planned
CAN Contoller
TMS320F241 www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm Texas Instruments 2.0B 16-bit DSP 6 Tx/Rx buffers 2 full-bit masks + 1 global mask no now now 8k x 16 flash, 544 x 16 RAM, 10-bit A/D, 8 x PWM, QEP, SCI, SPI 8k x 16 flash, 544 x 16 RAM, 10-bit A/D, 8 x PWM, QEP, SCI, SPI
TMS320F243
www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm
Texas Instruments
2.0B
16-bit DSP
6 Tx/Rx buffers 15 Tx/Rx buffers + 1 Rx buffer 15 Tx/Rx buffers + 1 Rx buffer 15 Tx/Rx buffers + 1 Rx buffer
2 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask 15 full-bit masks + 1 global mask
no
now
now
TC190C580 TMP95CS54F TMP95PS54F
doc.semicon.toshiba.co.jp doc.semicon.toshiba.co.jp doc.semicon.toshiba.co.jp
Toshiba Toshiba Toshiba
2.0B 2.0B 2.0B
none 16-bit 16-bit
no no no
now now now
now now now 64k ROM 48k OTP
CAN in Automation
CAN High-speed transceiver (ISO 11898-2)

Manufacturer Bosch type no. data rate max. [Mbd] short circuit [V] transient [V] ESD [kV] thermal shutdown slope control CMR [V] delay [ns] fan out (5) supply current [mA] stand-by current [A] packaging CF150B 0.5 -5...+36 Mietec Philips Philips SGS-Thomson Temic Unitrode Semiconductors Semiconductors (Siliconix) 82C251 1 -36...+36 -200...+200 2.5 yes variable -7...+12 170 64 <80 L9615 0.5 -5...+36 -200...+200 2 (1, 2) on/off -2...+7 (3) 230 32 <80 Si9200EY UC5350 1 1 1 -8...+18
MTC-3054 82C250 1 -3...+65
GND...+16 -8...+36 -60...+60 2 yes none -2...+7 120 (4) 32 70 -150...+100 2 yes variable -25...+18 100 (4) n.a. (6) 70
-200...+200 -200...+200 -150...+100 2 2 2 (1,2) n.a. yes on/off -2...+7 (3) 230 32 <80 variable -7...+12 100 32 110 variable -7...+12 170 64 <70
n.a. SOIC-8
300 SOP-16
<170 SO-8, DIP-8
<275 SO-8, DIP-8
n.a. SO-8
n.a. SO-8
1000 SOIC-8,DIL-8
http://www.can-cia.de/pth.htm [14.11.1999 13:09:14]
CAN in Automation
The users and manufacturers group

CiA membership benefits q Information Free of Charge q Participation in Marketing Activities q Influence on Specifications q Credit on CiA Events q Credit on CiA Publications q Entries in CiA Product Data Base Free of Charge Credits for CiA members on: q International CAN Conference Proceedings q Higher Layer Protocol Specifications supported by CAN in Automation q Entries in CiA Directories q Participation fees in CiA National Forums and In-house Seminars q Participation fees in CiA International Workshops q Participation fees in the international CAN Conference Joint marketing activities CiA is organizing several joint marketing activities, such as q Joint Stands e. g. at Hanover Fair Industry (Germany) more than 500 sqm, at Embedded Systems, Nrnberg (Germany) 80 sqm, at SPS/IPC/Drives, Nrnberg (Germany) about 190 sqm, at electronica, Munich (Germany), BiAS, Milan (Italy) and others. q Product Guides e. g. Internet data base, Product Guides to related application fields q Advertisements Advertisements in magazines and special editions q Seminars CiA members seize this opportunity to establish contacts by supporting papers. q International CAN Conference The table-Top exhibition accompanying this most important event is another occasion to reach a great number of prospective customers. q Table-Top Exhibitions
CiA
More:
Events CiA rules CiA operation structure CiA members list
Page contents:
Top Membership benefits Credits for CiA members Joint marketing activities CiA marketing activities
More:
Page contents:
http://www.can-cia.de/A.htm (1 von 2) [14.11.1999 13:10:02]
CAN in Automation
Table-Top exhibitions are also organized at fairs and seminars. CiA marketing activities q Information Free of Charge (brochures) q Sell of CAN Literature and Specifications q National CAN Forums q International CAN Workshops q CiA Stands at International Fairs (e.g. Embedded Systems Show and Conference/USA, National Manufacturing Week/USA, Automation/France, and others) In-house seminars CiA offers In-house Seminars for intensive training on CAN technology. Interested companies have to come up for the travel expenses of the trainer and pay a moderate honorar. iCC - international CAN Conference Once a year CiA is organizing the international CAN Conferences, during which international experts speak about newest CAN technologies and practical experiences on CAN networks. The conference is accompanied by a (table-Top) exhibition and attracts more than 200 participants every year. In the last years the iCC took place at Mainz, London, Paris, Berlin and San Jos, CA (USA). The found international CAN Conference found increasing interest from year to year. In 1999 it will be held in the Lingotto Conference Center, Turin (Italy). Technical support Standardization Conformance Testing Recommendations
More:
Page contents:
More:
Page contents:
http://www.can-cia.de/A.htm (2 von 2) [14.11.1999 13:10:02]
CAN in Automation
CiA rules
0. General (1) The association is named "CAN in AUTOMATION International Users and Manufacturers Group" and is registered in Erlangen (Germany). CiA Headquarters (HQ) are located in Erlangen. Other offices may be established by the CiA Board of Directors. (2) The official language is the English language. All minutes, internal papers and CiA documents have to be written in English (except the book-keeping for the German Revenue Office). 1. CiA associated members (AM) (1) Only students may be CiA Ams. CiA Ams may participate in CiA General Assemblies without voting rights and will receive minutes of CiA General Assemblies, proposals to the CiA General Assemblies and all official CiA Standards, CiA Draft Standards, CiA Draft Standard Proposals and CiA Recommendations. (2) CiA Ams may not run for election of CiA Boards of Directors or of CiA Technical Committee or CiA Business Committee. 2. CiA full class members (FCM) (1) Cia Full Class Members may be individuals, companies or non-profit organizations. CiA Full Class Members have the same rights as CiA Associated Members, but in addition they may vote in CiA General Assemblies and may run for election of CiA Board of Directors or CiA Technical Committee or CiA Business Committee. CiA Full Class Members will receive all minutes of CiA Business Committee (BC), CiA Technical Committee (TC), CiA Interest Groups (IG), CiA Special Interest Groups (SIG) and CiA Marketing Groups (MG). 3. CiA general assembly (GA) (1) The regular CiA GA takes place annually, but an irregular CiA GA can be conveened by either the CiA BoD or by the mutual consent of one quarter of CiA FCMs. (2) All CiA FCMs may speak on each agenda topic of the CiA
More:
CiA
More:
CiA
http://www.can-cia.de/ar.htm (1 von 4) [14.11.1999 13:10:09]
CAN in Automation
GA. The chairman of the CiA GA may limit the time allowed for the attenting CiA FCMs to not more than 5 Minutes per topic. 4. CiA board of directors (BoD) (1) The CiA BoD consists of three CiA FCMs representatives (Technical Director, Business Director, Managing Director) elected for one year on the CiA GA. They may participate in every CiA meeting. (2) The CiA Technical Director chairs the CiA Technical Committee. (3) The CiA Business Director chairs the CiA Business Committee. (4) The CiA Managing Director manages CiA Headquarters, CiA Offices and CiA Secretaries. 5. CiA technical committee (TC) (1) The CiA TC consists of The CiA Technical Director A representative of each CiA Interest Group Up to 5 different CiA FCMs to be elected by the CiA GA. (2) Each CiA FCM has only one vote in the CiA TC. (3) The CiA TC approves and coordinates the CiA Interest Groups. 6. CiA business committee (BC) (1) The CiA BC consists of The CiA Business Director A representative of each CiA Marketing Group Up to 5 different CiA FCMs to be elected by the CiA GA (2) Each CiA FCM has only one vote in the CiA BC. (3) The CiA BC developes the general marketing guidelines of the CiA and proposes the CiA budget to the CiA GA. (4) The CiA BC installs CiA Marketing Groups and coordinates their activities. 7. CiA interest groups (IG) (1) CiA IGs are initiated by at least 3 CiA FCMs. (2) The first meeting of the proposed CiA IG has to be announced to all CiA FCMs including the proposed scope of work. (3) During those meetings the following must happen: A workplan including goals has to be draft in accordance with
More:
CiA
CAN in Automation
the "CiA guidelines for IG" and submitted to the CiA TC for approval. (4) After approval by the CiA TC the IG has to elect a chairman. (5) CiA IGs may install CiA Special Interest Groups (SIG). The CiA SIG will be represented in the CiA IG by a representative. 8. CiA standards (1) CiA Standards proposed as CiA Draft Standards (DS) by a CiA IG are rejected, if more than one-third of the CiA FCMs votes against. This CiA DSs have to be distributed to all CiA FCMs at least 3 months before balloting deadline. In the balloting form is space to be reserved for comments. Balloting for CiA Standards is possible after a one year CiA DS period. 9. CiA draft standards (DS) (1) CiA DS proposed as CiA Draft Standard Proposals (DSP) by a CiA IG or a SIG shall be accepted by the IG in accordance to the "CiA guidelines for IG". 10. CiA draft standard proposal (DSP) (1) CiA DSP proposed as CiA Work Draft Proposals (WDP) by one or more CiA members shall be accepted by the CiA IG or SIG. (2) CiA WDPs may only be published for CiA internal purposes or after acceptance by the IG with the remark, that this document is not valid for implementation. 11. CiA recommendations (1) CiA Recommendations proposed by a CiA IG or members of the CiA TC shall be accepted by the CiA TC with the following voting rules: a) At least 50 % of the entitled to vote TC members must be present at the meeting, b) Accepted with a two-third majority, not containing abstained votes. (2) CiA Recommendations may be published only after acceptance by the CiA TC. 12. CiA marketing groups (MG) (1) CiA IGs are initiated by at least 3 CiA FCMs. (2) CiA MGs are installed by the CiA BC. The MG chairman is elected by the MG members.
More:
CiA
More:
CiA
CAN in Automation
(3) CiA MGs are related to national or regional markets or to application-specific or to higher layer protocols. 13. CiA secretaries (1) CiA Secretaries are engaged and noticed by the CiA Board of Directors. (2) CiA General Secretary operates CiA Headquarters and reports directly to the CiA Managing Director, CiA BC and CiA TC. (2) CiA Technical and Assistance Secretaries report to the CiA General Secretary. 14. Amendments (1) Ammendments of CiA Rules have to be approved by two-third majority of the present CiA FCMs in the CiA GA. 17 April 1997
CAN in Automation
Site contents
CiA CiA Rules CiA Operation Structures CiA Members List CiA Membership Application CiA Inhouse-Seminars CAN Information in Dutch Events Meetings Deadlines iCC Programm Exhibitions and Fairs Training + Education CiA CANschool
map
Page contents:
top CiA Events Literature Members only News Products CAN Protocol Higher Layer Protocols CANopen Protocols DeviceNet CAN Application Layer CAN Kingdom Standardization
Literature Order Form Bibliography (Books, Proceedings, Links...) CiA Standards CiA Standards CAN CiA Standards CAL CiA Standards CANopen CiA Standards Misc Products Product data base Chip survey High-speed Low-speed
Members only section
News Press Releases CiA News Newsletter Rate Card CAN Protocol General Application Technical Introduction Conformance Test FAQs
Page contents:
Higher Layer Protocols CANopen Technical Introduction Conformance Test DeviceNet Technical Introduction Conformance Test
http://www.can-cia.de/map.htm (1 von 2) [14.11.1999 13:10:59]
CAN in Automation
Certified Companies FAQs & design hints FAQs Vendor list CAN Application Layer Technical introduction Standardization CAN Kingdom Technical Introduction
Page contents:
http://www.can-cia.de/map.htm (2 von 2) [14.11.1999 13:10:59]
CAN in Automation
CiA Operationstructure
General Assembly Board of Directors: Business Director - Managing Director - Technical Director Business Committee Marketing Groups (MG) Headquarters Technical Committee Interest Groups (IG): IG Hydraulics IG Application Layer IG CANopen CANopen Special Interest Groups (SIG): SIG Programmable CANopen Devices SIG Safety SIG Generic I/O Modules SIG Drives and Motion Control SIG Human Machine Interfaces SIG Measuring Devices and Closed Loop Controllers SIG IEC 1131 Programmable Devices SIG Encoders SIG Public Transportation SIG Hydraulics SIG Maritime Electronics SIG Medical SIG Railways
CiA
More:
CiA CiA rules CiA members list
MG Benelux MG Scandinavia MG France MG Switzerland MG CANopen MG Device Net
http://www.can-cia.de/ao.htm [14.11.1999 13:11:09]
CAN in Automation
Events
CAN in Automation is organizing several events each year. These are not only Seminars, Workshops and Exhibitions, but also the most important international CAN Conference. 6th international CAN Conference: The international CAN Conference is CiAs most important event every year. Experts from all over the world speak about newest CAN technologies and practical experiences on CAN networks. It is accompanied by a table-top exhibition, workshops, seminars, etc. Training and education: Besides seminars and workshops CiA is organizing the CAN Schools (in Germany) and offers In-house Seminars at a reasonable price. Meetings: Usually only CiA members may attend the meetings of the several technical and marketing groups. However study groups and inaugural meetings invite guests some times. Exhibitions and fairs: CiA is organizing joint stands in European countries as well as the USA. Moreover CiA is attending at important fairs and exhibitions all over the world with CiA information stands. Deadlines: This page reminds CiA members of their "to do"s.
Marketing
More:
CiA Meetings Deadlines 6th iCC programme Exhibitions and fairs Training and education
http://www.can-cia.de/E.htm [14.11.1999 13:11:17]
CAN in Automation
CiA deadlines
November 8 very last deadline for registration CiA joint stand BIAS 2000, Milan (Italy) October 29 very last deadline for registration for table top exhibition 6th iCC at Turin (Italy)
Events
More:
CiA Events Meetings 6th iCC programme Exhibitions and fairs Training and educations
http://www.can-cia.de/ED.htm [14.11.1999 13:11:20]
CAN in Automation
Fairs and exhibitions

November 2 - 4 6th international CAN Conference, Turin (Italy) Table-top exhibition beside the sponsoring companies the following companies ordered one, two or more tables: Applicom (1), Arteco (1), Automata (1), Beckhoff (1), Dearborn (1), EMS Dr. Thomas Wnsche (1), esd (2), Fujitsu (1), i+ME Actia (1), Ixxat Automation (2), Janz Computer (2), Kvaser (1), Lumberg (1), MEN (1), Microtask (1), NSI (1), port (1), Rockwell Automation (4), Softing (3), Special Electronic Design (1), Warwick Manufacturing Group (1), Toshiba (1), Weidmller (2).
For more information and registration download
Events
More:
CiA Events Deadlines Meetings 6th iCC programme Training and educations
November 23 - 25 SPS/IPC/Drives 99, Nrnberg (Germany) CiA stand February 23 - 26, 2000 IBias 2000, Milan (Italy) CiA joint stand - sub-exhibitors: Arteco, Berghof, Janz, Softing
http://www.can-cia.de/EEF.htm [14.11.1999 13:11:25]
CAN in Automation
Conformance test
Page contents: What is Conformance Testing? More informations about the DeviceNet conformance test What is Conformance Testing? ODVA has established Independent Test Labs to verify conformance of DeviceNet products to the DeviceNet Specification. The first Test Lab was established at the Electronic Manufacturing Laboratory (EML) of the University of Michigan (Ann Arbor, MI USA). We now have two more Test Labs, one at Warwick Manufacturing Center at the University of Warwick in Coventry, England and the other at ASTEMRI (Advanced Software Technology and Mechatronics Research Institute) in Kyoto, Japan. These sites function to promote and verify interoperability and interchangeability of DeviceNet products, thereby providing an increased sense of security for users of these products. The testing sites make use of Conformance Testing Software developed by the Conformance Special Interest Group (SIG) within ODVA; participants are encouraged to purchase the test software from ODVA so that they may pre-test their products prior to submitting them to one or the testing sites for official testing. Detailed test results will be returned to the participant for review. Test results will also be forwarded to ODVA, and ODVA will publish a list of products that have passed. More informations about the DeviceNet conformance test
DeviceNet
More:
General introduction Technical introduction Specifications FAQs
Page contents:
http://www.can-cia.de/hdc.htm [14.11.1999 13:11:50]
Conformance Testing Directory

What is Conformance Testing? About the Test Conformance Test Policy ODVA Independent Test Labs About the Conformance Test Software Order Forms Listing of Products Tested By ODVA Independent Labs DeviceNet Interoperability Problem Reports Frequently Asked Questions About Conformance Testing
[ ODVA Home Page] .[ Send e-mail to ODVA] . [ Ask Dr. DeviceNet a Technical Question] [ODVA Catalog Request Form ] . [ODVA Services Information]
Copyright ODVA 1997-99 Most recent revision Sunday, August 8, 1999 webmaster
http://www.controlnet.org/ODVA/CONFTEST/conform.htm [14.11.1999 13:12:05]
CAN in Automation
CAN General introduction

Page contents : What's CAN The Attributes of CAN What's CAN ? The Controller Area Network (CAN) doesn't try to reach heaven like the Tower of Babel. CAN is a serial bus system especially suited for networking "intelligent" devices as well as sensors and actuators within a system or sub-system. The Attributes of CAN
CAN
More:
Technical introduction Applications Specifications Conformance test FAQ's Chips High-speed tranceiver Presentations:
CAN is a serial bus system with multi-master capabilities, that is, all CAN nodes are able to transmit data and several CAN nodes can request the bus simultaneously. The serial bus system with real-time capabilities is the subject of the ISO 11898 international standard and covers the lowest two layers of the ISO/OSI reference model. In CAN networks there is no addressing of subscribers or stations in the conventional sense, but instead, prioritized messages are transmitted. A transmitter sends a message to all CAN nodes (broadcasting). Each node decides on the basis of the identifier received whether it should process the message or not. The identifier also determines the priority that the message enjoys in competition for bus access. The relative simplicity of the CAN protocol means that very little cost and effort need to expended on personal training; the CAN chips interfaces make applications programming relatively simple. Introductory courses, function libraries, starter kits, host interfaces, I/O modules and tools are available from a variety of vendors permitting low-cost implementation of CAN networks. Low-cost controller chips implementing the CAN data link layer protocol in silicon and permitting simple connection to microcontrollers have been available since 1989. Today there are more than about 50 CAN protocol controller chips from more than 15 manufacturers announced and available. The use of CAN in most of European passenger cars and the decision by truck and off-road vehicle manufacturers for CAN guarantees the availability of CAN chips for more than 10
Physical Layer Data Link Layer Implementations Applications
Page contents:
Top Whats's CAN The Attributes of CAN
http://www.can-cia.de/cg.htm (1 von 2) [14.11.1999 13:12:37]
CAN in Automation
years. Other high volume markets, like domestic appliances and industrial control, also increase the CAN sales figures. Up to spring 1999 there are more than 150 million CAN nodes installed. One of the outstanding features of the CAN protocol is its high transmission reliability. The CAN controller registers a stations error and evaluates it statistically in order to take appropriate measures. These may extend to disconnecting the CAN node producing the errors. Each CAN message can transmit from 0 to 8 bytes of user information. Of course, you can transmit longer data information by using segmentation. The maximum transmission rate is specified as 1 Mbit/s. This value applies to networks up to 40 m. For longer distances the data rate must be reduced: for distances up to 500 m a speed of 125 kbit/s is possible, and for transmissions up to 1 km a data rate of 50 kbit/s is permitted.
More:
Technical introduction Applications Specifications Conformance test FAQ's Chips High-speed tranceiver Presentations: Physical Layer Data Link Layer Implementations Applications
Page contents:
Top Whats's CAN The Attributes of CAN
http://www.can-cia.de/cg.htm (2 von 2) [14.11.1999 13:12:37]
CAN in Automation
CAN Technical introduction

Page contents: How does it function Principles of data exchange Non-destructive bitwise arbitration Efficiency of bus allocation Message frame formats Detecting and signalling errors Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol Overview CAN controller with intermediate buffer CAN controller with object storage CAN slave controllers for I/O functions Physical CAN connection How does it function Principles of data exchange When data are transmitted by CAN, no stations are addressed, but instead, the content of the message (e.g. rpm or engine temperature) is designated by an identifier that is unique throughout the network. The identifier defines not only the content but also the priority of the message. This is important for bus allocation when several stations are competing for bus access. If the CPU of a given station wishes to send a message to one or more stations, it passes the data to be transmitted and their identifiers to the assigned CAN chip ("Make ready"). This is all the CPU has to do: To initiate data exchange. The message is constructed and transmitted by the CAN chip. As soon as the CAN chip receives the bus allocation ("Send Message") all other stations on the CAN network become receivers of this message ("Receive Message"). Each station in the CAN network, having received the message correctly, performs an acceptance test to determine whether the data received are relevant for that station ("Select"). If the data are of significance
CAN
More:
General introduction Applications Specifications Conformance test FAQ's
page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with intermediate buffer - CAN controller with object storage - CAN slave controllers for I/O functions Physical CAN connection
http://www.can-cia.de/ct.htm (1 von 13) [14.11.1999 13:12:55]
CAN in Automation
for the station concerned they are processed ("Accept"), otherwise they are ignored. A high degree of system and configuration flexibility is achieved as a result of the content-oriented addressing scheme. It is very easy to add stations to the existing CAN network without making any hardware or software modifications to the existing stations, provided that the new stations are purely receivers. Because the data transmission protocol does not require physical destination addresses for the individual components, it supports the concept of modular electronics and also permits multiple reception (broadcast, multicast) and the synchronization of distributed processes: measurements needed as information by several controllers can be transmitted via the network, in such a way that it is unnecessary for each controller to have its own sensor.
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with intermediate buffer - CAN controller with object storage - CAN slave controllers for I/O functions
Broadcast transmission and acceptance filtering by CAN nodes
CAN in Automation
Physical CAN connection Principle of non-destructive bitwise arbitration
Non-destructive bitwise arbitration For the data to be processed in real time they must be transmitted rapidly. This not only requires a physical data transfer path with up to 1 Mbit/s but also calls for rapid bus allocation when several stations wish to send messages simultaneously. In real-time processing the urgency of messages to be exchanged over the network can differ greatly: a rapidly changing dimension (e.g. engine load) has to be transmitted more frequently and therefore with less delays than other dimensions (e.g. engine temperature) which change relatively slowly. The priority at which a message is transmitted compared with another less urgent message is specified by the identifier of the message concerned. The priorities are laid down during system design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary number has the highest priority. Bus access conflicts are resolved by bitwise arbitration on the identifiers involved by each station observing the bus level bit for bit. In accordance with the "wired and" mechanism, by which the dominant state (logical 0) overwrites the recessive state (logical 1), the competition for bus allocation is lost by all those stations with recessive transmission and dominant observation. All "losers" automatically become receivers of the message with the highest priority and do not re-attempt transmission until the bus is available again. Efficiency of bus allocation The efficiency of the bus allocation system is determined mainly by the possible applications for a serial bus system. In order to judge as simply as possibly which bus systems are suitable for which applications the literature includes a method of classifying bus allocation procedures. Generally we distinguish between the following classes: q Bus allocation on a fixed time schedule Allocation is made sequentially to each participant for a maximum duration regardless of whether this participant needs the bus at this moment or not (examples: token
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with intermediate buffer - CAN controller with object storage - CAN slave controllers for
CAN in Automation
slot or token passing). Bus allocation on the basis of need The bus is allocated to one participant on the basis of transmission requests outstanding, i.e. the allocation system only considers participants wishing to transmit (examples: CSMA, CSMA/CD, flying master, round robin or bitwise arbitration).
I/O functions Physical CAN connection
For CAN, bus allocation is negotiated purely among the messages waiting to be transmitted. This means that the procedure specified by CAN is classified as allocation on the basis of need. Another means of assessing the efficiency of bus arbitration systems is the bus access method: q Non-destructive bus access With methods of this type the bus is allocated to one and only one station either immediately or within a specified time following a single bus access (by one or more stations). This ensures that each bus access by one or more stations leads to an unambiguous bus allocation (examples: token slot, token passing, round robin, bitwise arbitration). q Destructive bus allocation Simultaneous bus access by more than one station causes all transmission attempts to be aborted and therefore there is no successful bus allocation. More than one bus access may be necessary in order to allocate the bus at all, the number of attempts before bus allocation is successful being a purely statistical quantity (examples: CSMA/CD, Ethernet). In order to process all transmission requests of a CAN network while complying with latency constraints at as low a data transfer rate as possible, the CAN protocol must implement a bus allocation method that guarantees that there is always unambiguous bus allocation even when there are simultaneous bus accesses from different stations. The method of bitwise arbitration using the identifier of the messages to be transmitted uniquely resolves any collision between a number of stations wanting to transmit, and it does this at the latest within 13 (standard format) or 33 (extended format) bit periods for any bus access period. Unlike the message-wise arbitration employed by the CSMA/CD method this non-destructive method of conflict resolution ensures that no bus capacity is used without transmitting useful information.
More:
General introduction applications Specifications Conformance test FAQ's
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message implementations of the CAN protocol - overview - CAN controller with intermediate buffer - CAN controller with object storage - CAN slave controllers
CAN in Automation
Even in situations where the bus is overloaded the linkage of the bus access priority to the content of the message proves to be a beneficial system attribute compared with existing CSMA/CD or token protocols: In spite of the insufficient bus transport capacity, all outstanding transmission requests are processed in order of their importance to the overall system (as determined by the message priority). The available transmission capacity is utilized efficiently for the transmission of useful data since "gaps" in bus allocation are kept very small. The collapse of the whole transmission system due to overload, as can occur with the CSMA/CD protocol, is not possible with CAN. Thus, CAN permits implementation of fast, traffic-dependent bus access which is non-destructive because of bitwise arbitration based on the message priority employed. Non-destructive bus access can be further classified into q centralized bus access control q decentralized bus access control depending on whether the control mechanisms are present in the system only once (centralized) or more than once (decentralized). A communication system with a designated station (inter alia for centralized bus access control) must provide a strategy to take effect in the event of a failure of the master station. This concept has the disadvantage that the strategy for failure management is difficult and costly to implement and also that the takeover of the central station by a redundant station can be very time-consuming. For these reasons and to circumvent the problem of the reliability of the master station (and thus of the whole communication system), the CAN protocol implements decentralized bus control. All major communication mechanisms, including bus access control, are implemented several times in the system, because this is the only way to fulfill the high requirements for the availability of the communication system. In summary it can be said that CAN implements a traffic-dependent bus allocation system that permits, by means of a non-destructive bus access with decentralized bus access control, a high useful data rate at the lowest possible bus data rate in terms of the bus busy rate for all stations. The efficiency of the bus arbitration procedure is increased by the fact that the bus is utilized only by those stations with pending transmission requests. These requests are handled in the order of the importance of the messages for the system as a whole. This proves especially advantageous in overload situations. Since bus
for I/O functions Physical CAN connection
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with intermediate buffer - CAN controller with object
CAN in Automation
access is prioritized on the basis of the messages, it is possible to guarantee low individual latency times in real-time systems.
storage - CAN slave controllers for I/O functions Physical CAN connection
Message frame for standard format (CAN Specification 2.0A)
Message frame formats The CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier (ID). In the standard format the length of the ID is 11 bits and in the extended format the length is 29 bits. The message frame for transmitting messages on the bus comprises seven main fields. A message in the standard format begins with the start bit "start of frame", this is followed by the "arbitration field", which contains the identifier and the "RTR" (remote transmission request) bit, which indicates whether it is a data frame or a request frame without any data bytes (remote frame). The "control field" contains the IDE (identifier extension) bit, which indicates either standard format or extended format, a bit reserved for future extensions and - in the last 4 bits - a count of the data bytes in the data field. The "data field" ranges from 0 to 8 bytes in length and is followed by the "CRC field", which is used as a frame security check for detecting bit errors. The "ACK field" comprises the ACK slot (1 bit) and the ACK delimiter (1 recessive bit). The bit in the ACK slot is sent as a recessive bit and is overwritten as a dominant bit by those receivers which have at this time received the data correctly (positive acknowledgement). Correct messages are acknowledged by the receivers regardless of the result of the acceptance test. The end of the message is indicated by "end of frame". "Intermission" is the minimum number of bit periods separating consecutive messages. If there is no following bus access by any station, the bus remains idle ("bus idle"). Detecting and signalling errors Unlike other bus systems, the CAN protocol does not use acknowledgement messages but instead signals any errors
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with intermediate buffer - CAN controller with
CAN in Automation
that occur. For error detection the CAN protocol implements three mechanisms at the message level: q Cyclic Redundancy Check (CRC) The CRC safeguards the information in the frame by adding redundant check bits at the transmission end. At the receiver end these bits are re-computed and tested against the received bits. If they do not agree there has been a CRC error. q Frame check This mechanism verifies the structure of the transmitted frame by checking the bit fields against the fixed format and the frame size. Errors detected by frame checks are designated "format errors". q ACK errors As mentioned above, frames received are acknowledged by all recipients through positive acknowledgement. If no acknowledgement is received by the transmitter of the message (ACK error) this may mean that there is a transmission error which has been detected only by the recipients, that the ACK field has been corrupted or that there are no receivers. The CAN protocol also implements two mechanisms for error detection at the bit level: q Monitoring The ability of the transmitter to detect errors is based on the monitoring of bus signals: each node which transmits also observes the bus level and thus detects differences between the bit sent and the bit received. This permits reliable detection of all global errors and errors local to the transmitter. q Bit stuffing The coding of the individual bits is tested at bit level. The bit representation used by CAN is NRZ (non-return-to-zero) coding, which guarantees maximum efficiency in bit coding. The synchronization edges are generated by means of bit stuffing, i.e. after five consecutive equal bits the sender inserts into the bit stream a stuff bit with the complementary value, which is removed by the receivers. The code check is limited to checking adherence to the stuffing rule. If one or more errors are discovered by at least one station (any station) using the above mechanisms, the current transmission is aborted by sending an "error flag". This
object storage - CAN slave controllers for I/O functions Physical CAN connection
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with intermediate buffer
CAN in Automation
prevents other stations accepting the message and thus ensures the consistency of data throughout the network. After transmission of an erroneous message has been aborted, the sender automatically re-attempts transmission (automatic repeat request). There may again be competition for bus allocation. As a rule, retransmission will be begun within 23 bit periods after error detection; in special cases the system recovery time is 31 bit periods. However effective and efficient the method described may be, in the event of a defective station it might lead to all messages (including correct ones) being aborted, thus blocking the bus system if no measures for self-monitoring were taken. The CAN protocol therefore provides a mechanism for distinguishing sporadic errors from permanent errors and localizing station failures (fault confinement). This is done by statistical assessment of station error situations with the aim of recognizing a station's own defects and possibly entering an operating mode where the rest of the CAN network is not negatively affected. This may go as far as the station switching itself off to prevent messages erroneously recognized as incorrect from being aborted. Data reliability of the CAN protocol The introduction of safety-related systems in automobiles brought with it high requirements for the reliability of data transmission. The objective is frequently formulated as not permitting any dangerous situations for the driver to occur as a result of data exchange throughout the whole life of a vehicle. This goal is achieved if the reliability of the data is sufficiently high or the residual error probability is sufficiently low. In the context of bus systems data, reliability is understood as the capability to identify data corrupted by transmission faults. The residual error probability is a statistical measure of the impairment of data reliability: It specifies the probability that data will be corrupted and that this corruption will remain undetected. The residual error probability should be so small that on average no corrupted data will go undetected throughout the whole life of a system.
- CAN controller with object storage - CAN slave controllers for I/O functions Physical CAN connection
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with
CAN in Automation
intermediate buffer - CAN controller with object storage - CAN slave controllers for I/O functions Physical CAN connection
Residual error probability as a function of bit error probability
Calculation of the residual error probability requires that the errors which occur be classified and that the whole transmission path be described by a model. If we determine the residual error probability of CAN as a function of the bit error probability for message lengths of 80 to 90 bits, for system configurations of, for instance, five or ten nodes and with an error rate of 1/1000 (an error in one message in every thousand), then maximum bit error probability is approximately 0.02 - in the order of 10-13. Based on this it is possible to calculate the maximum number of undetectable errors for a given CAN network. For example, if a CAN network operates at a data rate of 1 Mbit/s, at an average bus capacity utilization of 50 percent, for a total operating life of 4000 hours and with an average message length of 80 bits, then the total number of messages transmitted is 9 x 1010. The statistical number of undetected transmission errors during the operating life is thus in the order of less than 10-2. Or to put it another way, with an operating time of eight hours per day on 365 days per year and an error rate of 0.7 s, one undetected error occurs every thousand years (statistical average). Extended format CAN message The SAE "Truck and Bus" subcommittee standardized signals and messages as well as data transmission protocols for various data rates. It became apparent that standardization of this kind is easier to implement when a longer identification field is available.
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the CAN protocol Extended format CAN message Implementations of the CAN protocol
CAN in Automation
To support these efforts, the CAN protocol was extended by the introduction of a 29-bit identifier. This identifier is made up of the existing 11-bit identifier (base ID) and an 18-bit extension (ID extension). Thus the CAN protocol allows the use of two message formats: StandardCAN (Version 2.0A) and ExtendedCAN (Version 2.0B). As the two formats have to coexist on one bus it is laid down which message has higher priority on the bus in the case of bus access collisions with differing formats and the same base identifier: The message in standard always has priority over the message in extended format. CAN controllers which support the messages in extended format can also send and receive messages in standard format. When CAN controllers which only cover the standard format (Version 2.0A) are used on one network, then only messages in standard format can be transmitted on the entire network. Messages in extended format would be misunderstood. However there are CAN controllers which only support standard format but recognize messages in extended format and ignore them (Version 2.0B passive). The distinction between standard format and extended format is made using the IDE bit (Identifier Extension Bit) which is transmitted as dominant in the case of a frame in standard format. For frames in extended format it is recessive. The RTR bit is transmitted dominant or recessive depending on whether data are being transmitted or whether a specific message is being requested from a station. In place of the RTR bit in standard format the SRR (substitute remote request) bit is transmitted for frames with extended ID. The SRR bit is always transmitted as recessive, to ensure that in the case of arbitration the standard frame always has priority bus allocation over an extended frame when both messages have the same base identifier. Unlike the standard format, in the extended format the IDE bit is followed by the 18-bit ID extension, the RTR bit and a reserved bit (r1). All the following fields are identical with standard format. Conformity between the two formats is ensured by the fact that the CAN controllers which support the extended format can also communicate in standard format.
- Overview - CAN controller with intermediate buffer - CAN controller with object storage - CAN slave controllers for I/O functions Physical CAN connection
More:
Page contents:
Top How does it function - Principles of data exchange - Non-destructive bitwise arbitration - Efficiency of bus allocation - Message frame formats - Detecting and signalling errors - Data reliability of the
CAN in Automation
Message frame for extended format (CAN specification 2.0B)
Implementations of the CAN protocol Overview Communication is identical for all implementations of the CAN protocol. There are differences, however, with regard to the extent to which the implementation takes over message transmission from the microcontrollers which follow it in the circuit. CAN controller with intermediate buffer CAN controllers with intermediate buffer (formerly called basicCAN chips) have implemented as hardware the logic necessary to create and verify the bitstream according to protocol. However, the administration of data sets to be sent and received, acceptance filtering in particular, is carried out to only a limited extent by the CAN controller. Typically, CAN controllers with intermediate buffer have two reception and one transmission buffer. The 8-bit code and mask registers allow a limited acceptance filtering (8 MSB of the identifier). Suitable choice of these register values allows groups of identifiers or in borderline cases all IDs to be selected. If more than the 8 ID-MSBs are necessary to differentiate between messages then the microcontroller following the CAN controller in the circuit must complement acceptance filtering by software. CAN controllers with intermediate buffer may place a strain on the microcontroller with the acceptance filtering, but they require only a small chip area and can therefore be produced at lower cost. In principle they can accept all objects in a CAN network. CAN controller with object storage CAN objects consist mainly of three components: Identifier, data length code and the actual useful data. CAN controllers with object storage (formerly called FullCAN) function like CAN controllers with intermediate buffers, but also administer certain objects. Where there are several simultaneous requests they determine, for example, which object is to be transmitted first. They also carry out acceptance filtering for incoming objects. The interface to the following microcontroller corresponds to a
CAN protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with intermediate buffer - CAN controller with object storage - CAN slave controllers for I/O functions Physical CAN connection
CAN in Automation
RAM. Data to be transmitted are written into the appropriate RAM area, data received are read out correspondingly. The microcontroller has to administer only a few bits (e. g. transmission request). CAN controllers with object storage are designed to take as much strain as possible off the local microcontroller. These CAN controllers require a greater chip area, however, and are therefore more expensive. In addition to this, they can only administer a limited number of chips. CAN controllers are now available which combine both principles of implementation. They have object storage, at least one of which is designed as an intermediate buffer. For this reason there is no longer any point in differentiating between basicCAN and fullCAN. CAN slave controllers for I/O functions As well as CAN controllers which support all functions of the CAN protocol there are also CAN implementations possible which do not require a following microcontroller. These CAN implementations are called SLIO (serial link I/O) acting as CAN slaves and having to be administered by a CAN master. Physical CAN connection The data rates (up to 1 Mbit/s) necessitate a sufficiently steep pulse slope, which can be implemented only by using power elements. A number of physical connections are basically possible. However, the users and manufacturers group CAN in Automation recommends the use of driver circuits in accordance with ISO 11898. Integrated driver chips in accordance with ISO 11898 are available from several companies. The international users and manufacturers group (CiA) also specifies several mechanical connections (cable and connectors).
CAN in Automation
Physical CAN Connection according to ISO 11898
CAN in Automation
Conformance test
CAN
More:
General introduction Technical introduction Applications Specifications FAQ's Chips High-speed tranceiver Presentations: Physical Layer Data Link Layer Implementations Applications
The CAN Conformance test plan standardized in ISO WD 16845 specifies the methodology and the abstract test suite necessary to check the conformance of any CAN implementation to the harmonized CAN specification. The test plan is a specific application of ISO 9646-1. The test plan environment consists of a lower tester, the IUT (implementation under test), and the upper tester running on a microcontroller, for example. Since the message storaging capability, the hardware acceptance filter, and the CPU interface are not standardized, the only link between lower tester and IUT are the PLS-Data.indicate and PLS-Data.request interfaces. The abstract test suites are independent one another. Each test suite checks the behaviour of the IUT for a particular parameter of the CAN specification. The test cases are grouped to received frame type cases, to transmitted frame type cases, and to bidirectional frame type cases. Each test type is subdivided in six test classes: q Valid frame format class q Error detection class q Active error frame management class q Overload frame class q Passive error state and bus-off class q Bit timing class The CAN Conformance test plan is implemented by two different test service providers. These are the German "Fachhochschule Braunschweig/Wolfenbttel" (University of Applied Science) and the French company Dassault Electronique. The German "Fachhochschule Braunschweig/Wolfenbttel" under Prof. Dr. W. Lawrenz provides a certificate which is mainly used by the chip manufacturer and the German automotive industry.
More:
General introduction Technical introduction Applications Specifications FAQ's Chips High-speed tranceiver Presentations: Physical Layer Data Link Layer Implementations Applications
http://www.can-cia.de/cc.htm [14.11.1999 13:13:05]
CAN in Automation
CAN Applications
Page contents: Overview The need for serial communication in vehicles Use of the CAN in vehicles Industrial application of the CAN Overview CAN networks can be used as an embedded communication system for microcontrollers as well as an open communication system for intelligent devices. The CAN serial bus system, originally developed for use in automobiles, is increasingly being used in industrial as well as building automation, medical equipment and maritime electronics. If the requirements for passenger cars networks are compared with those for industrial field bus systems, the similarities are remarkable. In both cases some of the major requirements are: Low cost, the ability to function in a difficult electrical environment, a high degree of real-time capability and ease of use. Some users, for example in the field of medical engineering, opted for CAN because they have to meet particulary stringent safety requirements. Similar problems are faced by manufacturers of other equipment with very high safety or reliability requirements (e. g. robots, lifts and transportation systems). The need for serial communication in vehicles Many vehicles already have a large number of electronic control systems. The growth of automotive electronics is the result partly of the customer's wish for better safety and greater comfort and partly of the government's requirements for improved emission control and reduced fuel consumption. Control devices that meet these requirements have been in use for some time in the area of engine timing, gearbox and carburettor throttle control and in anti-block systems (ABS) and acceleration skid control (ASC). The complexity of the functions implemented in these systems necessitates an exchange of data between them. With conventional systems, data is exchanged by means of
http://www.can-cia.de/cga.htm (1 von 4) [14.11.1999 13:13:13]
CAN
More:
General introduction Technical introduction Specifications Conformance test FAQ's Chips High-speed tranceiver Presentations: Physical Layer Data Link Layer Implementations Applications
Page contents:
Top Overview The need for serial communication in vehicles Use of the CAN in vehicles Industrial application of the CAN
CAN in Automation
dedicated signal lines, but this is becoming increasingly difficult and expensive as control functions become ever more complex. In the case of complex control systems (such as Motronic) in particular, the number of connections cannot be increased much further. Moreover, a number of systems are being developed, which implement functions covering more than one control device. For instance, ASC requires the interplay of engine timing and carburettor control in order to reduce torque when drive wheel slippage occurs. Another example of functions spanning more than one control unit is electronic gearbox control, where ease of gear-changing can be improved by a brief adjustment to ignition timing. If we also consider future developments aimed at overall vehicle optimization, it becomes necessary to overcome the limitations of conventional control device linkage. This can only be done by networking the system components using a serial data bus system. It was for this reason that Bosch developed the "Controller Area Network" (CAN), which has since been standardized internationally (ISO 11898) and has been "implemented in silicon" by several semiconductor manufacturers. Using CAN, peer stations (controllers, sensors and actuators) are connected via a serial bus. The bus itself is a symmetric or asymmetric two wire circuit, which can be either screened or unscreened. The electrical parameters of the physical transmission are also specified in ISO 11898. Suitable bus driver chips are available from a number of manufacturers. The CAN protocol, which corresponds to the data link layer in the ISO/OSI reference model, meets the real-time requirements of automotive applications. Unlike cable trees, the network protocol detects and corrects transmission errors caused by electromagnetic interference. Additional advantages of such a network are the easy configurability of the overall system and the possibility of central diagnosis. The purpose of using CAN in vehicles is to enable any station to communicate with any other without putting too great a load on the controller computer. Use of the CAN in vehicles There are four main applications for serial communication in vehicles, each having different requirements and objectives.
More:
Page contents:
More:
CAN in Automation
Networking controllers for engine timing, transmission, chassis and brakes. The data rates are in the range - typical of real-time systems - of 200kBit/s to 1Mbit/s. Networking components of chassis electronics and electronics, which make the vehicle more comfortable. Examples of such multiplex applications are lighting control, air-conditioning, central locking, and seat and mirror adjustment. Particular importance has to be attached here to the cost of the components and wiring requirements. Typical data rates are around 50kBit/s. In the near future, serial communication will also be used in the field of mobile communication in order to link components such as car radios, car telephones, navigation aids etc. to a central, ergonomically designed control panel. The functions defined in the Prometheus project, such as vehicle-to-vehicle and vehicle-to-infrastructure communication will depend to a large extent on serial communication. At present, CAN can be used for the first three applications, but for diagnosis the preferred solution is an interface according to ISO 9141. Industrial applications of the CAN A comparison of the requirements for vehicle bus systems and industrial field bus systems shows amazing similarities: Low cost, operability in a harsh electrical environment, high real-time capabilities and ease of use are equally desirable in both sectors. The standard use of CAN in Mercedes-Benz's "S" Class and the adoption of CAN by US commercial vehicle manufacturers for fast transmissions (up to 1 MBit/s) has made industrial users prick up their ears. Not only manufacturers of mobile and stationary agricultural and nautical machinery and equipment have chosen to use CAN, is has also been the choice of manufacturers of medical apparatus, textile machines, special-purpose machinery and elevator controls. The serial bus system is particularly well suited to networking "intelligent" I/O devices as well as sensors and actuators within a machine or plant. The textile machinery industry is one of the pioneers of CAN. One manufacturer equipped his looms with modular control systems communicating in real time via CAN networks as early as 1990. In the meantime several textile machinery manufacturers have joined together to form the "CAN Textile Users Group", which in turn is a member of the international
Page contents:
More:
General introduction Technical introduction Specifications Conformance test FAQ's Chips High-speed tranceiver Presentations: Physical Layer
CAN in Automation
users and manufacturers group "CAN in Automation". Similar requirements to those of the textile machinery are to be found in packaging machinery and machinery for paper manufacture and processing. In the USA a number of enterprises are using CAN in production lines and machine tools as an internal bus system for networking sensors and actuators within the line or machine. Some users, for instance in the medical engineering sector, decided in favour of CAN because they had particularly stringent safety requirements. Similar problems are faced by other manufacturers of machinery and equipment with particular requirements with respect to safety (e.g. robots and transport systems). Apart from the high transmission reliability, the low connection costs per station are a further decisive argument for CAN. In applications where price is critical it is of essential importance that CAN chips be available from a variety of manufacturers. The compactness of the controller chips is also an important argument, for instance in the field of low-voltage switchgear.
Data Link Layer Implementations Applications
Page contents:
CAN in Automation
Frequently asked question

Please send your questions to: headquarters@can-cia.de
CAN
More:
coming soon
General introduction Technical introduction Applications Specifications Conformance test Chips High-speed tranceiver Presentations: Physical Layer Data Link Layer Implementations Applications
http://www.can-cia.de/cf.htm [14.11.1999 13:13:18]
CAN in Automation
Standardization
CAN-related standards There are several official national and international standardization bodies as well as user organizations and private companies dealing with open CAN-based specifications. The following will give an overview on these activities, but will not claim for completeness. Standard State Organization Topic Main Applications
News
More:
Hot News CiA News CAN Newsletter Press Release
CAN Data Link Layer and Physical Layer

IS 11898 (Nov. ISO TC22 SC3 WG1 TF1 + 1993 + Amendment TF6 1 (1995) <under review> IS 11519-2 <will be withdrawn> CD 16845 J2284 Draft J2411 ISO TC22 SC3 WG1 TF6 SAE SAE ISO TC22 SC3 WG1 TF1 + TF6 CAN Low-Speed Transceiver and Data Link Layer CAN Conformance Testing CAN High-Speed Interface Single-Wire Physical Layer Car Body Electronics CAN Data Link Layer and Transceiver(s) Automotive and General Purpose
General Automotive Car Body Electronics
CAN-Related Standards for Vehicles

IS 11992-1, -2, -3 (under review) CD 15765-1, -2, -3, -4 CD 15031-3 (J1962) CD 16844-4, -5 WD 11783 CD 717617 CCP J1939-01 to J1939-81 DIN 9684 WDP-407 (prEN61349-2) WDP-4XX WDP-4XX ISO TC22 SC3 WG1 TF7 ISO TC23 SC19 WG1 ISO TC173 SC1 WG7 ASAM e.V. SAE DIN e.V. CiA/VDV (CLC TC278 WG3 SG1) CiA CANopen Special Interest Groups CiA CANopen SIG Railways CAN for Tachograph Systems J1939-based Serial Control and Communications M3S Network CAN Calibration Protocol Serial Vehicle Network Landwirtschaftliches Bus System (LBS) CANopen Application Profile for Public Transportation CANopen Device Profiles for Off-Road Vehicles CANopen Device Profiles for Railways Truck and Buses Agriculture and Forestry Wheelchairs Passenger Cars Truck and Buses Agriculture and Forestry Driver and Passenger Information Mobile Machinery Passenger-Trains and Cargo-Trains ISO TC22 SC3 WG1 TF2 ISO TC22 SC3 WG1 TF5 (SAE) ISO TC22 SC3 WG1 TF4 CAN Low-Speed Transceiver + Application Layer Diagnostics on CAN OBDII Diagnostics Truck & Trailer
Automotive Automotive
More:
http://www.can-cia.de/NS.htm (1 von 2) [14.11.1999 13:13:35]
CAN in Automation CAN Kingdom New Work Item Proposal Kvaser/CANHUG ISO TC22 SC3 WG1 (OSEK Group) Application Layer and Profiles OSEK-NM, OSEK-COM Off-Road Vehicles and General Purpose Automotive
CAN-Related Standards for Industrial Automation and General Purpose Control Systems
WD 15745-2 DS-201...207 PrEN50325-4 (DS-301) DSP-302 WD-304 DSP-4XX, WD-4XX FDIS 62026-3 FDIS 62026-5 PrEN 50325-2 PrEN 50325-3 DeviceNet Release 2.0 SDS Version 2.0 NMEA 2000 WDP-3XX CDA 101 ODVA Honeywell National Marine Electronics Association CiA IG Maritime Application Target Reliance Office of DoD CLC TC 65CX CiA CANopen SIG Programmable Devices CiA CANopen SIG Safety CiA CANopen Special Interest Groups IEC TC17B WG3 CANopen Framework for Programmable Devices CANopen Framework for Safety-relevant Systems CANopen Device Profiles for Industrial Control DeviceNet Specification SDS Specification DeviceNet Specification SDS Specification DeviceNet Specification SDS Specification J1939-based Application Layer CANopen Framework for Maritime Application CAN Kingdom-based Data Layer Industrial Automation Industrial Automation Navigation Systems Marine Target Control Systems in US Navy, USAF and Army Low-voltage switchgear and controlgear General Purpose Safety-relevant Systems Industrial Automation and General Purpose Low-voltage switchgear and controlgear ISO TC184 SC5 WG 5 CiA IG CAL CLC TC 65CX/CiA IG CANopen Application Framework for CAN-based Networks CAN Application Layer CANopen Communication Profile Industrial Automation General Purpose General Purpose
More:
To get more information you can visit the following Web sites:
CAN | CAL | CANopen | CEN | CENELEC | CiA | IEC | ISO | ODVA

http://www.can-cia.de/NS.htm (2 von 2) [14.11.1999 13:13:35]
CAN in Automation
Press Releases 1999

Page contents: CAN Sales Figures 6th international CAN Conference Worldwide unique Manufacturer Name for CANopen Certified CANopen Products ISO 11898 under Review CANopen Version 4.0 with enhanced features CANopen SIG Safety CANopen SIG Hydraulics CANopen Devices for Railways CANopen SIG Maritime Electronics CiA: 320 Members Worldwide CANopen in Railways CANopen in Off-Road Vehicles CiA Study Groups CAN-based Higher Layer Protocol Standardization CiA In-house Seminars Framework for Programmable CANopen Devices
News
More:
Hot News CiA News CAN Newsletter Standardization
Page contents:
Top CAN Sales Figures 6th iCC Unique CANopen Name Certified CANopen Products ISO 11898 under Review CANopen Version 4.0 CANopen SIG Safety CANopen SIG Hydraulics CANopen for Railways CANopen SIG Maritime CiA: 320 Members CANopen in Railways Off-Road Vehicles CiA Study Groups Higher Layer Protocol CiA In-house Seminars DSP-302 Version 2.0
CAN Sales Figures
Erlangen, 1999-07-21. CiA has accumulated the entire CAN protocol controller manufacturers sales figures for 1998 and their estimations for the next years. Compared with the last years survey you can see that the result for 1998 is higher than expected, 97 millions instead of 59.8 millions. These
http://www.can-cia.de/NP.htm (1 von 14) [14.11.1999 13:13:53]
CAN in Automation
figures are very conservative, because CiA did not consider sales figures from CAN chip manufacturers, which did not respond to the questionnaire. Sales figures for 2000 and the following years do not include all expected CAN nodes in cars produced in USA and Far East. Also not included are new application fields such as domestic appliances and other high-volume embedded systems. By beginning of this year, there were installed more than 140 millions of CAN controllers. 6th international CAN Conference Erlangen (Germany), 1999-07-05. From 2nd to 5th November, CAN in Automation (CiA) international users and manufacturers group is organizing the 6th international CAN Conference (iCC) in Torino (Italy). The iCC is accompanied by workshops and seminars as well as a table-top exhibition with more than 35 companies participating. In addition, there will be poster sessions and product presentations. Entrance to the exhibition, poster and product presentations is free. This most important event for the CAN community is sponsored by the Jackson group, an Italian publishing house, and several CAN chip suppliers (Hitachi, Infineon, Mitsubishi, Motorola, and NEC). Detailed iCC Program Worldwide unique Manufacturer Name for CANopen Erlangen (Germany), 1999-07-05. The recently published CANopen specification version 4.0 requires a worldwide unique manufacturer name. The CAN in Automation (CiA) international users and manufacturers group manages these names that identify uniquely a CANopen module. CiA Headquarters located in Erlangen (Germany) assigns these names on request; the price for non-members is 128 Euro (for CiA members this service is free of charge). CANopen version 4.0 is submitted for European standardization and is also the base for the work item on passenger information system for public transportation. Originally developed for industrial control, CANopen is now also used in off-road vehicles, medical equipment, maritime applications and in railways. Certified CANopen Products Erlangen (Germany), 1999-07-05. The first CANopen devices have passed the CiA Certification for products compliant to
More:
Page contents:
CAN in Automation
CANopen Version 3.0. The CANopen conformance testing specification was developed by CiA Members and implemented by National Instruments and the Technical University of Braunschweig. I/O modules from Beckhoff, the linear position sensor from MTS, the adapter board for Siemens drives from Intulogic, the adapter modules from HMS, and the drive controllers from Yaskawa and Omron have been already tested successfully by the CiA Test Laboratory. The Conformance Testing software is available by CiA, National Instruments, and others. The test tool runs on PC-based hardware, which provides a COTI interface. ISO 11898 under Review Erlangen, 1999-05-17. The regularly required review and update of the ISO 11898 standard will include the features described in the implementation guideline published by Bosch. In addition, the standard will specify different physical layers. Besides the high-speed transceiver, it will describe also a fault-tolerant transceiver. Several clarifications have been included, such as use of DLC, identifier restrictions, and bit timing requirements. The most important optional feature added to the CAN standard will be the time-triggered communication (TTC) option. The new ISO 11898 document will be completely restructured and divided in two parts: ISO 11898-1 specifies the CAN data link layer and the LLC sub-layer, ISO 11898-2 describes the MAU sub-layer of the so-called high-speed transceiver for data rates up to 1 Mbit/s. Later on, the specification of fault-tolerant low-speed physical layer will be added as part 3 (ISO 11898-3). The updated specification is compliant to the CAN Reference Models from Bosch (C Model and VHDL Model). This includes the clarifications described in the Addendum to the Bosch CAN Specification 2.0 A/B. The Data Length Codes (DLC) in the range of 0 to 7 indicate data fields of length of 0 to 7 bytes. All other DLCs indicate that the data field is 8 bytes long. That means, the DLCs in the range of 9 to 15 can be used for application-specific purposes. However, the proper use of remote frames has to be guaranteed by the system designer. Another clarification is that the SRR bit with a dominant value is ignored by the receiving nodes, but not for bit stuffing and arbitration. This is because a dominant value is neither a Bit error, nor a Stuff error, nor a CRC error, nor an Ack error. And, since the SRR bit is located in a stuffed bit field, a SRR bit received as dominant is also not a Form error. Since the SRR
More:
Page contents:
CAN in Automation
bit is received before the IDE bit, a receiver cannot decide instantly whether it receives a RTR or a SRR bit. That means only the IDE bit decides whether the frame is a Standard or an Extended frame. The harmonized CAN standard also clarifies that a dominant bit in the last bit of End of Frame (EOF) field will force the receiver to transmit an Overload frame. The transmitter interprets a dominant value in the last bit of EOF as the start of an Error frame initiated by one of the receivers, transmits itself an Error frame, and retransmits the corrupted message. This is why some message may be transferred doubled. Synchronization rule 4 in the CAN standard requires the Hard Synchronization to be performed at every edge from recessive-to-dominant during Bus Idle. Additionally Hard Synchronization is required for each received Start of Frame (SOF). A SOF can be received not only during Bus Idle, but also during Suspend Transmission and at the end of Intermission. Therefore, the reviewed CAN standard enables the Hard synchronization also for Suspend state and for the end of the Intermission state as the CAN Reference Models do. The restriction regarding the identifier range in the former CAN specifications will be not more valid in the reviewed CAN standard. This means, CAN controller compliant with ISO 11898 may support all identifiers in the range of 0 to 2047. If the IDE bit is recessive, also the other identifiers have to be supported. The reviewed CAN specification specifies an optional Bus Monitoring Mode. In this mode the CAN node is able to receive valid data frames and valid remote frames, but it sends only "recessive" bits on the CAN bus and it cannot start a transmission. If the MAC sub-layer is required to send a "dominant" bit (ACK bit), overload flag, or active error flag, the bit is routed internally, so that the MAC sub-layer monitors this "dominant" bit, although the CAN bus may remain recessive state. This mode can be used for automatic baud-rate detection. The optional time-triggered communication based on CAN (TCC) requires a synchronization of CAN nodes. Any node that supports the TTC option needs to provide a time base. The time base is a cyclic upcounter of at least 16-bit with either an internal or an external clock. Any message received or transmitted invokes a capture of the time base taken at the SOF recognition or at the sample point of the last bit of EOF. These optional hardware functions enable CAN user to transmit a data frame at a specific point of time. This trigger
More:
Page contents:
CAN in Automation
time is programmable. The trigger generation should be freely programmable by the CPU in the range of at least 0 to (216 1) x timer clocks. In order to achieve high accuracy - maximum 1 time quantum - these mechanisms have to be implemented in silicon. The time-triggered message do not compete with others to access the bus, because the single-shot option (disabling of automatic retransmission after error detection) guarantees that the next time-slot is not used by retransmitted frames. Of course, an application using the time-triggered communication based on CAN requires additional specification, but these are related to so-called higher layer protocols. Such protocols have to be developed and will be different for different application fields. CANopen Version 4.0 with enhanced features Erlangen, 1999-05-17. In summer 1999, CiA Interest Group CANopen is going to release the version 4.0 of the CANopen Communication Profile. It specifies some new functions such as timer-driven PDO transmission, SDO block transfer, and heartbeat message. Besides these functional enhancements, the profile describes also all used functions of the CAN Application Layer (CiA DS-201 to DS-207) except the Layer Management (LMT). The CiA DS-301 Version 4.0 document is completely restructured and meets the requirements of Cenelec. This is, because this specification is going to be submitted for European standardization as part 4 of the prEN 50325 (ISO 11898-based Controller-device interfaces) standard. The specification includes models for devices, communication services as well as the reference model according to ISO 7498. The physical layer chapter recommends bit rates and corresponding bit timing settings, and it gives some hints to design a physical CANopen network. In addition, CiA will publish the CiA DRP-302-1 CANopen Recommendation for cable and connector pin assignment. One of the most important changes to the version 3.0 is the inclusion of all CAL specifications required by CANopen. So the CANopen application layer chapter describes data types and encoding rules. The version 4.0 is completely upward compatible to version 3.0. However, in version 4.0 there are some optional functions specified, which do CANopen users and system integrators require. One of the missing features was a timer-driven Process Data Object (PDO). In the timer-driven triggering mode, message transmission is either triggered by the
More:
Page contents:
CAN in Automation
occurrence of an object-specific event or if a specified time has elapsed without occurrence of an event. The time is described in the PDO communication parameter set and it can be configured via Service Data Objects (SDO). Optionally a segmented communication can be transmitted with SDO Block Download or SDO Block Upload. These may be used to achieve higher bus throughputs. In the standard SDO download and upload services each segment is confirmed. In the SDO block services the Initiate SDO Block message is confirmed. It is followed by a block of segments, which is confirmed by only one message. The maximum number of segments per block is 128. In order to verify the correctness of a SDO block transfer, client and server calculate a CRC sequence (Cyclic Redundancy Checksum), this is exchanged and verified within the confirmed End SDO Block message. The check polynominal can be calculated from a formula or a table given in the CANopen specification. One of the minor changes is the renaming of the Prepared State into Stopped State. In the Stopped State, a device is forced to stop communication objects. It can only receive Network Management Objects, and it can perform node guarding, if active. This state can be used to achieve certain application behavior specified by device profiles. The new Boot-up Protocol is used to signal that a NMT slave has entered the node state Pre-operational after the state Initializing. The Boot-up message uses the same identifier as the Error Control Protocols, and contains one data byte with the fixed value of zero. Version 4.0 specifies two Error Control Protocols: The already used Node Guarding Protocol and the new Heartbeat Protocol. One of these protocols has to be supported. The Heartbeat Protocol defines an Error Control Service without need for remote frames. A Heartbeat Producer transmits a Heartbeat message cyclically. One or more Heartbeat Consumer receive the indication. The relationship between producer and consumer(s) is configurable via the object dictionary. The Heartbeat Consumer guards the reception of the Heartbeat within the Heartbeat Consumer Time. If the Heartbeat is not received within the Heartbeat Consumer Time, a Life Guarding Event will be generated. If the Heartbeat Producer Time is configured on a device, the Heartbeat Protocol starts immediately. If a device begins with a value for the Heartbeat Producer Time unequal to 0 the Heartbeat Protocol starts on the state transition from Initializing to Pre-operational. In this case, the Boot-up message is regarded as first Heartbeat message. It is not allowed for one device to use both control mechanisms,
More:
Page contents:
CAN in Automation
Guarding Protocol and Heartbeat Protocol, at the same time. If the Heartbeat Producer Time is unequal 0, the Heartbeat Protocol is used. It is recommended to use the Heartbeat Protocol in order to avoid remote frames. In order to reduce configuration effort for simple CANopen networks, a mandatory default identifier allocation scheme is defined. These identifiers are available in the Pre-operational state directly after the first initialization. If the device provides parameter storage capability, after configuration the identifiers may be changed permanently. In this case, only after Reset Communication the identifiers are set to their default values. The identifiers for Sync, Time stamp, and Emergency messages as well as for PDOs may be modified by means of dynamic distribution. Of course, a device has to provide the corresponding identifiers only for the supported communication objects. The identifiers for the NMT message, the Default SDO, and the NMT Error Control message must not be changed. The default ID allocation scheme consists of a functional part, which determines the object priority and a Node-ID-part, which allows distinguishing between devices of the same functionality. This allows a peer-to-peer PDO communication between a single master and up to 127 slave devices. It also supports the broadcasting of unconfirmed NMT objects, Sync, and Time-stamp message. In version 4.0, the pre-defined connection set supports at maximum 4 Receive-PDOs and 4 Transmit-PDOs. The CANopen Framework for Safety-Relevant Communication reserves the identifier range from 257 to 384 for safety-relevant data objects specified. Using CANopen in that different application fields, such industrial control, off-road vehicles, medical equipment, building automation, maritime electronics, railways, and even in omnibuses, requires some more data types and emergency error codes. The version 4.0 specifies now also the data types Unsigned24, -40, -48, -56 and -64 as well as Integer24, -40, -48, -56 and -64. In the case of device internal failure detection, the device may transmit an Emergency message. The Emergency object transmits the error code. The reviewed CANopen communication profile specifies some more codes, in particular those reporting failures and problems of the CAN controller. The error code 8110 signals CAN overrun meaning lost of frame. That a node has switched from active in passive error mode is indicated by error code 8120. This is to inform others that network-wide data consistency is not more guaranteed. The switch from passive into active error mode is
More:
Page contents:
CAN in Automation
indicated by the error code 8140. The error code 8130 is transmitted, if a node recovers from bus-off state. CANopen SIG Safety Erlangen, 1999-05-17. The CANopen Special Interest Group (SIG) Safety is specifying a CANopen Framework for Safety-relevant Systems. In the first proposal, Safety-Relevant Data Objects (SDRO) are defined that are made by two PDOs with COB-Ids differing in two identifier-bits. The data content of the second PDO is bit-wise inverted. This serial redundancy should avoid a redundant CANopen network. In addition, each SDRO is assigned with a configurable time-out. The receiving nodes will switch to a failsafe state, if the SDRO is not correctly received within the configured time. In addition, the framework will specify so-called global emergency switch messages transmitted in broadcast. The framework will also specify to use only the new heartbeat error control mechanism. CANopen SIG Hydraulics Erlangen, 1999-05-17. The recently established CANopen SIG Hydraulics is working on the CANopen Device Profile for Proportional Hydraulic Valves based on the bus-independent VDMA-Profile. Later, the CiA WD-408 device profile will describe also hydraulic drives. The work draft proposal already available for CiA members describes the application object attributes, and defines the default mapping of the Process Data Objects (PDO). The profile covers very simple valves as well as more intelligent devices providing position or pressure control functionality. CANopen Devices for Railways Erlangen, 1999-05-17. The Task Forces of the CANopen SIG Railways have started to develop CANopen device profiles for brake control, door control, and gateways to train-buses, such as WTB and EBAS. All these profiles are based on the corresponding UIC specifications. The CANopen device profile for door control is nearly ready; and it will also cover omnibus door controllers. The CANopen coach/trainbus gateway will be suitable for cargo trains as well as passenger trains including tramways, metros, and any other light trains. The CANopen SIG Railways will coordinate the work on device profiles and will establish further TFs (e.g. for air-conditioning) if required.
More:
Page contents:
CAN in Automation
CANopen SIG Maritime Electronics Erlangen, 1999-05-17. The CANopen SIG Maritime Electronics was established in April. The scope of the group is the specification of a CANopen Framework for Maritime Applications. It will specify additional network management functionality as well as implementation guidelines for redundant CANopen networks. In addition, the SIG will define maritime-specific device profiles, in particular gateways to maritime-specific subsystems such as engine control, fire-fighting systems, etc. The publication of the CANopen framework is scheduled for end of this year. CiA: 320 Members Worldwide Erlangen, 1999-01-12. The CAN in Automation (CiA) international users and manufacturers group, founded in 1992, was joined by 320 companies and non-profit institutes (1999, January 1st). The trade organization promotes the CAN (Controller Area Network) serial bus system. Besides general marketing activities, CiA Headquarters organize technical conferences, workshops, and in-house seminars. Members of the non-profit association specify higher-layer protocols such as CAL (CAN Application Layer) and CANopen as well as additional physical layer recommendations, e.g. baud-rates, bit-timings, and pin assignments of connectors. In the CiA Office located in Erlangen (Germany), seven secretaries provide worldwide technical, marketing and product information intelligence. (Remark: daughter companies and subsidiaries are automatically CiA Members and will not be counted separately). CANopen in Railways Erlangen, 1999-01-12. The CAN in Automation (CiA) international users and manufacturers group has established the CANopen Special Interest Group (SIG) Railways. This group coordinates the standardization of CANopen Device Profiles for railway applications. The profile specification will be done in several Task Forces. The SIG has established Task Forces for traction, brake, and door control. It is intended to submit CANopen profile specifications to European standardization bodies. CANopen in Off-Road Vehicles
More:
Page contents:
CAN in Automation
Erlangen, 1999-01-12. On behalf of the VDMA (Verband Deutscher Maschinen- und Anlagenbauer) working group for building machine, the University of Magdeburg has pre-developed some CANopen Device Profiles. The profiles for diesel engine, electronic gear, joystick, slope control, and hydraulics were handed over to the CAN in Automation (CiA) international users and manufacturers group in order to review these documents and to become CiA standards. The hydraulics profile should be harmonized with the bus-independent profile framework developed by the VDMA working group for fluid control. Beginning of February, CiA is going to establish related CANopen SIGs (Special Interest Groups). CiA Study Groups Erlangen, 1999-01-12. The CAN in Automation (CiA) international users and manufacturers group is calling for Study Groups (SG) on "OSEK and CANopen" as well as "Maritime Electronics". Users of the CANopen Profile Family, especially off-road vehicle manufacturers, bus and truck makers, as well as some industrial device providers requested a standardized operating system interface for CANopen implementation. In passenger cars OSEK-OS is the most successful operating system specification for real-time applications. In the according SG the possibility to combine OSEK-OS and CANopen will be discussed. Several providers of maritime electronics have already used CAN-based network for ship automation. The CiA SG Maritime Electronics will discuss the standardization requirements and the already existing efforts done in the NMEA2000 project. SG meetings are also open for non-members. CAN-based Higher Layer Protocol Standardization Erlangen, 1999-01-12. CAN-based higher layer protocols for industrial and general-purpose control applications are well established. DeviceNet and Smart Distributed System (SDS) are already submitted to IEC and Cenelec in order to become international resp. European standards. CANopen is also submitted for European standardization. The CAN-based J1939 protocol, mainly used in trucks and off-road vehicles, is already SAE standard. The American standard will not be submitted to ISO for international standardization, because the European truck manufacturer will accept J1939 as it is. On the
More:
Page contents:
Top 6th iCC Unique CANopen Name Certified CANopen Products ISO 11898 under Review CANopen Version 4.0 CANopen SIG Safety CANopen SIG Hydraulics CANopen for Railways CANopen SIG Maritime CiA: 320 Members CANopen in Railways Off-Road Vehicles CiA Study Groups Higher Layer Protocol CiA In-house Seminars DSP-302 Version 2.0
More:
CAN in Automation
other hand, there could be an overlapping with the ISO 11992 standard, which is the CAN-based truck-trailer interface. OSEK/VDX, the higher-layer protocol for passenger cars, is not yet submitted to ISO for international standardization. CiA In-house Seminars Erlangen, 1999-01-12. Last year, CiA started to offer in-house seminars on CAN technology. Topics were CAN protocol and implementations, CAN physical layer options, CAN applications, and CAN-based higher-layer protocols. CiA trainers educated several hundred engineers. Due to the success of these in-house seminars and the continuing demands, CiA will also offer this service in 1999. The price for 1-day seminar is 450 EUR plus travel and hotel expenses. Framework for Programmable CANopen Devices Erlangen, 1999-01-12. The CAN in Automation (CiA) international users and manufacturers group has updated the DSP-320 Framework for Programmable Devices. The current version 2.0 includes now chapters, which describe some new management objects such as the NMT start-up, the Slave Assignment, NMT Request. In addition, the CANopen Configuration Manager services were expanded, and the Multiplexor PDO specification was clarified. The DSP-302 specification also introduces some new configuration objects for these Multiplexor PDOs.
Page contents:
More:
Page contents:
Top 6th iCC Unique CANopen Name Certified CANopen Products ISO 11898 under Review CANopen Version 4.0 CANopen SIG Safety CANopen SIG Hydraulics CANopen for Railways CANopen SIG Maritime CiA: 320 Members
CAN in Automation
CANopen in Railways Off-Road Vehicles CiA Study Groups Higher Layer Protocol CiA In-house Seminars DSP-302 Version 2.0
More:
Page contents:
CAN in Automation
More:
Page contents:
More:
CAN in Automation
Page contents:

Can in Automation (Cia) : Higher Layer Protocols (HLP) Can The Bus Cia Members Only

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Can in Automation (Cia) : Higher Layer Protocols (HLP) Can The Bus Cia Members Only

Uploaded by

Copyright:

Available Formats

CAN in Automation (CiA) - Controller Area Network (CAN)

CAN in Automation (CiA)

Higher layer protocols (HLP)

CAN the bus

CiA members only

phone +49-9131-69086-0 fax +49-9131-69086-79 email:headquarters@can-cia.de

http://www.can-cia.de/ [14.11.1999 12:45:51]

Higher Layer Protocols DeviceNet

CAN Application Layer CAN Kingdom

CAN in Automation last update: 1999-07-26

http://www.can-cia.de/hg.htm [14.11.1999 12:46:07]

Data Packets Bus Topology Bus Addressing System Features

http://www.can-cia.de/hdg.htm (1 von 2) [14.11.1999 12:46:16]

CAN in Automation last update: 1999-07-27

http://www.can-cia.de/hdg.htm (2 von 2) [14.11.1999 12:46:16]

http://www.can-cia.de/hdt.htm (1 von 15) [14.11.1999 12:47:01]

http://www.can-cia.de/hdt.htm (2 von 15) [14.11.1999 12:47:01]

Figure 5. Open and Sealed Connectors are available on DeviceNet

http://www.can-cia.de/hdt.htm (3 von 15) [14.11.1999 12:47:01]

http://www.can-cia.de/hdt.htm (4 von 15) [14.11.1999 12:47:01]

http://www.can-cia.de/hdt.htm (5 von 15) [14.11.1999 12:47:01]

Source MAC ID Group 2 Message ID

Group 4 Message 7c0 1 ID 7ef (0 - 2f) 1 11X X X X 6 54 4 3 2 1 7f0 7ff 0

Figure 7 DeviceNet has 4 defined groups

http://www.can-cia.de/hdt.htm (8 von 15) [14.11.1999 12:47:02]

http://www.can-cia.de/hdt.htm (10 von 15) [14.11.1999 12:47:02]

http://www.can-cia.de/hdt.htm (13 von 15) [14.11.1999 12:47:02]

Message Router DeviceNet Connection Assembly Parameter Presence Sensing

1 1 2 (one explicit, one I/O) 1 1 (optional) 1

http://www.can-cia.de/hdt.htm (14 von 15) [14.11.1999 12:47:02]

CAN in Automation last update: 1999-10-29

http://www.can-cia.de/hdt.htm (15 von 15) [14.11.1999 12:47:02]

CAN related standards

http://www.can-cia.de/lsm.htm (1 von 3) [14.11.1999 12:47:19]

CAN Standards CAL Standards CANopen Standards Literature Order Form

http://www.can-cia.de/lsm.htm (2 von 3) [14.11.1999 12:47:19]

http://www.can-cia.de/lsm.htm (3 von 3) [14.11.1999 12:47:19]

CAN 2.0 Part A

http://www.can-cia.de/lsc.htm (1 von 2) [14.11.1999 12:47:29]

CAN 2.0 Part B

CAN 2.0 Addendum

http://www.can-cia.de/lsc.htm (2 von 2) [14.11.1999 12:47:29]

CAN Application layer

http://www.can-cia.de/lsa.htm (1 von 5) [14.11.1999 12:48:02]

http://www.can-cia.de/lsa.htm (4 von 5) [14.11.1999 12:48:02]

http://www.can-cia.de/lsa.htm (5 von 5) [14.11.1999 12:48:02]

http://www.can-cia.de/lso.htm (3 von 6) [14.11.1999 12:49:58]

http://www.can-cia.de/lso.htm (4 von 6) [14.11.1999 12:49:58]

http://www.can-cia.de/lso.htm (6 von 6) [14.11.1999 12:49:58]

Literature Order Form CiA Standards (in English):

http://www.can-cia.de/Lo.htm (1 von 4) [14.11.1999 12:50:33]

Standards (in English)

Proceedings (in English)

http://www.can-cia.de/Lo.htm (2 von 4) [14.11.1999 12:50:33]

CAN Literature (in German)

CAN Literature (in English)

CAN Literature (in Franais)

http://www.can-cia.de/Lo.htm (3 von 4) [14.11.1999 12:50:33]

Name: Company: Street: ZIP: City: Country: Phone: Fax: E-Mail:

http://www.can-cia.de/Lo.htm (4 von 4) [14.11.1999 12:50:33]

CAN Physical Layer for Industrial Applications DS 102 V2.0

CANopen Cabling and Connector Pin Assignment DR 303-1 V1.0

CANopen Representation of SI Units and Prefixes DR 303-2 V1.0

Kit 3: CT Software Kit 4: CT Software