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

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 CAN Information in marketing information with the aim of fostering Controller Area Dutch Network’s 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.

Higher layer CAN the bus CiA members protocols (HLP) only - General introduction - General introduction - CiA specifications - Specifications - CANopen - Technical info - Controller - Devicenet - Marketing info - Applications - CAN Kingdom

Events Standardization Products CiA phone +49-9131-69086-0 fax +49-9131-69086-79 Literature Download News email:[email protected]

http://www.can-cia.de/ [14.11.1999 12:45:51] CAN in Automation Higher Layer Protocols HLP DeviceNet CANopen

General introduction General introduction

Technical introduction Technical introduction

Specifications Specifications

Conformance test Conformance test

FAQs FAQs

Vendor list

CAN Application Layer CAN Kingdom

General introduction General introduction

Technical introduction Technical introduction

Specifications Specifications

http://www.can-cia.de/hg.htm [14.11.1999 12:46:07] CAN in Automation General introduction DeviceNet Page contents:

Features and functionality More: First information Technical introduction Features and functionality Specifications Network Up to 64 nodes Conformance test Size FAQs Network Selectable end-to-end network distance varies with speed Length Page contents:

Top Baud Rate Distance Features and 125 Kbps 500 m (1,640 ft) functionality First information 250 Kbps 250 m (820 ft)

500 Kbps 100 m (328 ft) Data 0-8 bytes Packets Bus Linear (trunkline/dropline); power and signal on the same Topology network cable Bus Peer-to-Peer with Multi-Cast (one-to-many); Multi-Master and Addressing Master/Slave special case; polled or change-of-state (exception-based) More: System Removal and replacement of devices from the network under Features power Technical introduction First information Specifications Conformance test DeviceNet is a low-cost communications link to connect industrial FAQs 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 Page contents: and eliminate expensive hardwiring. Top The direct connectivity provides improved communication between Features and devices as well as important device-level diagnostics not easily functionality accessible or available through hardwired I/O interfaces. First information 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

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 More: Vendor Association, Inc. (ODVA) for a nominal reproduction charge. Any company that manufactures (or intends to manufacture) Technical DeviceNet products may join ODVA and participate in technical introduction working groups that are developing enhancements to the DeviceNet Specifications Specification. Conformance test Buyers of the DeviceNet Specification receive an unlimited, FAQs 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 Page contents: many sources. The key hardware components are available from the largest worldwide suppliers of semiconductors. Top Features and Why the DeviceNet Communication Link? functionality First information 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 More: considerably in recent years, making it cost-effective to connect simple Technical devices never considered for SP50 fieldbus directly to a network. Such a standard for simple devices requires the same level of introduction interchange-ability as exists for 120/220 VAC and 24 VDC discrete, Specifications hardwired I/O. DeviceNet allows the interchangeability of simple Conformance test devices while making interconnectivity of more complex devices FAQs 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 Page contents: drives, or to count the number of packages that have passed on a conveyor in the previous hour. Top Features and © ODVA - The Open DeviceNet's Vendor Association functionality First information

http://www.can-cia.de/hdg.htm (2 von 2) [14.11.1999 12:46:16] CAN in Automation Technical introduction DeviceNet Page contents:

Physical Layer and Media More: Indicators and Configuration Switches General introduction Communication Protocol and Application Specifications The Object Model Conformance test Messaging FAQs Predefined Master/Slave Connection Set Device Profiles Page contents: Physical Layer and Media Top Chapter 9, Volume 1 in the DeviceNet Specifications defines the Physical Layer and allowable Topologies and components. The variety of Topologies Media that are possible is shown in Figure 2. The specification also deals Indicators and with system grounding, mixing thick and thin media, termination, Configuaration Switches and power distribution. Communication Protocol and Application The basic trunkline-dropline Topology provides separate twisted pair The Object Model busses for both signal and power distribution. Thick or thin cable can Messaging be used for either trunklines or droplines. End-to-end network Predefined Master/Slave distance varies with data rate and cable size. Connection Set Device Profiles Data Rates 125 Kbps 250 Kbps 500 Kbps

Thick Trunk Length 500 m 250 m 100 m (1,640 ft) (820 ft) (328 ft) Thin Trunk Length 100 m 100 m 100 m (328 ft) (328 ft) (328 ft) More: Maximum Drop Length 6 m 6 m 6 m (20 ft) (20 ft) (20 ft) General introduction Cumulative Drop Length 156 m 78 m 39 m Specifications (512 ft) (256 ft) (128 ft) Conformance test FAQs 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 Page contents: same bus cable. Other CAN-based networks allow only a single power supply (if at all) for the entire network. Top Physical Layer and Media Indicators and Configuaration Switches Communication Protocol and Application The Object Model Messaging Predefined Master/Slave Connection Set Device Profiles

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

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

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 A simplified block diagram of transceivers with both isolated and Device Profiles 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:

General introduction Specifications Conformance test FAQs

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

http://www.can-cia.de/hdt.htm (3 von 15) [14.11.1999 12:47:01] CAN in Automation contains information on how to use these cable and connector Page contents: components to construct single and multi-port taps. Top Indicators and Configuration Switches Physical Layer and Media Although DeviceNet does not require a product to have indicators, if Indicators and a product does have indicators, it must adhere to the DeviceNet Configuaration Switches Specification. It is recommended that either a Module Status LED Communication Protocol and a Network Status LED, or the combined Module Status/Network and Application Status LED be included. The Object Model Messaging The indicator(s) consist of bi-color (green/red) LEDs, which can Predefined Master/Slave have combinations of on, off or flashing. The Module Status LED Connection Set indicates whether or not the device has power and is operating Device Profiles properly. The Network Status LED indicates the status of the communication link.

Communication Protocol and Application More:

Chapters 3, 4 and 5, Volume 1 of the DeviceNet Specification General introduction defines the DeviceNet Communication Protocol. These chapters deal Specifications with connections, messaging protocol, and the communications related objects respectively. Conformance test FAQs 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. Page contents: A library of objects is contained in Chapter 6, Volume II of the DeviceNet Specifications. A library of Device Profiles is contained Top in Chapter 3, Volume II of the DeviceNet Specifications. ODVA Physical Layer and coordinates the work of industry experts in the development of both Media new Object and Device Profile Specifications. This is done through Indicators and Special Interest Groups (SIG). Configuaration Switches Communication Protocol DeviceNet supports strobed, polled, cyclic, change-of-state and and Application application-triggered data movement. The user can choose The Object Model master/slave, multi-master and peer-to-peer or a combination Messaging configuration depending on device capability and application Predefined Master/Slave requirements. The choice of data movement can significantly speed Connection Set up system response time. One popular application for DeviceNet is Device Profiles 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.

http://www.can-cia.de/hdt.htm (4 von 15) [14.11.1999 12:47:01] CAN in Automation To establish a connection, each DeviceNet product will implement either an Unconnected Message Manager (UCMM) or an More: Unconnected Port. Both perform their function by reserving some of the available CAN identifiers. The UCMM is described in detail in General introduction Chapter 4, Volume 1 of the DeviceNet Specification, and the Specifications Unconnected Port is described in Chapter 7, Volume 1. Conformance test When either the UCMM or the Unconnected Port is used to establish FAQs 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, Page contents: 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 Top 11-bit CAN identifier. Everything else is data. Physical Layer and Media The 11-bit CAN identifier is used to define the connection ID. Indicators and DeviceNet divides the 11-bit CAN identifier into four groups. The Configuaration Switches first three defined groups contain two fields, one 6-bit field for MAC Communication Protocol ID and the other for Message ID. The combined fields define the and Application connection ID. Figure 7 shows message groups definitions. Group The Object Model four messages are used for offline communications. Messaging Predefined Master/Slave Devices may be Clients or Servers or both. Clients and Servers may Connection Set be producers, consumers or both. In a typical Client device, its Device Profiles 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 More: Cyclic or Change-of-State messages. Similarly, some connections in either a Client or Server may only produce messages. These General introduction connections would be the source for Cyclic or Change-of-State Specifications messages. The use of Cyclic and Change-of-State connections can Conformance test substantially reduce bandwidth requirements. FAQs 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

http://www.can-cia.de/hdt.htm (5 von 15) [14.11.1999 12:47:01] CAN in Automation networks. Page contents: Another key benefit to nodes managing their identifiers is that a user Top can add and delete nodes and/or add additional peer-to-peer Physical Layer and messages among existing nodes at any time without having Media knowledge of the existing set-up. No centralized record must be Indicators and located or reconstructed. Since nodes know, which IDs are already in Configuaration Switches use, a tool simply has to request an I/O connection be added between Communication Protocol the two devices, specifying priority level, the data path (class, and Application instance, attribute) and the production trigger (cyclic, poll, or The Object Model change-of-state). Messaging Predefined Master/Slave Identifier Bits Hex Identity Connection Set 10 9 8 7 6 5 4 3 2 1 0 Range Usage Device Profiles Group 1 Source MAC ID 000 - Message 0 Message ID 3ff Group 1 Group 2 400 - Message 1 0 MAC ID Message More: 5ff Group 2 ID General introduction Group 3 Source MAC ID 600 - Message Specifications 1 1 Message 7bf Group 3 Conformance test ID FAQs Group 4 Message 7c0 - Message 1 1 1 1 1 ID 7ef Group 4 (0 - 2f) Page contents: Invalid 7f0 - 1 1 1 1 1 1 1 X X X X CAN Top 7ff Identifiers Physical Layer and Media 10 9 8 7 6 5 4 4 3 2 1 0 Indicators and Configuaration Switches Communication Protocol Figure 7 DeviceNet has 4 defined groups and Application The Object Model Messaging Predefined Master/Slave The Object Model Connection Set Device Profiles 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

http://www.can-cia.de/hdt.htm (6 von 15) [14.11.1999 12:47:02] CAN in Automation another on a DeviceNet network. The ranges of the four addressing components are shown in the following table: More: Address Lowest Highest Node 0 63 General introduction Specifications Class 1 65535 Conformance test Instance 0 65535 FAQs Attribute 1 255

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

Typical object classes found in a DeviceNet Product Object Class Specification Object Class Name More: Number Reference Vol II, Rel 1.2, 1 Identity General introduction page 6-3 Specifications Vol II, Rel 1.2, Conformance test 2 Message Router page 6-17 FAQs Vol I, Rel 1.3, 3 DeviceNet page 5-50 Vol II, Rel 1.2, 4 Assembly page 6-25 Vol I, Rel 1.3, 5 Connection page 5-6 Vol II, Rel 1.2, 6 Parameter page 6-95

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

http://www.can-cia.de/hdt.htm (7 von 15) [14.11.1999 12:47:02] CAN in Automation VendorID, a Device Type, a Product code, a revision, a status, a Page contents: serial number, a productname, and a state. The required services would be Get_Attribute_Single and a Reset. Top Physical Layer and Message Router Object - Vol II, Rel 1.2, page 6-17 Media A DeviceNet product will typically have a single instance (Instance Indicators and #1) of the Message Router Object. The Message Router Object is the Configuaration Switches component of a product that passes Explicit Messages to the other Communication Protocol Objects. It Generally does not have any external visibility over the and Application DeviceNet network. The Object Model Messaging DeviceNet Object - Vol I, Rel 1.3, page 5-50 Predefined Master/Slave A DeviceNet product will typically have a single instance (Instance Connection Set #1) of the DeviceNet Object. This instance would have as attributes: Device Profiles 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 More: A DeviceNet product will typical have one or more optional Assembly Objects. The primary purpose of these objects is to group General introduction different attributes (data) from different application objects into a Specifications single attribute, which can be moved with a single message. Conformance test FAQs 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 Page contents: connection between two nodes on a DeviceNet network. These two types of connections are called Explicit Messaging and I/O Top Messaging. Explicit Messages contain Attribute addressing, Physical Layer and Attribute values and a Service Code describing the desired action. Media I/O messages contain nothing but data. In an I/O message, all the Indicators and information about what to do with the data is contained in the Configuaration Switches Connection Object associated with that I/O message. Communication Protocol and Application Parameter Object - Vol II, Rel 1.2, page 6-95 The Object Model The optional Parameter object would be used in devices with Messaging configurable parameters. One instance would be present for each Predefined Master/Slave configurable parameter. The parameter object provides a standard Connection Set way for a configuration tool to access all parameters. Configuration Device Profiles 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.

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

The DeviceNet application layer defines how identifiers are assigned More: (thus controlling priorities), and how the CAN data field is used to General introduction specify services, move data, and determine its meaning. Specifications The way information flows on a communication network is critical. Conformance test Older communication technology consisted of messages that were FAQs 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 Page contents: identifier fields for the data. The identifier provides the means for multiple priority levels (used in arbitration), more efficient transfer Top of I/O data, and multiple consumers. Physical Layer and Media The device with data produces the data on the network with the Indicators and proper identifier. All devices who need data listen for messages. Configuaration Switches When devices recognized the appropriate identifier, they consume Communication Protocol the data. With the producer-consumer model, the message is no and Application longer specific to a particular source or destination. A single The Object Model message from one controller can be used by multiple motor starters Messaging using less bandwidth. Predefined Master/Slave Connection Set DeviceNet defines two different types of messaging. They are called Device Profiles 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 More: typically use high priority identifiers. I/O messages contain no protocol in the 8-byte data field. The only exception is for General introduction fragmented I/O messages where one byte is used for fragmentation Specifications protocol. The meaning of the message is implied by the connection Conformance test ID (CAN identifier). Before messages are sent using these IDs, both FAQs 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

http://www.can-cia.de/hdt.htm (9 von 15) [14.11.1999 12:47:02] CAN in Automation protocol overhead. There is no limit on the number of fragments. Page contents: Fragmentation is also defined for explicit messaging. This flexibility assures that as more sophisticated devices are introduced and more Top capabilities are designed into devices, they can be added to existing Physical Layer and DeviceNet networks. With its object-oriented design and addressing Media scheme, DeviceNet is unlimited in its ability to be expanded without Indicators and having to alter the basic protocol and connection model. Configuaration Switches Communication Protocol On the other end of the spectrum, a simple slave device application and Application with two message connections (one I/O and one explicit) can be The Object Model handled in less than 4K ROM and 175 bytes of RAM (Motorola Messaging 68HCO5X4, a CPU with a built-in CAN interface). Predefined Master/Slave Connection Set The General format for I/O messages is shown in figures 9-12 Device Profiles

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

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

General introduction Specifications Conformance test FAQs

Page contents:

Top Physical Layer and Predefined Master/Slave Connection Set Media Indicators and While DeviceNet provides a powerful Application Layer Protocol Configuaration Switches that allows dynamic configuring of connections between devices. It Communication Protocol has been recognized that some devices will have neither the need nor and Application the resources to use this powerful capability. For this reason, a set of The Object Model connection identifiers known as the Predefined Master/Slave Messaging Connection Set has been specificed to simplify the movement of I/O Predefined Master/Slave Connection Set and configuration-type data typically seen in a Master/Slave Device Profiles 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 More: require output data and configuration data. The Predefined Master/Slave Connection Set meets these needs by providing General introduction connection objects that are almost entirely configured at the time the Specifications device powers-up. The only remaining step necessary to begin the Conformance test flow of data is for a master device to claim ownership of this FAQs 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

http://www.can-cia.de/hdt.htm (11 von 15) [14.11.1999 12:47:02] CAN in Automation devices to take advantage of hardware filtering. Another important Page contents: benefit is that the establishment of connections from the Predefined Set is simplified considerably. Only a few messages are required to Top have I/O connections up and running. The Predefined Set contains Physical Layer and one explicit messaging connection and allows several different I/O Media connections including Bit Strobed Command/Response, Indicators and Change-of-State and Cyclic. Chapter 7, Volume I contains detailed Configuaration Switches information about the Predefined Master/Slave Connection Set. Communication Protocol and Application Change-of-State and Cyclic Transmission The Object Model With change-of-state, a device produces its data only when it Messaging changes. To be sure the consuming device knows that the producer is Predefined Master/Slave still alive and active, DeviceNet provides an adjustable, background Connection Set heartbeat rate. Devices send data whenever it changes or the Device Profiles 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 More: heartbeat, the controller is not burdened with having to send a nuisance request periodically just to make sure it is still there. This General introduction becomes even more efficient in the multicast case. Specifications Conformance test The cyclic option can reduce unnecessary traffic and packet processing. Instead of a temperature or analog input block being FAQs 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 Page contents: update time could have its cyclic rate set to 500 ms. Not only would Top this preserve bandwidth for more rapidly changing critical I/O data, Physical Layer and it would also be more accurate as well. For example, it might be Media scanned once every 30 ms as part of a large scan list with many bytes Indicators and of data per node on a heavily loaded master. This means that data Configuration Switches used in a PID calculation might have been sampled anywhere from Communication Protocol 470 to 530 ms. With cyclic production you know that the data and Application samples will be at precisely 500 ms. The Object Model Messaging By default, both change of state and cyclic are acknowledged Predefined Master/Slave exchanges (ACKs) so that the producer knows its intended Connection Set consumer(s) received the data. For applications where changes of Device Profiles 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

http://www.can-cia.de/hdt.htm (12 von 15) [14.11.1999 12:47:02] 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 More: logging. For alarm monitoring, it is important that a change-of-state not be General introduction missed, so the OI device would be included in the device's ACK list, Specifications assuring a retry (or several retries) if for some reason the OI missed Conformance test the message. On the other hand, if it was primarily a data collection FAQs 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 Page contents: one 300 ms later. Top Cyclic and change-of-state from the master is defined and selectable Physical Layer and on a per node basis. Media Indicators and Device Profiles Configuration Switches Communication Protocol The DeviceNet specification goes beyond a physical connection and Application protocol specification. It promotes interoperability by defining The Object Model standard device models. All devices of the same model must support Messaging common identity and communication status data. Device-specific Predefined Master/Slave data is contained in device profiles that are defined for various Connection Set device types. Simple devices (e.g. push buttons, motor starters, Device Profiles 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: More: ● Definition of the device's object model - This often contains a drawing like the one shown in the object General introduction model (figure 8). Usually there are tables, which list all of the Specifications object classes present in the device, the number of instances in Conformance test each class, how each object effects behavior, and the public FAQs interfaces to each object. ● 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. ● 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

http://www.can-cia.de/hdt.htm (13 von 15) [14.11.1999 12:47:02] CAN in Automation Message Router 1 Page contents: DeviceNet 1 Top Connection 2 (one explicit, one I/O) Physical Layer and Assembly 1 Media Indicators and Parameter 1 (optional) Configuration Switches Presence Sensing 1 Communication Protocol and Application The DeviceNet specification defines an Electronic Data Sheet The Object Model (EDS), which is a simple file format that allows product-specific Messaging information to be made available by vendors for all other vendors. Predefined Master/Slave This makes possible user-friendly configuration tools that can be Connection Set easily updated without having to constantly revise the configuration Device Profiles software tool. In order not to restrict enhancements, a means is also provided for addition of vendor specific, value-add options. The DeviceNet More: specification has public classes, services and attributes, which are defined in the DeviceNet specification and vendor-specific classes, General introduction services and attributes, which can be added by individual vendors. Specifications This allows vendors to provide additional functions to their Conformance test customers that are not covered in the specification. As FAQs vendor-specific items become more popular or commonplace, the mechanism to transition them to public items will be provided. © ODVA - The Open DeviceNet's Vendor Association 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

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

General introduction Specifications Conformance test FAQs

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

http://www.can-cia.de/hdt.htm (15 von 15) [14.11.1999 12:47:02] CAN in Automation CAN related standards CiA Standards Page contents: More:

DS 102 V2.0 CAN Standards DS 150 V1.1 CAL Standards DeviceNet CANopen Standards CAN Kingdom Literature Order CAN Physical Layer for Industrial Applications Form DS 102 V2.0

The scope of this document is, to define the content of the physical Page contents: layer and the basic characteristics of the physical medium, for communication according to the Controller Area Network protocol Top specification (CAN) between different types of electronic modules in DS 102 V2.0 general industrial applications. CAN is a serial communication DS 150 V1.1 protocol supporting distributed real-time control and multiplexing. DeviceNet This part refers to using a differentially driven two-wire bus line CAN Kingdom 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. More: The main features of the CAN Power Management Layer are ● 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,

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 CAN Standards network architecture, CAL Standards ● easy hardware implementation/integration into CAN CANopen Standards peripherial controllers, Literature Order ● coexistance of nodes with and without Power Management Layer support is possible. Form

DeviceNet Page contents: DeviceNet is a low-cost communications link to connect industrial devices (such as limit switches, photoelectric Top sensors, valve manifolds, motor starters, process sensors, bar DS 102 V2.0 DS 150 V1.1 code readers, variable frequency drives, panel displays and DeviceNet operator interfaces) to a network and eliminate expensive CAN Kingdom 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, More: royalty-free license to develop DeviceNet products. Companies looking for assistance may purchase sample code CAN Standards that eases their implementation, development toolkits, and CAL Standards development services from many sources. The key hardware CANopen Standards components are available from the largest worldwide suppliers of semiconductors. Literature Order Form 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

http://www.can-cia.de/lsm.htm (2 von 3) [14.11.1999 12:47:19] CAN in Automation systems. Most networks provide services for connected Page contents: modules. In control networks however, connected modules serve the network. CAN Kingdom takes advantage of this fact, Top making separation of module and system development not DS 102 V2.0 only possible but even simple. DS 150 V1.1 DeviceNet In fact, most papers written on the subject of Controller Area CAN Kingdom 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.

http://www.can-cia.de/lsm.htm (3 von 3) [14.11.1999 12:47:19] CAN in Automation CAN CiA Standards Page contents:

CAN 2.0 Part A More: CAN 2.0 Part B CAL Standards CAN 2.0 Addendum CANopen Standards Related Standards CAN Standard

The acceptance and introduction of serial communication to more and more applications has led to requirements that the Page contents: assignment of message identifiers to communication functions Top be standardized for certain applications. These applications CAN 2.0 Part A can be realized with CAN more comfortably, if the dress range CAN 2.0 Part B that originally has been defined by 11 identifier bits is CAN 2.0 Addendum 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 More: 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 CAL Standards the message format in CAN Specification 1.2 is equivalent to CANopen Standards the standard format and therefore is still valid. Furthermore, Related Standards the extended format has been defined so that messages in

standard format and extended format can coexist within the same network. Page contents:

This CAN Specification 2.0 consists of two parts, with Top CAN 2.0 Part A ● CAN 2.0 Part A CAN 2.0 Part B CAN 2.0 Addendum 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 protocol’s 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 CiA All specifications can be ordered Standards More: Page contents: CAN Standards DS 201 V1.1 - CAN in the OSI Reference Model CANopen Standards DS 202 V1.1 - CAN based Message Specification (CMS) Related Standards DS 203 V1.1 - Network Managment (NMT) DS 204 V1.1 - Distributor (DBT) Literature Order DS 205 V1.1 - Layer Managment (LMT) Form DS 206 V1.1 - Recommended Standard CAL Module Data Sheet

DS 207 V1.1 - Application Layer Naming Conventions Page contents: CAN Application Layer (CAL) for Industrial Applications Top DS 201 V1.1 The Controller Area Network (CAN) is a data communication DS 202 V1.1 network designed to fit distributed real-time control DS 203 V1.1 applications. It was originally developed and applied by the DS 204 V1.1 automotive industry to solve the cabling problem inside DS 205 V1.1 vehicles. However CAN also provides good properties as a DS 206 V1.1 control network for industrial applications. DS 207 V1.1

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 More: network where modules from different suppliers can cooperate in distributed applications. CAN Standards CANopen Standards CAN based Message Specification (CMS) Related Standards DS 202 V1.1 Literature Order This document contains the service and protocol specification Form 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.

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: Page contents: ● DS 202-1 V1.1: CMS Service Specification members only Top DS 201 V1.1 ● DS 202-2 V1.1: CMS Protocol Specification DS 202 V1.1 members only DS 203 V1.1 ● DS 202-3 V1.1: CMS Data Types and Encoding Rules DS 204 V1.1 members only DS 205 V1.1 DS 206 V1.1 CMS is one of the application layer service entities of the CAN DS 207 V1.1 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 More: form of objects and remote services on these objects. This allows other applications to cooperate with it by executing CAN Standards these services that CMS supports on these objects. CANopen Standards Related Standards Network Management (NMT) DS 203 V1.1 Literature Order Form 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 Page contents: that standardize the CAN Application Layer for Industrial Applications. Top DS 201 V1.1 These two parts are in the different documents: DS 202 V1.1 ● DS 203-1 V1.1: NMT Service Specification DS 203 V1.1 members only DS 204 V1.1 DS 205 V1.1 ● DS 203-2 V1.1: NMT Protocol Specification DS 206 V1.1 members only DS 207 V1.1 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

http://www.can-cia.de/lsa.htm (2 von 5) [14.11.1999 12:48:02] CAN in Automation consequence of building a distributed application and must be compared to the advantages of building a distributed application. More:

Distributor (DBT) CAN Standards DS 204 V1.1 CANopen Standards Related Standards This document contains the service and protocol specification of the Distributor (DBT). DBT is part of the CAN Application Literature Order Layer. This document is part of a set of documents that Form standardize the CAN Application Layer for Industrial Applications. These two parts are in the different documents: Page contents: ● DS 204-1 V1.1: DBT Service Specification Top members only DS 201 V1.1 ● DS 204-2 V1.1: DBT Protocol Specification DS 202 V1.1 DS 203 V1.1 members only DS 204 V1.1 The essential issue in creating an open system where DS 205 V1.1 modules from independent suppliers can cooperate via CAN, DS 206 V1.1 DS 207 V1.1 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 More: to the Communication Objects that a module uses. The dynamic distribution does not necessarily take place every CAN Standards time the module is 'powered on'. Depending on the facilities of CANopen Standards the module, distribution may only be required once e.g. when Related Standards the module is installed to the network. Literature Order Layer Management (LMT) Form DS 205 V1.1

This document contains the service and protocol specification Page contents: of the Layer Management (LMT). LMT is part of the CAN Application Layer. This document is part of a set of documents Top that standardize the CAN Application Layer for Industrial DS 201 V1.1 Applications. DS 202 V1.1 DS 203 V1.1 These two parts are in the different documents: DS 204 V1.1 ● DS 205-1 V1.1: LMT Service Specification DS 205 V1.1 members only DS 206 V1.1 DS 207 V1.1 ● DS 205-2 V1.1: LMT Protocol Specification

http://www.can-cia.de/lsa.htm (3 von 5) [14.11.1999 12:48:02] 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. More: The following parameters can be inquired and/or changed by the use of LMT: CAN Standards ● NMT-address of the NMT Service Element, CANopen Standards Related Standards ● bit timing parameters of the physical layer, ● LMT address. Literature Order Form 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 Page contents: Slaves with and without a unique LMT-address or non-volatile storage. Top DS 201 V1.1 Recommended Standard CAL Module Data Sheet DS 202 V1.1 DS 206 V1.1 members only DS 203 V1.1 DS 204 V1.1 This document contains a description of a recommended DS 205 V1.1 standard for a CAL module data sheet. DS 206 V1.1 DS 207 V1.1 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.

http://www.can-cia.de/lsa.htm (4 von 5) [14.11.1999 12:48:02] 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.

http://www.can-cia.de/lsa.htm (5 von 5) [14.11.1999 12:48:02] CAN in Automation CANopen CiA All specifications can be ordered. Standards Page contents: More:

DS 301 V4.0 - Application Layer and Communication Profile CAN Standards DSP 302 V2.0 - Framework for Programmable CANopen Devices CAL Standards DSP 401 V1.4 - Device Profile for I/O Modules Related Standards DSP 402 V1.1 - Device Profile Drives and Motion Control DSP 403 V1.0 - Device Profile Human Machine Interfaces Literature Order Form DSP 405 V1.0 - Device Profile for IEC 1131 Programmable Devices DSP 406 V2.0 - Device Profile for Encoders Page contents:

Application Layer and Communication Profile for Industrial Top Systems DS 301 V4.0 DS 301 V4.0 members only DSP 302 V2.0 DSP 401 V1.4 This document contains the description of the CANopen DSP 402 V1.1 Application Layer and Communication Profile for Industrial DSP 403 V1.0 Applications using CAN as their installation bus. DSP 405 V1.0 DSP 406 V2.0 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] 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: ● The dynamic establishment of SDO connections between devices. Dynamic SDO connections are handled by the SDO Manager. ● The term CANopen Manager is introduced to specify more clearly the network functionality of a network controlling device. More: ● The definition of dynamically allocated entries in an object dictionary, which can be used for the CAN Standards representation of I/O data e.g. on programmable nodes CAL Standards like PLCs. Related Standards ● A general mechanism for downloading program data and Literature Order Form functions for the control of programs on a device. ● A possibility for detecting and configuration of unconfigured nodes during system boot-up by means of Page contents: a Configuration Manager. ● A debugging mechanism in the form of an OS command Top and prompt. DS 301 V4.0 DSP 302 V2.0 ● A multiplexed PDO, which allows to write data of object DSP 401 V1.4 dictionary entries on a group of nodes simultaneously. DSP 402 V1.1 The multiplexed PDO also has non-group applications. DSP 403 V1.0 DSP 405 V1.0 Some of these new mechanisms are also useful not only for DSP 406 V2.0 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.

http://www.can-cia.de/lso.htm (2 von 6) [14.11.1999 12:49:58] 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 More: Intelligent Peripheral Device. CAN Standards Device Profile Drives and Motion Control CAL Standards DSP 402 V1.1 members only Related Standards This document represents the standardized CANopen Device Literature Order Form Profile for digital controlled motion products like servo controllers, frequency converters or stepper motors. Page contents: All the above devices use communication techniques, which conform to those described in the CANopen Application Layer Top and Communication Profile. This document should be DS 301 V4.0 consulted in parallel to this profile. DSP 302 V2.0 DSP 401 V1.4 The starting and sTopping of the drive and several mode DSP 402 V1.1 specific commands are executed by the statemachine. DSP 403 V1.0 DSP 405 V1.0 The operation mode defines the behaviour of the drive. The DSP 406 V2.0 following modes are defined in this profile:

● 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.

http://www.can-cia.de/lso.htm (3 von 6) [14.11.1999 12:49:58] 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:

CAN Standards ● Profile Torque Mode CAL Standards Related Standards In this mode the torque control with all related parameters is described. Literature Order Form

● Velocity Mode Page contents:

Many frequency inverters use this simple mode to Top control the velocity of the drive with limits and ramp DS 301 V4.0 functions. DSP 302 V2.0 DSP 401 V1.4 The Velocity Mode is rather separated from the other modes DSP 402 V1.1 and does not interfere with them so much. For this reason, the DSP 403 V1.0 naming of object dictionary entries differs a little bit from the DSP 405 V1.0 other modes. DSP 406 V2.0 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

http://www.can-cia.de/lso.htm (4 von 6) [14.11.1999 12:49:58] 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 More: Layer and Communication Profile. The additional mechanisms specified in the framework are useful especially for devices CAN Standards such as PLCs, very intelligent HMI or CANopen tools. CAL Standards These documents should be consulted in parallel to this Related Standards profile. Literature Order Form 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. Page contents:

The profile defines display functions and user functions. This Top device profile is based upon the definitions in the CANopen DS 301 V4.0 Communication Profile. DSP 302 V2.0 DSP 401 V1.4 The definitions of simple HMI, intelligent HMI and very DSP 402 V1.1 intelligent HMI refers to the kind of the implemented CANopen DSP 403 V1.0 Communication Profile. DSP 405 V1.0 DSP 406 V2.0 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

http://www.can-cia.de/lso.htm (5 von 6) [14.11.1999 12:49:58] 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 last update: 1999-07-26

http://www.can-cia.de/lso.htm (6 von 6) [14.11.1999 12:49:58] CAN in Automation Literature Order Form CiA

CiA Standards (in English): More: CAN Presentations download here CiA Draft Standard 102 (Version 2.0) Downloads CAN Physical Layer CAN Newsletter 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) More:

CiA Draft Standard Proposal 302 (Version 2.0) Downloads Framework for Programmable CANopen Devices CAN Newsletter (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) More: CiA Draft Standard Proposal 403 (Version 1.0) CANopen Device Profile Downloads For for Human Machine Interfaces (52 pages, 49 EUR + CAN Newsletter German VAT)

CiA Draft Standard Proposal 405 (Version 1.0) CANopen Device Profile For IEC 1131 Programmable Devices (32 pages, 35 EUR + German VAT)

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) Downloads CAN Newsletter

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) More: Volume 1 and 2, Release 2.0 DeviceNet Downloads (paper and CD-ROM version: 320 EUR + German VAT + CAN Newsletter postage)

Proceedings (in English) 2nd international CAN Conference 1995 (340 pages, free of charge)

3rd international CAN Conference 1996 (360 pages, 21 EUR) More: 4th international CAN Conference 1997 Downloads (360 pages 41 EUR CAN Newsletter 5th international CAN Conference 1998 (302+ pages 61 EUR

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

CAN Literature (in German) Prof. Konrad Etschberger CAN 2nd edition, available September 1999

More: Prof. Wolfhard Lawrenz CAN Downloads 3nd edition, (500 Seiten 85,90 EUR) CAN Newsletter

Sonderheft Controller Area Network Vogel Verlag (100 Seiten 16 EUR)

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

CAN Literature (in Français) More:

Le Bus CAN Downloads Dominic Paret, 277 pages (250 FF) CAN Newsletter Le Bus Can Applications Dominic Paret, 340 pages (250 FF)

Magazines (in English): published quarterly in March, June, September, December

http://www.can-cia.de/Lo.htm (3 von 4) [14.11.1999 12:50:33] CAN in Automation CAN Newsletter 1-year subscription (4 issues) More: (15 EUR in Europe, 26 EUR in Overseas) Downloads CAN Newsletter 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 in Automation Download Download Presentations: More: Physical Layer Data Link Layer Download for members Implementations Applications CANopen Page contents: top Presentations Specifications: Specifications Orderforms 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 More: describing both standard and extended message formats. Download for In order to be compatible with this CAN Specification 2.0 it is members required that a CAN implementation be compatible with either Part A or Part B. CAN 2.0 Addendum ... Page contents:

top CAN Physical Layer for Industrial Applications Presentations Specifications DS 102 V2.0 Orderforms

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

More: Orderforms: Download for Training & Education members iCC iCC Conference Page contents: iCC Seminars & Workshops top Fairs & Exibitions Presentations Specifications Orderforms © CAN in Automation last update:1999-10-13

http://www.can-cia.de/d.htm (2 von 2) [14.11.1999 12:51:23] CAN in Automation General introduction CANopen Page contents:

Advantages & features More: First information Technical introduction Specifications Advantages Features Conformance test ❍ Open and vendor ❍ Auto configuration of FAQs independent the network Vendor list ❍ Supports ❍ Easy access to all Vendor ID registration inter-operability of device parameters different devices ❍ Device ❍ High speed real-time synchronisation Presentation: capability ❍ Cyclic and ❍ Modular - covers event-driven data CANopen simple to complex transfer devices ❍ Synchronous ❍ User-friendly - wide reading or setting of Page contents: variety of support inputs, outputs or Top tools available parameters 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 More: automated machinery. One of the distinguishing features of Technical introduction CANopen is its support for data exchange at the supervisory control level as well as accommodating the integration of very Specifications small sensors and actuators on the same physical network. Conformance test This avoids the unnecessary expense of gateways linking FAQs sensor/actuator bus systems with higher communication Vendor list networks and makes CANopen particularly attractive to original equipment manufacturers. Vendor ID registration

presentation:

CANopen

Page contents:

Top Advantages & features First information

http://www.can-cia.de/hog.htm (2 von 2) [14.11.1999 12:52:04] CAN in Automation Technical introduction CANopen Page Content :

Built on standards More: Application layer and communication profile General introduction Communication model Specifications Network initialization and management Conformance test Data transfer mechanisms FAQs Service data objects Vendor list Process data objects Events Vendor ID Synchronization registration Polling PDO mapping Presentation: Device profiles CANopen Object dictionary Object dictionary - example CANopen development Page contents:

Built on Standards Top Built on standards Open fieldbus systems enable the construction of machines by Application layer and connecting components from multiple vendors while communication profile minimizing the effort required for interfacing. To achieve an Communication model open networking system, it is necessary to standardize the Network initialization and various layers of communication used. management Data transfer CANopen uses the international CAN standard, ISO 11898 as mechanisms the basis for communication. This standard covers the lower Service data objects two layers of communication specified by the OSI model. Process data objects Building on this, the CANopen profile family specifies Events standardized communication mechanisms and device Synchronization functionality for CAN-based systems. The profile family, which Polling PDO mapping is available and maintained by CAN in Automation (CiA) Device profiles consists of the Application layer and communication profile Object dictionary (DS 301), various frameworks and recommendations (CiA Object dictionary - DS-30x) and various device profiles (CiA DS-40x). example CANopen development 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] CAN in Automation systems based on CAN, it is necessary to define, which data More: have to be transmitted and with which services. CANopen provides one such definition, which is especially suitable for General introduction real-time industrial automation. Specifications Development of the Application layer and communication Conformance test profile started with the following objectives: FAQs ● Clear and concise structure to ease implementation and Vendor list maintenance Vendor ID ● Use existing international standards as far as possible registration ● Support for CAN chips with acceptance filtering and message storage capabilities (FullCAN) to allow Presentation: implementation in simple devices ● Use smallest possible number of communication objects CANopen (CAN identifiers)

● Easily scalable from simple to complex functionality to cover the wide range of devices found in automated Page contents: machinery Top ● Provide reliable and deterministic network behaviour Built on standards Application layer and With these objectives in mind, CANopen was developed using communication profile only a small number of communication services necessary for Communication model machine automation, resulting in low processor and memory Network initialization and overhead. Considering the data flow requirements of management automation systems led to the definition of the following Data transfer Communication model. mechanisms Service data objects Communication Model Process data objects Events The CANopen protocol defines several methods for Synchronization transmission and reception of messages over the CAN bus. Polling These messages are referred to as communication objects. PDO mapping Synchronous data transfers allow network wide coordinated Device profiles data acquisition and actuation. Synchronous transfers are Object dictionary supported by predefined communication objects i.e. Sync Object dictionary - Objects transmitted on a cyclic time period and Time Stamp example Objects. Asynchronous or event messages may be sent at any CANopen development 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).

http://www.can-cia.de/hot.htm (2 von 9) [14.11.1999 12:52:55] CAN in Automation CANopen defines four types of messages (communication More: objects): ● Network administration messages such as Layer General introduction Management (LMT) and Network Management (NMT) Specifications ● Service Data Objects (SDO) Conformance test ● Process Data Objects (PDO) FAQs ● Predefined messages such as the Sync Object, Time Vendor list Stamp Object and Emergency Object Vendor ID Network Initialisation and Management registration

Network management services are used to control the Presentation: operating state of devices in a CANopen network. Using network management the following functionality is available: CANopen ● Dynamic or static distribution of CAN identifiers for SDO/PDO communication and error services Page contents: ● Control over node operating states and communication modes for individual or multiple nodes Top ● Periodic Polling of nodes to detect nodes that are no Built on standards longer alive or functioning correctly Application layer and communication profile ● Instead of Polling every device produce a message that he is Communication model still alive and other devices can "hear" to this messages Network initialization and management Data Transfer Mechanisms Data transfer mechanisms CANopen defines two Data transfer mechanisms, which have Service data objects very different characteristics and are intended to cover the full Process data objects range of requirements found in automation applications. Events Synchronization Service Data Object (SDO) transfers are acyclic and are Polling typically used for configuring devices on a CANopen network PDO mapping with low priority. Individual parameters are addressed using a Device profiles 16 bit index and an 8 bit sub-index addressing mechanism. Object dictionary Data transfers in this mode may be greater than 8 bytes by Object dictionary - use of multiple CAN telegrams. example CANopen development 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

http://www.can-cia.de/hot.htm (3 von 9) [14.11.1999 12:52:55] CAN in Automation downloading programs. They are also used to define the type More: and format of information communicated using the Process Data Objects. General introduction Service Data Objects provide the following functionality: Specifications Conformance test ● Transmit data of any size (boolean to large files) FAQs ● Confirmed services (request/response) for read and Vendor list write of any data ● Expedited transfer of data less than or equal to 4 bytes Vendor ID total length registration ● Segmented transfer of data greater than 4 bytes total length Presentation: ● Abort of data transfer by either Client or Server with optional error feedback CANopen In CANopen devices, all parameters and variables, which are to be accessible via CAN are clearly arranged in an object Page contents: dictionary, which is described in more detail later. All the objects in the object dictionary can be read and/or written via Top SDO. Built on standards Application layer and Process Data Objects communication profile Communication model The Process Data Objects (PDO) do not contain any explicit Network initialization and protocol overhead and this allows very fast and flexible management exchange of data between applications running on each node. Data transfer mechanisms PDOs can be transmitted directly from any device on the Service data objects network simultaneously to any number of other devices. This Process data objects multicast capability is one of the unique features of CAN and is Events exploited to the full by CANopen. Synchronization Polling Events PDO mapping Device profiles CANopen supports different modes for transfer of real-time Object dictionary data. One mode is simply to send a PDO telegram on the Object dictionary - occurrence of an event. For example, a digital I/O transmits example the state of its input lines when they change state. An CANopen development 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

http://www.can-cia.de/hot.htm (4 von 9) [14.11.1999 12:52:55] CAN in Automation The synchronized mode allows devices on the network to be More: tightly synchronized to a master clock. This is essential in some motion control applications or in applications where General introduction remote inputs and outputs have to be read or written Specifications simultaneously. This mode is particularly useful where control Conformance test loops are closed over the bus necessitating synchronous FAQs sampling of Process data. As well as the cycle time, the Vendor list protocol also allows many other parameters to be changed. For instance, it is possible to transmit some of the data only Vendor ID every n-th cycle. registration Synchronous and event-driven objects may be mixed freely on the network. Presentation: CANopen

Page contents:

Top Built on standards Application layer and communication profile Communication model Network initialization and management Data transfer mechanisms Polling Service data objects Process data objects Finally it is also possible to read Process data from other Events nodes by Polling. A PDO can be used to poll a particular set of Synchronization data at any time using the CAN remote frame mechanism. Polling PDO mapping PDO Mapping Device profiles Object dictionary A special feature of CANopen is that the data contained in Object dictionary - PDOs may either be predefined by the device manufacturer or example it may be configured by the application. Thus it is possible to CANopen development 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

http://www.can-cia.de/hot.htm (5 von 9) [14.11.1999 12:52:55] CAN in Automation independent manufacturers can produce standardized More: devices. The advantages of this approach are numerous and perhaps, most importantly it allows a system integrator to General introduction decouple himself from a specific device manufacturer. This Specifications allows networks of devices from independent manufacturers to Conformance test be constructed without having to write specific software for FAQs networking each device together. Both optional and manufacturer specific functionality can also be defined for a Vendor list device using the CANopen profiling mechanism, making Vendor ID CANopen device profiles future proof. By defining mandatory device characteristics, basic network operation is guaranteed. registration By defining mechanisms for both optional and manufacturer specific functionality future CANopen devices will not be Presentation: constrained by an out of date standard. CANopen 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 Page contents: displays. Top Object Dictionary Built on standards Application layer and All device parameters are listed in the standardiZed CANopen communication profile Object Dictionary and each entry is assigned a 16 bit index, Communication model which is used to access the data. The Object Dictionary Network initialization and management contains the description, data type and structure of each Data transfer parameter. mechanisms The CANopen Object Dictionary is organized in several Service data objects sections comprising a data type area, a communication profile Process data objects area, a device profile area and a manufacturer specific area. Events Synchronization The structure is shown in the table below: Polling Index Object Dictionary Section PDO mapping 0001-001F Static Data Types (e.g. Boolean, Integer 16) Device profiles Object dictionary 0020-003F Complex Data Types (e.g. PDO CommPar, SDO Object dictionary - Parameter) example 0040-005F Manufacturer Specific Data Types CANopen development 0060-009F Device Profile Specific Data Types

1000-1FFF Communication Profile Area 2000-5FFF Manufacturer Specific Area 6000-9FFF Device Profile Area (as defined in the CANopen Device Profiles)

Object Dictionary - Example

http://www.can-cia.de/hot.htm (6 von 9) [14.11.1999 12:52:55] CAN in Automation Many different data types are supported from simple bit values More: to complex structures and these are defined in the object dictionary. Manufacturer specific data types may also be General introduction defined. Specifications The communication profile area contains information about the Conformance test communication as well as some basic data about the device. FAQs The data mapping for PDO messages is also defined here. Vendor list The device profile area contains device specific parameters. Vendor ID There is a range of mandatory entries in the dictionary which ensures that all CANopen devices of a particular type show registration the same basic behaviour. Some extended device features are Presentation: defined as optional. This means that a manufacturer is not obliged to provide all extended functionality on his device but if CANopen 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. Page contents:

An extract from a sample object dictionary is shown below. Top Index Sub-Index Object Name Type Attribute Default Value Built on standards 1000 00 VAR device type unsigned const 00 03 01 91H Application layer and 32 communication profile 1001 00 VAR error register unsigned ro 00H Communication model 8 Network initialization and 1002 00 VAR manufacturer unsigned ro 00 00 00 00H management status 32 Data transfer register mechanisms 1003 ARRAY error register Service data objects 00 number of unsigned ro 01H Process data objects entries 8 Events 01 error value unsigned ro 00H Synchronization 32 Polling 1008 00 VAR manufacturer vis-string const “CiA_Product” PDO mapping device name Device profiles 1009 00 VAR manufacturer vis-string const “V1.1” hardware Object dictionary version Object dictionary - 100A 00 VAR manufacturer vis-string const “V2.4” example software CANopen development 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

http://www.can-cia.de/hot.htm (7 von 9) [14.11.1999 12:52:55] CAN in Automation 00 VAR number of unsigned ro 02H More: entries 8 01 VAR receive PDO unsigned rw COB-ID 32 General introduction 02 VAR PDO type unsigned rw FFH Specifications 8 Conformance test 6000 ARRAY read 8 input FAQs lines Vendor list 00 VAR number of unsigned ro 01H input lines in 8 groups of 8 Vendor ID 01 VAR read state of unsigned ro registration 8 input lines 8 Presentation: CANopen Development CANopen 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 Page contents: Automation (CiA). The work is coordinated by the CiA Interest Group CANopen and associated Special Interest Groups. All Top Built on standards of these groups are completely open to any member of CiA. 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

http://www.can-cia.de/hot.htm (8 von 9) [14.11.1999 12:52:55] CAN in Automation 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

http://www.can-cia.de/hot.htm (9 von 9) [14.11.1999 12:52:55] CAN in Automation Frequently asked questions CANopen Please send your questions to [email protected]

More: General introduction coming soon 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 CANopen Page contents: More:

Introduction Technical Introduction test procedure Specifications Test tool Conformance test Certified companies FAQs FAQs & design hints members only Vendor list

Introduction Vendor ID registration

The growing CANopen market is shared by more and more manufacturers of CANopen devices. All of them implemented Presentation: a software covering communication services of higher protocol layers basing on the CANopen Communication Profile. To CANopen guarantee Conformance of the implementations to the

CANopen Communication Profile as base for correct functionality and possible interoperability of CANopen devices Page contents: CiA now offers a standardized test procedure. The certificate, that you will get after the passed test Top procedure, can also be used for Introduction marketing activities. Test procedure Test tool Certified companies FAQs & design hints Test Procedure members only

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 More: Devices Revision 1.1 includes a static test where timing requirements are not taken into consideration. For every test a Technical Introduction test report will be generated listing all steps of the test and all Specifications errors that have occured during the test. Conformance test FAQs In a first step the EDS (Electronic Data Sheet) of the CANopen device is tested. By means of a EDS a CANopen device can Vendor list be described with respect to the contents of its object Vendor ID registration 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 Presentation: consistency of the EDS. CANopen 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] CAN in Automation network states and transitions. Page contents:

Test procedure at CiA Top Introduction CAN in Automation offers the service of an official test Test procedure laboratory where CANopen devices can be certified. Please Test tool contact CiA headquarters for arranging a date for the test. Certified companies FAQs & design hints Within one session many devices can be tested. For a second members only 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 More: supply. Technical Introduction The certificate describes the hardware of the device (CAN Specifications controller, microcontroller) and the versions of the CANopen Conformance test implementation and the EDS file. One certificate can be given FAQs for a number of devices. The certified devices will be Vendor list presented on our Internet Websites. non-members members Vendor ID registration Basic Rate per Test Session 260.- EURO 130.- EURO Rate per hour 80.- EURO Presentation: Certificate 100.- EURO 50.- EURO CANopen * Prices don't include German VAT.

Please contact CiA headquarters for arranging a date. Page contents:

Test Tool Top Introduction The CANopen Conformance Test Suite, which is also used for Test procedure CANopen certification at CiA headquarters is now available for Test tool every Vendor and buyer of CANopen devices. So everybody Certified companies can check conformance to the standards and prepare the FAQs & design hints devices to pass the certification process. members only 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 Hardware Price Kit 1**: - 1.325.- EURO* CT Software Kit 2**: AT-CAN one port board 1.530.- EURO* CT Software (driver for W95 only)

http://www.can-cia.de/hoc.htm (2 von 3) [14.11.1999 12:53:13] CAN in Automation Kit 3**: PCI-CAN one port board 1.685.- EURO* More: CT Software (drivers for W95 and Win-NT) Kit 4**: PCMCIA-CAN one port board Technical Introduction 1.735.- EURO* CT Software (drivers for W95 and Win-NT) Specifications Conformance test * Prices don't include German VAT. ** Kits for Compact PCI/PXI and CAN two port boards are available on request. FAQs Vendor list The Conformance Test Suite Updates with Bug Fixes are available free of charge from the National Instruments server. Vendor ID registration 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 Presentation: free of charge. CANopen Contact Address for Test Suite Orders:

1. National Instruments Germany GmbH Konrad-Celtis-Str. 79 Page contents: D-81369 München Top phone: +49-89-7413130 Introduction fax: +49-7146035 Test procedure Email: [email protected] Test tool Certified companies FAQs & design hints 2. CAN in Automation (CiA) e.V. members only International Headquarters Am Weichselgarten 26 D-91058 Erlangen phone: +49-9131-690 86-0 fax: +49-9131-690 86-79 Email: [email protected]

http://www.can-cia.de/hoc.htm (3 von 3) [14.11.1999 12:53:13] CAN in Automation Vendor list CANopen

More: members can download this list as a comma seperated General introduction text file (.csv) Technical introduction

Specifications Company Department Vendor-ID Conformance test Antal Electronic 0000001A FAQs Applicom International 00000020 Vendor ID Arteco SpA 00000006 registration Ascom Autelca AG 00000025 bebro electronic GmbH 00000027 Presentation: Beckhoff Automation 00000002 GmbH CANopen Brand Innovators BV 00000038 CiA Headquarters 00000001

CMZ 0000000A Comap s.r.o. 0000002F Computechnic AG 00000037 Danfoss Fluid Power A/S MH-TME 00000019 Datamicro Co. LTD 00000026 Elrest GmbH 00000032 EMS Dr. Thomas Wünsche 0000002B Epec Oy 00000030 Epis-Microcomputer 0000001C ERL GmbH 00000029 esd electronic system 00000017 design gmbh ESR Dipl.-Ing. Pollmeier 0000000F GmbH Festo AG & Co. OV-M 0000001D F-Tron Elektronik GmbH 00000011 G.A.S. Gesellschaft für Antriebs- und 00000010 Steuerungstechnik mbH Graf-Syteco 0000002D Gustav Wurm GmbH & Co. 0000000B

http://www.can-cia.de/hov.htm (1 von 3) [14.11.1999 12:53:23] CAN in Automation

Hengstler GmbH 00000008 HMS 0000001B Indutron Industrieelektronik IMT 00000035 GmbH Isel-Automation 00000031 Ixxat Automation GmbH / 00000004 STZP Janz Computer AG 00000007 KEB Antriebstechnik 00000014 Klaschka GmbH & Co. 0000002A Kübler GmbH 00000013 Lawicel HB 00000033 Lust Antriebstechnik GmbH 00000016 McLennan Servo Supplies 00000012 Ltd. MEN Mikro Elektronik 004D454E GmbH MicroControl GmbH & Co. 0000000E KG Micro-key bv 00000022 MOOG Germany 00000028 Novotron GmbH 0000001F More: Port GmbH 00000034 General introduction ProControl AG Power and Motion Control 0000000C Technical Robert Bosch GmbH Automationstechnik 00000024 introduction Sevcon Ltd. 0000001E Specifications SIG Positec Automation Conformance test Technologie + Integration (TI) 0000002E GmbH FAQs SMH Automation 00000009 Vendor ID Softing GmbH 0000000D registration Techno-Matic ApS 00000023 Technoteam GmbH Verkehrstechnik 00000018 Presentation: Tetra Pak R&D Automation 0000002C CANopen Institut für TU Bergakademie Freiberg 00000015 Automatisierungstechnik Vector Informatik GmbH 00000005 WAGO Kontakttechnik Electronicc 00000021 GmbH Weidmüller ConneXt 00000003 GmbH & Co.

http://www.can-cia.de/hov.htm (2 von 3) [14.11.1999 12:53:23] CAN in Automation

Zürcher Hochschule Institut für Mechatronische 00000036 Winterthur (ZHW) Systeme (IMS)

http://www.can-cia.de/hov.htm (3 von 3) [14.11.1999 12:53:23] CAN in Automation News

CAN Newsletter More:

Hardware + Software + Tools + Engineering Hot News CiA News published by pz marketing Simon-Schoeffel-Str. 21 Press Release D-90427 Nuernberg Standardization Fax +49-911-3067283 Email: [email protected] Page contents: This unique magazine updating its readers with technology, product and other information related to Controller Area Network is published quarterly (March, top June, September, and December). VHDL model View into September 1999 issue Management Frameworks View into June 1999 issue Interfacing the 82527 View into March 1999 issue other topics

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 More: is the more often it is possible to use it. For this it is important Hot News to be able to tailor the architecture and the interfaces to the specific needs of a design. In our approach this is done by CiA News carefully analyzing the possible requirements of a component Press Release and using a supermodel concept implementing all reasonable Standardization 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.

http://www.can-cia.de/NN.htm (1 von 3) [14.11.1999 12:56:37] CAN in Automation Page contents: Mapping of CAN Devices to WWW based Management Frameworks top The mapping of the management functions of a CAN device VHDL model requires an appropriate description of the communication Management objects and of the functionality the module provides. These Frameworks descriptions can be derived from communication and device Interfacing the 82527 profiles (standardized communication objects), and from the other topics 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 More: functions. These DCOM components can be embedded into or accessed from hypertext documents. They perform a Hot News transparent data exchange with a DCOM server across the CiA News LAN. The DCOM server is implemented in the gateway. Press Release The problem of re-using description information in different Standardization context (e.g. definition, management, visualization, application development) was addressed by creating XML descriptions for fieldbus components. Based on an appropriate Document Page contents: Type Definition (DTD), an XML description of a CANopen Device Profile was created. This description holds all top information necessary to generate the associated document in VHDL model HTML format (Fig. 6). An XSL style sheet with formatting and Management filtering instructions supports the generation of the document. Frameworks This style sheet has to be developed once, and it can be Interfacing the 82527 re-used for other profile descriptions. In addition, more other topics 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.

http://www.can-cia.de/NN.htm (2 von 3) [14.11.1999 12:56:37] 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) More: should be used. The 82527 matches the AS, R/W#, E and AD7 to AD0 signals with microcontroller pin-for-pin (see fig. 1). Hot News The INT# pin of the CAN chip is tied to the 68HC11 IRQ# pin, CiA News and the Reset# pin is tied to a microcontroller pin or reset Press Release circuit (RC network). The Reset# pin must be asserted to V_Il Standardization 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 Page contents: address bits from the microcontroller. The signal must be generated 131 ns after a valid address is given on the bus, top when the baudrate is 1 Mbit/s. The 82527 requires the CS# VHDL model signal to be valid 20 ns before AS goes low. The Management microcontroller sends a valid address 151 ns prior to AS Frameworks falling. Interfacing the 82527 other topics

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

http://www.can-cia.de/NN.htm (3 von 3) [14.11.1999 12:56:37] CAN in Automation Hot News News Page contents:

CANopen Recommendations More: iCC in Torino CiA News ODVA in Korea Press Release Distributor as ODVA Members Newsletter CAN Chip Sales Figures Standardization Reviewed CAN Specification Safety Communication for CANopen CAN in the German Army Page contents:

CANopen Recommendations Recommendations iCC in Torino Erlangen, October 1999. CAN in Automation (CiA) has ODVA in Korea published the CANopen Draft Recommendation (DR) for Distributor Cabling and Connector Pin Assignment (CiA DR-303-1) as Sales Figures well as for SI Unit and Prefix Representation (CiA DR-303-2). CAN Review The CiA DR-303-1 gives some general guidelines and rules of Safety on CANopen CAN in the German thumb regarding the cabling of CANopen networks. In Army 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 More: Torino (2nd to 4th November). The early birds rate is valid by October, 15th. You also may now register for the workshops CiA News (English language) and seminars (Italian language). Press Release More information Newsletter Standardization 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] CAN in Automation and Danfoss. ODVA Korea will act as the marketing and training Page contents: arm for all DeviceNet-related activities. The Korea Instrumentation and Controls Association (KICA) supported by the Korean Recommendations government is promoting DeviceNet training. iCC in Torino ODVA in Korea More information Distributor Sales Figures Distributor as ODVA Member CAN Review Safety on CANopen Erlangen, September 1999. ODVA is inviting distributors to join CAN in the German the DeviceNet association. A new ODVA member category for Army 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.

http://www.can-cia.de/N.htm (2 von 3) [14.11.1999 12:56:53] 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 last update: 1999-08-15

http://www.can-cia.de/N.htm (3 von 3) [14.11.1999 12:56:53] CAN in Automation CiA News News Page contents:

ASAM on CANopen More: CANopen in Off-road Vehicles Hot News CiA Study Group Avionics Press Release CANopen Communication Profile for Safety Communication Newsletter CANopen Recommendations for Cabling and Connector Pin Standardization Assignment CANopen Recommendations for SI Units and Prefixes CANopen Device Profile for Generic I/O Modules Page contents: CANopen Device Profile for Door Control CANopen Application Profile for Integrated Operating Theater top ASAM on CANopen CANopen Framework for Maritime Applications Off-road Vehicles Avionics ASAM on CANopen Safety Communication Cabling and Connectors Erlangen, 1999-09-09. ASAM e.V. and CiA e.V. will establish the SI Units and Prefixes joint working group "ASAM on CANopen”. ASAM specifications I/O Modules are widely used in testing automobiles. In order to interconnect Door Control ASAM-compliant sub-systems via CANopen, there is a need for Medical specific CANopen interface profiles to map ASAM objects into the Maritime 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 [email protected]

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] CAN in Automation

Please mail your registration to [email protected] More: CiA Study Group Avionics Hot News Erlangen, 1999-07-12. CiA has called for an avionics study Press Release group. In the first meeting nine companies participated and Newsletter discussed the state of aerospace projects using CAN Standardization 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 Page contents: scheduled on November, 3rd in Torino. Topics will be specific requirements for CAN physical layer as well as discussion on top higher-layer protocols, in particular, CANaerospace and ASAM on CANopen CANopen. Interested parties in the CiA Study group Avionics Off-road Vehicles can contact CiA Headquarters ([email protected]). Avionics Safety Communication CANopen Communication Profile for Safety Communication Cabling and Connectors SI Units and Prefixes Erlangen, 1999-07-10. The CANopen Communication Profile I/O Modules for Safety-Relevant Data Transmission (CiA WD-304) is Door Control intended to be an add-on to the CANopen Application Layer Medical and Communication Profile (CiA DS-301), which is already Maritime 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 More: ensure compatibility, the usage of identifiers and predefined objects has to be coordinated with the CANopen standard and Hot News existing device profiles. As there is no use of data bits in the Press Release safe communication method, it is compatible with already Newsletter published device profiles. Standardization 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.

http://www.can-cia.de/NC.htm (2 von 5) [14.11.1999 12:57:23] CAN in Automation SRDOs (safety relevant data objects) shall distribute Page contents: safety-relevant data. A standard PDO or SDO is not sufficient for hard safety requirements. So with the SRDOs different top measures (e.g. redundancy, cyclic transmission etc.) are taken ASAM on CANopen to ensure safety. An identifier range not currently in use for Off-road Vehicles CANopen has been used for the SRDO transmissions. Avionics An SRDO consists of two CAN data frames with different Safety Communication identifiers. The user data in both transmissions is redundant, Cabling and Connectors i.e. the meaning of the data is the same, but the data on the SI Units and Prefixes 2nd transmission is inverted bit by bit. SRDOs must be I/O Modules Door Control transmitted periodically. If required, SRDOs can also be Medical transmitted event driven, e.g. to ensure fast reaction after a Maritime 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 More: parameters for CANopen networks. The major part of this recommendation deals with the pin assignments for Hot News general-purpose, industrial, and special-purpose connectors. Press Release This document is under final revision and will be published in Newsletter Fall 1999. CiA Members may send comments by July, 20th. Standardization More information (members-only section)

CANopen Recommendations for SI Units and Prefixes Page contents:

Erlangen, 1999-07-10. The CiA DRP-303-2 document top specifies the representation of SI units and prefixes to be used ASAM on CANopen in CANopen device, interface, and application profiles. This Off-road Vehicles recommendation is already used in the CANopen device Avionics profile for proportional valves (CiA WD-408). The Safety Communication recommendation is under final revision and will be published in Cabling and Connectors Fall 1999. CiA Members are asked to send comments by July, SI Units and Prefixes 20th. I/O Modules More information (members-only section) Door Control Medical CANopen Device Profile for Generic I/O Modules Maritime

http://www.can-cia.de/NC.htm (3 von 5) [14.11.1999 12:57:23] 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) More: CANopen Device Profile for Door Control Hot News Erlangen, 1999-07-10. The Task Force Door Control of the CANopen Special Interest Group (SIG) Railways has released Press Release for CiA internal discussion the CANopen Profile Door Control Newsletter (CiA WD-409). The device profile is based on UIC Standardization 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 Page contents: British cargo-sprinter manufactured by Windhoff. The next generation of the German cargo-sprinter will also make use of top CANopen networks. Other CANopen applications in railways ASAM on CANopen are under development, e. g. in some Czech, Italian, and Off-road Vehicles Avionics Swiss railways. Interested parties in the CANopen profiles for Safety Communication railways can contact CiA Headquarters Cabling and Connectors ([email protected]). SI Units and Prefixes More information (members-only section) I/O Modules Door Control CANopen Application Profile for Integrated Operating Theater Medical Maritime 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 ([email protected]).

CANopen Framework for Maritime Applications

Erlangen, 1999-07-10. The CANopen Special Interest Group

http://www.can-cia.de/NC.htm (4 von 5) [14.11.1999 12:57:23] 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 ([email protected]).

http://www.can-cia.de/NC.htm (5 von 5) [14.11.1999 12:57:23] CAN in Automation Overview Literature Literature just released

CiA Compact Disc More: All published CiA Specifications are available on CD Literature order form including all CANopen profiles. Downloads 6th iCC Proceedings CAN Newsletter 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

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 More: ordered. CAN Standards CANopen Standards CAL Standards ● Standards for CAN Related Standards ● Standards for CAN Application Layer Literature Order Form ● 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 Events

6th international CAN Conference '99

2nd - 4th November Turin (Italy), Lingotto Conference Center 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 Gschlößl (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 Wollschläger (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 Rüdiger (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 http://www.can-cia.de/EiCC.htm (2 von 6) [14.11.1999 12:59:38] CAN in Automation Francesco Riti (Eurosicma), Ferdinando Pozzi (Oasys srl): CAN in packaging and plaster machines Eric Médan (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. Jörgen 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

http://www.can-cia.de/EiCC.htm (3 von 6) [14.11.1999 12:59:38] CAN in Automation language) Workshop and seminar registration form

Tuesday, 1999-11-2 Seminars Time Workshop 1 + 1a (Italian language) 14.00-16.00 CAN (V-Systems) 1 CANopen (CiA) 16.00-18.00 DeviceNet (Rockwell) 2

Wednesday, 1999-11-3 Seminars Time Workshop 2 (Italian language) 14.00-16.00 CANopen (V-Systems) 3 16.00-18.00 CAN Kingdom I livelli Applicativi CAL, (Kvaser) DeviceNet and SDS per il Protocollo CAN (Prof. S. Cavalieri, Univ. di Catania) 4

Thursday, 1999-11-4 Time Workshop 3 Workshop 4 14.00-18.00 Measurement and DeviceNet calibration of ECUs (Rockwell) (Vector)

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/Wolfenbüttel) 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!

http://www.can-cia.de/EiCC.htm (4 von 6) [14.11.1999 12:59:38] 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: [email protected]

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),

http://www.can-cia.de/EiCC.htm (5 von 6) [14.11.1999 12:59:38] CAN in Automation Weidmüller (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, Weidmüller.

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.

http://www.can-cia.de/EiCC.htm (6 von 6) [14.11.1999 12:59:38] CAN in Automation CAN bibliography Literature Page contents:

Books More: Magazines Literature order form iCC Proceedings Downloads Articles and application notes CAN Newsletter Books

Konrad Etschberger: CAN - Controller Area Network. Page contents: Hanser-Verlag, München 1996. 400 pages. ISBN. Books The first part of the book introduces the CAN data link layer Magazines and the CAN high-speed physical layer. The second part iCC Proceedings describes the CAN Application Layer (CAL). All CMS, DBT, Articles 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 More: development and test strategies. Literature order form Wolfhard Lawrenz: CAN System Engineering - From Theory to Downloads Practical Applications. 468 pages. Springer-Verlag, New York, 1997. ISBN 0-387-94939-9. CAN Newsletter 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. Page contents: Books Dominique Paret: Le bus CAN - De la théorie à la pratique. Magazines 277 pages. Dunod, Paris 1995. ISBN 2-10003164-3 iCC Proceedings The book introduces into CAN data link layer and physical Articles 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] 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 More: iCC Proceedings Literature order form Downloads The annual international CAN Conference is the most CAN Newsletter important event for the CAN community.

• 1st iCC Proceedings. CAN in Automation, Erlangen 1994. Page contents: • 2nd iCC Proceedings. CAN in Automation, Erlangen 1995. Books • 3rd iCC Proceedings. CAN in Automation, Erlangen 1996. Magazines • 4th iCC Proceedings. CAN in Automation, Erlangen 1997. iCC Proceedings • 5th iCC Proceedings. CAN in Automation, Erlangen 1998. Articles • 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

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

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.

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.

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 • Sales Contacts CAN news & events • Application notes About CAN • AN457, 80C51 External Memory Interfacing • AN91014, Application of the P8xC592 microcontroller with CAN-interface CAN support & tools • AN92002, Extended Frame Format - A New Option of the CAN Protocol Sales contacts • 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] Philips Semiconductors - CAN Bus; Support and tools; 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.

http://www-eu2.semiconductors.com/can/support/ (2 von 3) [14.11.1999 13:08:06] Philips Semiconductors - CAN Bus; Support and tools;

http://www-eu2.semiconductors.com/can/support/ (3 von 3) [14.11.1999 13:08:06] CAN in Automation Products News

CAN Product Information More:

There is an enormous number of CAN products available. In Product Data Base general, CAN products can be classified in chip-level and CAN chip device-level modules, software, and tools. CiA provides several Transceiver chip services to find CAN products. CiA Members may entry their products and services in the CiA PRODUCT DATABASE. More CAN Newsletter specific product information regarding embedded networking is DeviceNet Catalog 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 More: OSEK/Com/NM. The hardware support of object segmentation and re-assembling will unburden the microcontroller from Product Data Base processing of interrupts. The CAN data link layer module CAN chip provides the same features as the SJA1000 stand-alone Transceiver chip controller. CAN Newsletter DeviceNet Catalog 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

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 More: its SAB80C90/91 family of stand-alone CAN controllers. All Product Data Base known failures and problems are solved. CAN chip More information www.infineon.com/us/micro/can/content.html Transceiver chip CAN Newsletter 8051-based Microcontroller featuring CAN DeviceNet Catalog

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.

http://www.can-cia.de/P.htm (2 von 4) [14.11.1999 13:08:20] 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

http://www.can-cia.de/P.htm (3 von 4) [14.11.1999 13:08:20] 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

http://www.can-cia.de/P.htm (4 von 4) [14.11.1999 13:08:20] Welcome to CAN in Automation e.V. Product Class

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 Object Storage Acceptance Filtering CAN Contoller Website (Data Sheet and Application Notes) Company Microcontroller Bridge Samples Volume Remarks Version Capacity Capability 4kB SRAM, 256 x 16 RAM, 40 MHz 2 x 14 Tx/Rx buffers + 1 14 Tx/Rx buffers + 1 DS80C390 www.dalsemi.com Dallas 8-bit possible now 1Q00 clock rate, 2.0B double Rx buffer double Rx buffer 16/32-bit math coprocessor 128KB Mask ROM, 4K RAM, 1 x 16-bit 16 full-bit masks + 2 MB90548 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No 1Q00 2Q00 UARTx2, A/D, 2.0B (FFMC16LX) global masks Ext Bus Interface, QFP100. 256KB Mask ROM, 6K RAM, 2 x 16-bit 16 full-bit masks + 2 MB90594 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No n.a. now UARTx3, A/D, 4 2.0B (FFMC16LX) global masks Stepper Motor Drivers, QFP100. 128KB Mask ROM, 4K RAM, 1 x 16-bit 16 full-bit masks + 2 MB90598 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No 1Q00 1Q00 UARTx2, A/D, 4 2.0B (FFMC16LX) global masks Stepper Motor Drivers, QFP100. 64K Flash, 2K 1 x 16-bit 8 full-bit masks + 2 MB90F497 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 8 Tx/Rx buffers No 4Q99 1Q00 RAM, UART, 2.0B (FFMC16LX) global masks A/D, QFP64. 128KB Flash, 6K RAM, UARTx2, 2 x 16-bit 16 full-bit masks + 2 MB90F543 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No n.a. now A/D, Ext Bus 2.0B (FFMC16LX) global masks Interface, QFP100. 128KB Flash, 4K RAM, UARTx2, 1 x 16-bit 16 full-bit masks + 2 MB90F548 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No 1Q00 2Q00 A/D, Ext Bus 2.0B (FFMC16LX) global masks Interface, QFP100. 256KB Flash, 6K RAM, UARTx2, 1 x 16-bit 16 full-bit masks + 2 MB90F549 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No 4Q99 1Q00 A/D, Ext Bus 2.0B (FFMC16LX) global masks Interface, QFP100. 384KB Flash 8K RAM, UARTx3, 2 x 16-bit 16 full-bit masks + 2 MB90F591 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No now now A/D, 4 Stepper 2.0B (FFMC16LX) global masks Motor Drivers, QFP100. 256KB Flash 6K RAM, UARTx3, 2 x 16-bit 16 full-bit masks + 2 MB90F594A www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No n.a. now A/D, 4 Stepper 2.0B (FFMC16LX) global masks Motor Drivers, QFP100. 128KB Flash, 4K RAM, UARTx2, 1 x 16-bit 16 full-bit masks + 2 MB90F598 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 16 Tx / Rx buffers No n.a. now A/D, 4 Stepper 2.0B (FFMC16LX) global masks Motor Drivers, QFP100.

http://www.can-cia.de/pc.htm (1 von 6) [14.11.1999 13:08:48] CAN Contoller 512KB Flash, 16K RAM, 3 x 16 full-bit masks + 2 UARTx3, A/D, 4 MB91F361 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu 32-bit (FR) 16 Tx / Rx buffers No now 4Q99 2.0B global masks Stepper Motor Drivers, 64MHz, LQFP208 15 Tx/Rx buffers + 1 15 full-bit masks + 1 H8/300H semiconductor.hitachi.com/h8/?adjump=frontpage_products-section Hitachi 2.0B 16-bit no n.a. n.a. ASIC solution Rx buffer global mask currently dedicated 30 Tx/Rx buffers + 2 30 full-bit masks + 2 automotive H8S/2623 semiconductor.hitachi.com/h8/?adjump=frontpage_products-section Hitachi 2.0B 16-bit no n.a. n.a. Rx buffers global masks customers only (open market support 3Q99 30 Tx/Rx buffers + 2 30 full-bit masks + 2 SH7055 semiconductor.hitachi.com/superh/?adjump=frontpage_products-section Hitachi 2.0B 32-bit no n.a. n.a. Rx buffers global masks 15 Tx/Rx buffers + 1 15 full-bit masks + 1 SuperH semiconductor.hitachi.com/superh/?adjump=frontpage_products-section Hitachi 2.0B 32-bit no n.a. n.a. ASIC solution Rx buffer global mask 256k flash, 10k 14 Tx/Rx buffers + 1 15 full-bit masks + 1 RAM, I2C, 2 x C161CI www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit no now now double Rx buffer global mask ASC, 2 x SSC, RTC 14 Tx/Rx buffers + 1 15 full-bit masks + 1 64k OTP, 6 x C164CI www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit no now now double Rx buffer global mask PWM, RTC 14 Tx/Rx buffers + 1 15 full-bit masks + 1 ROMless-, 32k or C167CR www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit no now now double Rx buffer global mask 128k ROM-, flash 128k flash, 4k 14 Tx/Rx buffers + 1 15 full-bit masks + 1 X-flash, 11k C167CS www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit no now now double Rx buffer global mask RAM, 24 analog inputs 32k OTP, ROM 14 Tx/Rx buffers + 1 15 full-bit masks + 1 C505C/CA www.infineon.com/us/micro/can/content.html Infineon 2.0B 8-bit no now now less, 16k or 32k double Rx buffer global mask ROM, 4 x PWM 14 Tx/Rx buffers + 1 15 full-bit masks + 1 64k OTP, 4 x C515C www.infineon.com/us/micro/can/content.html Infineon 2.0B 8-bit no now now double Rx buffer global mask PWM SAE81C90/91 www.infineon.com/us/micro/can/content.html Infineon 2.0Bp none 16 Tx/Rx buffers 16 full-bit masks no now now 2 x 8-bit I/O ports technology independend IniCAN www.inicore.com Inicore 2.0B 8-bit or DSP implemenation-specific implemention-specific possible n.a. n.a. functions for chip integrations 14 Tx/Rx buffers + 1 15 full-bit masks + 1 AN82527 developer.intel.com/design/auto/network.htm Intel 2.0B none no now now double Rx buffer global mask 14 Tx/Rx buffers + 1 15 full-bit masks + 1 AN87C196CA developer.intel.com/design/auto/network.htm Intel 2.0B 16-bit no now now double Rx buffer global mask 14 Tx/Rx buffers + 1 15 full-bit masks + 1 AN87C196CB developer.intel.com/design/auto/network.htm Intel 2.0B 16-bit no now now double Rx buffer global mask 14 Tx/Rx buffers + 1 15 full-bit masks + 1 AS82527 developer.intel.com/design/auto/network.htm Intel 2.0B none no now now double Rx buffer global mask 14 Tx/Rx buffers + 1 15 full-bit masks + 1 AS87C196CB developer.intel.com/design/auto/network.htm Intel 2.0B 16-bit no now now double Rx buffer global mask SPI Interface, 3 Tx buffers + 2 Rx 6 full-bit masks + 2 MCP2510 www.microchip.com Microchip 2.0B none no n.a. n.a. PDIP/SOIC18, buffers global masks TSSOP20 Micronas 16 full-bit masks + 1 on 32k Flash, 16 CCU3010E www.intermetall.de/docu.html 2.0B 8-bit flash 16 Tx/Rx buffers no now Intermetall global mask request time-stamps

http://www.can-cia.de/pc.htm (2 von 6) [14.11.1999 13:08:48] CAN Contoller 3 indepemdemt Micronas 3 x 16 full-bit masks + 1 on CAN-Modules, CDC-1 www.intermetall.de/docu.html 16-bit flash 16 Tx/Rx buffers yes now Intermetall 2.0B global mask request 256k Flash, 16 time-stamps 2 independent 2 x 16 full-bit masks + 3 on-chip CAN M306NOMCT-xxxFP www.mitsubishichips.com Mitsubishi 16-bit 16 Tx/Rx buffers yes now now 2.0B global masks modules, 3 phase motor controllers 1 Tx buffer + 2 Rx 1 full-bit mask + 1 M37630M4-xxxFP www.mitsubishichips.com Mitsubishi 2.0B 8-bit no now now buffers global mask 1 Tx buffer + 2 Rx 1 full-bit mask + 1 M37632MF-xxxFP www.mitsubishichips.com Mitsubishi 2.0B 8-bit no now now buffers global mask 1 Tx buffer + 2 Rx 64-pin packaging 68HC(7)05X32 www.mot.sps.com/csic/techdata/appnote Motorola 2.0A 8-bit 1 global 8-bit mask no now now buffers (32 KROM) 1 Tx buffer + 2 Rx 28-pin packaging 68HC(7)05X4 www.mot.sps.com/csic/techdata/appnote Motorola 2.0A 8-bit 1 global 8-bit mask no now now buffers (4K ROM) 1 global 32-bit or 2 3 Tx buffers + 2 Rx 64-pin packaging 68HC(9)08AZ60 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 8-bit global 16-bit or 4 no now now buffers (60K flash) global 8-bit masks 1 Tx buffer + 2 Rx 64-pin packaging 68HC05X16 www.mot.sps.com/csic/techdata/appnote Motorola 2.0A 8-bit 1 global 8-bit mask no now now buffers (16K ROM) 1 global 32-bit or 2 3 Tx buffers + 2 Rx 100-pin packaging 68HC08AZ0 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 8-bit global 16-bit or 4 no now now buffers (ROM less) global 8-bit masks 1 global 32-bit or 2 3 Tx buffers + 2 Rx 64-pin packaging 68HC08AZ16 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 8-bit global 16-bit or 4 no n.a. now buffers (16K ROM) global 8-bit masks 1 global 32-bit or 2 3 Tx buffers + 2 Rx 64-pin packaging 68HC08AZ24 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 8-bit global 16-bit or 4 no n.a. now buffers (24K ROM) global 8-bit masks 1 global 32-bit or 2 3 Tx buffers + 2 Rx 64-pin packaging 68HC08AZ32 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 8-bit global 16-bit or 4 no n.a. now buffers (32K ROM) global 8-bit masks 1 global 32-bit or 2 3 Tx buffers + 2 Rx 80-pin packaging 68HC912BC32 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 16-bit global 16-bit or 4 no now now buffers (32K flash) global 8-bit masks 1 global 32-bit or 2 3 Tx buffers + 2 Rx 112-pin packaging 68HC912D60 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 16-bit global 16-bit or 4 no now now buffers (60K flash) global 8-bit masks 2 independent 1 global 32-bit or 2 on-chip CAN 2 x 3 Tx buffers + 2 Rx 68HC912DG128 www.mot.sps.com/csic/techdata/appnote Motorola 16-bit global 16-bit or 4 yes now now modules, 112-pin 2.0B buffers global 8-bit masks packaging (128K flash) 16 full-bit masks + 3 time-stamp, flash MC68376 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 32-bit 16 Tx/Rx buffers no now now global masks memory 16 full-bit masks + 3 time-stamp, flash MC68F396 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 32-bit 16 Tx/Rx buffers no now now global masks memory 2 independent on-chip CAN 2 x 16 full-bit masks + 3 MPC555 www.mot.sps.com/csic/techdata/appnote Motorola 32-bit 16 Tx/Rx buffers yes now 4Q99 modules, 2.0B global masks time-stamp, flash memory 8-byte frames can 1 Tx 2-byte buffer + 2 COP684BC www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit 1 global 8-bit mask no now now be handles up to Rx 2-byte buffers 125 kbit/s

http://www.can-cia.de/pc.htm (3 von 6) [14.11.1999 13:08:48] CAN Contoller 8-byte frames can 1 Tx 2-byte buffer + 2 COP688/89EB www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit 1 global 8-bit mask no now now be handles up to Rx 2-byte buffers 125 kbit/s 8-byte frames can 1 Tx 2-byte buffer + 2 COP87/L88/89EB www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit 1 global 8-bit mask no now now be handles up to Rx 2-byte buffers 125 kbit/s 8-byte frames can 1 Tx 2-byte buffer + 2 COP87L84BC www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit 1 global 8-bit mask no now now be handles up to Rx 2-byte buffers 125 kbit/s 8-byte frames can 1 Tx 2-byte buffer + 2 COP888/89EB www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit 1 global 8-bit mask no now now be handles up to Rx 2-byte buffers 125 kbit/s 8-byte frames can 1 Tx 2-byte buffer + 2 COP8884BC www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit 1 global 8-bit mask no now now be handles up to Rx 2-byte buffers 125 kbit/s 15 Tx/Rx buffers + 1 14 full-bit masks + 1 CR16MCS9 www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0B 16-bit no now now flash memory Rx buffer global mask 128k Flash, 2 x 32 full-bit masks + 3‘4 QFP144, LCD, ATOMIC - D703121 www.nec.de NEC 32-bit RISC 32 Tx/Rx buffers possible 4Q00 1Q01 2.0B 29-bit masks CAN Time System, 2x FCAN 256k Flash, 3 x 64 full-bit masks + 3‘4 QFP144, LCD, ATOMIC - D703123 www.nec.de NEC 32-bit RISC 64 Tx/Rx buffers possible 1Q00 3Q00 2.0B 29-bit masks CAN Time System, 3x FCAN 256k Flash, ATOMIC µPD 3 x 32-bit RISC 64 full-bit masks + 3‘4 QFP144, LCD, www.nec.de NEC 64 Tx/Rx buffers possible 4Q99 3Q00 70F3123 2.0B Flash 29-bit masks CAN Time System, 3x FCAN 32/48k, QFP64, 2 Tx buffers + 16 Rx 16 full-bit masks + 2 µPD 780814/6 www.nec.de NEC 2.0B 8-bit no 1Q00 4Q00 EEPROM, CAN buffers global 29-bit masks Time System 32/48k, QFP80, LCD, EEPROM, 2 Tx buffers + 16 Rx 16 full-bit masks + 2 µPD 780824/6 www.nec.de NEC 2.0B 8-bit no now 1Q00 Stepper motor buffers global 29-bit masks driver, CAN Time System 60k, QFP100, 2 Tx buffers + 16 Rx 16 full-bit masks + 2 µPD 780948 www.nec.de NEC 2.0B 8-bit no now now LCD, CAN Time buffers global 29-bit masks System 2 Tx buffers + 16 Rx 16 full-bit masks + 2 D780948 + µPD 780949 www.nec.de NEC 2.0B 8-bit no now 2Q00 buffers global 29-bit masks EEPROM 16k, SSOP30, 2 Tx buffers + 14 Rx 14 full-bit masks + 2 µPD 789850 www.nec.de NEC 2.0B 8-bit no 1Q00 4Q00 CAN Time buffers global 29-bit masks System 2 Tx buffers + 16 Rx 16 full-bit masks + 2 D78081X with µPD 78F0818 www.nec.de NEC 2.0B 8-bit Flash no now 3Q00 buffers global 29-bit masks 60k Flash 2 Tx buffers + 16 Rx 16 full-bit masks + 2 D78082X with µPD 78F0828 www.nec.de NEC 2.0B 8-bit Flash no now 2Q00 buffers global 29-bit masks 60k Flash 60k Flash, 2 Tx buffers + 16 Rx 16 full-bit masks + 2 QFP100, LCD, µPD 78F0948 www.nec.de NEC 2.0B 8-bit Flash no now now buffers global 29-bit masks CAN Time System 2 Tx buffers + 16 Rx 16 full-bit masks + 2 D78F0948 + µPD 78F0949 www.nec.de NEC 2.0B 8-bit Flash no now 2Q00 buffers global 29-bit masks EEPROM 16k Flash, 2 Tx buffers + 14 Rx 14 full-bit masks + 2 µPD 78F9850 www.nec.de NEC 2.0B 8-bit Flash no 1Q00 4Q00 SSOP30, CAN buffers global 29-bit masks Time System http://www.can-cia.de/pc.htm (4 von 6) [14.11.1999 13:08:48] CAN Contoller MSM9225 www.oki-europe.de OKI Electric 2.0B none 16 Tx/Rx buffers 16 full-bit masks no now now in maintenance P82C150 www-us.semiconductors.philips.com/can/products/ Philips 2.0Bp SLIO n.a. n. a. no now now state, not for new desing-ins 1 Tx buffer + 64 Rx 1 global 32-bit mask or P8XC591 www-us.semiconductors.philips.com/can/products/ Philips 2.0B 8-bit no now 1Q00 FIFO 2 global 16-bit masks 1 Tx buffer + 2 Rx P8XC592/8 www-us.semiconductors.philips.com/can/products/ Philips 2.0A 8-bit 1 global 8-bit mask no now now buffers will replace P8XC59X www-us.semiconductors.philips.com/can/products/ Philips 2.0B 8-bit to be defined to be defined no 2Q00 3Q00 P8x592/8 1 Tx buffer + 64 Rx 1 global 32-bit mask or SJA1000 www-us.semiconductors.philips.com/can/products/ Philips 2.0B none no now now replaces 82C200 FIFO 2 global 16-bit masks CANopen, 32 full-bit masks + DeviceNet and XA-C3 www-us.semiconductors.philips.com/can/products/ Philips 2.0B 16-bit 32 Tx/Rx buffers no 4Q99 1Q00 global masks OSEK transport layer hardwired CAN Core, VHDL- and CAN Core www.sican.com Sican 2.0B optional implementation-specific implementation-specific possible now now Verilog Model for ASIC and FPGA 40V 1 Tx buffer + 1 Rx SuperSmartPower, L9942/ST6 www.st.com/stonline/books/index.html ST-Microelectronics 2.0A 8-bit 1 global 11-bit mask no now 4Q99 buffer OTP, ROM versions (2Q00) 14 Tx/Rx buffers + 1 14 Tx/Rx buffers + 1 128 kbyte flash, ST10F1167 www.st.com/stonline/books/index.html ST-Microelectronics 2.0B 16-bit no now now double Rx buffer double Rx buffer 32k or ROMless now ST72511R4 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no now (ROM 16k, TQFP64 1Q00) now ST72511R6 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no now (ROM 32k, TQFP64 1Q00) now ST72511R7 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no now (ROM 48k, TQFP64 1Q00) now ST72511R9 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no now (ROM 60k, TQFP64 1Q00) 2Q00 16k, 256EE, ST72532J4 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no 1Q00 (ROM TQFP44 3Q00) 2Q00 ST72532K4 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no 1Q00 (ROM 16k, 256EE, SO34 3Q00) now 16k, 256EE, ST72532R4 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no now (ROM TQFP64 3Q00) 40V SuperSmartPower, UD05 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no now 4Q99 OTP, ROM versions (2Q00) 8k x 16 flash, 544 2 full-bit masks + 1 not x 16 RAM, 10-bit TMS320C241 www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm Texas Instruments 2.0B 16-bit DSP 6 Tx/Rx buffers no now global mask planned A/D, 8 x PWM, QEP, SCI, SPI

http://www.can-cia.de/pc.htm (5 von 6) [14.11.1999 13:08:48] CAN Contoller 8k x 16 flash, 544 2 full-bit masks + 1 x 16 RAM, 10-bit TMS320F241 www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm Texas Instruments 2.0B 16-bit DSP 6 Tx/Rx buffers no now now global mask A/D, 8 x PWM, QEP, SCI, SPI 8k x 16 flash, 544 2 full-bit masks + 1 x 16 RAM, 10-bit TMS320F243 www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm Texas Instruments 2.0B 16-bit DSP 6 Tx/Rx buffers no now now global mask A/D, 8 x PWM, QEP, SCI, SPI 15 Tx/Rx buffers + 1 15 full-bit masks + 1 TC190C580 doc.semicon.toshiba.co.jp Toshiba 2.0B none no now now Rx buffer global mask 15 Tx/Rx buffers + 1 15 full-bit masks + 1 TMP95CS54F doc.semicon.toshiba.co.jp Toshiba 2.0B 16-bit no now now 64k ROM Rx buffer global mask 15 Tx/Rx buffers + 1 15 full-bit masks + 1 TMP95PS54F doc.semicon.toshiba.co.jp Toshiba 2.0B 16-bit no now now 48k OTP Rx buffer global mask

http://www.can-cia.de/pc.htm (6 von 6) [14.11.1999 13:08:48] CAN in Automation

CAN High-speed transceiver (ISO 11898-2)

Manufacturer Bosch Mietec Philips Philips SGS-Thomson Temic Unitrode Semiconductors Semiconductors (Siliconix) type no. CF150B MTC-3054 82C250 82C251 L9615 Si9200EY UC5350 data rate 0.5 1 1 1 0.5 1 1 max. [Mbd] short circuit -5...+36 -3...+65 -8...+18 -36...+36 -5...+36 GND...+16 -8...+36 [V] transient [V] -200...+200 -200...+200 -150...+100 -200...+200 -200...+200 -60...+60 -150...+100 ESD [kV] 2 2 2 2.5 2 2 2 thermal (1,2) n.a. yes yes (1, 2) yes yes shutdown slope on/off variable variable variable on/off none variable control CMR [V] -2...+7 (3) -7...+12 -7...+12 -7...+12 -2...+7 (3) -2...+7 -25...+18 delay [ns] 230 100 170 170 230 120 (4) 100 (4) fan out (5) 32 32 64 64 32 32 n.a. (6) supply <80 110 <70 <80 <80 70 70 current [mA] stand-by n.a. 300 <170 <275 n.a. n.a. 1000 current [µA] packaging SOIC-8 SOP-16 SO-8, DIP-8 SO-8, DIP-8 SO-8 SO-8 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 CiA membership benefits ● Information Free of Charge More: ● Participation in Marketing Activities ● Influence on Specifications Events CiA rules ● Credit on CiA Events CiA operation ● Credit on CiA Publications structure ● Entries in CiA Product Data Base Free of Charge CiA members list Credits for CiA members on:

● International CAN Conference Proceedings ● Higher Layer Protocol Specifications supported by CAN in Automation Page contents: ● Entries in CiA Directories Top ● Participation fees in CiA National Forums and In-house Membership benefits Seminars Credits for CiA members ● Participation fees in CiA International Workshops Joint marketing activities CiA marketing activities ● Participation fees in the international CAN Conference

Joint marketing activities

CiA is organizing several joint marketing activities, such as More: ● Joint Stands e. g. at Hanover Fair Industry (Germany) more than 500 sqm, Events at Embedded Systems, Nürnberg (Germany) 80 sqm, at CiA rules SPS/IPC/Drives, Nürnberg (Germany) about 190 sqm, at CiA operation electronica, Munich (Germany), BiAS, Milan (Italy) and others. structure ● Product Guides CiA members list e. g. Internet data base, Product Guides to related application fields ● Advertisements Advertisements in magazines and special editions Page contents: ● Seminars CiA members seize this opportunity to establish contacts by Top supporting papers. Membership benefits ● International CAN Conference Credits for CiA members Joint marketing activities The table-Top exhibition accompanying this most important CiA marketing activities event is another occasion to reach a great number of prospective customers. ● Table-Top Exhibitions

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. More: CiA marketing activities Events ● Information Free of Charge (brochures) CiA rules ● Sell of CAN Literature and Specifications CiA operation ● National CAN Forums structure ● International CAN Workshops CiA members list ● CiA Stands at International Fairs (e.g. Embedded Systems Show and Conference/USA, National Manufacturing Week/USA, Automation/France, and others) In-house seminars Page contents:

CiA offers In-house Seminars for intensive training on CAN Top technology. Interested companies have to come up for the Membership benefits travel expenses of the trainer and pay a moderate honorar. Credits for CiA members Joint marketing activities iCC - international CAN Conference CiA marketing activities 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) More: exhibition and attracts more than 200 participants every year. In the last years the iCC took place at Mainz, London, Paris, Events Berlin and San José, CA (USA). The found international CAN CiA rules Conference found increasing interest from year to year. In CiA operation 1999 it will be held in the Lingotto Conference Center, Turin structure (Italy). CiA members list Technical support Standardization Conformance Testing Recommendations Page contents: © CAN in Automation Top last update: 99-08-11 Membership benefits Credits for CiA members Joint marketing activities CiA marketing activities

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 - More: International Users and Manufacturers Group" and is CiA 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 More: may vote in CiA General Assemblies and may run for election of CiA Board of Directors or CiA Technical Committee or CiA 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

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. More: (4) The CiA Managing Director manages CiA Headquarters, CiA Offices and CiA Secretaries. CiA

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

http://www.can-cia.de/ar.htm (2 von 4) [14.11.1999 13:10:09] CAN in Automation the "CiA guidelines for IG" and submitted to the CiA TC for More: approval. (4) After approval by the CiA TC the IG has to elect a CiA 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 More: or after acceptance by the IG with the remark, that this document is not valid for implementation. CiA

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.

http://www.can-cia.de/ar.htm (3 von 4) [14.11.1999 13:10:09] 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 last update: 99-08-11

http://www.can-cia.de/ar.htm (4 von 4) [14.11.1999 13:10:09] CAN in Automation Site contents map CiA Events CiA Rules Meetings Page contents: CiA Operation Deadlines Structures top CiA CiA Members List iCC Programm Events CiA Membership Exhibitions and Fairs Literature Application Members only News CiA Inhouse-Seminars Training + Education Products CAN Information in CiA CANschool CAN Protocol Dutch Higher Layer Protocols CANopen Protocols DeviceNet CAN Application Layer Literature Members only CAN Kingdom section Standardization Order Form Bibliography (Books, Proceedings, Links...) CiA Standards News CiA Standards CAN Press Releases Page contents: CiA Standards CAL CiA News CiA Standards Newsletter top CANopen CiA Events CiA Standards Misc Rate Card Literature Members only Products CAN Protocol News Product data base General Application Products CAN Protocol Chip survey Technical Introduction Higher Layer Protocols High-speed Conformance Test CANopen Protocols Low-speed FAQs DeviceNet CAN Application Layer CAN Kingdom Standardization Higher Layer Protocols

CANopen DeviceNet Technical Introduction Technical Introduction Conformance Test 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 Page contents: FAQs top Vendor list CiA Events CAN Application CAN Kingdom Literature Layer Members only Technical introduction Technical Introduction News Products CAN Protocol Standardization Higher Layer Protocols CANopen Protocols DeviceNet CAN Application Layer CAN Kingdom Standardization © CAN in Automation last update: 99-10-15

http://www.can-cia.de/map.htm (2 von 2) [14.11.1999 13:10:59] CAN in Automation CiA Operationstructure CiA General Assembly More: Board of Directors: Business Director - Managing Director - Technical Director CiA CiA rules Business Committee Headquarters Technical Committee CiA members list

Marketing Groups Interest Groups (IG): (MG) IG Hydraulics IG Application Layer IG CANopen

MG Benelux CANopen Special Interest Groups (SIG): MG Scandinavia MG France SIG Programmable CANopen Devices MG Switzerland SIG Safety MG CANopen SIG Generic I/O Modules MG Device Net 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

http://www.can-cia.de/ao.htm [14.11.1999 13:11:09] CAN in Automation Events Marketing CAN in Automation is organizing several events each year. These are not only Seminars, Workshops and Exhibitions, but More: also the most important international CAN Conference. 6th international CAN Conference: CiA Meetings The international CAN Conference is CiA’s most important Deadlines event every year. Experts from all over the world speak about 6th iCC programme newest CAN technologies and practical experiences on CAN Exhibitions and fairs networks. It is accompanied by a table-top exhibition, workshops, seminars, etc. Training and education 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. © CAN in Automation last update: 99-10-06

http://www.can-cia.de/E.htm [14.11.1999 13:11:17] CAN in Automation CiA deadlines Events November 8 very last deadline for registration CiA joint stand BIAS 2000, More: Milan (Italy) CiA Events October 29 Meetings very last deadline for registration for table top exhibition 6th 6th iCC programme iCC at Turin (Italy) Exhibitions and fairs Training and educations © CAN in Automation l last update: 99-10-26

http://www.can-cia.de/ED.htm [14.11.1999 13:11:20] CAN in Automation Fairs and exhibitions Events

November 2 - 4 6th international CAN Conference, Turin (Italy) More: Table-top exhibition CiA beside the sponsoring companies the following companies ordered Events one, two or more tables: Deadlines Applicom (1), Arteco (1), Automata (1), Beckhoff (1), Dearborn (1), Meetings EMS Dr. Thomas Wünsche (1), esd (2), Fujitsu (1), i+ME Actia (1), 6th iCC programme Ixxat Automation (2), Janz Computer (2), Kvaser (1), Lumberg (1), Training and educations MEN (1), Microtask (1), NSI (1), port (1), Rockwell Automation (4), Softing (3), Special Electronic Design (1), Warwick Manufacturing Group (1), Toshiba (1), Weidmüller (2). For more information and registration download November 23 - 25 SPS/IPC/Drives 99, Nürnberg (Germany) CiA stand February 23 - 26, 2000 IBias 2000, Milan (Italy) CiA joint stand - sub-exhibitors: Arteco, Berghof, Janz, Softing © CAN in Automation last update: 99-10-26

http://www.can-cia.de/EEF.htm [14.11.1999 13:11:25] CAN in Automation Conformance test DeviceNet Page contents:

What is Conformance Testing? More: More informations about the DeviceNet conformance test General introduction What is Conformance Testing? Technical introduction ODVA has established Independent Test Labs to verify conformance Specifications of DeviceNet products to the DeviceNet Specification. The first Test FAQs 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 Page contents: Center at the University of Warwick in Coventry, England and the other at ASTEMRI (Advanced Software Technology and Top Mechatronics Research Institute) in Kyoto, Japan. Advantages & features First information 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 © CAN in Automation last update: 1999-07-23

http://www.can-cia.de/hdc.htm [14.11.1999 13:11:50] ODVA - The Open DeviceNet's Vendor Association

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]

http://www.controlnet.org/ODVA/CONFTEST/conform.htm [14.11.1999 13:12:05] CAN in Automation CAN General introduction CAN Page contents :

What's CAN More: The Attributes of CAN Technical introduction Applications What's CAN ? Specifications The Controller Area Network (CAN) doesn't try to reach Conformance test heaven like the Tower of Babel. CAN is a serial bus system FAQ's especially suited for networking "intelligent" devices as well as sensors and actuators within a system or sub-system. Chips High-speed tranceiver The Attributes of CAN Presentations: CAN is a serial bus system with multi-master capabilities, that is, all CAN nodes are able to transmit data and several CAN Physical Layer nodes can request the bus simultaneously. The serial bus Data Link Layer system with real-time capabilities is the subject of the ISO 11898 international standard and covers the lowest two layers Implementations of the ISO/OSI reference model. In CAN networks there is no Applications 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). Page contents: Each node decides on the basis of the identifier received whether it should process the message or not. The identifier Top also determines the priority that the message enjoys in Whats's CAN competition for bus access. The Attributes of CAN 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

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 More: and industrial control, also increase the CAN sales figures. Up to spring 1999 there are more than 150 million CAN nodes Technical introduction installed. Applications One of the outstanding features of the CAN protocol is its high Specifications transmission reliability. The CAN controller registers a stations Conformance test error and evaluates it statistically in order to take appropriate FAQ's measures. These may extend to disconnecting the CAN node producing the errors. Chips High-speed tranceiver Each CAN message can transmit from 0 to 8 bytes of user information. Of course, you can transmit longer data Presentations: information by using segmentation. The maximum transmission rate is specified as 1 Mbit/s. This value applies to Physical Layer networks up to 40 m. For longer distances the data rate must Data Link Layer 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 Implementations kbit/s is permitted. 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 CAN Page contents:

How does it function More: Principles of data exchange General introduction Non-destructive bitwise arbitration Applications Efficiency of bus allocation Specifications Message frame formats Conformance test Detecting and signalling errors FAQ's Data reliability of the CAN protocol

Extended format CAN message page contents:

Implementations of the CAN protocol Top How does it function Overview - Principles of data CAN controller with intermediate buffer exchange CAN controller with object storage - Non-destructive bitwise CAN slave controllers for I/O functions arbitration - Efficiency of bus Physical CAN connection allocation - Message frame formats How does it function - Detecting and signalling errors Principles of data exchange - Data reliability of the CAN When data are transmitted by CAN, no stations are addressed, protocol but instead, the content of the message (e.g. rpm or engine Extended format CAN temperature) is designated by an identifier that is unique message throughout the network. The identifier defines not only the Implementations of the content but also the priority of the message. This is important CAN protocol for bus allocation when several stations are competing for bus - Overview - CAN controller with access. intermediate buffer If the CPU of a given station wishes to send a message to one - CAN controller with or more stations, it passes the data to be transmitted and their object identifiers to the assigned CAN chip ("Make ready"). This is all storage the CPU has to do: To initiate data exchange. The message is - CAN slave controllers for constructed and transmitted by the CAN chip. As soon as the I/O functions CAN chip receives the bus allocation ("Send Message") all Physical CAN connection 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

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 More: multiple reception (broadcast, multicast) and the synchronization of distributed processes: measurements General introduction needed as information by several controllers can be transmitted Applications via the network, in such a way that it is unnecessary for each Specifications controller to have its own sensor. 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 Broadcast transmission and acceptance filtering by CAN nodes 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

http://www.can-cia.de/ct.htm (2 von 13) [14.11.1999 13:12:55] 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 More: exchanged over the network can differ greatly: a rapidly changing dimension (e.g. engine load) has to be transmitted General introduction more frequently and therefore with less delays than other Applications dimensions (e.g. engine temperature) which change relatively Specifications slowly. Conformance test FAQ's 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 Page contents: design in the form of corresponding binary values and cannot be changed dynamically. The identifier with the lowest binary Top number has the highest priority. How does it function - Principles of data Bus access conflicts are resolved by bitwise arbitration on the exchange identifiers involved by each station observing the bus level bit - Non-destructive bitwise for bit. In accordance with the "wired and" mechanism, by arbitration which the dominant state (logical 0) overwrites the recessive - Efficiency of bus state (logical 1), the competition for bus allocation is lost by all allocation those stations with recessive transmission and dominant - Message frame formats observation. All "losers" automatically become receivers of the - Detecting and signalling message with the highest priority and do not re-attempt errors transmission until the bus is available again. - Data reliability of the CAN Efficiency of bus allocation protocol Extended format CAN The efficiency of the bus allocation system is determined message mainly by the possible applications for a serial bus system. In Implementations of the order to judge as simply as possibly which bus systems are CAN protocol suitable for which applications the literature includes a method - Overview of classifying bus allocation procedures. Generally we - CAN controller with distinguish between the following classes: intermediate buffer - CAN controller with ● Bus allocation on a fixed time schedule object Allocation is made sequentially to each participant for a storage maximum duration regardless of whether this participant - CAN slave controllers needs the bus at this moment or not (examples: token for

http://www.can-cia.de/ct.htm (3 von 13) [14.11.1999 13:12:55] CAN in Automation slot or token passing). I/O functions ● Bus allocation on the basis of need Physical CAN connection 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). 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. More: Another means of assessing the efficiency of bus arbitration systems is the bus access method: General introduction ● Non-destructive bus access applications With methods of this type the bus is allocated to one and Specifications only one station either immediately or within a specified Conformance test time following a single bus access (by one or more FAQ's 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 Page contents: arbitration). ● Destructive bus allocation Top How does it function Simultaneous bus access by more than one station - Principles of data causes all transmission attempts to be aborted and exchange therefore there is no successful bus allocation. More than - Non-destructive bitwise one bus access may be necessary in order to allocate the arbitration bus at all, the number of attempts before bus allocation is - Efficiency of bus successful being a purely statistical quantity (examples: allocation CSMA/CD, Ethernet). - Message frame formats - Detecting and signalling In order to process all transmission requests of a CAN network errors while complying with latency constraints at as low a data - Data reliability of the transfer rate as possible, the CAN protocol must implement a CAN bus allocation method that guarantees that there is always protocol unambiguous bus allocation even when there are simultaneous Extended format CAN bus accesses from different stations. The method of bitwise message arbitration using the identifier of the messages to be implementations of the transmitted uniquely resolves any collision between a number CAN protocol of stations wanting to transmit, and it does this at the latest - overview within 13 (standard format) or 33 (extended format) bit periods - CAN controller with for any bus access period. Unlike the message-wise arbitration intermediate buffer employed by the CSMA/CD method this non-destructive - CAN controller with object method of conflict resolution ensures that no bus capacity is storage used without transmitting useful information. - CAN slave controllers

http://www.can-cia.de/ct.htm (4 von 13) [14.11.1999 13:12:55] CAN in Automation Even in situations where the bus is overloaded the linkage of for the bus access priority to the content of the message proves to I/O functions be a beneficial system attribute compared with existing Physical CAN connection 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. More: Non-destructive bus access can be further classified into General introduction ● centralized bus access control Applications ● decentralized bus access control Specifications depending on whether the control mechanisms are present in Conformance test the system only once (centralized) or more than once FAQ's (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 Page contents: master station. This concept has the disadvantage that the strategy for failure management is difficult and costly to Top implement and also that the takeover of the central station by a How does it function redundant station can be very time-consuming. For these - Principles of data exchange reasons and to circumvent the problem of the reliability of the - Non-destructive bitwise master station (and thus of the whole communication system), arbitration the CAN protocol implements decentralized bus control. All - Efficiency of bus major communication mechanisms, including bus access allocation control, are implemented several times in the system, because - Message frame formats this is the only way to fulfill the high requirements for the - Detecting and signalling availability of the communication system. errors - Data reliability of the In summary it can be said that CAN implements a CAN traffic-dependent bus allocation system that permits, by means protocol of a non-destructive bus access with decentralized bus access Extended format CAN control, a high useful data rate at the lowest possible bus data message rate in terms of the bus busy rate for all stations. The efficiency Implementations of the of the bus arbitration procedure is increased by the fact that the CAN protocol bus is utilized only by those stations with pending transmission - Overview requests. - CAN controller with intermediate buffer These requests are handled in the order of the importance of - CAN controller with the messages for the system as a whole. This proves object especially advantageous in overload situations. Since bus http://www.can-cia.de/ct.htm (5 von 13) [14.11.1999 13:12:55] CAN in Automation access is prioritized on the basis of the messages, it is possible storage to guarantee low individual latency times in real-time systems. - 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 More: the extended format the length is 29 bits. The message frame for transmitting messages on the bus comprises seven main General introduction fields. Applications Specifications A message in the standard format begins with the start bit "start Conformance test of frame", this is followed by the "arbitration field", which contains the identifier and the "RTR" (remote transmission FAQ's 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 Page contents: indicates either standard format or extended format, a bit Top reserved for future extensions and - in the last 4 bits - a count How does it function of the data bytes in the data field. - Principles of data The "data field" ranges from 0 to 8 bytes in length and is exchange - Non-destructive bitwise followed by the "CRC field", which is used as a frame security arbitration check for detecting bit errors. The "ACK field" comprises the - Efficiency of bus ACK slot (1 bit) and the ACK delimiter (1 recessive bit). The bit allocation in the ACK slot is sent as a recessive bit and is overwritten as a - Message frame formats dominant bit by those receivers which have at this time - Detecting and signalling received the data correctly (positive acknowledgement). errors Correct messages are acknowledged by the receivers - Data reliability of the regardless of the result of the acceptance test. The end of the CAN message is indicated by "end of frame". "Intermission" is the protocol minimum number of bit periods separating consecutive Extended format CAN messages. If there is no following bus access by any station, message the bus remains idle ("bus idle"). Implementations of the CAN protocol Detecting and signalling errors - Overview - CAN controller with Unlike other bus systems, the CAN protocol does not use intermediate buffer acknowledgement messages but instead signals any errors - CAN controller with

http://www.can-cia.de/ct.htm (6 von 13) [14.11.1999 13:12:55] CAN in Automation that occur. For error detection the CAN protocol implements object three mechanisms at the message level: storage - CAN slave controllers ● Cyclic Redundancy Check (CRC) for The CRC safeguards the information in the frame by I/O functions adding redundant check bits at the transmission end. At Physical CAN connection 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. ● 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". ● ACK errors As mentioned above, frames received are acknowledged More: by all recipients through positive acknowledgement. If no acknowledgement is received by the transmitter of the General introduction message (ACK error) this may mean that there is a Applications transmission error which has been detected only by the Specifications recipients, that the ACK field has been corrupted or that Conformance test there are no receivers. FAQ's The CAN protocol also implements two mechanisms for error detection at the bit level: ● Monitoring Page contents: The ability of the transmitter to detect errors is based on Top the monitoring of bus signals: each node which transmits How does it function also observes the bus level and thus detects differences - Principles of data between the bit sent and the bit received. This permits exchange reliable detection of all global errors and errors local to - Non-destructive bitwise the transmitter. arbitration ● Bit stuffing - Efficiency of bus allocation The coding of the individual bits is tested at bit level. The - Message frame formats bit representation used by CAN is NRZ - Detecting and signalling (non-return-to-zero) coding, which guarantees maximum errors efficiency in bit coding. The synchronization edges are - Data reliability of the generated by means of bit stuffing, i.e. after five CAN consecutive equal bits the sender inserts into the bit protocol stream a stuff bit with the complementary value, which is Extended format CAN removed by the receivers. The code check is limited to message checking adherence to the stuffing rule. Implementations of the CAN protocol If one or more errors are discovered by at least one station - Overview (any station) using the above mechanisms, the current - CAN controller with transmission is aborted by sending an "error flag". This intermediate buffer

http://www.can-cia.de/ct.htm (7 von 13) [14.11.1999 13:12:55] CAN in Automation prevents other stations accepting the message and thus - CAN controller with ensures the consistency of data throughout the network. object storage After transmission of an erroneous message has been aborted, - CAN slave controllers the sender automatically re-attempts transmission (automatic for repeat request). There may again be competition for bus I/O functions allocation. As a rule, retransmission will be begun within 23 bit Physical CAN connection 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 More: with the aim of recognizing a station's own defects and possibly entering an operating mode where the rest of the CAN network General introduction is not negatively affected. This may go as far as the station Applications switching itself off to prevent messages erroneously recognized Specifications as incorrect from being aborted. Conformance test FAQ's Data reliability of the CAN protocol

The introduction of safety-related systems in automobiles brought with it high requirements for the reliability of data Page contents: transmission. The objective is frequently formulated as not Top permitting any dangerous situations for the driver to occur as a How does it function result of data exchange throughout the whole life of a vehicle. - Principles of data This goal is achieved if the reliability of the data is sufficiently exchange high or the residual error probability is sufficiently low. In the - Non-destructive bitwise arbitration context of bus systems data, reliability is understood as the - Efficiency of bus capability to identify data corrupted by transmission faults. The allocation residual error probability is a statistical measure of the - Message frame formats impairment of data reliability: It specifies the probability that - Detecting and signalling data will be corrupted and that this corruption will remain errors undetected. The residual error probability should be so small - Data reliability of the that on average no corrupted data will go undetected CAN throughout the whole life of a system. protocol Extended format CAN message Implementations of the CAN protocol - Overview - CAN controller with

http://www.can-cia.de/ct.htm (8 von 13) [14.11.1999 13:12:55] 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 More: errors which occur be classified and that the whole transmission path be described by a model. If we determine the General introduction residual error probability of CAN as a function of the bit error Applications probability for message lengths of 80 to 90 bits, for system configurations of, for instance, five or ten nodes and with an Specifications error rate of 1/1000 (an error in one message in every Conformance test thousand), then maximum bit error probability is approximately FAQ's 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. Page contents:

For example, if a CAN network operates at a data rate of 1 Top Mbit/s, at an average bus capacity utilization of 50 percent, for How does it function a total operating life of 4000 hours and with an average - Principles of data message length of 80 bits, then the total number of messages exchange transmitted is 9 x 1010. The statistical number of undetected - Non-destructive bitwise transmission errors during the operating life is thus in the order arbitration of less than 10-2. Or to put it another way, with an operating - Efficiency of bus time of eight hours per day on 365 days per year and an error allocation rate of 0.7 s, one undetected error occurs every thousand - Message frame formats - Detecting and signalling years (statistical average). errors - Data reliability of the Extended format CAN message CAN protocol The SAE "Truck and Bus" subcommittee standardized signals Extended format CAN and messages as well as data transmission protocols for message various data rates. It became apparent that standardization of Implementations of the this kind is easier to implement when a longer identification CAN protocol field is available.

http://www.can-cia.de/ct.htm (9 von 13) [14.11.1999 13:12:55] CAN in Automation - Overview To support these efforts, the CAN protocol was extended by - CAN controller with the introduction of a 29-bit identifier. This identifier is made up intermediate buffer of the existing 11-bit identifier (base ID) and an 18-bit extension - CAN controller with (ID extension). Thus the CAN protocol allows the use of two object message formats: StandardCAN (Version 2.0A) and storage ExtendedCAN (Version 2.0B). As the two formats have to - CAN slave controllers coexist on one bus it is laid down which message has higher for priority on the bus in the case of bus access collisions with I/O functions differing formats and the same base identifier: The message in Physical CAN connection 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 More: format. For frames in extended format it is recessive. General introduction The RTR bit is transmitted dominant or recessive depending on Applications whether data are being transmitted or whether a specific Specifications message is being requested from a station. In place of the RTR Conformance test bit in standard format the SRR (substitute remote request) bit is FAQ's 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 Page contents: base identifier. Top Unlike the standard format, in the extended format the IDE bit How does it function is followed by the 18-bit ID extension, the RTR bit and a - Principles of data exchange reserved bit (r1). - Non-destructive bitwise All the following fields are identical with standard format. arbitration Conformity between the two formats is ensured by the fact that - Efficiency of bus the CAN controllers which support the extended format can allocation also communicate in standard format. - Message frame formats - Detecting and signalling errors - Data reliability of the

http://www.can-cia.de/ct.htm (10 von 13) [14.11.1999 13:12:55] CAN in Automation CAN protocol Extended format CAN message Message frame for extended format (CAN specification 2.0B) Implementations of the Implementations of the CAN protocol CAN protocol - Overview Overview - CAN controller with intermediate buffer Communication is identical for all implementations of the CAN - CAN controller with protocol. There are differences, however, with regard to the object storage extent to which the implementation takes over message - CAN slave controllers transmission from the microcontrollers which follow it in the for circuit. I/O functions Physical CAN connection 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

http://www.can-cia.de/ct.htm (11 von 13) [14.11.1999 13:12:55] 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).

http://www.can-cia.de/ct.htm (12 von 13) [14.11.1999 13:12:55] CAN in Automation

Physical CAN Connection according to ISO 11898

http://www.can-cia.de/ct.htm (13 von 13) [14.11.1999 13:12:55] CAN in Automation Conformance test CAN More:

The CAN Conformance test plan standardized in ISO WD General introduction 16845 specifies the methodology and the abstract test suite Technical introduction necessary to check the conformance of any CAN Applications implementation to the harmonized CAN specification. The test plan is a specific application of ISO 9646-1. The test plan Specifications environment consists of a lower tester, the IUT FAQ's (implementation under test), and the upper tester running on a Chips microcontroller, for example. Since the message storaging capability, the hardware acceptance filter, and the CPU High-speed tranceiver interface are not standardized, the only link between lower Presentations: tester and IUT are the PLS-Data.indicate and PLS-Data.request interfaces. Physical Layer The abstract test suites are independent one another. Each Data Link Layer test suite checks the behaviour of the IUT for a particular Implementations parameter of the CAN specification. The test cases are grouped to received frame type cases, to transmitted frame Applications type cases, and to bidirectional frame type cases. Each test More: type is subdivided in six test classes: ● Valid frame format class General introduction ● Error detection class Technical introduction ● Active error frame management class Applications ● Overload frame class Specifications FAQ's ● Passive error state and bus-off class ● Bit timing class Chips High-speed tranceiver The CAN Conformance test plan is implemented by two different test service providers. These are the German Presentations: "Fachhochschule Braunschweig/Wolfenbüttel" (University of Applied Science) and the French company Dassault Physical Layer Electronique. Data Link Layer The German "Fachhochschule Braunschweig/Wolfenbüttel" Implementations under Prof. Dr. W. Lawrenz provides a certificate which is mainly used by the chip manufacturer and the German Applications automotive industry. © CAN in Automation last update: 1999-07-23

http://www.can-cia.de/cc.htm [14.11.1999 13:13:05] CAN in Automation CAN Applications CAN Page contents:

Overview More: The need for serial communication in vehicles General introduction Use of the CAN in vehicles Technical introduction Industrial application of the CAN Specifications Conformance test Overview FAQ's CAN networks can be used as an embedded communication system for microcontrollers as well as an open communication Chips system for intelligent devices. High-speed tranceiver The CAN serial bus system, originally developed for use in Presentations: automobiles, is increasingly being used in industrial as well as building automation, medical equipment and maritime Physical Layer electronics. If the requirements for passenger cars networks Data Link Layer are compared with those for industrial field bus systems, the Implementations similarities are remarkable. In both cases some of the major requirements are: Low cost, the ability to function in a difficult Applications electrical environment, a high degree of real-time capability

and ease of use. Page contents: Some users, for example in the field of medical engineering, opted for CAN because they have to meet particulary stringent Top safety requirements. Similar problems are faced by Overview manufacturers of other equipment with very high safety or The need for serial reliability requirements (e. g. robots, lifts and transportation communication in systems). vehicles Use of the CAN in The need for serial communication in vehicles vehicles Industrial application of Many vehicles already have a large number of electronic the CAN 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 in Automation dedicated signal lines, but this is becoming increasingly More: difficult and expensive as control functions become ever more complex. In the case of complex control systems (such as General introduction Motronic) in particular, the number of connections cannot be Technical introduction increased much further. Specifications Moreover, a number of systems are being developed, which Conformance test implement functions covering more than one control device. FAQ's For instance, ASC requires the interplay of engine timing and carburettor control in order to reduce torque when drive wheel Chips slippage occurs. Another example of functions spanning more High-speed tranceiver than one control unit is electronic gearbox control, where ease of gear-changing can be improved by a brief adjustment to Presentations: ignition timing. Physical Layer If we also consider future developments aimed at overall Data Link Layer vehicle optimization, it becomes necessary to overcome the limitations of conventional control device linkage. This can Implementations only be done by networking the system components using a Applications 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 Page contents: been "implemented in silicon" by several semiconductor manufacturers. Top Overview Using CAN, peer stations (controllers, sensors and actuators) The need for serial are connected via a serial bus. The bus itself is a symmetric or communication in asymmetric two wire circuit, which can be either screened or vehicles unscreened. The electrical parameters of the physical Use of the CAN in transmission are also specified in ISO 11898. Suitable bus vehicles driver chips are available from a number of manufacturers. Industrial application of the CAN 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, More: 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.

http://www.can-cia.de/cga.htm (2 von 4) [14.11.1999 13:13:13] CAN in Automation Networking controllers for engine timing, transmission, chassis General introduction and brakes. The data rates are in the range - typical of Technical introduction real-time systems - of 200kBit/s to 1Mbit/s. Specifications Networking components of chassis electronics and Conformance test electronics, which make the vehicle more comfortable. FAQ's Examples of such multiplex applications are lighting control, air-conditioning, central locking, and seat and mirror Chips adjustment. Particular importance has to be attached here to High-speed tranceiver the cost of the components and wiring requirements. Typical Presentations: data rates are around 50kBit/s. In the near future, serial communication will also be used in Physical Layer the field of mobile communication in order to link components Data Link Layer such as car radios, car telephones, navigation aids etc. to a central, ergonomically designed control panel. The functions Implementations defined in the Prometheus project, such as vehicle-to-vehicle Applications and vehicle-to-infrastructure communication will depend to a large extent on serial communication. Page contents: At present, CAN can be used for the first three applications, but for diagnosis the preferred solution is an interface Top according to ISO 9141. Overview The need for serial Industrial applications of the CAN communication in vehicles A comparison of the requirements for vehicle bus systems and Use of the CAN in industrial field bus systems shows amazing similarities: Low vehicles cost, operability in a harsh electrical environment, high Industrial application of real-time capabilities and ease of use are equally desirable in the CAN 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 More: manufacturers of mobile and stationary agricultural and nautical machinery and equipment have chosen to use CAN, General introduction is has also been the choice of manufacturers of medical Technical introduction apparatus, textile machines, special-purpose machinery and Specifications elevator controls. The serial bus system is particularly well Conformance test suited to networking "intelligent" I/O devices as well as FAQ's sensors and actuators within a machine or plant. Chips The textile machinery industry is one of the pioneers of CAN. One manufacturer equipped his looms with modular control High-speed tranceiver systems communicating in real time via CAN networks as Presentations: early as 1990. In the meantime several textile machinery manufacturers have joined together to form the "CAN Textile Physical Layer Users Group", which in turn is a member of the international

http://www.can-cia.de/cga.htm (3 von 4) [14.11.1999 13:13:13] CAN in Automation users and manufacturers group "CAN in Automation". Similar Data Link Layer requirements to those of the textile machinery are to be found in packaging machinery and machinery for paper manufacture Implementations and processing. Applications In the USA a number of enterprises are using CAN in production lines and machine tools as an internal bus system Page contents: for networking sensors and actuators within the line or machine. Top Overview Some users, for instance in the medical engineering sector, The need for serial decided in favour of CAN because they had particularly communication in stringent safety requirements. Similar problems are faced by vehicles other manufacturers of machinery and equipment with Use of the CAN in particular requirements with respect to safety (e.g. robots and vehicles transport systems). Industrial application of the CAN 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.

http://www.can-cia.de/cga.htm (4 von 4) [14.11.1999 13:13:13] CAN in Automation Frequently asked question CAN Please send your questions to: [email protected]

More: General introduction coming soon 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 News CAN-related standards

There are several official national and international standardization bodies as More: 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 Hot News claim for completeness. CiA News Standard Organization Topic Main Applications CAN Newsletter State Press Release CAN Data Link Layer and Physical Layer IS 11898 (Nov. ISO TC22 SC3 WG1 TF1 + CAN Data Link Layer Automotive and General 1993 + Amendment TF6 and Transceiver(s) Purpose 1 (1995) IS 11519-2 ISO TC22 SC3 WG1 TF1 + CAN Low-Speed Car Body Electronics TF6 Transceiver and Data Link Layer CD 16845 ISO TC22 SC3 WG1 TF6 CAN Conformance General Testing J2284 SAE CAN High-Speed Automotive Interface Draft J2411 SAE Single-Wire Physical Car Body Electronics Layer

CAN-Related Standards for Vehicles

IS 11992-1, -2, -3 ISO TC22 SC3 WG1 CAN Low-Speed Truck & Trailer TF4 Transceiver + Application (under review) Layer CD 15765-1, -2, -3, ISO TC22 SC3 WG1 Diagnostics on CAN Automotive -4 TF2 CD 15031-3 ISO TC22 SC3 WG1 OBDII Diagnostics Automotive TF5 (SAE) (J1962) CD 16844-4, -5 ISO TC22 SC3 WG1 CAN for Tachograph Truck and Buses More: TF7 Systems WD 11783 ISO TC23 SC19 WG1 J1939-based Serial Control Agriculture and Forestry Hot News and Communications CiA News CD 717617 ISO TC173 SC1 WG7 M3S Network Wheelchairs CAN Newsletter CCP ASAM e.V. CAN Calibration Protocol Passenger Cars Press Release J1939-01 to SAE Serial Vehicle Network Truck and Buses J1939-81

DIN 9684 DIN e.V. Landwirtschaftliches Bus Agriculture and Forestry System (LBS) WDP-407 CiA/VDV (CLC TC278 CANopen Application Driver and Passenger (prEN61349-2) WG3 SG1) Profile for Public Information Transportation WDP-4XX CiA CANopen Special CANopen Device Profiles Mobile Machinery Interest Groups for Off-Road Vehicles WDP-4XX CiA CANopen SIG CANopen Device Profiles Passenger-Trains and Railways for Railways Cargo-Trains

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

CAN Kingdom Kvaser/CANHUG Application Layer and Off-Road Vehicles and Profiles General Purpose

New Work Item ISO TC22 SC3 WG1 OSEK-NM, OSEK-COM Automotive Proposal (OSEK Group)

CAN-Related Standards for Industrial Automation and General Purpose Control Systems WD 15745-2 ISO TC184 SC5 WG 5 Application Framework Industrial Automation for CAN-based Networks DS-201...207 CiA IG CAL CAN Application Layer General Purpose PrEN50325-4 CLC TC 65CX/CiA IG CANopen General Purpose More: CANopen Communication Profile (DS-301) Hot News DSP-302 CiA CANopen SIG CANopen Framework for General Purpose Programmable Devices Programmable Devices CiA News WD-304 CiA CANopen SIG CANopen Framework for Safety-relevant Systems CAN Newsletter Safety Safety-relevant Systems Press Release DSP-4XX, WD-4XX CiA CANopen Special CANopen Device Profiles Industrial Automation Interest Groups for Industrial Control and General Purpose

FDIS 62026-3 IEC TC17B WG3 DeviceNet Specification Low-voltage switchgear and controlgear FDIS 62026-5 SDS Specification PrEN 50325-2 CLC TC 65CX DeviceNet Specification Low-voltage switchgear and controlgear PrEN 50325-3 SDS Specification DeviceNet Release ODVA DeviceNet Specification Industrial Automation 2.0 SDS Version 2.0 Honeywell SDS Specification Industrial Automation NMEA 2000 National Marine J1939-based Application Navigation Systems Electronics Association Layer WDP-3XX CiA IG Maritime CANopen Framework for Marine Application Maritime Application CDA 101 Target Reliance Office CAN Kingdom-based Target Control Systems of DoD Data Layer in US Navy, USAF and Army

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 News Page contents:

CAN Sales Figures More: 6th international CAN Conference Hot News Worldwide unique Manufacturer Name for CANopen CiA News Certified CANopen Products CAN Newsletter ISO 11898 under Review Standardization CANopen Version 4.0 with enhanced features CANopen SIG Safety CANopen SIG Hydraulics Page contents: CANopen Devices for Railways CANopen SIG Maritime Electronics Top CAN Sales Figures CiA: 320 Members Worldwide 6th iCC CANopen in Railways Unique CANopen Name CANopen in Off-Road Vehicles Certified CANopen CiA Study Groups Products CAN-based Higher Layer Protocol Standardization ISO 11898 under Review CANopen Version 4.0 CiA In-house Seminars CANopen SIG Safety Framework for Programmable CANopen Devices CANopen SIG Hydraulics CANopen for Railways CANopen SIG Maritime CAN Sales Figures CiA: 320 Members CANopen in Railways Off-Road Vehicles CiA Study Groups Higher Layer Protocol CiA In-house Seminars DSP-302 Version 2.0

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 More: respond to the questionnaire. Sales figures for 2000 and the following years do not include all expected CAN nodes in cars Hot News produced in USA and Far East. Also not included are new CiA News application fields such as domestic appliances and other high-volume embedded systems. By beginning of this year, CAN Newsletter there were installed more than 140 millions of CAN controllers. Standardization

6th international CAN Conference Page contents: Erlangen (Germany), 1999-07-05. From 2nd to 5th November, CAN in Automation (CiA) international users and Top manufacturers group is organizing the 6th international CAN CAN Sales Figures Conference (iCC) in Torino (Italy). The iCC is accompanied by 6th iCC workshops and seminars as well as a table-top exhibition with Unique CANopen Name more than 35 companies participating. In addition, there will be Certified CANopen Products poster sessions and product presentations. Entrance to the ISO 11898 under Review exhibition, poster and product presentations is free. This most CANopen Version 4.0 important event for the CAN community is sponsored by the CANopen SIG Safety Jackson group, an Italian publishing house, and several CAN CANopen SIG chip suppliers (Hitachi, Infineon, Mitsubishi, Motorola, and Hydraulics NEC). CANopen for Railways CANopen SIG Maritime Detailed iCC Program CiA: 320 Members CANopen in Railways Worldwide unique Manufacturer Name for CANopen Off-Road Vehicles CiA Study Groups Erlangen (Germany), 1999-07-05. The recently published Higher Layer Protocol CANopen specification version 4.0 requires a worldwide CiA In-house Seminars unique manufacturer name. The CAN in Automation (CiA) DSP-302 Version 2.0 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

http://www.can-cia.de/NP.htm (2 von 14) [14.11.1999 13:13:53] CAN in Automation CANopen Version 3.0. The CANopen conformance testing specification was developed by CiA Members and More: implemented by National Instruments and the Technical University of Braunschweig. I/O modules from Beckhoff, the Hot News linear position sensor from MTS, the adapter board for CiA News Siemens drives from Intulogic, the adapter modules from HMS, and the drive controllers from Yaskawa and Omron CAN Newsletter have been already tested successfully by the CiA Test Standardization 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. Page contents:

ISO 11898 under Review Top CAN Sales Figures Erlangen, 1999-05-17. The regularly required review and 6th iCC update of the ISO 11898 standard will include the features Unique CANopen Name described in the implementation guideline published by Bosch. Certified CANopen Products In addition, the standard will specify different physical layers. ISO 11898 under Review Besides the high-speed transceiver, it will describe also a CANopen Version 4.0 fault-tolerant transceiver. Several clarifications have been CANopen SIG Safety included, such as use of DLC, identifier restrictions, and bit CANopen SIG timing requirements. The most important optional feature Hydraulics added to the CAN standard will be the time-triggered CANopen for Railways communication (TTC) option. CANopen SIG Maritime The new ISO 11898 document will be completely restructured CiA: 320 Members and divided in two parts: ISO 11898-1 specifies the CAN data CANopen in Railways link layer and the LLC sub-layer, ISO 11898-2 describes the Off-Road Vehicles MAU sub-layer of the so-called high-speed transceiver for data CiA Study Groups rates up to 1 Mbit/s. Later on, the specification of fault-tolerant Higher Layer Protocol low-speed physical layer will be added as part 3 (ISO CiA In-house Seminars 11898-3). The updated specification is compliant to the CAN DSP-302 Version 2.0 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

http://www.can-cia.de/NP.htm (3 von 14) [14.11.1999 13:13:53] 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 More: only the IDE bit decides whether the frame is a Standard or an Extended frame. Hot News The harmonized CAN standard also clarifies that a dominant CiA News bit in the last bit of End of Frame (EOF) field will force the receiver to transmit an Overload frame. The transmitter CAN Newsletter interprets a dominant value in the last bit of EOF as the start of Standardization 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. Page contents: Synchronization rule 4 in the CAN standard requires the Hard Synchronization to be performed at every edge from Top CAN Sales Figures recessive-to-dominant during Bus Idle. Additionally Hard 6th iCC Synchronization is required for each received Start of Frame Unique CANopen Name (SOF). A SOF can be received not only during Bus Idle, but Certified CANopen also during Suspend Transmission and at the end of Products Intermission. Therefore, the reviewed CAN standard enables ISO 11898 under Review the Hard synchronization also for Suspend state and for the CANopen Version 4.0 end of the Intermission state as the CAN Reference Models CANopen SIG Safety do. CANopen SIG The restriction regarding the identifier range in the former CAN Hydraulics specifications will be not more valid in the reviewed CAN CANopen for Railways standard. This means, CAN controller compliant with ISO CANopen SIG Maritime 11898 may support all identifiers in the range of 0 to 2047. If CiA: 320 Members the IDE bit is recessive, also the other identifiers have to be CANopen in Railways supported. Off-Road Vehicles The reviewed CAN specification specifies an optional Bus CiA Study Groups Higher Layer Protocol Monitoring Mode. In this mode the CAN node is able to CiA In-house Seminars receive valid data frames and valid remote frames, but it DSP-302 Version 2.0 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 http://www.can-cia.de/NP.htm (4 von 14) [14.11.1999 13:13:53] 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 - More: 1) x timer clocks. In order to achieve high accuracy - maximum ±1 time quantum - these mechanisms have to be implemented Hot News in silicon. The time-triggered message do not compete with CiA News others to access the bus, because the single-shot option (disabling of automatic retransmission after error detection) CAN Newsletter guarantees that the next time-slot is not used by retransmitted Standardization 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 Page contents: protocols. Such protocols have to be developed and will be Top different for different application fields. CAN Sales Figures 6th iCC CANopen Version 4.0 with enhanced features Unique CANopen Name Certified CANopen Erlangen, 1999-05-17. In summer 1999, CiA Interest Group Products CANopen is going to release the version 4.0 of the CANopen ISO 11898 under Review Communication Profile. It specifies some new functions such CANopen Version 4.0 as timer-driven PDO transmission, SDO block transfer, and CANopen SIG Safety heartbeat message. Besides these functional enhancements, CANopen SIG the profile describes also all used functions of the CAN Hydraulics Application Layer (CiA DS-201 to DS-207) except the Layer CANopen for Railways Management (LMT). CANopen SIG Maritime The CiA DS-301 Version 4.0 document is completely CiA: 320 Members restructured and meets the requirements of Cenelec. This is, CANopen in Railways because this specification is going to be submitted for Off-Road Vehicles European standardization as part 4 of the prEN 50325 (ISO CiA Study Groups 11898-based Controller-device interfaces) standard. The Higher Layer Protocol specification includes models for devices, communication CiA In-house Seminars services as well as the reference model according to ISO DSP-302 Version 2.0 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

http://www.can-cia.de/NP.htm (5 von 14) [14.11.1999 13:13:53] CAN in Automation occurrence of an object-specific event or if a specified time has elapsed without occurrence of an event. The time is More: described in the PDO communication parameter set and it can be configured via Service Data Objects (SDO). Hot News Optionally a segmented communication can be transmitted CiA News with SDO Block Download or SDO Block Upload. These may be used to achieve higher bus throughputs. In the standard CAN Newsletter SDO download and upload services each segment is Standardization 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 Page contents: number of segments per block is 128. In order to verify the correctness of a SDO block transfer, client and server Top CAN Sales Figures calculate a CRC sequence (Cyclic Redundancy Checksum), 6th iCC this is exchanged and verified within the confirmed End SDO Unique CANopen Name Block message. The check polynominal can be calculated Certified CANopen from a formula or a table given in the CANopen specification. Products One of the minor changes is the renaming of the Prepared ISO 11898 under Review State into Stopped State. In the Stopped State, a device is CANopen Version 4.0 forced to stop communication objects. It can only receive CANopen SIG Safety Network Management Objects, and it can perform node CANopen SIG guarding, if active. This state can be used to achieve certain Hydraulics application behavior specified by device profiles. CANopen for Railways The new Boot-up Protocol is used to signal that a NMT slave CANopen SIG Maritime has entered the node state Pre-operational after the state CiA: 320 Members Initializing. The Boot-up message uses the same identifier as CANopen in Railways the Error Control Protocols, and contains one data byte with Off-Road Vehicles the fixed value of zero. Version 4.0 specifies two Error Control CiA Study Groups Higher Layer Protocol Protocols: The already used Node Guarding Protocol and the CiA In-house Seminars new Heartbeat Protocol. One of these protocols has to be DSP-302 Version 2.0 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, http://www.can-cia.de/NP.htm (6 von 14) [14.11.1999 13:13:53] CAN in Automation Guarding Protocol and Heartbeat Protocol, at the same time. If the Heartbeat Producer Time is unequal 0, the Heartbeat More: Protocol is used. It is recommended to use the Heartbeat Protocol in order to avoid remote frames. Hot News In order to reduce configuration effort for simple CANopen CiA News networks, a mandatory default identifier allocation scheme is defined. These identifiers are available in the Pre-operational CAN Newsletter state directly after the first initialization. If the device provides Standardization 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. Page contents: The identifiers for Sync, Time stamp, and Emergency messages as well as for PDOs may be modified by means of Top CAN Sales Figures dynamic distribution. Of course, a device has to provide the 6th iCC corresponding identifiers only for the supported Unique CANopen Name communication objects. The identifiers for the NMT message, Certified CANopen the Default SDO, and the NMT Error Control message must Products not be changed. ISO 11898 under Review The default ID allocation scheme consists of a functional part, CANopen Version 4.0 which determines the object priority and a Node-ID-part, which CANopen SIG Safety allows distinguishing between devices of the same CANopen SIG functionality. This allows a peer-to-peer PDO communication Hydraulics between a single master and up to 127 slave devices. It also CANopen for Railways supports the broadcasting of unconfirmed NMT objects, Sync, CANopen SIG Maritime and Time-stamp message. In version 4.0, the pre-defined CiA: 320 Members connection set supports at maximum 4 Receive-PDOs and 4 CANopen in Railways Transmit-PDOs. The CANopen Framework for Off-Road Vehicles Safety-Relevant Communication reserves the identifier range CiA Study Groups Higher Layer Protocol from 257 to 384 for safety-relevant data objects specified. CiA In-house Seminars Using CANopen in that different application fields, such DSP-302 Version 2.0 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 http://www.can-cia.de/NP.htm (7 von 14) [14.11.1999 13:13:53] CAN in Automation indicated by the error code 8140. The error code 8130 is transmitted, if a node recovers from bus-off state. More: CANopen SIG Safety Hot News Erlangen, 1999-05-17. The CANopen Special Interest Group CiA News (SIG) Safety is specifying a CANopen Framework for CAN Newsletter Safety-relevant Systems. In the first proposal, Safety-Relevant Standardization 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 Page contents: should avoid a redundant CANopen network. In addition, each SDRO is assigned with a configurable time-out. The receiving Top nodes will switch to a failsafe state, if the SDRO is not CAN Sales Figures correctly received within the configured time. In addition, the 6th iCC framework will specify so-called global emergency switch Unique CANopen Name messages transmitted in broadcast. The framework will also Certified CANopen Products specify to use only the new heartbeat error control ISO 11898 under Review mechanism. CANopen Version 4.0 CANopen SIG Safety CANopen SIG Hydraulics CANopen SIG Hydraulics Erlangen, 1999-05-17. The recently established CANopen SIG CANopen for Railways Hydraulics is working on the CANopen Device Profile for CANopen SIG Maritime Proportional Hydraulic Valves based on the bus-independent CiA: 320 Members VDMA-Profile. Later, the CiA WD-408 device profile will CANopen in Railways describe also hydraulic drives. The work draft proposal already Off-Road Vehicles available for CiA members describes the application object CiA Study Groups attributes, and defines the default mapping of the Process Higher Layer Protocol Data Objects (PDO). The profile covers very simple valves as CiA In-house Seminars well as more intelligent devices providing position or pressure DSP-302 Version 2.0 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.

http://www.can-cia.de/NP.htm (8 von 14) [14.11.1999 13:13:53] CAN in Automation CANopen SIG Maritime Electronics More: Erlangen, 1999-05-17. The CANopen SIG Maritime Electronics was established in April. The scope of the group is Hot News the specification of a CANopen Framework for Maritime CiA News Applications. It will specify additional network management CAN Newsletter functionality as well as implementation guidelines for redundant CANopen networks. In addition, the SIG will define Standardization maritime-specific device profiles, in particular gateways to maritime-specific subsystems such as engine control, fire-fighting systems, etc. The publication of the CANopen Page contents: framework is scheduled for end of this year. Top CAN Sales Figures CiA: 320 Members Worldwide 6th iCC Unique CANopen Name Erlangen, 1999-01-12. The CAN in Automation (CiA) Certified CANopen international users and manufacturers group, founded in 1992, Products was joined by 320 companies and non-profit institutes (1999, ISO 11898 under Review January 1st). The trade organization promotes the CAN CANopen Version 4.0 (Controller Area Network) serial bus system. Besides general CANopen SIG Safety marketing activities, CiA Headquarters organize technical CANopen SIG conferences, workshops, and in-house seminars. Members of Hydraulics the non-profit association specify higher-layer protocols such CANopen for Railways as CAL (CAN Application Layer) and CANopen as well as CANopen SIG Maritime additional physical layer recommendations, e.g. baud-rates, CiA: 320 Members bit-timings, and pin assignments of connectors. In the CiA CANopen in Railways Office located in Erlangen (Germany), seven secretaries Off-Road Vehicles provide worldwide technical, marketing and product CiA Study Groups information intelligence. Higher Layer Protocol (Remark: daughter companies and subsidiaries are CiA In-house Seminars DSP-302 Version 2.0 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

http://www.can-cia.de/NP.htm (9 von 14) [14.11.1999 13:13:53] CAN in Automation

Erlangen, 1999-01-12. On behalf of the VDMA (Verband Deutscher Maschinen- und Anlagenbauer) working group for More: building machine, the University of Magdeburg has pre-developed some CANopen Device Profiles. The profiles Hot News for diesel engine, electronic gear, joystick, slope control, and CiA News hydraulics were handed over to the CAN in Automation (CiA) CAN Newsletter international users and manufacturers group in order to review Standardization these documents and to become CiA standards. The hydraulics profile should be harmonized with the bus-independent profile framework developed by the VDMA Page contents: working group for fluid control. Beginning of February, CiA is going to establish related CANopen SIGs (Special Interest Top Groups). 6th iCC Unique CANopen Name CiA Study Groups Certified CANopen Products Erlangen, 1999-01-12. The CAN in Automation (CiA) ISO 11898 under Review international users and manufacturers group is calling for CANopen Version 4.0 Study Groups (SG) on "OSEK and CANopen" as well as CANopen SIG Safety "Maritime Electronics". Users of the CANopen Profile Family, CANopen SIG especially off-road vehicle manufacturers, bus and truck Hydraulics makers, as well as some industrial device providers requested CANopen for Railways a standardized operating system interface for CANopen CANopen SIG Maritime implementation. In passenger cars OSEK-OS is the most CiA: 320 Members CANopen in Railways successful operating system specification for real-time Off-Road Vehicles applications. In the according SG the possibility to combine CiA Study Groups OSEK-OS and CANopen will be discussed. Higher Layer Protocol Several providers of maritime electronics have already used CiA In-house Seminars CAN-based network for ship automation. The CiA SG Maritime DSP-302 Version 2.0 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 More:

Erlangen, 1999-01-12. CAN-based higher layer protocols for Hot News industrial and general-purpose control applications are well CiA News established. DeviceNet and Smart Distributed System (SDS) CAN Newsletter are already submitted to IEC and Cenelec in order to become Standardization 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

http://www.can-cia.de/NP.htm (10 von 14) [14.11.1999 13:13:53] CAN in Automation other hand, there could be an overlapping with the ISO 11992 Page contents: standard, which is the CAN-based truck-trailer interface. OSEK/VDX, the higher-layer protocol for passenger cars, is Top not yet submitted to ISO for international standardization. 6th iCC Unique CANopen Name CiA In-house Seminars Certified CANopen Products Erlangen, 1999-01-12. Last year, CiA started to offer in-house ISO 11898 under Review seminars on CAN technology. Topics were CAN protocol and CANopen Version 4.0 implementations, CAN physical layer options, CAN CANopen SIG Safety applications, and CAN-based higher-layer protocols. CiA CANopen SIG trainers educated several hundred engineers. Due to the Hydraulics success of these in-house seminars and the continuing CANopen for Railways demands, CiA will also offer this service in 1999. The price for CANopen SIG Maritime CiA: 320 Members 1-day seminar is 450 EUR plus travel and hotel expenses. CANopen in Railways Off-Road Vehicles Framework for Programmable CANopen Devices CiA Study Groups Higher Layer Protocol Erlangen, 1999-01-12. The CAN in Automation (CiA) CiA In-house Seminars international users and manufacturers group has updated the DSP-302 Version 2.0 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 More: Multiplexor PDO specification was clarified. The DSP-302 specification also introduces some new configuration objects Hot News for these Multiplexor PDOs. CiA News © CAN in Automation CAN Newsletter last update: 1999-08-15 Standardization

Page contents:

http://www.can-cia.de/NP.htm (11 von 14) [14.11.1999 13:13:53] CAN in Automation CANopen in Railways Off-Road Vehicles CiA Study Groups Higher Layer Protocol CiA In-house Seminars DSP-302 Version 2.0

Hot News CiA News CAN Newsletter Standardization

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

http://www.can-cia.de/NP.htm (12 von 14) [14.11.1999 13:13:53] CAN in Automation

Hot News CiA News CAN Newsletter Standardization

Page contents:

Hot News CiA News CAN Newsletter Standardization

http://www.can-cia.de/NP.htm (13 von 14) [14.11.1999 13:13:53] CAN in Automation Page contents:

http://www.can-cia.de/NP.htm (14 von 14) [14.11.1999 13:13:53]