can_org (1)

CAN HLP Members only Map home

CAN in Automation (CiA)international users and manufacturers group

Founded in March 1992, CiA provides technical, product andmarketing information with the aim of fostering Controller AreaNetwork’s image and providing a path for future developmentsof the CAN protocol. The non-profit trade association with apersistently increasing number of members develops andsupports various CAN-based higher layer protocols: CANApplication Layer (CAL), CAN Kingdom, CANopen, DeviceNet.

CAN Information inDutch

Higher layerprotocols (HLP)- General introduction- CANopen- Devicenet- CAN Kingdom

CAN the bus

- General introduction- Specifications- Controller- Applications

CiA membersonly- CiA specifications- Technical info- Marketing info

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

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

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

http://www.can-cia.de/intern/m.htm



http://www.can-cia.de/start.htm


http://www.can-cia.de/amgbdi.htm



http://www.can-cia.de/hkg.htm




http://www.can-cia.de/intern/dm.htm



Higher Layer Protocols HLPDeviceNet

General introduction

Technical introduction

Specifications

Conformance test

FAQs

CAN Application LayerGeneral introduction


Specifications

CANopenGeneral introduction


Specifications

Conformance test

FAQs

Vendor list

CAN KingdomGeneral introduction


Specifications

© CAN in Automation

last update: 1999-07-26

CAN in Automation

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

http://206.103.159.87/ODVA/WATSNEW/drDN-A/drdevnet.html

http://www.can-cia.de/hag.htm

http://www.can-cia.de/hat.htm


http://www.can-cia.de/hkt.htm

General introduction DeviceNetPage contents:

Features and functionalityFirst information

Features and functionality

NetworkSize

Up to 64 nodes

NetworkLength

Selectable end-to-end network distance varies with speed

Baud Rate Distance125 Kbps 500 m (1,640 ft)

250 Kbps 250 m (820 ft)

500 Kbps 100 m (328 ft)

DataPackets

0-8 bytes

BusTopology

Linear (trunkline/dropline); power and signal on the samenetwork cable

BusAddressing

Peer-to-Peer with Multi-Cast (one-to-many); Multi-Master andMaster/Slave special case; polled or change-of-state(exception-based)

SystemFeatures

Removal and replacement of devices from the network underpower

First information

DeviceNet is a low-cost communications link to connect industrialdevices (such as limit switches, photoelectric sensors, valvemanifolds, motor starters, process sensors, bar code readers, variablefrequency drives, panel displays and operator interfaces) to a networkand eliminate expensive hardwiring.

The direct connectivity provides improved communication betweendevices as well as important device-level diagnostics not easilyaccessible or available through hardwired I/O interfaces.

DeviceNet is a simple, networking solution that reduces the cost andtime to wire and install industrial automation devices, while providinginterchangeability of "like" components from multiple vendors.

DeviceNet is an open network standard. The specification and

More:

TechnicalintroductionSpecificationsConformance testFAQs

Page contents:TopFeatures andfunctionalityFirst information

More:



CAN in Automation

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





protocol are open; vendors are not required to purchase hardware,software or licensing rights to connect devices to a system. Anyonemay obtain the DeviceNet Specification from the Open DeviceNetVendor Association, Inc. (ODVA) for a nominal reproduction charge.Any company that manufactures (or intends to manufacture)DeviceNet products may join ODVA and participate in technicalworking groups that are developing enhancements to the DeviceNetSpecification.

Buyers of the DeviceNet Specification receive an unlimited,royalty-free license to develop DeviceNet products. Companieslooking for assistance may purchase sample code that eases theirimplementation, development toolkits, and development services frommany sources. The key hardware components are available from thelargest worldwide suppliers of semiconductors.

Why the DeviceNet Communication Link?

For years the process industry has been attempting to develop asingle, open standard to address all kinds of field devices. The originalscope of their standards effort was aimed at replacing the 4-20 mAstandard with a single digital standard. As the scope increased toaddress complex and sophisticated services (such as high data ratecommunications between controllers, time synchronization of largenumbers of devices scanning at very high speeds), the developmentof a single standard became delayed.

At the same time, the cost of communication technology has droppedconsiderably in recent years, making it cost-effective to connect simpledevices never considered for SP50 fieldbus directly to a network. Sucha standard for simple devices requires the same level ofinterchange-ability as exists for 120/220 VAC and 24 VDC discrete,hardwired I/O. DeviceNet allows the interchangeability of simpledevices while making interconnectivity of more complex devicespossible. In addition to reading the state of discrete devices,DeviceNet provides the capability to report temperatures, to read theload current in a motor starter, to change the deceleration rate ofdrives, or to count the number of packages that have passed on aconveyor in the previous hour.

© ODVA - The Open DeviceNet's Vendor Association

More:



More:



© CAN in Automationlast update: 1999-07-27

CAN in Automation

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

http://www.odva.org/





Technical introduction DeviceNetPage contents:

Physical Layer and MediaIndicators and Configuration SwitchesCommunication Protocol and ApplicationThe Object ModelMessagingPredefined Master/Slave Connection SetDevice Profiles

Physical Layer and Media

Chapter 9, Volume 1 in the DeviceNet Specifications defines theallowable Topologies and components. The variety of Topologiesthat are possible is shown in Figure 2. The specification also dealswith system grounding, mixing thick and thin media, termination,and power distribution.

The basic trunkline-dropline Topology provides separate twisted pairbusses for both signal and power distribution. Thick or thin cable canbe used for either trunklines or droplines. End-to-end networkdistance varies with data rate and cable size.

Data Rates 125 Kbps 250 Kbps 500 Kbps

Thick Trunk Length 500 m(1,640 ft)

250 m(820 ft)

100 m(328 ft)

Thin Trunk Length 100 m(328 ft)

100 m(328 ft)

100 m(328 ft)

Maximum Drop Length 6 m(20 ft)

6 m(20 ft)

6 m(20 ft)

Cumulative Drop Length 156 m(512 ft)

78 m(256 ft)

39 m(128 ft)

The end-to-end network distance varies with data rate and cablethickness.

Devices can be powered directly from the bus and communicate witheach other using the same cable. Nodes can be removed or insertedfrom the network without powering-down the network.

Power taps can be added at any point the network, which makesredundant power supplies possible. The trunkline current rating is 8amps. An opto-isolated design option allows externally powered

More:

General introductionSpecificationsConformance testFAQs

Page contents:TopPhysical Layer andMediaIndicators andConfiguaration SwitchesCommunication Protocoland ApplicationThe Object ModelMessagingPredefined Master/SlaveConnection SetDevice Profiles

More:


CAN in Automation

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





devices (e.g. AC Drives starters and solenoid valves) to share thesame bus cable. Other CAN-based networks allow only a singlepower supply (if at all) for the entire network.


More:



CAN in Automation




A simplified block diagram of transceivers with both isolated andnon-isolated physical layers is shown in figure 3 and figure 4. TheDeviceNet Specifications contain additional information concerningcomponent requirements, protection from mis-wiring, and examples.

Figure 5. Open and Sealed Connectors are available on DeviceNet

Several different connector types can be used on DeviceNet (seefigure 5). Both sealed and unsealed connectors are available. Large(mini-style) and small (micro-style) sizes of pluggable, sealedconnectors are available. For products, which do not require sealedconnectors, open-style connectors can be used. Screw or clampconnections can be made directly to the cable if a pluggableconnection is not required. The DeviceNet Specification also

More:



More:


CAN in Automation






contains information on how to use these cable and connectorcomponents to construct single and multi-port taps.

Indicators and Configuration Switches

Although DeviceNet does not require a product to have indicators, ifa product does have indicators, it must adhere to the DeviceNetSpecification. It is recommended that either a Module Status LEDand a Network Status LED, or the combined Module Status/NetworkStatus LED be included.

The indicator(s) consist of bi-color (green/red) LEDs, which canhave combinations of on, off or flashing. The Module Status LEDindicates whether or not the device has power and is operatingproperly. The Network Status LED indicates the status of thecommunication link.

Communication Protocol and Application

Chapters 3, 4 and 5, Volume 1 of the DeviceNet Specificationdefines the DeviceNet Communication Protocol. These chapters dealwith connections, messaging protocol, and the communicationsrelated objects respectively.

Applications using DeviceNet combine standard or applicationspecific objects together into what is called a Device Profile. TheDevice Profile fully defines the device as viewed from the network.A library of objects is contained in Chapter 6, Volume II of theDeviceNet Specifications. A library of Device Profiles is containedin Chapter 3, Volume II of the DeviceNet Specifications. ODVAcoordinates the work of industry experts in the development of bothnew Object and Device Profile Specifications. This is done throughSpecial Interest Groups (SIG).

DeviceNet supports strobed, polled, cyclic, change-of-state andapplication-triggered data movement. The user can choosemaster/slave, multi-master and peer-to-peer or a combinationconfiguration depending on device capability and applicationrequirements. The choice of data movement can significantly speedup system response time. One popular application for DeviceNet isto use a standard, pre-defined set of connections, which allowdevices to operate in a Master/Slave Connection Set.

Connections

The DeviceNet Communication Protocol is based on the idea ofconnections. You must establish a connection with a device in orderto exchange information with it.


More:



CAN in Automation




To establish a connection, each DeviceNet product will implementeither an Unconnected Message Manager (UCMM) or anUnconnected Port. Both perform their function by reserving some ofthe available CAN identifiers. The UCMM is described in detail inChapter 4, Volume 1 of the DeviceNet Specification, and theUnconnected Port is described in Chapter 7, Volume 1.

When either the UCMM or the Unconnected Port is used to establishan Explicit Messaging Connection, that connection is then used tomove information from one node to the other, or to establishadditional I/O Connections. Once connections have been established,I/O data may be moved among devices on the network. At this point,all the protocol of the DeviceNet I/O message is contained within the11-bit CAN identifier. Everything else is data.

The 11-bit CAN identifier is used to define the connection ID.DeviceNet divides the 11-bit CAN identifier into four groups. Thefirst three defined groups contain two fields, one 6-bit field for MACID and the other for Message ID. The combined fields define theconnection ID. Figure 7 shows message groups definitions. Groupfour messages are used for offline communications.

Devices may be Clients or Servers or both. Clients and Servers maybe producers, consumers or both. In a typical Client device, itsconnection would produce requests and consume responses. In atypical Server device, its connections would consume requests andproduce responses. DeviceNet provides for several variations on thismodel. Some connections in either a Client or a Server may onlyconsume messages. These connections would be the destination forCyclic or Change-of-State messages. Similarly, some connections ineither a Client or Server may only produce messages. Theseconnections would be the source for Cyclic or Change-of-Statemessages. The use of Cyclic and Change-of-State connections cansubstantially reduce bandwidth requirements.

By design, nodes in a DeviceNet system are responsible formanaging their own identifiers. These identifiers are interleaved(distributed) throughout the entire range. All nodes have a full rangeof message priorities available to them regardless of their MAC ID.Through the duplicate MAC ID algorithm, the uniqueness of CANidentifiers is guaranteed without the need for a central tool or recordfor each network.

A related issue is detection of duplicate nodes. Because DeviceNetuses a device address inside the CAN Identifier Field, it presents amechanism for detecting duplicate addressed devices. Preventingduplicate addresses is better than trying to locate them after theyoccur - something not taken into account in other CAN-based

More:



More:


CAN in Automation






networks.

Another key benefit to nodes managing their identifiers is that a usercan add and delete nodes and/or add additional peer-to-peermessages among existing nodes at any time without havingknowledge of the existing set-up. No centralized record must belocated or reconstructed. Since nodes know, which IDs are already inuse, a tool simply has to request an I/O connection be added betweenthe two devices, specifying priority level, the data path (class,instance, attribute) and the production trigger (cyclic, poll, orchange-of-state).

Identifier Bits HexRange

IdentityUsage10 9 8 7 6 5 4 3 2 1 0

0Group 1

Message IDSource MAC ID 000 -

3ffMessageGroup 1

1 0 MAC IDGroup 2Message

ID

400 -5ff

MessageGroup 2

1 1Group 3Message

ID

Source MAC ID 600 -7bf

MessageGroup 3

1 1 1 1 1Group 4 Message

ID(0 - 2f)

7c0 -7ef

MessageGroup 4

1 1 1 1 1 1 1 X X X X7f0 -7ff

InvalidCAN

Identifiers

10 9 8 7 6 5 4 4 3 2 1 0

Figure 7 DeviceNet has 4 defined groups

The Object Model

The Object Model provides a template for organizing andimplementing the Attributes (data), Services (methods or procedures)and Behaviors of the components of a DeviceNet product (see figure8). The model provides an addressing scheme for each attributeconsisting of four numbers. They are the Node Address (MAC ID),the Object Class Identifier, the Instance Number, and the AttributeNumber. This four-level address is used in conjuction with anExplicit Messaging Connection to move data from one place to


More:



CAN in Automation




another on a DeviceNet network. The ranges of the four addressingcomponents are shown in the following table:

Address Lowest Highest

Node 0 63

Class 1 65535

Instance 0 65535

Attribute 1 255

Typical object classes found in a DeviceNet Product

Object ClassNumber

Object Class NameSpecification

Reference

1 IdentityVol II, Rel 1.2,

page 6-3

2 Message RouterVol II, Rel 1.2,

page 6-17

3 DeviceNetVol I, Rel 1.3,

page 5-50

4 AssemblyVol II, Rel 1.2,

page 6-25

5 ConnectionVol I, Rel 1.3,

page 5-6

6 ParameterVol II, Rel 1.2,

page 6-95

Identity Object - Vol II, Rel 1.2, page 6-3A DeviceNet product will typically have a single instance (Instance#1) of the Identity Object. This instance will have as attributes a

More:



More:


CAN in Automation






VendorID, a Device Type, a Product code, a revision, a status, aserial number, a productname, and a state. The required serviceswould be Get_Attribute_Single and a Reset.

Message Router Object - Vol II, Rel 1.2, page 6-17A DeviceNet product will typically have a single instance (Instance#1) of the Message Router Object. The Message Router Object is thecomponent of a product that passes Explicit Messages to the otherObjects. It Generally does not have any external visibility over theDeviceNet network.

DeviceNet Object - Vol I, Rel 1.3, page 5-50A DeviceNet product will typically have a single instance (Instance#1) of the DeviceNet Object. This instance would have as attributes:Node Address or MAC ID, baudrate, Bus-Off action, Bus-Offcounter, the allocation choice, and the master's MAC ID. The onlyrequired service is Get_Attribute_Single.

Assembly Object(s) - Vol II, Rel 1.2, page 6-25A DeviceNet product will typical have one or more optionalAssembly Objects. The primary purpose of these objects is to groupdifferent attributes (data) from different application objects into asingle attribute, which can be moved with a single message.

Connection Objects - Vol I, Rel 1.3, page 5-6A DeviceNet product will typically have at least two connectionobjects. Each connection object represents one end point of a virtualconnection between two nodes on a DeviceNet network. These twotypes of connections are called Explicit Messaging and I/OMessaging. Explicit Messages contain Attribute addressing,Attribute values and a Service Code describing the desired action.I/O messages contain nothing but data. In an I/O message, all theinformation about what to do with the data is contained in theConnection Object associated with that I/O message.

Parameter Object - Vol II, Rel 1.2, page 6-95The optional Parameter object would be used in devices withconfigurable parameters. One instance would be present for eachconfigurable parameter. The parameter object provides a standardway for a configuration tool to access all parameters. Configurationoptions, which are attributes of the Parameter object could includevalues, ranges, text strings, and limits.

Application ObjectsUsually at least one application object besides those from theAssembly or Parameter Class will be present in a device. There are anumber of standard objects in the DeviceNet Object Library inChapter 6, Volume II.


More:



CAN in Automation




Messaging

The DeviceNet application layer defines how identifiers are assigned(thus controlling priorities), and how the CAN data field is used tospecify services, move data, and determine its meaning.

The way information flows on a communication network is critical.Older communication technology consisted of messages that wereconstructed with a specific source and destination. Instead of atraditional source-destination approach, DeviceNet uses a moreefficient Producer-Consumer Model, which requires a packet to haveidentifier fields for the data. The identifier provides the means formultiple priority levels (used in arbitration), more efficient transferof I/O data, and multiple consumers.

The device with data produces the data on the network with theproper identifier. All devices who need data listen for messages.When devices recognized the appropriate identifier, they consumethe data. With the producer-consumer model, the message is nolonger specific to a particular source or destination. A singlemessage from one controller can be used by multiple motor startersusing less bandwidth.

DeviceNet defines two different types of messaging. They are calledI/O Messaging and Explicit Messaging.

I/O messages are for time-critical, control-oriented data. Theyprovide a dedicated, special-purpose communication path between aproducing application and one or more consuming applications.They are exchanged across single or multi-cast connections andtypically use high priority identifiers. I/O messages contain noprotocol in the 8-byte data field. The only exception is forfragmented I/O messages where one byte is used for fragmentationprotocol. The meaning of the message is implied by the connectionID (CAN identifier). Before messages are sent using these IDs, boththe device sending and receiving must be configured. Theconfiguration contains the source and destination object attributeaddresses for the producer and consumer of the data.

Explicit messages provide multi-purpose, point-to-pointcommunication paths between two devices. They provide the typicalrequest/response-oriented network communications used to performnode configuration and problem diagnosis. Explicit messagestypically use low priority identifiers and contain the specificmeaning of the message right in the data field. This includes theservice to be performed and the specific object attribute address.

Fragmentation services are provided for messages that are longerthan 8 bytes. Each I/O Message fragment incurs only a single byte of

More:



More:


CAN in Automation






protocol overhead. There is no limit on the number of fragments.Fragmentation is also defined for explicit messaging. This flexibilityassures that as more sophisticated devices are introduced and morecapabilities are designed into devices, they can be added to existingDeviceNet networks. With its object-oriented design and addressingscheme, DeviceNet is unlimited in its ability to be expanded withouthaving to alter the basic protocol and connection model.

On the other end of the spectrum, a simple slave device applicationwith two message connections (one I/O and one explicit) can behandled in less than 4K ROM and 175 bytes of RAM (Motorola68HCO5X4, a CPU with a built-in CAN interface).

The General format for I/O messages is shown in figures 9-12


More:



CAN in Automation




Predefined Master/Slave Connection Set

While DeviceNet provides a powerful Application Layer Protocolthat allows dynamic configuring of connections between devices. Ithas been recognized that some devices will have neither the need northe resources to use this powerful capability. For this reason, a set ofconnection identifiers known as the Predefined Master/SlaveConnection Set has been specificed to simplify the movement of I/Oand configuration-type data typically seen in a Master/Slavearchitecture.

Many sensors and actuators are designed to perform somepredetermined function (sense pressure, start motor, etc.) and thetype and amount of data the device will produce and/or consume isknown at power-up. Typically these devices provide input data orrequire output data and configuration data. The PredefinedMaster/Slave Connection Set meets these needs by providingconnection objects that are almost entirely configured at the time thedevice powers-up. The only remaining step necessary to begin theflow of data is for a master device to claim ownership of thispredefined connection set within its slave(s).

Message Group 2 is used for the definition of these identifiers (referback to figure 7). One noticeable difference in Group 2 is that theMAC ID is not specified as Source MAC ID. This allows the use ofDestination ID. There are strict rules about the use of this kind ofconnection to prevent duplicate CAN identifiers on the bus. The useof Destination ID allows devices, which are centralized and whichmust communicate with many nodes (a master) to borrow identifiersfrom those nodes. In addition, the MAC ID and Message ID fieldsare reversed. This allows the Group ID and MAC ID to fall withinthe most significant 8 bits of the CAN identifier. This is importantbecause many low-cost, 8-bit CAN chips can hardware filter only thefirst 8 bits. The exclusive use of Destination MAC ID further allows

More:



More:


CAN in Automation






devices to take advantage of hardware filtering. Another importantbenefit is that the establishment of connections from the PredefinedSet is simplified considerably. Only a few messages are required tohave I/O connections up and running. The Predefined Set containsone explicit messaging connection and allows several different I/Oconnections including Bit Strobed Command/Response,Change-of-State and Cyclic. Chapter 7, Volume I contains detailedinformation about the Predefined Master/Slave Connection Set.

Change-of-State and Cyclic TransmissionWith change-of-state, a device produces its data only when itchanges. To be sure the consuming device knows that the producer isstill alive and active, DeviceNet provides an adjustable, backgroundheartbeat rate. Devices send data whenever it changes or theheartbeat timer expires. This serves to keep the connection alive andlet the consumer know his data source has not faulted in some way.The minimum time on the heartbeat prevents inherently noisy nodesfrom dominating the network. By having the device generate theheartbeat, the controller is not burdened with having to send anuisance request periodically just to make sure it is still there. Thisbecomes even more efficient in the multicast case.

The cyclic option can reduce unnecessary traffic and packetprocessing. Instead of a temperature or analog input block beingscanned dozens of times every second, it can be set up to report itsdata on a regular basis consistent with the rate of change it candetect. A temperature sensor on a slow PID loop with a 500 msupdate time could have its cyclic rate set to 500 ms. Not only wouldthis preserve bandwidth for more rapidly changing critical I/O data,it would also be more accurate as well. For example, it might bescanned once every 30 ms as part of a large scan list with many bytesof data per node on a heavily loaded master. This means that dataused in a PID calculation might have been sampled anywhere from470 to 530 ms. With cyclic production you know that the datasamples will be at precisely 500 ms.

By default, both change of state and cyclic are acknowledgedexchanges (ACKs) so that the producer knows its intendedconsumer(s) received the data. For applications where changes ofstate or cyclic rates are extremely fast, it makes no sense to clutter upthe network with ACK packets. Unnecessary ACKs can besuppressed 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 mostappropriate interval, whether that be cyclic or change-of-state. Withthe ACK Handler Object it is possible to have multiple consumers ofthe slaves' data, not just the master. This multicast is especially


More:


Page contents:TopPhysical Layer andMediaIndicators andConfiguration SwitchesCommunication Protocoland ApplicationThe Object ModelMessagingPredefined Master/SlaveConnection SetDevice Profiles

CAN in Automation




useful for operator interface (OI) devices, which can just listen forthe data they need, whether it is for display, alarm monitoring or datalogging.

For alarm monitoring, it is important that a change-of-state not bemissed, so the OI device would be included in the device's ACK list,assuring a retry (or several retries) if for some reason the OI missedthe message. On the other hand, if it was primarily a data collectiondevice logging values every 5 seconds (and the node is producingvalues every 300 ms for control purposes), you would not have thelogger set to ACK. If the logger misses a value, it can grab the nextone 300 ms later.

Cyclic and change-of-state from the master is defined and selectableon a per node basis.

Device Profiles

The DeviceNet specification goes beyond a physical connectionprotocol specification. It promotes interoperability by definingstandard device models. All devices of the same model must supportcommon identity and communication status data. Device-specificdata is contained in device profiles that are defined for variousdevice types. Simple devices (e.g. push buttons, motor starters,photocells, pneumatic valve actuators) from multiple vendors thatcomply with their device type profile will be logicallyinterchangeable.

A device profile will contain the following sections:

Definition of the device's object model -This often contains a drawing like the one shown in the objectmodel (figure 8). Usually there are tables, which list all of theobject classes present in the device, the number of instances ineach class, how each object effects behavior, and the publicinterfaces to each object.

●

Definintion of the device's I/O data format -This usually includes definition of Assembly Objectdefinition, which contains the address (class, instance, andattribute) of the desired data components.

●

Definition of the device's configurable parameters and publicinterfaces to those parameters. This information is also oftencontained in an Electronic Data Sheet (EDS), which could beincluded with the device's user documentation.

●

As an example, a photoelectric sensor (Device Type 6) wouldcontain the following objects:

Identity Object 1

More:



More:


CAN in Automation






Message Router 1

DeviceNet 1

Connection 2 (one explicit, one I/O)

Assembly 1

Parameter 1 (optional)

Presence Sensing 1

The DeviceNet specification defines an Electronic Data Sheet(EDS), which is a simple file format that allows product-specificinformation to be made available by vendors for all other vendors.This makes possible user-friendly configuration tools that can beeasily updated without having to constantly revise the configurationsoftware tool.

In order not to restrict enhancements, a means is also provided foraddition of vendor specific, value-add options. The DeviceNetspecification has public classes, services and attributes, which aredefined in the DeviceNet specification and vendor-specific classes,services and attributes, which can be added by individual vendors.This allows vendors to provide additional functions to theircustomers that are not covered in the specification. Asvendor-specific items become more popular or commonplace, themechanism to transition them to public items will be provided.

© ODVA - The Open DeviceNet's Vendor Association


More:



CAN in Automation





More:




CAN in Automation




CAN related standards CiAStandards

Page contents:

DS 102 V2.0DS 150 V1.1DeviceNetCAN Kingdom

CAN Physical Layer for Industrial ApplicationsDS 102 V2.0

The scope of this document is, to define the content of the physicallayer and the basic characteristics of the physical medium, forcommunication according to the Controller Area Network protocolspecification (CAN) between different types of electronic modules ingeneral industrial applications. CAN is a serial communicationprotocol supporting distributed real-time control and multiplexing.This part refers to using a differentially driven two-wire bus linewith common return as physical medium.

Power Management Layer SpecificationDS 150 V1.1 members only

This document specifies facilities and services of an PowerManagement Layer protocol entity on the CAN bus allowingsignificant reduction of power consumption in CAN networksby the introduction of the so-called network standby capability.The power reduction facilities of current CAN controllerhardware designs by using the sleep mode, which can berecognized as a de-facto standard; are supported for usageunder all higher layer protocols during an internal PowerManagement Layer IDLE state.

WARNING: This CAN Power Management Layer deals withreliable communication on CAN networks with power reductioncapability. There is very little relationship to the ISO/OSIPower Management Layer otherwise.

The main features of the CAN Power Management Layer arestandby capability supports CAN sleep mode for usageunder all CAN higher-layer protocols, i.e. functional LLCinterface remains virtually the same although timebehaviour may change,

●

More:

CAN StandardsCAL StandardsCANopen Standards

Literature OrderForm

Page contents:TopDS 102 V2.0DS 150 V1.1DeviceNetCAN Kingdom

More:

CAN in Automation

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

http://www.can-cia.de/DS102.pdf


http://www.can-cia.de/intern/DS150.pdf




full compatibility with CAN multi-master decentralizednetwork architecture,

●

easy hardware implementation/integration into CANperipherial controllers,

●

coexistance of nodes with and without PowerManagement Layer support is possible.

●

DeviceNet

DeviceNet is a low-cost communications link to connectindustrial devices (such as limit switches, photoelectricsensors, valve manifolds, motor starters, process sensors, barcode readers, variable frequency drives, panel displays andoperator interfaces) to a network and eliminate expensivehardwiring.

The direct connectivity provides improved communicationbetween devices as well as important device-level diagnosticsnot easily accessible or available through hardwired I/Ointerfaces.

DeviceNet is an open network standard. The specification andprotocol are open; vendors are not required to purchasehardware, software or licensing rights to connect devices to asystem. Anyone may obtain the DeviceNet Specification fromthe Open DeviceNet Vendor Association, Inc. (ODVA) for anominal reproduction charge (currently $250 USD + postage).Any company that manufactures (or intends to manufacture)DeviceNet products may join ODVA and participate intechnical working groups that are developing enhancements tothe DeviceNet Specification.

Buyers of the DeviceNet Specification receive an unlimited,royalty-free license to develop DeviceNet products.Companies looking for assistance may purchase sample codethat eases their implementation, development toolkits, anddevelopment services from many sources. The key hardwarecomponents are available from the largest worldwide suppliersof semiconductors.

CAN Kingdom (external link to Kvaser)

The CAN protocol has a great hidden power that is notobvious until you have penetrated the problems arounddesigning distributed embedded control systems whereindependently developed modules will be integrated into thesystem. CAN Kingdom is especially developed for such




More:



CAN in Automation


http://www.kvaser.com/archive/ck/


systems. Most networks provide services for connectedmodules. In control networks however, connected modulesserve the network. CAN Kingdom takes advantage of this fact,making separation of module and system development notonly possible but even simple.

In fact, most papers written on the subject of Controller AreaNetwork design are, in my opinion, misleading as they are builtupon the OSI model. The OSI model was developed forcommunication networks. Such networks are intended to beaccessed by users, unknown at the design phase, duringruntime. In a controller area network, where real-time featuresare essential, all communication needs have to be known atthe design phase. CAN Kingdom is open only during thisphase. At runtime a CAN Kingdom network works exactly inthe way the network designer has decided.



CAN in Automation


CAN CiAStandards

Page contents:

CAN 2.0 Part ACAN 2.0 Part BCAN 2.0 Addendum

CAN Standard

The acceptance and introduction of serial communication tomore and more applications has led to requirements that theassignment of message identifiers to communication functionsbe standardized for certain applications. These applicationscan be realized with CAN more comfortably, if the dress rangethat originally has been defined by 11 identifier bits isenlarged. Therefore a second message format ('extendedformat') is introduced that provides a larger address rangedefined by 29 bits. This will relieve the system designer fromcompromizes with respect to defining well-structured namingschemes. Users of CAN who do not need the identifer rangeoffered by the extended format, can rely on the conventional11 bit identifier range ('standard format') further on. In thiscase they can make use of the CAN implementations that arealready available on the market, or of new controllers thatimplement both formats.

In order to distinguish standard and extended format the firstreserved bit of the CAN message format, as it is defined inCAN Specification 1.2, is used. This is done in such a way thatthe message format in CAN Specification 1.2 is equivalent tothe standard format and therefore is still valid. Furthermore,the extended format has been defined so that messages instandard format and extended format can coexist within thesame network.

This CAN Specification 2.0 consists of two parts, with

CAN 2.0 Part A

describing the CAN message format as it is defined inCAN Specification 1.2;

●

More:

CAL StandardsCANopen StandardsRelated Standards

Page contents:TopCAN 2.0 Part ACAN 2.0 Part BCAN 2.0 Addendum

More:

CAL StandardsCANopen StandardsRelated Standards

Page contents:TopCAN 2.0 Part ACAN 2.0 Part BCAN 2.0 Addendum

CAN in Automation

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

http://www.can-cia.de/CAN20A.pdf




CAN 2.0 Part B

describing both standard and extended messageformats.

●

In order to be compatible with this CAN Specification 2.0 it isrequired that a CAN implementation be compatible with eitherPart A or Part B.

CAN 2.0 Addendum

Implementation Guide for the CAN Protocol

The Controller Area Network protocol specification documentdescribes the function of the network on the whole.Additionally, Bosch provides a Reference CAN Model to theCAN licensees, supporting the protocol’s implementation intothe licensees’ CAN controller nodes.



CAN in Automation

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

http://www.can-cia.de/CAN20B.pdf


http://www.can-cia.de/CAN2AD.pdf


CAN Application layerAll specifications can be ordered

CiAStandards

Page contents:

DS 201 V1.1 - CAN in the OSI Reference ModelDS 202 V1.1 - CAN based Message Specification (CMS)DS 203 V1.1 - Network Managment (NMT)DS 204 V1.1 - Distributor (DBT)DS 205 V1.1 - Layer Managment (LMT)DS 206 V1.1 - Recommended Standard CAL Module Data SheetDS 207 V1.1 - Application Layer Naming Conventions

CAN Application Layer (CAL) for Industrial Applications

The Controller Area Network (CAN) is a data communicationnetwork designed to fit distributed real-time controlapplications. It was originally developed and applied by theautomotive industry to solve the cabling problem insidevehicles. However CAN also provides good properties as acontrol network for industrial applications.

CAN in the OSI Reference ModelDS 201 V1.1 members only

This document contains a description of the CAN ReferenceModel. This document is part of a set of documents thatstandardize the CAN Application Layer for IndustrialApplications.

The purpose of the CAN Reference Model and its relatedservice- and protocol specifications is to make CAN an opennetwork where modules from different suppliers can cooperatein distributed applications.

CAN based Message Specification (CMS)DS 202 V1.1

This document contains the service and protocol specificationand the data types and encoding rules of the CAN basedMessage Specification (CMS). CMS is part of the CANApplication Layer. This document is part of a set of documentsthat standardize the CAN Application Layer for IndustrialApplications.

More:

CAN StandardsCANopen StandardsRelated Standards


Page contents:TopDS 201 V1.1DS 202 V1.1DS 203 V1.1DS 204 V1.1DS 205 V1.1DS 206 V1.1DS 207 V1.1

More:



CAN in Automation

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





These three parts are in the different documents:DS 202-1 V1.1: CMS Service Specificationmembers only

●

DS 202-2 V1.1: CMS Protocol Specificationmembers only

●

DS 202-3 V1.1: CMS Data Types and Encoding Rules members only

●

CMS is one of the application layer service entities of the CANReference Model.

CMS is a language to specify what Communication Objects amodule uses and how they are formatted. CMS can describeall CAN layer 2 features. This means also that existingapplications can be described in CMS. Furthermore CMSoffers the application a possibility to model its behaviour in theform of objects and remote services on these objects. Thisallows other applications to cooperate with it by executingthese services that CMS supports on these objects.

Network Management (NMT)DS 203 V1.1

This document contains the service and protocol specificationof the Network Management (NMT). NMT is part of the CANApplication Layer. This document is part of a set of documentsthat standardize the CAN Application Layer for IndustrialApplications.

These two parts are in the different documents:DS 203-1 V1.1: NMT Service Specificationmembers only

●

DS 203-2 V1.1: NMT Protocol Specificationmembers only

●

NMT is one of the application layer entities in the CANReference Model.

The NMT aids in the development of distributed applications.Due to the fact that an application is distributed, certain eventshave to be handles (e.g. failures of parts of the application)that would not occure if the same application had not beendistributed.

The application has to deal with these network managementaspects, although they have nothing to do with goal of theapplication (e.g. controlling a process). These aspects are the


More:




CAN in Automation


http://www.can-cia.de/intern/DS202_1.pdf











consequence of building a distributed application and must becompared to the advantages of building a distributedapplication.

Distributor (DBT)DS 204 V1.1

This document contains the service and protocol specificationof the Distributor (DBT). DBT is part of the CAN ApplicationLayer. This document is part of a set of documents thatstandardize the CAN Application Layer for IndustrialApplications.

These two parts are in the different documents:DS 204-1 V1.1: DBT Service Specificationmembers only

●

DS 204-2 V1.1: DBT Protocol Specificationmembers only

●

The essential issue in creating an open system wheremodules from independent suppliers can cooperate via CAN,is how the identifiers and inhibit-times are assigned to theCommunication Objects that a module uses. Identifiers areused by the Data Link Layer and inhibit-times are defined bythe CMS service element of the CAN Application Layer.

The DBT is a service element of the CAN Application Layerthat offers dynamic distribution of identifiers and inhibit-timesto the Communication Objects that a module uses. Thedynamic distribution does not necessarily take place everytime the module is 'powered on'. Depending on the facilities ofthe module, distribution may only be required once e.g. whenthe module is installed to the network.

Layer Management (LMT)DS 205 V1.1

This document contains the service and protocol specificationof the Layer Management (LMT). LMT is part of the CANApplication Layer. This document is part of a set of documentsthat standardize the CAN Application Layer for IndustrialApplications.

These two parts are in the different documents:DS 205-1 V1.1: LMT Service Specificationmembers only

●

DS 205-2 V1.1: LMT Protocol Specification●

More:




More:




CAN in Automation












members only

LMT is one of the application layer entities in the CANReference Model.

LMT offers the possibility to inquire and change the settings ofcertain parameters of the local layers on a CAN module withLMT Slave capabilities by a CAN module with LMT Mastercapabilities via the CAN Network.

The following parameters can be inquired and/or changed bythe use of LMT:

NMT-address of the NMT Service Element,●

bit timing parameters of the physical layer,●

LMT address.●

By using LMT,a LMT Slave can be configured for a CANnetwork without using any devices like DIP-switches for settingthe parameters. There are several solutions available for LMTSlaves with and without a unique LMT-address or non-volatilestorage.

Recommended Standard CAL Module Data SheetDS 206 V1.1 members only

This document contains a description of a recommendedstandard for a CAL module data sheet.

The purpose of the recommended standard module data sheetis the provision of a standard description format for thecomplete specification of CAL-based modules innon-standardized-profile (proprietary) applications.

The recommended Module Data Sheet consists of three partsand shall specify the functionality of a module as accessiblefrom the bus. This means that not only the communicationinterface has to be specified but also the application specificfunctionality.

Application Layer Naming ConventionsDS 207 V1.1 members only

This document contains the naming conventions that apply toinstances of the objects that are defined by the serviceelements of the CAN Application Layer. This document is apart of a set of documents that standardize the CANApplication Layer for Industrial Applications.

More:




CAN in Automation







The CAN Application Layer offers an open CAN networkwhere modules from different suppliers cooperate in adistributed application. To this purpose, the service elementsof the CAN Application Layer model their functionality throughthe use of objects. Applications can create instances of thoseobjects identified by a name. These names have anetwork-wide scope. Applications that want to execute remoteservices via the network on such an object must know itsname and this name must identify the object.



CAN in Automation


CANopenAll specifications can be ordered.

CiAStandards

Page contents:

DS 301 V4.0 - Application Layer and Communication ProfileDSP 302 V2.0 - Framework for Programmable CANopen DevicesDSP 401 V1.4 - Device Profile for I/O ModulesDSP 402 V1.1 - Device Profile Drives and Motion ControlDSP 403 V1.0 - Device Profile Human Machine InterfacesDSP 405 V1.0 - Device Profile for IEC 1131 Programmable DevicesDSP 406 V2.0 - Device Profile for Encoders

Application Layer and Communication Profile for IndustrialSystemsDS 301 V4.0 members only

This document contains the description of the CANopenApplication Layer and Communication Profile for IndustrialApplications using CAN as their installation bus.

The CANopen Application Layer defines the services andobjects that are necessary to form a open communication forIndustrial Applications on a CAN network.

The CANopen Communication Profile forms the interfacebetween the CANopen Application Layer and the CANopenDevice Profiles. It includes the real-time communication modeland the protocols which are common to all devices in thenetwork. Device Profiles, on the other hand, are a commonmeans to describe device specific functionality.

An introduction to CANopen Device Profiles is given in thisdocument as well, however, the specification of full deviceprofiles does not fall within the scope of this document.

Framework for Programmable CANopen DevicesDSP 302 V2.0 members only

In general the mechanisms which are specified in thecommunication profile are sufficient for the definition of profilesfor devices which, on the application level, provide some kindof I/O functionality. Example devices include I/O modules,drives and regulators. These devices whilst they may becomplex are not termed ‘intelligent’ as they do not run anapplication level program.

More:

CAN StandardsCAL StandardsRelated Standards

Literature Order Form

Page contents:TopDS 301 V4.0DSP 302 V2.0DSP 401 V1.4DSP 402 V1.1DSP 403 V1.0DSP 405 V1.0DSP 406 V2.0

CAN in Automation

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



http://www.can-cia.de/intern/DSP302.pdf



For the description and operation of intelligent devices furthermechanisms are necessary which are specified in thisdocument. This document has to be regarded as a frameworkfor the definition of device profiles for intelligent orprogrammable devices in form of an extension to theCANopen Communication Profile. The additional mechanismsspecified in this document are useful especially for intelligentdevices like PLCs, HMIs or CANopen tools. This documentcomprises the following mechanisms and definitions:

The dynamic establishment of SDO connectionsbetween devices. Dynamic SDO connections arehandled by the SDO Manager.

●

The term CANopen Manager is introduced to specifymore clearly the network functionality of a networkcontrolling device.

●

The definition of dynamically allocated entries in anobject dictionary, which can be used for therepresentation of I/O data e.g. on programmable nodeslike PLCs.

●

A general mechanism for downloading program data andfunctions for the control of programs on a device.

●

A possibility for detecting and configuration ofunconfigured nodes during system boot-up by means ofa Configuration Manager.

●

A debugging mechanism in the form of an OS commandand prompt.

●

A multiplexed PDO, which allows to write data of objectdictionary entries on a group of nodes simultaneously.The multiplexed PDO also has non-group applications.

●

Some of these new mechanisms are also useful not only forintelligent or programmable devices. Therefore it is expected,that these probably will be included in a future revision of theCANopen Communication Profile.

Device Profile for I/O ModulesDSP 401 V1.4 members only

This document represents the CANopen device profiles fordigital and analogue Input and Output modules.

All the above devices use communication techniques, whichconform to those described in the CANopen Application Layerand Communication Profile. This document should beconsulted in parallel to this profile.

More:




CAN in Automation





The purpose of the I/O modules is to connect sensors andactors to the CAN bus. They can receive configurationinformation via the service data objects such as I/Oconfigurations, conversion parameters for converting data intomeaningful measurements and so on. At run time, data can beread from the sensor over the CAN bus by either a request orinterrupt (event) mechanism. The I/O modules also have aprocess data object mapping, which may be configured over aservice data object for real time operation.

Data can also be sent via the CAN bus to those I/O modulesthat have output capabilities. Output data can be sent to an I/Omodule via service data objects or process data objects. TheI/O modules themselves are controlled by either theconfiguration master or put as remote modules for anIntelligent Peripheral Device.

Device Profile Drives and Motion ControlDSP 402 V1.1 members only

This document represents the standardized CANopen DeviceProfile for digital controlled motion products like servocontrollers, frequency converters or stepper motors.


The starting and sTopping of the drive and several modespecific commands are executed by the statemachine.

The operation mode defines the behaviour of the drive. Thefollowing modes are defined in this profile:

Homing Mode●

This mode describes the various methods to find a homeposition (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 andprofiled moves using a Trajectory Generator are possibleas well.

More:




CAN in Automation





Interpolated Position Mode●

This mode describes the time interpolation of singleaxles and the spatial interpolation of coordinated axles.Synchronisation mechanisms and interpolation databuffers are covered by this mode.

Profile Velocity Mode●

The Profile Velocity Mode is used to control the velocityof the drive with no special regard of the position. Itsupplies limit functions and trajectory generation.

Profile Torque Mode●

In this mode the torque control with all relatedparameters is described.

Velocity Mode●

Many frequency inverters use this simple mode tocontrol the velocity of the drive with limits and rampfunctions.

The Velocity Mode is rather separated from the other modesand does not interfere with them so much. For this reason, thenaming of object dictionary entries differs a little bit from theother modes.

The manufacturer commits in the manual which modes aresupported by his device.

If more than one mode is supported, then the manufactureralso defines whether the change of operation mode is allowedwhile the drive is moving or only when the drive is sTopped.

Device Profile Human Machine InterfacesDSP 403 V1.0 members only

This document represents the device profiles for HumanMachine Interfaces (HMI).

HMI devices use communication techniques, which conform to

More:




CAN in Automation





those described in the CANopen Application Layer andCommunication Profile. In general the mechanisms, which arespecified in the communication profile are sufficient for thedefinition of profiles for devices, which, on the applicationlevel, provide some kind of I/O functionality. Example devicesinclude I/O modules, drives and regulators. These devices,while they may be complex, are not termed ‘intelligent’ as theydo not run an application level program.

For the description and operation of intelligent devices furthermechanisms are necessary, which are specified in theFramework for Programmable CANopen Devices. Thisspecification has to be regarded as a framework for thedefinition of device profiles for intelligent or programmabledevices in form of an extension to the CANopen ApplicationLayer and Communication Profile. The additional mechanismsspecified in the framework are useful especially for devicessuch as PLCs, very intelligent HMI or CANopen tools.

These documents should be consulted in parallel to thisprofile.

The purpose of the device profile for a Human MachineInterface (HMI) is to support simple HMI devices as well asintelligent and very intelligent HMI devices.

The profile defines display functions and user functions. Thisdevice profile is based upon the definitions in the CANopenCommunication Profile.

The definitions of simple HMI, intelligent HMI and veryintelligent HMI refers to the kind of the implemented CANopenCommunication Profile.

Device Profile for IEC1131 Programmable DevicesDSP 405 V1.0 members only

This document represents the standardized CANopen DeviceProfile for IEC1131 programmable devices like PLCs.

All the above devices use communication techniques, whichconform to those described in the CANopen Application Layerand Communication Profile and the Framework forProgrammable CANopen Devices. These documents shouldbe consulted in parallel to this profile.

This paper coversthe access to a CANopen communication system fromwithin an IEC1131 program

1.

More:




CAN in Automation





based on variables, i.e. access to elementaryIEC1131 variable objects,

.

based on calls to function block.b.

utility functions for debugging, monitoring and networkmanagement

2.

With respect to integrating tools for CANopen configurationand IEC1131 programming and debugging, this paper definestwo different kinds of integration:

The network-centric approach, in which IEC1131programming is assumed to be done after CANopenconfiguration, being logically below configuration

1.

The PLC-centric approach, in which CANopenconfiguration is assumed to be done after IEC1131programming, being logically only one part of theconfiguration of the complex PLC system

2.

Device Profile for EncodersDSP 406 V2.0 members only

This document represents the CANopen device profiles forincremental and absolute, linear and rotary encoders. Besidesposition and velocity output possibility complete camfunctionality is covered. In addition it is possible to handlemulti sensors through one CANopen device.


The purpose of encoders is to detect positions of any kind ofmachine tools. Encoders detect positions and transmit theposition values across the CAN network. They can receiveconfiguration information via the service data objects,conversion parameters for calculating a - to the applicationadapted - position value. In the operational status, the positionvalue can be read from the encoder by Remote TransmissionRequest telegrams or Sync Telegrams. Additionally, theencoders can transmit cyclic the position values.


CAN in Automation




Literature Order Form CiACiA Standards (in English):CAN Presentations download hereCiA Draft Standard 102 (Version 2.0)CAN Physical LayerFor Industrial Applications (4 pages, free of charge)Download as PDF FileCiA 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 LayerFor Industrial Applications (150 pages, 65 EUR + GermanVAT)

CiA Draft Standard 301 (Version 4.0)CANopen Communication ProfileFor Industrial Systems ( 65 EUR+ German VAT)

CiA Draft Standard Proposal 302 (Version 2.0)Framework for Programmable CANopen Devices(30 pages, 35 EUR + German VAT)

CiA Draft Standard Proposal 401 (Version 1.4)CANopen Device ProfileFor I/0 Modules (115 pages, 49 EUR + German VAT)

CiA Draft Standard Proposal 402 (Version 1.0)CANopen Device ProfileFor Drives and Motion Control (200 pages, 65 EUR + GermanVAT)

CiA Draft Standard Proposal 403 (Version 1.0)CANopen Device ProfileFor for Human Machine Interfaces (52 pages, 49 EUR +German VAT)

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

More:

DownloadsCAN Newsletter

More:


More:


CAN in Automation

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




CiA Draft Standard Proposal 406 (Version 2.0)CANopen Device ProfileFor Encoders (111 pages, 49 EUR + German VAT)

All CAN + CANopen Standards CD-Version(150 Euro + German VAT)

Standards (in English)

CAN Kingdom 3.0to download go to

Volume 1 and 2, Release 2.0DeviceNet(paper version: 260 EUR + German VAT + postage)

Volume 1 and 2, Release 2.0DeviceNet(CD-ROM: 260 EUR + German VAT + postage)

Volume 1 and 2, Release 2.0DeviceNet(paper and CD-ROM version: 320 EUR + German VAT +postage)

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

3rd internationalCAN Conference 1996(360 pages, 21 EUR)

4th internationalCAN Conference 1997(360 pages 41 EUR

5th internationalCAN Conference 1998(302+ pages 61 EUR

More:


More:


More:


CAN in Automation


http://www.kvaser.se/canking/index.htm




CAN Literature (in German)Prof. Konrad EtschbergerCAN2nd edition, available September 1999

Prof. Wolfhard LawrenzCAN3nd edition, (500 Seiten 85,90 EUR)

SonderheftController Area NetworkVogel Verlag (100 Seiten 16 EUR)

CAN Literature (in English)Prof. Dr. Wolfhard LawrenzCAN System Engineering1st edition, (468 pages 60,33 EUR or 69,95 $ )

CAN Literature (in Français)

Le Bus CANDominic Paret, 277 pages (250 FF)Le Bus Can ApplicationsDominic Paret, 340 pages (250 FF)

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

More:


More:


CAN in Automation




CAN Newsletter 1-year subscription (4 issues)(15 EUR in Europe, 26 EUR in Overseas)

Name:

Company:

Street:

ZIP:

City:

Country:

Phone:

Fax:

E-Mail:

More:


CAN in Automation



Download DownloadPresentations:

Physical LayerData Link LayerImplementationsApplicationsCANopen

Specifications:CAN Specification 2.0 consists of two parts, with

CAN 2.0 Part Adescribing the CAN message format as it is defined in CANSpecification 1.2;

CAN 2.0 Part Bdescribing both standard and extended message formats.

In order to be compatible with this CAN Specification 2.0 it isrequired that a CAN implementation be compatible with either Part Aor Part B.CAN 2.0 Addendum ...

CAN Physical Layer for Industrial Applications

DS 102 V2.0

CANopen Cabling and Connector Pin Assignment

DR 303-1 V1.0

CANopen Representation of SI Units and Prefixes

DR 303-2 V1.0

More:

Download formembers

Page contents:topPresentationsSpecificationsOrderforms

More:

Download formembers


CAN in Automation

http://www.can-cia.de/d.htm (1 von 2) [14.11.1999 12:51:23]

http://www.can-cia.de/CANphy.pdf


http://www.can-cia.de/CANdll.pdf


http://www.can-cia.de/CANimpl.pdf


http://www.can-cia.de/CANappl.pdf


http://www.can-cia.de/canopen.pdf

http://www.can-cia.de/canopen.pdf









http://www.can-cia.de/DR303_1.pdf










Orderforms:Training & Education

iCCiCC ConferenceiCC Seminars & Workshops

Fairs & Exibitions

More:

Download formembers


© CAN in Automationlast update:1999-10-13

CAN in Automation

http://www.can-cia.de/d.htm (2 von 2) [14.11.1999 12:51:23]

http://www.can-cia.de/regconf.pdf


http://www.can-cia.de/regsem.pdf





General introduction CANopenPage contents:

Advantages & featuresFirst information

Advantages

Open and vendorindependent

❍

Supportsinter-operability ofdifferent devices

❍

High speed real-timecapability

❍

Modular - coverssimple to complexdevices

❍

User-friendly - widevariety of supporttools available

❍

Features

Auto configuration ofthe network

❍

Easy access to alldevice parameters

❍

Devicesynchronisation

❍

Cyclic andevent-driven datatransfer

❍

Synchronousreading or setting ofinputs, outputs orparameters

❍

First Information

CANopen is a networking system based on the serial busController Area Network (CAN). The CANopenCommunication Profile (CiA DS-301) supports both directaccess to device parameters and time-critical process datacommunication. CANopen device profiles (CiA DS-40x) definestandards for basic device functionality while providing amplescope for additional vendor-specific device features. CANopenunleashes the full power of CAN by allowing directpeer-to-peer data exchange between nodes in an organizedand, if necessary, deterministic manner. The networkmanagement functions specified in CANopen simplify projectdesign, implementation and diagnosis by providing standardmechanisms for network start-up and error management.

CANopen supports both-cyclic and event-drivencommunication. This makes it possible to reduce the bus loadto a minimum but still maintaining extremely short reactiontimes. High communication performance can be achieved atrelatively low baud rates, thus reducing EMC problems andminimizing cable costs.

More:

Technical introductionSpecificationsConformance testFAQsVendor list

Vendor ID registration

Presentation:

CANopen

Page contents:TopAdvantages & featuresFirst information

CAN in Automation

http://www.can-cia.de/hog.htm (1 von 2) [14.11.1999 12:52:04]


http://www.can-cia.de/VendorID.pdf


http://www.can-cia.de/CANopen.pdf


CANopen is the ideal networking system for all types ofautomated machinery. One of the distinguishing features ofCANopen is its support for data exchange at the supervisorycontrol level as well as accommodating the integration of verysmall sensors and actuators on the same physical network.This avoids the unnecessary expense of gateways linkingsensor/actuator bus systems with higher communicationnetworks and makes CANopen particularly attractive tooriginal equipment manufacturers.

More:

Technical introductionSpecificationsConformance testFAQsVendor list


presentation:

CANopen




CAN in Automation

http://www.can-cia.de/hog.htm (2 von 2) [14.11.1999 12:52:04]






Technical introduction CANopenPage Content :

Built on standardsApplication layer and communication profileCommunication modelNetwork initialization and managementData transfer mechanismsService data objectsProcess data objectsEventsSynchronizationPollingPDO mappingDevice profilesObject dictionaryObject dictionary - exampleCANopen development

Built on Standards

Open fieldbus systems enable the construction of machines byconnecting components from multiple vendors whileminimizing the effort required for interfacing. To achieve anopen networking system, it is necessary to standardize thevarious layers of communication used.

CANopen uses the international CAN standard, ISO 11898 asthe basis for communication. This standard covers the lowertwo layers of communication specified by the OSI model.Building on this, the CANopen profile family specifiesstandardized communication mechanisms and devicefunctionality for CAN-based systems. The profile family, whichis available and maintained by CAN in Automation (CiA)consists of the Application layer and communication profile(DS 301), various frameworks and recommendations (CiADS-30x) and various device profiles (CiA DS-40x).

Application Layer and Communication Profile

The CANopen Application Layer and Communication Profile(CiA DS 301) defines “how” data should be exchangedbetween devices and describes the interface to the underlyingcommunication medium. To realize open interoperable

More:

General introductionSpecificationsConformance testFAQsVendor list

Vendor IDregistration

Presentation:

CANopen

Page contents:TopBuilt on standardsApplication layer andcommunication profileCommunication modelNetwork initialization andmanagementData transfermechanismsService data objectsProcess data objectsEventsSynchronizationPollingPDO mappingDevice profilesObject dictionaryObject dictionary -exampleCANopen development

CAN in Automation

http://www.can-cia.de/hot.htm (1 von 9) [14.11.1999 12:52:55]







systems based on CAN, it is necessary to define, which datahave to be transmitted and with which services. CANopenprovides one such definition, which is especially suitable forreal-time industrial automation.

Development of the Application layer and communicationprofile started with the following objectives:

Clear and concise structure to ease implementation andmaintenance

●

Use existing international standards as far as possible●

Support for CAN chips with acceptance filtering andmessage storage capabilities (FullCAN) to allowimplementation in simple devices

●

Use smallest possible number of communication objects(CAN identifiers)

●

Easily scalable from simple to complex functionality tocover the wide range of devices found in automatedmachinery

●

Provide reliable and deterministic network behaviour●

With these objectives in mind, CANopen was developed usingonly a small number of communication services necessary formachine automation, resulting in low processor and memoryoverhead. Considering the data flow requirements ofautomation systems led to the definition of the followingCommunication model.

Communication Model

The CANopen protocol defines several methods fortransmission and reception of messages over the CAN bus.These messages are referred to as communication objects.Synchronous data transfers allow network wide coordinateddata acquisition and actuation. Synchronous transfers aresupported by predefined communication objects i.e. SyncObjects transmitted on a cyclic time period and Time StampObjects. Asynchronous or event messages may be sent at anytime and allow a device to immediately notify another devicewithout having to wait for a synchronous data transfer to takeplace. The content of both synchronous and event telegrams(Process Data Objects) may be dynamically configured at bootup by the machine controller. Although CAN is restricted totransfers of a maximum of 8 data bytes within one telegram,data transfers larger than 8 bytes are also provided for by theprotocol (Service Data Objects).

More:



Presentation:

CANopen


CAN in Automation








CANopen defines four types of messages (communicationobjects):

Network administration messages such as LayerManagement (LMT) and Network Management (NMT)

●

Service Data Objects (SDO)●

Process Data Objects (PDO)●

Predefined messages such as the Sync Object, TimeStamp Object and Emergency Object

●

Network Initialisation and Management

Network management services are used to control theoperating state of devices in a CANopen network. Usingnetwork management the following functionality is available:

Dynamic or static distribution of CAN identifiers forSDO/PDO communication and error services

●

Control over node operating states and communicationmodes for individual or multiple nodes

●

Periodic Polling of nodes to detect nodes that are nolonger alive or functioning correctly

●

Instead of Polling every device produce a message that he isstill alive and other devices can "hear" to this messages

●

Data Transfer Mechanisms

CANopen defines two Data transfer mechanisms, which havevery different characteristics and are intended to cover the fullrange of requirements found in automation applications.

Service Data Object (SDO) transfers are acyclic and aretypically used for configuring devices on a CANopen networkwith low priority. Individual parameters are addressed using a16 bit index and an 8 bit sub-index addressing mechanism.Data transfers in this mode may be greater than 8 bytes byuse of multiple CAN telegrams.

Process Data Object (PDO) transfers are typically used forhigh speed, high priority data. Data in a PDO telegram islimited to 8 bytes or less. The format and data content of themessage may be fixed or dynamically configured using SDOdata transfers.

Service Data Objects

Service Data Objects (SDOs) are normally used for deviceconfiguration such as setting device parameters or

More:



Presentation:

CANopen


CAN in Automation








downloading programs. They are also used to define the typeand format of information communicated using the ProcessData Objects.

Service Data Objects provide the following functionality:Transmit data of any size (boolean to large files)●

Confirmed services (request/response) for read andwrite of any data

●

Expedited transfer of data less than or equal to 4 bytestotal length

●

Segmented transfer of data greater than 4 bytes totallength

●

Abort of data transfer by either Client or Server withoptional error feedback

●

In CANopen devices, all parameters and variables, which areto be accessible via CAN are clearly arranged in an objectdictionary, which is described in more detail later. All theobjects in the object dictionary can be read and/or written viaSDO.

Process Data Objects

The Process Data Objects (PDO) do not contain any explicitprotocol overhead and this allows very fast and flexibleexchange of data between applications running on each node.PDOs can be transmitted directly from any device on thenetwork simultaneously to any number of other devices. Thismulticast capability is one of the unique features of CAN and isexploited to the full by CANopen.

Events

CANopen supports different modes for transfer of real-timedata. One mode is simply to send a PDO telegram on theoccurrence of an event. For example, a digital I/O transmitsthe state of its input lines when they change state. Ananalogue input module might send the state of an input lineonce this state has exceeded a pre-configured value. Thismode allows the bus load to be reduced to a minimum and ahigh communication performance can be realized withrelatively low bit rates. It also allows the reaction time tochanging data, which is the critical factor in many applications,to be kept very short.

Synchronization

More:



Presentation:

CANopen


CAN in Automation








The synchronized mode allows devices on the network to betightly synchronized to a master clock. This is essential insome motion control applications or in applications whereremote inputs and outputs have to be read or writtensimultaneously. This mode is particularly useful where controlloops are closed over the bus necessitating synchronoussampling of Process data. As well as the cycle time, theprotocol also allows many other parameters to be changed.For instance, it is possible to transmit some of the data onlyevery n-th cycle.

Synchronous and event-driven objects may be mixed freely onthe network.

Polling

Finally it is also possible to read Process data from othernodes by Polling. A PDO can be used to poll a particular set ofdata at any time using the CAN remote frame mechanism.

PDO Mapping

A special feature of CANopen is that the data contained inPDOs may either be predefined by the device manufacturer orit may be configured by the application. Thus it is possible tooptimize real-time data transfer for a particular application. It iseven possible, by means of a place holder mapping, to serveseveral nodes with data in the same message.

Device Profiles

CANopen uses the concept of device profiles, which aidssystems integration and device standardization. By conformingto the guidelines contained in a CANopen device profile two

More:



Presentation:

CANopen


CAN in Automation








independent manufacturers can produce standardizeddevices. The advantages of this approach are numerous andperhaps, most importantly it allows a system integrator todecouple himself from a specific device manufacturer. Thisallows networks of devices from independent manufacturers tobe constructed without having to write specific software fornetworking each device together. Both optional andmanufacturer specific functionality can also be defined for adevice using the CANopen profiling mechanism, makingCANopen device profiles future proof. By defining mandatorydevice characteristics, basic network operation is guaranteed.By defining mechanisms for both optional and manufacturerspecific functionality future CANopen devices will not beconstrained by an out of date standard.

CANopen device profiles are being defined for a whole rangeof different device types including digital and analogue I/Omodules, drives, motion controllers, encoders and operatordisplays.

Object Dictionary

All device parameters are listed in the standardiZed CANopenObject Dictionary and each entry is assigned a 16 bit index,which is used to access the data. The Object Dictionarycontains the description, data type and structure of eachparameter.

The CANopen Object Dictionary is organized in severalsections comprising a data type area, a communication profilearea, a device profile area and a manufacturer specific area.The structure is shown in the table below:Index Object Dictionary Section0001-001F Static Data Types (e.g. Boolean, Integer 16)

0020-003F Complex Data Types (e.g. PDO CommPar, SDOParameter)

0040-005F Manufacturer Specific Data Types

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 CANopenDevice Profiles)

Object Dictionary - Example

More:



Presentation:

CANopen


CAN in Automation








Many different data types are supported from simple bit valuesto complex structures and these are defined in the objectdictionary. Manufacturer specific data types may also bedefined.

The communication profile area contains information about thecommunication as well as some basic data about the device.The data mapping for PDO messages is also defined here.

The device profile area contains device specific parameters.There is a range of mandatory entries in the dictionary whichensures that all CANopen devices of a particular type showthe same basic behaviour. Some extended device features aredefined as optional. This means that a manufacturer is notobliged to provide all extended functionality on his device but ifhe wishes to do so, he must do it in a pre-defined fashion.Additionally, there is sufficient address space for trulymanufacturer specific functionality.

An extract from a sample object dictionary is shown below.Index Sub-Index Object Name Type Attribute Default Value1000 00 VAR device type unsigned

32const 00 03 01 91H

1001 00 VAR error register unsigned8

ro 00H

1002 00 VAR manufacturerstatusregister

unsigned32

ro 00 00 00 00H

1003 ARRAY error register 00 number of

entriesunsigned8

ro 01H

01 error value unsigned32

ro 00H

1008 00 VAR manufacturerdevice name

vis-string const “CiA_Product”

1009 00 VAR manufacturerhardwareversion

vis-string const “V1.1”

100A 00 VAR manufacturersoftwareversion

vis-string const “V2.4”

1018 RECORD identityobject

00 VAR number ofentries

unsigned8

const 01H

01 VAR Vendor-ID unsigned32

const 01H

1400 RECORD 1st receivePDOparameter

More:



Presentation:

CANopen


CAN in Automation








00 VAR number ofentries

unsigned8

ro 02H

01 VAR receive PDOCOB-ID

unsigned32

rw

02 VAR PDO type unsigned8

rw FFH

6000 ARRAY read 8 inputlines

00 VAR number ofinput lines ingroups of 8

unsigned8

ro 01H

01 VAR read state of8 input lines

unsigned8

ro

CANopen Development

The CANopen Specifications are maintained by the InterestGroup CANopen and related Special Interest Groups withinthe international CAN users and manufacturers group, CAN inAutomation (CiA). The work is coordinated by the CiA InterestGroup CANopen and associated Special Interest Groups. Allof these groups are completely open to any member of CiA.

More:



Presentation:

CANopen


CAN in Automation








More:



Presentation:

CANopen

Page contents:TopBuilt on standardsApplication layer andcommunication profileCommunication modelNetwork initialization andmanagementData transfermechanismsService data objectsProcess data objectsEventsSynchronizationPollingPDO mappingdevice profilesobject dictionaryobject dictionary -exampleCANopen development



CAN in Automation








Frequently asked questions CANopenPlease send your questions to [email protected]

coming soon

More:

General introductionTechnical introductionSpecificationsConformance testVendor list


Presentation:

CANopen



CAN in Automation

http://www.can-cia.de/hof.htm [14.11.1999 12:53:02]

mailto:[email protected]






Conformance test CANopenPage contents:

Introductiontest procedureTest toolCertified companiesFAQs & design hints members only

Introduction

The growing CANopen market is shared by more and moremanufacturers of CANopen devices. All of them implementeda software covering communication services of higher protocollayers basing on the CANopen Communication Profile. Toguarantee Conformance of the implementations to theCANopen Communication Profile as base for correctfunctionality and possible interoperability of CANopen devicesCiA now offers a standardized test procedure. The certificate,that you will get after the passed testprocedure, can also be used formarketing activities.

Test Procedure

The CANopen devices are tested with respect to the CANopenCommunication Profile CiA DS-301, Version 3.0, not to aspecial device profile. The Test Description for CANopenDevices Revision 1.1 includes a static test where timingrequirements are not taken into consideration. For every test atest report will be generated listing all steps of the test and allerrors that have occured during the test.

In a first step the EDS (Electronic Data Sheet) of the CANopendevice is tested. By means of a EDS a CANopen device canbe described with respect to the contents of its objectdictionary. The following requirements shall be fulfilled by thecontents of the EDS: Correct value ranges, support ofmandatory entries, references pointing to existing entries andconsistency of the EDS.

In a second step the physical CANopen device is tested. Thispart includes the test of the Communication Protocol, the testof the EDS against the object dictionary and the verification of

More:

Technical IntroductionSpecificationsConformance testFAQsVendor list


Presentation:

CANopen

Page contents:TopIntroductionTest procedureTest toolCertified companiesFAQs & design hintsmembers only

More:



Presentation:

CANopen

CAN in Automation

http://www.can-cia.de/hoc.htm (1 von 3) [14.11.1999 12:53:13]

http://www.can-cia.de/hocc.htm

http://www.can-cia.de/intern/mhocf.htm













network states and transitions.

Test procedure at CiA

CAN in Automation offers the service of an official testlaboratory where CANopen devices can be certified. Pleasecontact CiA headquarters for arranging a date for the test.

Within one session many devices can be tested. For a secondtest of a device, which failed in the first session no new basicrate 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 powersupply.

The certificate describes the hardware of the device (CANcontroller, microcontroller) and the versions of the CANopenimplementation and the EDS file. One certificate can be givenfor a number of devices. The certified devices will bepresented on our Internet Websites.

non-members membersBasic Rate per Test Session 260.- EURO 130.- EURORate per hour 80.- EUROCertificate 100.- EURO 50.- EURO

* Prices don't include German VAT.

Please contact CiA headquarters for arranging a date.

Test Tool

The CANopen Conformance Test Suite, which is also used forCANopen certification at CiA headquarters is now available forevery Vendor and buyer of CANopen devices. So everybodycan check conformance to the standards and prepare thedevices to pass the certification process.

The Conformance Test (CT) Suite, which was implemented byNational Instruments consists of a PC software and a CANinterface card. The following kits are available:

Software Hardware PriceKit 1**:CT Software - 1.325.- EURO*

Kit 2**:CT Software

AT-CAN one port board(driver for W95 only) 1.530.- EURO*


More:



Presentation:

CANopen


CAN in Automation


http://www.can-cia.de/framail.html










Kit 3**:CT Software

PCI-CAN one port board(drivers for W95 and Win-NT) 1.685.- EURO*

Kit 4**:CT Software

PCMCIA-CAN one port board(drivers for W95 and Win-NT) 1.735.- EURO*

* Prices don't include German VAT.** Kits for Compact PCI/PXI and CAN two port boards are available on request.

The Conformance Test Suite Updates with Bug Fixes areavailable free of charge from the National Instruments server.The updates can be found at the N.I. ftp-server as exe-files fordownloading. Please note that only Bug Fixes are free ofcharge, a version update with increased functionality is notfree of charge.

Contact Address for Test Suite Orders:National Instruments Germany GmbHKonrad-Celtis-Str. 79D-81369 Münchenphone: +49-89-7413130fax: +49-7146035Email: [email protected]

1.

CAN in Automation (CiA) e.V.International HeadquartersAm Weichselgarten 26D-91058 Erlangenphone: +49-9131-690 86-0fax: +49-9131-690 86-79Email: [email protected]

2.

More:



Presentation:

CANopen



CAN in Automation


ftp://ftp.natinst.com/










Vendor list CANopen

members can download this list as a comma seperatedtext file (.csv)

Company Department Vendor-IDAntal Electronic 0000001A

Applicom International 00000020

Arteco SpA 00000006

Ascom Autelca AG 00000025

bebro electronic GmbH 00000027Beckhoff AutomationGmbH 00000002

Brand Innovators BV 00000038CiA Headquarters 00000001CMZ 0000000A

Comap s.r.o. 0000002F

Computechnic AG 00000037Danfoss Fluid Power A/S MH-TME 00000019Datamicro Co. LTD 00000026

Elrest GmbH 00000032

EMS Dr. Thomas Wünsche 0000002B

Epec Oy 00000030

Epis-Microcomputer 0000001C

ERL GmbH 00000029esd electronic systemdesign gmbh 00000017

ESR Dipl.-Ing. PollmeierGmbH 0000000F

Festo AG & Co. OV-M 0000001DF-Tron Elektronik GmbH 00000011G.A.S. Gesellschaft fürAntriebs- undSteuerungstechnik mbH

00000010

Graf-Syteco 0000002D

Gustav Wurm GmbH & Co. 0000000B

More:General introductionTechnicalintroductionSpecificationsConformance testFAQs


Presentation:

CANopen

CAN in Automation

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

http://www.can-cia.de/intern/hov.csv

http://www.can-cia.de/intern/hov.csv







Hengstler GmbH 00000008

HMS 0000001BIndutron IndustrieelektronikGmbH IMT 00000035

Isel-Automation 00000031Ixxat Automation GmbH /STZP 00000004

Janz Computer AG 00000007

KEB Antriebstechnik 00000014

Klaschka GmbH & Co. 0000002A

Kübler GmbH 00000013

Lawicel HB 00000033

Lust Antriebstechnik GmbH 00000016McLennan Servo SuppliesLtd. 00000012

MEN Mikro ElektronikGmbH 004D454E

MicroControl GmbH & Co.KG 0000000E

Micro-key bv 00000022MOOG Germany 00000028Novotron GmbH 0000001F

Port GmbH 00000034ProControl AG Power and Motion Control 0000000CRobert Bosch GmbH Automationstechnik 00000024Sevcon Ltd. 0000001ESIG Positec AutomationGmbH Technologie + Integration (TI) 0000002E

SMH Automation 00000009

Softing GmbH 0000000D

Techno-Matic ApS 00000023Technoteam GmbH Verkehrstechnik 00000018Tetra Pak R&D Automation 0000002C

TU Bergakademie Freiberg Institut fürAutomatisierungstechnik 00000015

Vector Informatik GmbH 00000005WAGO KontakttechnikGmbH Electronicc 00000021

Weidmüller ConneXtGmbH & Co. 00000003

More:General introductionTechnicalintroductionSpecificationsConformance testFAQs


Presentation:

CANopen

CAN in Automation








Zürcher HochschuleWinterthur (ZHW)

Institut für MechatronischeSysteme (IMS) 00000036



CAN in Automation


News CAN Newsletter

Hardware + Software + Tools + Engineering

published by pz marketingSimon-Schoeffel-Str. 21

D-90427 NuernbergFax +49-911-3067283Email: [email protected]

This unique magazine updating its readers with technology, product and otherinformation related to Controller Area Network is published quarterly (March,June, September, and December).

View into September 1999 issueView into June 1999 issueView into March 1999 issue

Preview to the December issue:

Synthesizable VHDL model for CAN Protocol

The synthesizable VHDL model has been developed at theInstitute for Computer Aided Circuit Design, University ofErlangen-Nuremberg. The function of this implementation is tointerface CPUs with the serial 2-wire CAN bus with regard tothe CAN protocol specified in ISO 11898-1 (11-bit and 29-bitframes). Special attention has been given to the configurationof the device by parameters, an important factor for itsreusability.One of the major values of a reusable component is the easeof reuse in different design environments. The more flexible itis the more often it is possible to use it. For this it is importantto be able to tailor the architecture and the interfaces to thespecific needs of a design. In our approach this is done bycarefully analyzing the possible requirements of a componentand using a supermodel concept implementing all reasonableand necessary functionality. An important feature is thepossibility to configure a component during operation. For thiscase it is necessary to implement additional control registerswhich can be modified and influence the componentsfunctionality.

More:

Hot NewsCiA NewsPress ReleaseStandardization

Page contents:topVHDL modelManagementFrameworksInterfacing the 82527other topics

More:


CAN in Automation

http://www.can-cia.de/NN.htm (1 von 3) [14.11.1999 12:56:37]

http://www.can-cia.de/NN3.htm





Mapping of CAN Devices to WWW based ManagementFrameworksThe mapping of the management functions of a CAN devicerequires an appropriate description of the communicationobjects and of the functionality the module provides. Thesedescriptions can be derived from communication and deviceprofiles (standardized communication objects), and from thedevice documentation (vendor-specific objects and functions).Both types of information are used to design the user interfacethat will be embedded into hypertext pages.The CANopen application layer protocol and CANopen DeviceProfiles define the communication objects implemented in thenetworked modules. These objects have been mapped tovariables in scripts. The scripts are used as control instancesfor ActiveX-objects that the management functionality of themodules is mapped to. The interconnection to the CANnetwork is performed by an OLE Automation driver for CAN.The scripts pass data from this driver object to the controls ina web page. In addition, DCOM-enabled software componentshave been implemented for a mapping of the managementfunctions. These DCOM components can be embedded into oraccessed from hypertext documents. They perform atransparent data exchange with a DCOM server across theLAN. The DCOM server is implemented in the gateway.The problem of re-using description information in differentcontext (e.g. definition, management, visualization, applicationdevelopment) was addressed by creating XML descriptions forfieldbus components. Based on an appropriate DocumentType Definition (DTD), an XML description of a CANopenDevice Profile was created. This description holds allinformation necessary to generate the associated document inHTML format (Fig. 6). An XSL style sheet with formatting andfiltering instructions supports the generation of the document.This style sheet has to be developed once, and it can bere-used for other profile descriptions. In addition, moregeneralized DTD and style-sheet allow an easy porting of thedevice profile to other fieldbusses. The XML Document ObjectModel (DOM) allows access to XML files from a Script or ahigh-level programming language. So, based on the sameXML file, specific style sheets and scripts can be used tocreate input files for other management tasks. For example, aScript can create the CANopen-specific Electronic Data Sheet(EDS), or Device Configuration File (DCF) files.


More:



CAN in Automation



Interfacing the 82527 to 68HC11

The CAN controller from Intel provides six modes to interfacea microcontroller. For the 68HC11 microcontroller fromMotorola, an 8-bit non-Intel multiplexed interface (mode 2)should be used. The 82527 matches the AS, R/W#, E andAD7 to AD0 signals with microcontroller pin-for-pin (see fig. 1).The INT# pin of the CAN chip is tied to the 68HC11 IRQ# pin,and the Reset# pin is tied to a microcontroller pin or resetcircuit (RC network). The Reset# pin must be asserted to V_Ilor less for a minimum of 1 ms after V_CC in the operationrange in order to guarantee a proper device reset. The CS#signal may be generated by a PAL decoding the upperaddress bits from the microcontroller. The signal must begenerated 131 ns after a valid address is given on the bus,when the baudrate is 1 Mbit/s. The 82527 requires the CS#signal to be valid 20 ns before AS goes low. Themicrocontroller sends a valid address 151 ns prior to ASfalling.

Other Topics

+ Business News+ Semiconductor News+ Device News+ Software News+ Tool News

Annual subscription prices:

16 EUR for Europe26 EUR for Overseas

Advertising rates


More:



CAN in Automation


http://www.can-cia.de/NNA.htm


Hot News NewsPage contents:

CANopen RecommendationsiCC in TorinoODVA in KoreaDistributor as ODVA MembersCAN Chip Sales FiguresReviewed CAN SpecificationSafety Communication for CANopenCAN in the German Army

CANopen Recommendations

Erlangen, October 1999. CAN in Automation (CiA) haspublished the CANopen Draft Recommendation (DR) forCabling and Connector Pin Assignment (CiA DR-303-1) aswell as for SI Unit and Prefix Representation (CiA DR-303-2).The CiA DR-303-1 gives some general guidelines and rules ofthumb regarding the cabling of CANopen networks. Inaddition, a number of pin assignments for different connectorsis specified. In the CiA DR-303-2 there is a coding ofdimensions (SI unit and prefix) defined that should be used bythe CANopen device profiles. With the standardized coding ofdimensions even simple human machine interface devices caneasily display the actual dimension of an application object.

More information

iCC in Torino

Erlangen, September 1999. CAN in Automation has startedthe registration for the international CAN Conference (iCC) inTorino (2nd to 4th November). The early birds rate is valid byOctober, 15th. You also may now register for the workshops(English language) and seminars (Italian language).

More information

ODVA in Korea

Erlangen, September 1999. In July, a Korean ODVA meeting washeld in Seoul. More than 25 companies participated in the creationand development of DeviceNet in Korea, including representativesfrom Samsung, Rockwell, Turck, Pepperl+Fuchs, Festo, Eurotherm

More:

CiA NewsPress ReleaseNewsletterStandardization

Page contents:RecommendationsiCC in TorinoODVA in KoreaDistributorSales FiguresCAN ReviewSafety on CANopenCAN in the GermanArmy

More:

CiA NewsPress ReleaseNewsletterStandardization

CAN in Automation

http://www.can-cia.de/N.htm (1 von 3) [14.11.1999 12:56:53]

http://www.can-cia.de/D.htm



and Danfoss. ODVA Korea will act as the marketing and trainingarm for all DeviceNet-related activities. The Korea Instrumentationand Controls Association (KICA) supported by the Koreangovernment is promoting DeviceNet training.

More information

Distributor as ODVA Member

Erlangen, September 1999. ODVA is inviting distributors to jointhe DeviceNet association. A new ODVA member category fordistributors was created. "This is a logical and high-valueprogression ODVA," said Executive Director Bill Moss. "Distributormembers provide unparalleled insight into the needs of the end userand will be an invaluable partner in our effort to promote theadoption of DeviceNet." The standard distributor membership is$500 per year. The initial membership drive is limited to NorthAmerican distributors.

More information

CAN Chip Sales Figures

Erlangen, August 1999. CAN in Automation (CiA) hasaccumulated the CAN chip sales figures from most of the CANcontroller manufacturers. The total number of sold CAN nodesin 1998 is about 97 millions. About 7 millions were stand-alonecontrollers. According to the market survey there were sold31.8 millions 8-bit microcontrollers with integrated CANmodules. About 58.3 million CAN nodes implement 16-bitmicrocontrollers with on-chip CAN.

More information

Reviewed CAN Specification

Frankfurt, July 1999. The reviewed CAN Standard has beenhanded over to the responsible ISO Working Group (TC22SC3 WG1). The ISO 11898 document has been divided in twoparts: part 1 deals with the CAN data link layer protocol andthe medium access control specification, and part 2 describesthe CAN high-speed physical layer. In addition to someclarification, the CAN protocol was enhanced by some optionalfeatures such as time-triggered communication and silentmode. First silicon implementing all the new options will beavailable by end of this year.

Page contents:RecommendationsiCC in TorinoODVA in KoreaDistributorSales FiguresCAN ReviewSafety on CANopenCAN in the GermanArmy

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 CommunicationProfile for Safety Relevant Data Communication as CiA WorkDraft 304. This document is available for CiA internaldiscussions only and will be passed to the German authoritiesfor approval in Fall 1999. After approval it will be published asCiA DSP-304.

More information

CAN in the German Army

Trier, June 1999. The German armed forces have establisheda group discussing the use of CAN in vehicles. In the meetingsseveral vehicle manufacturers and suppliers are participating.In parallel, an European working group of the armed forcesdiscusses the use of CAN. Particularly the standardization ofhigher-layer protocols will be discussed: mainly CANopenversus J1939.


CAN in Automation


CiA News NewsPage contents:

ASAM on CANopenCANopen in Off-road VehiclesCiA Study Group AvionicsCANopen Communication Profile for Safety CommunicationCANopen Recommendations for Cabling and Connector PinAssignmentCANopen Recommendations for SI Units and PrefixesCANopen Device Profile for Generic I/O ModulesCANopen Device Profile for Door ControlCANopen Application Profile for Integrated Operating TheaterCANopen Framework for Maritime Applications

ASAM on CANopen

Erlangen, 1999-09-09. ASAM e.V. and CiA e.V. will establish thejoint working group "ASAM on CANopen”. ASAM specificationsare widely used in testing automobiles. In order to interconnectASAM-compliant sub-systems via CANopen, there is a need forspecific CANopen interface profiles to map ASAM objects into theCANopen object dictionary. The joint working group should specifythe requirements on such an interface profile. CANopen and ASAMexperts will write the interface profile, which will be given forreview to the joint working group. The inaugural meeting of thisjoint WG is scheduled on October, 14th in Wolfsburg at Volkswagenfacilities.

Please mail your registration to [email protected]

CANopen in Off-road Vehicles

Erlangen, 1999-09-09. CANopen networks are increasingly usedin off-road vehicles. In order to develop and review CANopendevices profiles for these application fields (road constructionmachines, agriculture and forestry machines, truck-based cranes andaircraft washing robots, etc.), CiA is calling for an inaugural meetingof the CANopen SIG "Off-road Vehicles”. Some of the alreadydeveloped device profiles such as for proportional hydraulic valvescan be used also for off-road vehicles. Other profiles pre-developedby the University of Magdeburg only have to be reviewed, andothers may be developed from the scratch. The inaugural meetingwill be on the 27th of October at the University of Magdeburg.

More:

Hot NewsPress ReleaseNewsletterStandardization

Page contents:topASAM on CANopenOff-road VehiclesAvionicsSafety CommunicationCabling and ConnectorsSI Units and PrefixesI/O ModulesDoor ControlMedicalMaritime

CAN in Automation

http://www.can-cia.de/NC.htm (1 von 5) [14.11.1999 12:57:23]



http://www.can-cia.de/n.htm

http://www.can-cia.de/np.htm

http://www.can-cia.de/ns.htm

Please mail your registration to [email protected]

CiA Study Group Avionics

Erlangen, 1999-07-12. CiA has called for an avionics studygroup. In the first meeting nine companies participated anddiscussed the state of aerospace projects using CANtechnology. There are three different application fieldsaddressed: Flight-critical control systems, auxiliary systems(e.g. air-condition), and flight-simulators. The next meeting isscheduled on November, 3rd in Torino. Topics will be specificrequirements for CAN physical layer as well as discussion onhigher-layer protocols, in particular, CANaerospace andCANopen. Interested parties in the CiA Study group Avionicscan contact CiA Headquarters ([email protected]).

CANopen Communication Profile for Safety Communication

Erlangen, 1999-07-10. The CANopen Communication Profilefor Safety-Relevant Data Transmission (CiA WD-304) isintended to be an add-on to the CANopen Application Layerand Communication Profile (CiA DS-301), which is alreadysubmitted for European standardization. The CiA WD-304document describes only the data transport mechanism onCANopen network that allows the exchange of safety-relevantdata. Due to CANopen compatibility, communication is limitedto 64 safe communication objects, so up to 64 producers ofsafety-relevant objects can operate in a single CANopennetwork. The number of consumers of safety-relevant objectsis not defined (at least one receiver is necessary).The additional safety-relevant communication shall not affectthe normal operation and services on a CANopen network.Safety-relevant communication is not related to a special classof devices, so that no special device profile has to be used. Toensure compatibility, the usage of identifiers and predefinedobjects has to be coordinated with the CANopen standard andexisting device profiles. As there is no use of data bits in thesafe communication method, it is compatible with alreadypublished device profiles.In a CANopen network the data interface to the applicationprogram within a certain node is only via the CANopen objecttable. So the application itself has no access to the datasequence and the time behavior of the CAN bus. The safetytests due to timing conformance has to be done in the safetyCAN interface.

More:



More:


CAN in Automation












SRDOs (safety relevant data objects) shall distributesafety-relevant data. A standard PDO or SDO is not sufficientfor hard safety requirements. So with the SRDOs differentmeasures (e.g. redundancy, cyclic transmission etc.) are takento ensure safety. An identifier range not currently in use forCANopen has been used for the SRDO transmissions.An SRDO consists of two CAN data frames with differentidentifiers. The user data in both transmissions is redundant,i.e. the meaning of the data is the same, but the data on the2nd transmission is inverted bit by bit. SRDOs must betransmitted periodically. If required, SRDOs can also betransmitted event driven, e.g. to ensure fast reaction after asafety critical change on the input. RTR must not be used forSRDOs; SRDO communication is only allowed in thenetwork-state "operational". SRDOs are only valid, if both CANframes are received properly (without failure and in time). Theredundant transmission is sent after the first transmission tothe CAN controller with minimum delay.More information (members-only section)

CANopen Recommendations for Cabling and Connector PinAssignment

Erlangen, 1999-07-10. The CiA DRP-303-1 documentspecifies naming conventions as well as AC and DCparameters for CANopen networks. The major part of thisrecommendation deals with the pin assignments forgeneral-purpose, industrial, and special-purpose connectors.This document is under final revision and will be published inFall 1999. CiA Members may send comments by July, 20th.More information (members-only section)

CANopen Recommendations for SI Units and Prefixes

Erlangen, 1999-07-10. The CiA DRP-303-2 documentspecifies the representation of SI units and prefixes to be usedin CANopen device, interface, and application profiles. Thisrecommendation is already used in the CANopen deviceprofile for proportional valves (CiA WD-408). Therecommendation is under final revision and will be published inFall 1999. CiA Members are asked to send comments by July,20th.More information (members-only section)

CANopen Device Profile for Generic I/O Modules


More:



CAN in Automation


http://www.can-cia.de/intern/mtssi.htm







Erlangen, 1999-07-10. The already published CANopendevice profile (CiA DSP-401 Version 1.4) is under review. Thenew version will be mainly compatible to the predecessor,however, some minor objects have been changed. Thereviewed document will be in accordance to the CiA DS-301Version 4.0 CANopen specification. The proposed changesare documented in the CiA WDP-401. CiA Members may sendcommends by August, 1st. This reviewed device profile will bepublished as CiA DS-401 Version 2.0, and will be the base forinteroperability tests for CANopen I/O modules.More information (members-only section)

CANopen Device Profile for Door Control

Erlangen, 1999-07-10. The Task Force Door Control of theCANopen Special Interest Group (SIG) Railways has releasedfor CiA internal discussion the CANopen Profile Door Control(CiA WD-409). The device profile is based on UICspecifications by means of using the same data types as TCN.This device profile will be part of the CANopen applicationprofile for railways. CANopen is already implemented in theBritish cargo-sprinter manufactured by Windhoff. The nextgeneration of the German cargo-sprinter will also make use ofCANopen networks. Other CANopen applications in railwaysare under development, e. g. in some Czech, Italian, andSwiss railways. Interested parties in the CANopen profiles forrailways can contact CiA Headquarters([email protected]).More information (members-only section)

CANopen Application Profile for Integrated Operating Theater

Erlangen, 1999-07-10. The CANopen Special Interest Group(SIG) Medical is going to specify an application profile forintegrated operating theaters. This specification will definehot-swapping functionality and automatic configurationcapability in order to ensure that the medical have not to dealwith network or device configuration. This profile waspre-developed by Siemens and will be reviewed by the SIGMedical. Interested parties in the CANopen device andapplication profile for medical equipment can contact CiAHeadquarters ([email protected]).

CANopen Framework for Maritime Applications

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

More:



CAN in Automation










(SIG) Maritime Electronics has been established to define aframework, which meets the requirements of the relatedauthorities. Kongsberg Norcontrol already uses CANopen, andother CiA Members such as MTU like to implement CANopenbridges and interface to reduce system integration efforts.Interested parties in the CANopen framework for maritimeelectronics can contact CiA Headquarters([email protected]).


CAN in Automation



Overview Literature Literature just released

CiA Compact DiscAll published CiA Specifications are available on CDincluding all CANopen profiles.

6th iCC ProceedingsThe proceedings of the 6th international CAN Conferenceincludes all 36 presentations.

CANopen RecommendationsThe CANopen Draft Recommendations (CiA DR-303) forcabeling and connector pin assignments as well asrepresentation of SI units and prefixes.

More literature

CAN Bibliography: Overview on books, magazines,proceedings, etc.

Literature order form: Literature provided by CiAHeadquarters

CiA Standards: List of all published CiA specifications


More:

Literature order formDownloadsCAN Newsletter

CAN in Automation

http://www.can-cia.de/L.htm [14.11.1999 12:58:56]

http://www.can-cia.de/LBC6.htm


CiAStandards

CAN in Automation offers different Standards, which can beordered.

Standards for CAN●

Standards for CAN Application Layer●

Standards for CANopen●

Other related CAN Standards●

More:

CAN StandardsCANopen StandardsCAL StandardsRelated Standards




CAN in Automation

http://www.can-cia.de/ls.htm [14.11.1999 12:59:12]


iCC Programme Events

6th international CAN Conference '992nd - 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 byNEC ElectronicsHitachi EuropeInfineon TechnologiesJackson Group(Automazione Oggi, Elettronica Oggi and Fieldbus andNetworks)MitsubishiMotorola

Organized byCAN in Automation e. V.

iCC`99 programmeConference registration form

Tuesday, 1999-11-2

9.00 - 10.30 Session I: TransceiverChairman: Viktor Schiffer (Rockwell Automation)Heinrich Gschlößl (Infineon Technologies): A Comparison of thedifferent CAN Physical Layers and their CAN-Transceiver Solutions

CAN in Automation

http://www.can-cia.de/EiCC.htm (1 von 6) [14.11.1999 12:59:38]







Richard J. Baird (Delphi Automotive Systems), Christopher A. Lupini(Delphi Automotive Systems). Single Wire CAN Physical LayerMohammad A. Livani (University Ulm): A Transparent Approach toFault-tolerant Broadcast in CAN

11.00 - 12.30 Session II: Physical LayerChairman: Robert Hugel (Robert Bosch GmbH)Prof. Dr. H. Beikirch (University Rostock): CAN Physical Layer forSpecial ApplicationsDr. Lutz Rauchhaupt (Ifak e.V. Magdeburg): Wireless CAN ExtensionsBob Lounsbury (Rockwell Automation): Designing an Industrial Networkwith unshielded Cable and IDC Connectors

9.00 - 10.30 Session III: Application ModelingChairman: Alfred Krappel (Hitachi Europe GmbH)Daniel Berglund (Kvaser AB): Using UML for Modeling CAN SystemsDr. Martin Wollschläger (Otto v. Guericke Univ. Magdeburg):CANopen Device Descriptions Using General Purpose ModelingLanguagesDr. Hayon A. Thompson (Rolls-Royce University): A CAN-Bus-BasedSafety-Critical Distributed Aero-Engine Control Systems ArchitectureDemonstrator

11.00 - 12.30 Session IV: System ModelingChairman: Prof. Dr. Gerhard Gruhler (STA Reutlingen)Markus Weseloh, Prof. Roland Rüdiger (FH BS/WF): Applying ModernSoftware Design Principles: A CAN Tool based on ExtensibilityWolfgang Wiewesiek, Volker Nieten (NEC Electronics Germany):Micro-Controller Simulator with CAN FunctionalitySofiane Ouni, Farouk Kamoun (ENSI): Efficient Protocol for Hard RealTime Communication on Control Area Network (CAN)

Wednesday, 1999-11-3

9.00 - 10.30 Session V: TimingChairman: Lars-Berno Fredriksson (Kvaser)Jose Alberto Fonseca, Pedro Fonseca (University of Aveiro):Scheduling and Synchronisation in CAN based Distibuted SystemsGianluca Cena, Adriano Valenzano (Cens-CNR Politecnico Torino):Enhancing the Efficiency of Controller Area NetworksFlorian Hartwich, Armin Bassemir (Robert Bosch GmbH). TheConfiguration of the CAN Bit Timing

11.00 - 12.30 Session VI: Gateway TechnologyChairman: Lars-Berno Fredriksson (Kvaser)Gerd Nusser (FH Reutlingen), Prof. Dr. G. Gruhler (STA Reutlingen):Teleservice of CAN Systems Via InternetDonal Heffernan, Paul Conway (PEI Technologies): CAN and the newIEEE 1451 Standard Transducer InterfaceKim Hiong Ang (University of Warwick), Bennet Levine (ContemporaryControl System): Device Net over TCP / IP Gateway

9.00 - 10.30 Session VII: Industrial ApplicationChairman: Joanne Dunn (Motorola)Paolo Ursino (Automata S.p.A.), Christoph Melzer (Automata GmbH):Injection Moulding Machines: A Distributed Control Approach

CAN in Automation


Francesco Riti (Eurosicma), Ferdinando Pozzi (Oasys srl): CAN inpackaging and plaster machinesEric Médan (NSi.): CAN Bus to 6000m down in Oil Prospecting

11.00 - 12.30 Session VIII: Transport ApplicationChairman: Andrea Borin (Magneti Marelli S.p.A.)Ulrich Dreher, Hans-Joachim Aupperle (Smart ElectronicDevelopment GmbH): CAN Applications in VehiclesWilliam B. Vlcek (Ascent Technologies Inc.), Steven N. Ernest (JacobsVehicle Systems): Implementing the CAN Calibration Protocol (CCP) inan SAE J1939 ApplicationStefano Vitturi (PST Galileo): Implementation of a CANopen Interfacefor the Remote Control of an Elevator System

Thursday, 1999-11-4

9.00 - 11.30 Session IX: ImplementationChairman: Klaus Turski (NEC Electronics Germany)Alfred Krappel, Naoyuki Hirayama (Hitachi Europe GmbH): AutomotiveMicrocontrollers with On-Chip CANAvi Ginsberg (Motorola Israel): Flex-CAN Communication Module forEmbedded MicrocontrollersPeter Hank (Philips Semiconductors): New Generation of CANController Supporting Higher Layer Protocols

11.00 - 12.30 Session X: Bridge TechnologyChairman: Viktor Schiffer (Rockwell Automation)Adriano Tamagnone (Six Tau S.p.A.): DSS - Distributed DiagnosticSystemsMahmut Tenruh (University of Sussex): Design and Implementation of aCAN / CAN Cut-through BridgeFlorian Bogenberger (Motorola GmbH), Ulf Warschat (Audi AG):High Level Performance Analysis of a quadruple CAN Gateway

9.00 - 10.30 Session XI: Physical Layer TestingChairman: Robert Hugel (Robert Bosch GmbH)Kiah Hion Tang, Richard McLaughlin (Warwick Manufacturing Group):DeviceNet Physical Layer Design and Conformance TestinJiri Pinker, Jiri Skala ( University of West Bohemia): Monitoring CANPerformance in Installations with High Level of InterferenceDr. Marcus Rimen, Dr. Jörgen Christmansson (CR & T AB): CANFault Injection

11.00 - 12.30 Session XII: Design ToolsChairman: Wouter Linneman (Infineon Technologies)Norya Lavorel (NSI): Conformity Certification Tools and Methods in aMultiplexed ArchitectureAlexander Semjonov ( Motorola Research Lab.): The Development ofthe Embedded Network Software based upon the Layer Model by Meansof Static Configuration ToolAlberto Bonastre, Rafael Ors (University of Valencia): A CANapplication layer protocol for the implementation of distributed expertsystems

iCC workshops (English language) and iCC seminars (Italian

CAN in Automation


language)Workshop and seminar registration form

Tuesday, 1999-11-2

Time Workshop 1 + 1a Seminars(Italian language)

14.00-16.00 CANopen (CiA) CAN (V-Systems) 116.00-18.00 DeviceNet (Rockwell) 2

Wednesday, 1999-11-3

Time Workshop 2 Seminars(Italian language)

14.00-16.00

CAN Kingdom(Kvaser)

CANopen (V-Systems)3

16.00-18.00 I livelli Applicativi CAL,DeviceNet and SDSper il Protocollo CAN

(Prof. S. Cavalieri,Univ. di Catania) 4

Thursday, 1999-11-4Time Workshop 3 Workshop 4

14.00-18.00 Measurement andcalibration of ECUs

(Vector)

DeviceNet(Rockwell)

Programme committee

Andrea Borin (Magneti Marelli)Lars-Berno Fredriksson (Kvaser)Prof. Dr. Gerhard Gruhler (STA Reutlingen)Robert Hugel (Robert Bosch)Prof. Dr. Wolfhard Lawrenz (FH Braunschweig/Wolfenbüttel)Viktor Schiffer (Rockwell Automation)Klaus Turski (NEC)Tobias Wenzel (Infineon Technologies)Holger Zeltwanger (CAN in Automation)

Registration information

Registration feeIncludes a copy of the CAN Conference proceedings respectively theworkshop or seminar hand-outs.

Registrations for the workshops or seminars are not valid for the CANConference nor vice versa!

CAN in Automation



Remark: Co-speakers are not registered automatically!

The Table-top exhibition, poster presentations, and productpresentations, however, may be visited by everybody free ofcharge.

ConfirmationWill be sent only to early registered attendees (upto 15th October 1999).

CancellationsReceived by 15th October will be refunded after the Conference less a 50Euro handling fee. For cancellations after 15th October 1999 no refundswill be made.

Conference registrationstarts on Tuesday 2nd November at 7.30 a. m. at the registration desk.You are strictly recommended to register early and to please use theadvance registration form.

Conference languageConference and Workshops are held in English language. The seminarsare held in Italian language.

Hotel accommodationParticipants will book their hotel rooms directly. A hotel list will be givenwith the confirmation.

Please return your registration form(s) to:

CAN in Automation (CiA) e. V.Am Weichselgarten 26D-91058 Erlangen (Germany)

Fax +49-9131-69086-79E-mail: [email protected]

Table-Top Exhibition

After several years, in which we had the accompanyingexhibitions not under the cover of CiA, which caused differentproblems, we finally are organizing the usual table-topexhibition again. The conditions and benefits for table-topexhibitors have been changed a little and are most interestingfor you all! Beside the sponsoring companies the followingcompanies have ordered one or two (or even four!) tables topresent 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+MEActia (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 ElectronicDesign (1), Toshiba (1), Warwick Manufacturing Group (1),

CAN in Automation


Weidmüller (2).

Product PresentationsThe following companies will give one or more presentationson their products and services. Each presentation will take 15minutes. The product presentations will start at 2 p. m. eachday 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 PresentationsThe third opportunity to get the newest information on CANproducts are the poster presentations. Beside the sponsorsand table-top exhibitors Milan Vukoje of Vickers, Casella (Italy)and Herbert Braisz of University of Erlangen (Germany) willgive a poster presentation.


CAN in Automation


CAN bibliography LiteraturePage contents:

BooksMagazinesiCC ProceedingsArticles and application notes

Books

Konrad Etschberger: CAN - Controller Area Network.Hanser-Verlag, München 1996. 400 pages. ISBN.The first part of the book introduces the CAN data link layerand the CAN high-speed physical layer. The second partdescribes the CAN Application Layer (CAL). All CMS, DBT,NMT, and LMT services and protocols are discussed. In thethird part, there is given a CAL application including programexamples.(The book is not more available, the new edition will bepublished by end of 1999)

Wolfhard Lawrenz: CAN - Grundlagen und Praxis. 3rd Edition.457 pages. Huethig-Verlag, Heidelberg 1999. ISBN3-7785-2734-7.The book describes the CAN data link layer and physical layeroptions in detail including implementations. In addition, thereare some chapters introducing higher-layer protocols, but donot discuss them in depth. Other chapters describes someapplications and products. The last chapter explainsdevelopment and test strategies.

Wolfhard Lawrenz: CAN System Engineering - From Theory toPractical Applications. 468 pages. Springer-Verlag, New York,1997. ISBN 0-387-94939-9.The book describes the CAN data link layer and physical layeroptions in detail. It is based on the 2nd Edition of theCAN-Book published in German language.

Dominique Paret: Le bus CAN - De la théorie à la pratique.277 pages. Dunod, Paris 1995. ISBN 2-10003164-3The book introduces into CAN data link layer and physicallayer. It describes in detail the CAN protocol and some CANcontroller. Higher-layer protocols and software tools areintroduced briefly.

More:


Page contents:BooksMagazinesiCC ProceedingsArticles

More:



CAN in Automation

http://www.can-cia.de/LB.htm (1 von 2) [14.11.1999 13:00:06]



All available books can be ordered by CiA

Magazines

CAN Newsletter: Hardware + Software + Tools + EngineeringQuarterly published magazine reporting market, product andtechnology news and articles on CAN technology. Themagazine is published since June 1992.

The CAN Newsletter can be subscribed via CiA

iCC Proceedings

The annual international CAN Conference is the mostimportant event for the CAN community.

• 1st iCC Proceedings. CAN in Automation, Erlangen 1994.• 2nd iCC Proceedings. CAN in Automation, Erlangen 1995.• 3rd iCC Proceedings. CAN in Automation, Erlangen 1996.• 4th iCC Proceedings. CAN in Automation, Erlangen 1997.• 5th iCC Proceedings. CAN in Automation, Erlangen 1998.• 6th iCC Proceedings. CAN in Automation, Erlangen 1999.

Articles and application notes

CAN controller and transceiver chip specific articles areavailable by the semiconductor providers. You can contact therelated web pages via the product surveys on CAN controllerand CAN high-speed transceivers

Go to application notes from Infineon

Go to application notes from Intel

Go to application notes from National Semiconductors

Go to application notes from Motorola(Software driver) or (Bit-timing)

Go to application notes from Philips Seminconductors


More:



CAN in Automation

http://www.can-cia.de/LB.htm (2 von 2) [14.11.1999 13:00:06]










http://www.can-cia.de/www.national.com/pf/CO/COP884BC.html




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

Check out our site at

www.infineon.com

Error

http://www.infineon.com/redirection/error_404b.htm [14.11.1999 13:00:53]

http://www.infineon.com/

Application NotesDatasheetsArchitecture OverviewSpecification Update

Development ToolsPrice Quote & OrderingProduct Selector

CommercialFlash MemoryCommercialMicrocontrollers

Controller Area Network Application NotesAP-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

* Legal Information © 1999 Intel Corporation

Controller Area Network Application Notes

http://developer.intel.com/design/auto/can/applnots/INDEX.HTM [14.11.1999 13:02:32]

http://developer.intel.com/

http://developer.intel.com/sites/developer/contents.htm?iid=devheader+contents&

http://developer.intel.com/sites/developer/search.htm?iid=devheader+search&

http://developer.intel.com/design/sitehelp/index.htm?iid=devheader+contact&

http://support.intel.com/sites/support/index.htm?iid=devheader+support&

http://www.intel.com/index.htm?iid=devheader+corp&/

http://developer.intel.com/design/resources/index.htm?iid=devheader+resources&

http://developer.intel.com/design/idf/index.htm?iid=devheader+idf&

http://developer.intel.com/update/index.htm?iid=devheader+update&

http://developer.intel.com/design/product.htm

http://developer.intel.com/platforms/

http://developer.intel.com/software/

http://developer.intel.com/technology/

http://developer.intel.com/design/auto/can/applnots/

http://developer.intel.com/design/auto/can/datashts/272250.htm

http://developer.intel.com/design/auto/can/archover/272410.htm

http://developer.intel.com/design/auto/can/specupdt/272876.htm

http://amber.intel.com/scripts-toolcat/arch.asp?architecture=5

http://developer.intel.com/design/disti/

http://apps.intel.com/product_selector/index.asp

http://developer.intel.com/design/flash/

http://developer.intel.com/design/flash/

http://developer.intel.com/design/embcontrol/

http://developer.intel.com/design/embcontrol/

http://developer.intel.com/design/auto/can/applnots/272762.htm




http://developer.intel.com/sites/developer/tradmarx.htm

AN464: Software Driver Routines for the MotorolaMC68HC05 CAN Module

The Controller Area Network (CAN) protocol describes a serial communications protocol forinterrupt-driven, real-time control applications, primarily in the automotive sector. This note describesdriver routines which provide an interface between application software in the MCU ROM and the CANmodule. The routines allow for the initialisation of the module, the transmission of messages previouslystored in RAM, and the automatic handling of received messages. They have been written to run on theMC68HC05X4 but can easily be adapted to run on any M68HC05 MCU supporting the CAN protocol.

© Copyright 1994,1999 Motorola, Inc. All rights reserved.Please Read Our Copyright and Disclaimer Notice

Fri Jan 24 16:11:59 MST 1997

AN464

http://www.mot-sps.com/lit/html/an464.html [14.11.1999 13:05:58]

http://www.mot.com/

http://www.mot-sps.com/sps/General/chips.html

http://www.mot-sps.com/sps/General/sales.html

http://www.mot-sps.com/sps/General/applications.html

http://www.mot-sps.com/sps/General/news.html

http://www.mot-sps.com/sps/General/about.html

http://www.mot-sps.com/sps/General/index.html

http://www.mot-sps.com/mcu/documentation/pdf/an464.pdf



http://www.mot-sps.com/sps/General/feedback.html

http://www.mot-sps.com/sps/General/navigator.html

http://www.mot-sps.com/cgi-bin/search

http://www.mot-sps.com/sps/General/copyright.html


AN1798: CAN Bit Timing Requirements

Controller Area Network (CAN) is a serial, asynchronous multi-master communication protocol forconnecting electronic control modules in automotive and industrial applications. Paper examines therelationship and constraints between the bit timing parameters, the reference oscillator tolerance, and thevarious signla propagation delays in the system.

© Copyright 1994,1999 Motorola, Inc. All rights reserved.Please Read Our Copyright and Disclaimer Notice

AN1798

http://www.mot-sps.com/lit/html/an1798.html [14.11.1999 13:06:33]

http://www.mot.com/

http://www.mot-sps.com/sps/General/chips.html


http://www.mot-sps.com/sps/General/applications.html

http://www.mot-sps.com/sps/General/news.html

http://www.mot-sps.com/sps/General/about.html


http://www.mot-sps.com/books/apnotes/pdf/an1798rev0.pdf



http://www.mot-sps.com/sps/General/feedback.html

http://www.mot-sps.com/sps/General/navigator.html

http://www.mot-sps.com/cgi-bin/search



CAN products & systems

CAN news & events

About CAN

CAN support & tools

Sales contacts

Support & tools

• Sales Contacts• Application notes • AN457, 80C51 External Memory Interfacing • AN91014, Application of the P8xC592 microcontroller with CAN-interface • AN92002, Extended Frame Format - A New Option of the CAN Protocol • AN95092, How to Handle Data Overrun Conditions of the 82C200, 8xC592 and 8xCE598 • AN96116, PCA82C250/PCA82C251 CAN Transceiver • AN97046, Determination of Bit Timing Parameters for the CAN Controller SJA1000 • AN97076, SJA1000 Stand-alone CAN controller • Upgrading Note, 82C200 to SJA1000

Sales Contacts

Industrial applicationsAutomotive applications

Application notes

80C51 External Memory InterfacingThe 80C51 family is arguably the most popular 8-bit embedded controller line-upthanks to an efficient yet powerful architecture, multi-sourcing by the world's topsemiconductor companies and unprecedented third-party tool support. Thisapplication note looks in detail at the external memory interfacing for 80C51devices.

Download the full application note.

Application of the P8xC592 microcontroller with CAN-interfaceThe P8xC592 covers the complete CAN specification, offering importantfeatures such as multi-master serial communication capability with a high numberof participating network nodes, programmable data transmission rates up to 1Mbits/s and powerful error handling. This application note provides a simplecircuit example for a CAN module using the P8xC592. Flowcharts are includedwhich familiarize the reader with the software aspects of CAN communication. Apractical example shows that there is very little CPU load for the control of CANcommunication.

Download the full paper.

Extended Frame Format - A New Option of the CAN ProtocolIn addition to the CAN 'standard frame format', which is specified with an 11-bitidentifier, in 1991 Bosch introduced the CAN 'extended frame format', whichoperates with a 29-bit identifier. This paper contains a description and acomparison of both frame formats. Both have their own advantages: the extendedframe format provides more message types and a much higher number of unique

Philips Semiconductors - CAN Bus; Support and tools;

http://www-eu2.semiconductors.com/can/support/ (1 von 3) [14.11.1999 13:08:06]

http://www-eu2.semiconductors.com/search/

http://www-eu2.semiconductors.com/comments/

http://www.philips.com/

http://www.philips.com/

http://www-eu2.semiconductors.com/index.html

http://www-eu2.semiconductors.com/can/

http://www-eu2.semiconductors.com/can/products/

http://www-eu2.semiconductors.com/can/news/

http://www-eu2.semiconductors.com/can/aboutus/

http://www-eu2.semiconductors.com/can/support/salescontacts.html

http://www-eu2.semiconductors.com/can/support/salescontacts.html

http://www-eu2.semiconductors.com/can/support/salescontacts.html#industrialapps

http://www-eu2.semiconductors.com/can/support/salescontacts.html#industrialapps

http://www-eu2.semiconductors.com/can/support/salescontacts.html#automotiveapps

http://www-eu2.semiconductors.com/can/support/salescontacts.html#automotiveapps

http://www-eu2.semiconductors.com/microcontrol/

http://www-eu2.semiconductors.com/acrobat/applicationnotes/AN457.pdf


http://www-eu2.semiconductors.com/pip/P8xC592

http://www-eu2.semiconductors.com/pip/P8xC592

http://www-eu2.semiconductors.com/acrobat/applicationnotes/592.pdf

http://www-eu2.semiconductors.com/acrobat/applicationnotes/592.pdf

identifiers, while the standard frame format offers lower bus access times, higherbus throughput and greater commercial availability of products.

Download the full paper.

How to Handle Data Overrun Conditions of the 82C200, 8xC592 and8xCE598Data overrun conditions may occur in CAN bus systems, if received messagescannot be read fast enough from the receive buffer by a CPU. Normally thecontroller software for a CAN bus system should be designed so the receivebuffer is serviced without resulting in an overrun condition. This application notegives a recommendation on how to handle those rare occasions when a dataoverrun does occur.


PCA82C250/251 CAN TransceiverThe PCA82C250 and PCA82C251 are advanced transceivers foruse in automotive and general industrial applications, offering transfer rates up to1 Mbits/s. They support the differential bus signal representation described in theinternational standard for high-speed in-vehicle CAN applications (ISO 11898).This application note provides information on how to use the PCA82C250/251transceivers and discusses several topics of interest such as slope control mode,stand-by mode, bus length and maximum number of bus nodes per network.


Determination of Bit Timing Parameters for the CAN Controller SJA1000The CAN protocol provides for programming of the bit-rate, and the number andlocation of data samples in a bit period. Optimization of these parametersguarantees message synchronization and proper error detection at the extremesof oscillator tolerance and propagation delay. A step-by-step method forcalculating optimum CAN bit timing parameters for a given set of systemconstraints is presented. Support is given for adjustment of PhilipsSemiconductors' SJA1000 and PCx82C200 CAN controllers. Detailedexamples are also included.


SJA1000 Stand-alone CAN controllerWith the SJA1000, Philips Semiconductors provides a stand-alone CANcontroller which is more than a simple replacement of the PCA82C200. This CAN2.0B-compliant controller offers a number of additional features, implemented fora wide range of applications, supporting system optimization, diagnosis andmaintenance.


Upgrading Note - 82C200 to SJA1000The SJA1000 is the successor product for the PCx82C200 Stand-aloneCAN Controller. It is pin-compatible to the 82C200 design. As the SJA1000 is acompletely new design with a range of additional features including full CAN 2.0B,the following notes give a short overview of what hardware and softwaredesigners should consider when migrating from the 82C200 to the SJA1000 inexisting designs.

Download the full upgrading note.



http://www-eu2.semiconductors.com/acrobat/applicationnotes/EXTENDED.pdf

http://www-eu2.semiconductors.com/acrobat/applicationnotes/EXTENDED.pdf



http://www-eu2.semiconductors.com/pip/PCA82C250






http://www-eu2.semiconductors.com/pip/SJA1000










http://www-eu2.semiconductors.com/can/aboutus/#canbus2specs

http://www-eu2.semiconductors.com/acrobat/applicationnotes/UPGRADE11.pdf

http://www-eu2.semiconductors.com/acrobat/applicationnotes/UPGRADE11.pdf

Copyright © 1999Royal Philips ElectronicsAll rights reserved.Terms and conditions.



http://www-eu2.semiconductors.com/terms.html

Products News CAN Product Information

There is an enormous number of CAN products available. Ingeneral, CAN products can be classified in chip-level anddevice-level modules, software, and tools. CiA provides severalservices to find CAN products. CiA Members may entry theirproducts and services in the CiA PRODUCT DATABASE. Morespecific product information regarding embedded networking isavailable in CiA's EMBEDDED CAN DIRECTORY, and CANopenproducts are advertised in the CANopen PRODUCT GUIDE. Bothare available free of charge, and will be send on request (sendemail).CAN protocol controller chips are listed in the CAN DATA LINKLAYER SURVEY, and CAN transceiver chips are listed in the CANHIGH-SPEED TRANSCEIVER SURVEY.

Transport Layer in Silicon

Hamburg (Germany), October 1999. At the 6th iCC in Torino(Italy), Philips Semiconductors will officially announce theXA-3C 16-bit microcontroller with CAN module andmicro-coded transport layer for CANopen, DeviceNet, andOSEK/Com/NM. The hardware support of object segmentationand re-assembling will unburden the microcontroller fromprocessing of interrupts. The CAN data link layer moduleprovides the same features as the SJA1000 stand-alonecontroller.

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 isbased on the TouCAN implementation. FlexCAN provides upto 64 message buffers. This CAN module will be implementedon several microcontroller families from Motorola includingPowerPC and Mcore. It is intended to offer also two CANmodules on one chip.


More:

Product Data BaseCAN chipTransceiver chipCAN NewsletterDeviceNet Catalog

More:


CAN in Automation

http://www.can-cia.de/P.htm (1 von 4) [14.11.1999 13:08:20]




Stand-Alone CAN Controller re-designed

Munich (Germany), September 1999. Infineon has redesignedits SAB80C90/91 family of stand-alone CAN controllers. Allknown failures and problems are solved.

More information www.infineon.com/us/micro/can/content.html

8051-based Microcontroller featuring CAN

San Jose (USA), September 1999. At the Embedded SystemsConference in San Jose (California) Philips Semiconductorshas announced the P8xC591 microcontroller with an on-chipCAN module supporting Standard and Extended frameformats (2.0 B active). The CAN module is the very same as inthe SJA 1000 stand-alone CAN controller. It provides PeliCAN(Philips Extended Library CAN) functionality, includinglisten-only mode and self-test mode, error interrupts andarbitration lost capture. Enhanced PeliCAN features includefour independently configurable identifier filters (screeners)that each include a 32-bit match and a 32-bit mask. The four32-bit masks will allow designers to specify a unique groupaddress per screener. Other P8xC591 features include 16Kbyte of internal program memory that is expandableexternally to 64 Kbyte, three 16-bit timers/counters, and 32digital I/O port pins. The microcontroller also features a 10-bitA/D converter with 6 multiplexed analog inputs and a fast 8-bitconversion option, a 16-bit capture/compare unit, an 8-bitPulse Width Modulated (PWM) unit with two output channelsas well as an UART and I2C interface.

More informationwww-us.semiconductors.philips.com/can/products/

8051-based Microcontroller with two CAN Modules

San Jose (USA), September 1999. At the Embedded SystemsConference in San Jose (California) Dallas Semiconductorshas launched the DS80C390 dual CAN microcontrollerrunning at 40 MHz clock rates. The microcontroller canaddress up to 4 Mbyte of external data memory and up to 4Mbyte of external program memory. It comes in 64-pin LQFPor 68-pin PLCC packaging. Currently in full production, themicrocontroller with additional three timers/counters, serialport, and eight digital I/O ports is available at a cost of $ 7.40in quantities of 25,000. The chip has on-chip 4 Kbyte SRAM.

More:


CAN in Automation


http://www.infineon.com/us/micro/can/content.html

http://www-us.semiconductors.philips.com/can/products/



Both integrated CAN modules support data rates up to 1Mbit/s. Each CAN module has 15 message buffers, 14 areprogrammable in either transmit or receive mode. The last oneis a receive-only message buffer featuring capacity to storetwo 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 transceiverscompliant to ISO 11898 and several CAN fault-toleranttransceivers. In addition, a CAN single-wire transceiver will bereleased.


Single-wire CAN Transceiver

Sunnyvale (USA), September 1999. Philips Semiconductorsand Infineon have developed Single-wire CAN transceiverchips. The AU5790 from Philips supports data rates up to 30kbit/s. The transceiver provides sleep and wake-up functionsalong with a network active signal. In high-speed mode thetransceiver supports the bus signal levels as specified for theCAN_H output of the fault-tolerant CAN transceiver TJA 1053from Philips Semiconductors.

More informationwww-us.semiconductors.philips.com/can/products/

CAN Controller with Group Message Function

Duesseldorf (Germany), July 1999. The MSM9225 from OKI isstand-alone CAN controller, which is supporting 11-bit and29-bit identifier frames. The chip comes in a 44-pin plasticQFP package and is specified for a temperature range of -40to +115 °C. Each of the 16 implemented message buffers canindividually configured as transmit or receive buffer. If thegroup message function is used, a part of an identifier can bemasked. This can increase the number of receivableidentifiers. To use the group message function, set themessage number of the target message to set the groupmessage function at the GMR register. Then set the bits to bemasked at the GMSK register. Depending on the location of

CAN in Automation


http://www.dallas.com/



bits to be masked, another identifier being set at the messagememory may be received. In this case, the priority of identifiersbeing set on the message is calculated and the identifierhaving the highest priority is received. The received data iswritten to the message memory indicated by the message forwhich the identifier with the highest priority is set. The CANcontroller can support two message groups.

MIPS3000-based Processor for Telematik

Hamburg (Germany), July 1999. Philips Semiconductors hasintroduced the SAF3100 processor featuring MIPS3000-based32-bit core, 12-channel GPS base-band module, UARTmodem, 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 hasannounced the availability of its TMS320F241 andTMS320F243 digital signal processors with on-chip CANcontroller. Both DSPs are optimized for digital motor-controlapplications such as industrial drives and automotive. With theFlash-based versions (8 Kbyte), motor controller designerscan program quickly o Flash memory then transfer that codeto a more cost-effective ROM-based DSP for volumeproduction. The DSPs operate at 20 million instructions persecond (MIPS), and feature serial peripheral interface (SPI),A/D converter, and a CAN interface. The F241 comes in a68-pin plastic leaded chip carrier (PLCC) or a 64-pin plasticquad flatpack (PQFP). The F243 is packaged in a 144-pin thinquad flatpack (TQFP).

http://www.ti.com/sc/docs/products/dsp/tms320f241.htm

Further product information


CAN in Automation


http://www.ti.com/sc/docs/products/dsp/tms320f241.html

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-Optionsand HLP-Support-Options appear (HLP=Higher Layer Protocol).

2. Select at least one Product-Category-Option or HLP-Support-Option. To choose several options usethe “SHIFT-Key“.

3. Press the “Search Database button“ and you will receive a list of products matching with yourselection.

4. Leave the CiA Database by clicking the “Exit“ button.

Welcome to CAN in Automation e.V.

http://www.can-cia.de/pdb.htm [14.11.1999 13:08:26]

CAN Contoller Website (Data Sheet and Application Notes) Company CANVersion Microcontroller Object Storage

CapacityAcceptance Filtering

Capability Bridge Samples Volume Remarks

DS80C390 www.dalsemi.com Dallas2 x2.0B

8-bit14 Tx/Rx buffers + 1double Rx buffer

14 Tx/Rx buffers + 1double Rx buffer

possible now 1Q00

4kB SRAM, 256 x16 RAM, 40 MHzclock rate,16/32-bit mathcoprocessor

MB90548 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu1 x2.0B

16-bit(FFMC16LX)

16 Tx / Rx buffers16 full-bit masks + 2global masks

No 1Q00 2Q00

128KB MaskROM, 4K RAM,UARTx2, A/D,Ext Bus Interface,QFP100.


16-bit(FFMC16LX)


No n.a. now

256KB MaskROM, 6K RAM,UARTx3, A/D, 4Stepper MotorDrivers, QFP100.


16-bit(FFMC16LX)


No 1Q00 1Q00

128KB MaskROM, 4K RAM,UARTx2, A/D, 4Stepper MotorDrivers, QFP100.

MB90F497 www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu1 x2.0B

16-bit(FFMC16LX)

8 Tx/Rx buffers8 full-bit masks + 2global masks

No 4Q99 1Q0064K Flash, 2KRAM, UART,A/D, QFP64.


16-bit(FFMC16LX)


No n.a. now

128KB Flash, 6KRAM, UARTx2,A/D, Ext BusInterface,QFP100.


16-bit(FFMC16LX)


No 1Q00 2Q00



16-bit(FFMC16LX)


No 4Q99 1Q00



16-bit(FFMC16LX)


No now now

384KB Flash 8KRAM, UARTx3,A/D, 4 StepperMotor Drivers,QFP100.

MB90F594A www.fujitsu-fme.com/index4.html?/products/micro/can/start.html Fujitsu2 x2.0B

16-bit(FFMC16LX)


No n.a. now

256KB Flash 6KRAM, UARTx3,A/D, 4 StepperMotor Drivers,QFP100.


16-bit(FFMC16LX)


No n.a. now

128KB Flash, 4KRAM, UARTx2,A/D, 4 StepperMotor Drivers,QFP100.

CAN Contoller

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

http://www.dalsemi.com/

http://www.fujitsu-fme.com/index4.html?/products/micro/can/start.html











32-bit (FR) 16 Tx / Rx buffers16 full-bit masks + 2global masks

No now 4Q99

512KB Flash,16K RAM,UARTx3, A/D, 4Stepper MotorDrivers, 64MHz,LQFP208

H8/300H semiconductor.hitachi.com/h8/?adjump=frontpage_products-section Hitachi 2.0B 16-bit15 Tx/Rx buffers + 1Rx buffer

15 full-bit masks + 1global mask

no n.a. n.a. ASIC solution

H8S/2623 semiconductor.hitachi.com/h8/?adjump=frontpage_products-section Hitachi 2.0B 16-bit30 Tx/Rx buffers + 2Rx buffers

30 full-bit masks + 2global masks

no n.a. n.a.

currentlydedicatedautomotivecustomers only(open marketsupport 3Q99

SH7055 semiconductor.hitachi.com/superh/?adjump=frontpage_products-section Hitachi 2.0B 32-bit30 Tx/Rx buffers + 2Rx buffers


no n.a. n.a.

SuperH semiconductor.hitachi.com/superh/?adjump=frontpage_products-section Hitachi 2.0B 32-bit15 Tx/Rx buffers + 1Rx buffer


no n.a. n.a. ASIC solution

C161CI www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer


no now now

256k flash, 10kRAM, I2C, 2 xASC, 2 x SSC,RTC

C164CI www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer


no now now64k OTP, 6 xPWM, RTC

C167CR www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer


no now nowROMless-, 32k or128k ROM-, flash

C167CS www.infineon.com/us/micro/can/content.html Infineon 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer


no now now

128k flash, 4kX-flash, 11kRAM, 24 analoginputs

C505C/CA www.infineon.com/us/micro/can/content.html Infineon 2.0B 8-bit14 Tx/Rx buffers + 1double Rx buffer


no now now32k OTP, ROMless, 16k or 32kROM, 4 x PWM

C515C www.infineon.com/us/micro/can/content.html Infineon 2.0B 8-bit14 Tx/Rx buffers + 1double Rx buffer


no now now64k OTP, 4 xPWM

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

IniCAN www.inicore.com Inicore 2.0B 8-bit or DSP implemenation-specific implemention-specific possible n.a. n.a.

technologyindependendfunctions for chipintegrations

AN82527 developer.intel.com/design/auto/network.htm Intel 2.0B none14 Tx/Rx buffers + 1double Rx buffer


no now now

AN87C196CA developer.intel.com/design/auto/network.htm Intel 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer


no now now

AN87C196CB developer.intel.com/design/auto/network.htm Intel 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer


no now now

AS82527 developer.intel.com/design/auto/network.htm Intel 2.0B none14 Tx/Rx buffers + 1double Rx buffer


no now now

AS87C196CB developer.intel.com/design/auto/network.htm Intel 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer


no now now

MCP2510 www.microchip.com Microchip 2.0B none3 Tx buffers + 2 Rxbuffers


no n.a. n.a.SPI Interface,PDIP/SOIC18,TSSOP20

CCU3010E www.intermetall.de/docu.html MicronasIntermetall

2.0B 8-bit flash 16 Tx/Rx buffers16 full-bit masks + 1global mask

no nowonrequest

32k Flash, 16time-stamps

CAN Contoller



http://semiconductor.hitachi.com/h8/?adjump=frontpage_products-section

http://semiconductor.hitachi.com/h8/?adjump=frontpage_products-section

http://semiconductor.hitachi.com/superh/?adjump=frontpage_products-section

http://semiconductor.hitachi.com/superh/?adjump=frontpage_products-section








http://www.inicore.com/

http://developer.intel.com/design/auto/network.htm





http://www.microchip.com/

http://www.intermetall.de/docu.html

CDC-1 www.intermetall.de/docu.html MicronasIntermetall

3 x2.0B

16-bit flash 16 Tx/Rx buffers16 full-bit masks + 1global mask

yes nowonrequest

3 indepemdemtCAN-Modules,256k Flash, 16time-stamps

M306NOMCT-xxxFP www.mitsubishichips.com Mitsubishi2 x2.0B

16-bit 16 Tx/Rx buffers16 full-bit masks + 3global masks

yes now now

2 independenton-chip CANmodules, 3 phasemotor controllers

M37630M4-xxxFP www.mitsubishichips.com Mitsubishi 2.0B 8-bit1 Tx buffer + 2 Rxbuffers

1 full-bit mask + 1global mask

no now now

M37632MF-xxxFP www.mitsubishichips.com Mitsubishi 2.0B 8-bit1 Tx buffer + 2 Rxbuffers

1 full-bit mask + 1global mask

no now now

68HC(7)05X32 www.mot.sps.com/csic/techdata/appnote Motorola 2.0A 8-bit1 Tx buffer + 2 Rxbuffers

1 global 8-bit mask no now now64-pin packaging(32 KROM)

68HC(7)05X4 www.mot.sps.com/csic/techdata/appnote Motorola 2.0A 8-bit1 Tx buffer + 2 Rxbuffers

1 global 8-bit mask no now now28-pin packaging(4K ROM)

68HC(9)08AZ60 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 8-bit3 Tx buffers + 2 Rxbuffers

1 global 32-bit or 2global 16-bit or 4global 8-bit masks

no now now64-pin packaging(60K flash)

68HC05X16 www.mot.sps.com/csic/techdata/appnote Motorola 2.0A 8-bit1 Tx buffer + 2 Rxbuffers

1 global 8-bit mask no now now64-pin packaging(16K ROM)

68HC08AZ0 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 8-bit3 Tx buffers + 2 Rxbuffers


no now now100-pin packaging(ROM less)



no n.a. now64-pin packaging(16K ROM)







68HC912BC32 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 16-bit3 Tx buffers + 2 Rxbuffers



68HC912D60 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 16-bit3 Tx buffers + 2 Rxbuffers



68HC912DG128 www.mot.sps.com/csic/techdata/appnote Motorola2 x2.0B

16-bit3 Tx buffers + 2 Rxbuffers


yes now now

2 independenton-chip CANmodules, 112-pinpackaging (128Kflash)

MC68376 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 32-bit 16 Tx/Rx buffers16 full-bit masks + 3global masks

no now nowtime-stamp, flashmemory

MC68F396 www.mot.sps.com/csic/techdata/appnote Motorola 2.0B 32-bit 16 Tx/Rx buffers16 full-bit masks + 3global masks

no now nowtime-stamp, flashmemory

MPC555 www.mot.sps.com/csic/techdata/appnote Motorola2 x2.0B

32-bit 16 Tx/Rx buffers16 full-bit masks + 3global masks

yes now 4Q99

2 independenton-chip CANmodules,time-stamp, flashmemory

COP684BC www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit1 Tx 2-byte buffer + 2Rx 2-byte buffers

1 global 8-bit mask no now now8-byte frames canbe handles up to125 kbit/s

CAN Contoller


http://www.intermetall.de/docu.html

http://www.mitsubishichips.com/



http://www.mot.sps.com/csic/techdata/appnote














http://www.national.com/appinfo/mcu/0,1755,48,00.html

COP688/89EB www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit1 Tx 2-byte buffer + 2Rx 2-byte buffers


COP87/L88/89EB www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit1 Tx 2-byte buffer + 2Rx 2-byte buffers


COP87L84BC www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit1 Tx 2-byte buffer + 2Rx 2-byte buffers


COP888/89EB www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit1 Tx 2-byte buffer + 2Rx 2-byte buffers


COP8884BC www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0Bp 8-bit1 Tx 2-byte buffer + 2Rx 2-byte buffers


CR16MCS9 www.national.com/appinfo/mcu/0,1755,48,00.html NatSem 2.0B 16-bit15 Tx/Rx buffers + 1Rx buffer


no now now flash memory

ATOMIC - D703121 www.nec.de NEC2 x2.0B

32-bit RISC 32 Tx/Rx buffers32 full-bit masks + 3‘429-bit masks

possible 4Q00 1Q01

128k Flash,QFP144, LCD,CAN TimeSystem, 2x FCAN

ATOMIC - D703123 www.nec.de NEC3 x2.0B

32-bit RISC 64 Tx/Rx buffers64 full-bit masks + 3‘429-bit masks

possible 1Q00 3Q00


ATOMIC µPD70F3123

www.nec.de NEC3 x2.0B

32-bit RISCFlash

64 Tx/Rx buffers64 full-bit masks + 3‘429-bit masks

possible 4Q99 3Q00


µPD 780814/6 www.nec.de NEC 2.0B 8-bit2 Tx buffers + 16 Rxbuffers

16 full-bit masks + 2global 29-bit masks

no 1Q00 4Q0032/48k, QFP64,EEPROM, CANTime System

µPD 780824/6 www.nec.de NEC 2.0B 8-bit2 Tx buffers + 16 Rxbuffers


no now 1Q00

32/48k, QFP80,LCD, EEPROM,Stepper motordriver, CAN TimeSystem

µPD 780948 www.nec.de NEC 2.0B 8-bit2 Tx buffers + 16 Rxbuffers


no now now60k, QFP100,LCD, CAN TimeSystem



no now 2Q00D780948 +EEPROM



no 1Q00 4Q0016k, SSOP30,CAN TimeSystem

µPD 78F0818 www.nec.de NEC 2.0B 8-bit Flash2 Tx buffers + 16 Rxbuffers


no now 3Q00D78081X with60k Flash



no now 2Q00D78082X with60k Flash



no now now

60k Flash,QFP100, LCD,CAN TimeSystem



no now 2Q00D78F0948 +EEPROM



no 1Q00 4Q0016k Flash,SSOP30, CANTime System

CAN Contoller








http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

http://www.nec.de/

MSM9225 www.oki-europe.de OKI Electric 2.0B none 16 Tx/Rx buffers 16 full-bit masks no now now

P82C150 www-us.semiconductors.philips.com/can/products/ Philips 2.0Bp SLIO n.a. n. a. no now nowin maintenancestate, not for newdesing-ins

P8XC591 www-us.semiconductors.philips.com/can/products/ Philips 2.0B 8-bit1 Tx buffer + 64 RxFIFO

1 global 32-bit mask or2 global 16-bit masks

no now 1Q00

P8XC592/8 www-us.semiconductors.philips.com/can/products/ Philips 2.0A 8-bit1 Tx buffer + 2 Rxbuffers

1 global 8-bit mask no now now

P8XC59X www-us.semiconductors.philips.com/can/products/ Philips 2.0B 8-bit to be defined to be defined no 2Q00 3Q00will replaceP8x592/8

SJA1000 www-us.semiconductors.philips.com/can/products/ Philips 2.0B none1 Tx buffer + 64 RxFIFO

1 global 32-bit mask or2 global 16-bit masks

no now now replaces 82C200

XA-C3 www-us.semiconductors.philips.com/can/products/ Philips 2.0B 16-bit 32 Tx/Rx buffers32 full-bit masks +global masks

no 4Q99 1Q00

CANopen,DeviceNet andOSEK transportlayer hardwired

CAN Core www.sican.com Sican 2.0B optional implementation-specific implementation-specific possible now now

CAN Core,VHDL- andVerilog Model forASIC and FPGA

L9942/ST6 www.st.com/stonline/books/index.html ST-Microelectronics 2.0A 8-bit1 Tx buffer + 1 Rxbuffer

1 global 11-bit mask no now 4Q99

40VSuperSmartPower,OTP, ROMversions (2Q00)

ST10F1167 www.st.com/stonline/books/index.html ST-Microelectronics 2.0B 16-bit14 Tx/Rx buffers + 1double Rx buffer

14 Tx/Rx buffers + 1double Rx buffer

no now now128 kbyte flash,32k or ROMless

ST72511R4 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no nownow(ROM1Q00)

16k, TQFP64


32k, TQFP64


48k, TQFP64


60k, TQFP64

ST72532J4 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no 1Q002Q00(ROM3Q00)

16k, 256EE,TQFP44

ST72532K4 www.st.com/stonline/books/index.html ST-Microelectronics 2.0Bp 8-bit 3 Tx/Rx buffers 2 global 11-bit masks no 1Q002Q00(ROM3Q00)

16k, 256EE, SO34


16k, 256EE,TQFP64

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

40VSuperSmartPower,OTP, ROMversions (2Q00)

TMS320C241 www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm Texas Instruments 2.0B 16-bit DSP 6 Tx/Rx buffers2 full-bit masks + 1global mask

nonotplanned

now

8k x 16 flash, 544x 16 RAM, 10-bitA/D, 8 x PWM,QEP, SCI, SPI

CAN Contoller


http://www.oki-europe.de/

http://www-us.semiconductors.philips.com/can/products






http://www.sican.com/

http://www.st.com/stonline/books/index.html










http://www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm

TMS320F241 www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm Texas Instruments 2.0B 16-bit DSP 6 Tx/Rx buffers2 full-bit masks + 1global mask

no now now


TMS320F243 www.ti.com/sc/docs/dsps/hotline/wizard2xx.htm Texas Instruments 2.0B 16-bit DSP 6 Tx/Rx buffers2 full-bit masks + 1global mask

no now now


TC190C580 doc.semicon.toshiba.co.jp Toshiba 2.0B none15 Tx/Rx buffers + 1Rx buffer


no now now

TMP95CS54F doc.semicon.toshiba.co.jp Toshiba 2.0B 16-bit15 Tx/Rx buffers + 1Rx buffer


no now now 64k ROM

TMP95PS54F doc.semicon.toshiba.co.jp Toshiba 2.0B 16-bit15 Tx/Rx buffers + 1Rx buffer


no now now 48k OTP

CAN Contoller




http://doc.semicon.toshiba.co.jp/



CAN High-speed transceiver (ISO 11898-2)

Manufacturer Bosch Mietec PhilipsSemiconductors

PhilipsSemiconductors

SGS-Thomson Temic(Siliconix)

Unitrode

type no. CF150B MTC-3054 82C250 82C251 L9615 Si9200EY UC5350

data ratemax. [Mbd]

0.5 1 1 1 0.5 1 1

short circuit[V]

-5...+36 -3...+65 -8...+18 -36...+36 -5...+36 GND...+16 -8...+36

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

thermalshutdown

(1,2) n.a. yes yes (1, 2) yes yes

slopecontrol

on/off variable variable variable on/off none variable

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)

supplycurrent[mA]

<80 110 <70 <80 <80 70 70

stand-bycurrent [µA]

n.a. 300 <170 <275 n.a. n.a. 1000

packaging SOIC-8 SOP-16 SO-8, DIP-8 SO-8, DIP-8 SO-8 SO-8 SOIC-8,DIL-8



CAN in Automation

http://www.can-cia.de/pth.htm [14.11.1999 13:09:14]

The users and manufacturers group CiACiA membership benefits

Information Free of Charge●

Participation in Marketing Activities●

Influence on Specifications●

Credit on CiA Events●

Credit on CiA Publications●

Entries in CiA Product Data Base Free of Charge●

Credits for CiA members on:International CAN Conference Proceedings●

Higher Layer Protocol Specifications supported by CAN inAutomation

●

Entries in CiA Directories●

Participation fees in CiA National Forums and In-houseSeminars

●

Participation fees in CiA International Workshops●

Participation fees in the international CAN Conference●

Joint marketing activities

CiA is organizing several joint marketing activities, such asJoint Standse. g. at Hanover Fair Industry (Germany) more than 500 sqm,at Embedded Systems, Nürnberg (Germany) 80 sqm, atSPS/IPC/Drives, Nürnberg (Germany) about 190 sqm, atelectronica, Munich (Germany), BiAS, Milan (Italy) and others.

●

Product Guidese. g. Internet data base, Product Guides to related applicationfields

●

AdvertisementsAdvertisements in magazines and special editions

●

SeminarsCiA members seize this opportunity to establish contacts bysupporting papers.

●

International CAN ConferenceThe table-Top exhibition accompanying this most importantevent is another occasion to reach a great number ofprospective customers.

●

Table-Top Exhibitions●

More:

EventsCiA rulesCiA operationstructureCiA members list

Page contents:TopMembership benefitsCredits for CiA membersJoint marketing activitiesCiA marketing activities

More:



CAN in Automation

http://www.can-cia.de/A.htm (1 von 2) [14.11.1999 13:10:02]


http://www.can-cia.de/AM.htm



Table-Top exhibitions are also organized at fairs andseminars.

CiA marketing activitiesInformation Free of Charge (brochures)●

Sell of CAN Literature and Specifications●

National CAN Forums●

International CAN Workshops●

CiA Stands at International Fairs (e.g. Embedded SystemsShow and Conference/USA, National ManufacturingWeek/USA, Automation/France, and others)

●

In-house seminars

CiA offers In-house Seminars for intensive training on CANtechnology. Interested companies have to come up for thetravel expenses of the trainer and pay a moderate honorar.

iCC - international CAN Conference

Once a year CiA is organizing the international CANConferences, during which international experts speak aboutnewest CAN technologies and practical experiences on CANnetworks. The conference is accompanied by a (table-Top)exhibition and attracts more than 200 participants every year.In the last years the iCC took place at Mainz, London, Paris,Berlin and San José, CA (USA). The found international CANConference found increasing interest from year to year. In1999 it will be held in the Lingotto Conference Center, Turin(Italy).

Technical support

StandardizationConformance TestingRecommendations


More:



More:



CAN in Automation

http://www.can-cia.de/A.htm (2 von 2) [14.11.1999 13:10:02]

http://www.can-cia.de/AIH.htm





CiArules

0. General

(1) The association is named "CAN in AUTOMATION -International Users and Manufacturers Group" and isregistered in Erlangen (Germany). CiA Headquarters (HQ) arelocated in Erlangen. Other offices may be established by theCiA Board of Directors.(2) The official language is the English language. All minutes,internal papers and CiA documents have to be written inEnglish (except the book-keeping for the German RevenueOffice).

1. CiA associated members (AM)

(1) Only students may be CiA Ams. CiA Ams may participatein CiA General Assemblies without voting rights and willreceive minutes of CiA General Assemblies, proposals to theCiA General Assemblies and all official CiA Standards, CiADraft Standards, CiA Draft Standard Proposals and CiARecommendations.(2) CiA Ams may not run for election of CiA Boards ofDirectors or of CiA Technical Committee or CiA BusinessCommittee.

2. CiA full class members (FCM)

(1) Cia Full Class Members may be individuals, companies ornon-profit organizations. CiA Full Class Members have thesame rights as CiA Associated Members, but in addition theymay vote in CiA General Assemblies and may run for electionof CiA Board of Directors or CiA Technical Committee or CiABusiness Committee. CiA Full Class Members will receive allminutes of CiA Business Committee (BC), CiA TechnicalCommittee (TC), CiA Interest Groups (IG), CiA Special InterestGroups (SIG) and CiA Marketing Groups (MG).

3. CiA general assembly (GA)

(1) The regular CiA GA takes place annually, but an irregularCiA GA can be conveened by either the CiA BoD or by themutual consent of one quarter of CiA FCMs.(2) All CiA FCMs may speak on each agenda topic of the CiA

More:

CiA

More:

CiA

CAN in Automation

http://www.can-cia.de/ar.htm (1 von 4) [14.11.1999 13:10:09]

http://www.can-cia.de/intern/MGAI.htm



GA. The chairman of the CiA GA may limit the time allowed forthe 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 inevery CiA meeting.(2) The CiA Technical Director chairs the CiA TechnicalCommittee.(3) The CiA Business Director chairs the CiA BusinessCommittee.(4) The CiA Managing Director manages CiA Headquarters,CiA Offices and CiA Secretaries.

5. CiA technical committee (TC)

(1) The CiA TC consists ofThe CiA Technical DirectorA representative of each CiA Interest GroupUp 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 InterestGroups.

6. CiA business committee (BC)

(1) The CiA BC consists ofThe CiA Business DirectorA representative of each CiA Marketing GroupUp 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 ofthe CiA and proposes the CiA budget to the CiA GA.(4) The CiA BC installs CiA Marketing Groups and coordinatestheir 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 beannounced to all CiA FCMs including the proposed scope ofwork.(3) During those meetings the following must happen:A workplan including goals has to be draft in accordance with

More:

CiA

CAN in Automation


http://www.can-cia.de/intern/MMBI.htm


the "CiA guidelines for IG" and submitted to the CiA TC forapproval.(4) After approval by the CiA TC the IG has to elect achairman.(5) CiA IGs may install CiA Special Interest Groups (SIG). TheCiA SIG will be represented in the CiA IG by a representative.

8. CiA standards

(1) CiA Standards proposed as CiA Draft Standards (DS) by aCiA IG are rejected, if more than one-third of the CiA FCMsvotes against. This CiA DSs have to be distributed to all CiAFCMs at least 3 months before balloting deadline. In theballoting form is space to be reserved for comments. Ballotingfor 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 inaccordance to the "CiA guidelines for IG".

10. CiA draft standard proposal (DSP)

(1) CiA DSP proposed as CiA Work Draft Proposals (WDP) byone or more CiA members shall be accepted by the CiA IG orSIG.(2) CiA WDPs may only be published for CiA internal purposesor after acceptance by the IG with the remark, that thisdocument is not valid for implementation.

11. CiA recommendations

(1) CiA Recommendations proposed by a CiA IG or membersof the CiA TC shall be accepted by the CiA TC with thefollowing voting rules: a) At least 50 % of the entitled to voteTC members must be present at the meeting,b) Accepted with a two-third majority, not containing abstainedvotes.(2) CiA Recommendations may be published only afteracceptance 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 iselected by the MG members.

More:

CiA

More:

CiA

CAN in Automation


http://www.can-cia.de/LS.htm

http://www.can-cia.de/intern/MMG.htm



(3) CiA MGs are related to national or regional markets or toapplication-specific or to higher layer protocols.

13. CiA secretaries

(1) CiA Secretaries are engaged and noticed by the CiA Boardof Directors.(2) CiA General Secretary operates CiA Headquarters andreports directly to the CiA Managing Director, CiA BC and CiATC.(2) CiA Technical and Assistance Secretaries report to the CiAGeneral Secretary.

14. Amendments

(1) Ammendments of CiA Rules have to be approved bytwo-third majority of the present CiA FCMs in the CiA GA.

17 April 1997


CAN in Automation


Site contents mapCiA EventsCiA Rules MeetingsCiA OperationStructures

Deadlines

CiA Members List iCC ProgrammCiA MembershipApplication

Exhibitions and Fairs

CiA Inhouse-Seminars Training + EducationCAN Information inDutch

CiA CANschool

Literature Members onlysection

Order FormBibliography (Books,Proceedings, Links...)CiA Standards NewsCiA Standards CAN Press ReleasesCiA Standards CAL CiA NewsCiA StandardsCANopen

Newsletter

CiA Standards Misc Rate Card

Products CAN ProtocolProduct data base General ApplicationChip survey Technical IntroductionHigh-speed Conformance TestLow-speed FAQs

Higher LayerProtocols

CANopen DeviceNetTechnical Introduction Technical IntroductionConformance Test Conformance Test

Page contents:topCiAEventsLiteratureMembers onlyNewsProductsCAN ProtocolHigher Layer ProtocolsCANopen ProtocolsDeviceNetCAN Application LayerCAN KingdomStandardization


CAN in Automation

http://www.can-cia.de/map.htm (1 von 2) [14.11.1999 13:10:59]

http://www.can-cia.de/EM.htm


http://www.can-cia.de/AMA.htm

http://www.can-cia.de/AMA.htm


http://www.can-cia.de/ETE.htm



http://www.can-cia.de/ACS.htm



http://www.can-cia.de/LS.htm



http://www.can-cia.de/nc.htm

http://www.can-cia.de/nna.htm

http://www.can-cia.de/p.htm

Certified CompaniesFAQs & design hintsFAQsVendor list

CAN ApplicationLayer

CAN Kingdom

Technical introduction Technical Introduction

Standardization



CAN in Automation

http://www.can-cia.de/map.htm (2 von 2) [14.11.1999 13:10:59]






http://www.can-cia.de/hat.htm

http://www.can-cia.de/hkt.htm


CiA Operationstructure CiAGeneral Assembly

Board of Directors:Business Director - Managing Director - Technical Director

Business Committee

Headquarters

Technical Committee

Marketing Groups(MG)

Interest Groups (IG):IG Hydraulics

IG Application LayerIG CANopen

MG BeneluxMG ScandinaviaMG FranceMG SwitzerlandMG CANopenMG Device Net

CANopen Special Interest Groups (SIG):

SIG Programmable CANopen DevicesSIG Safety

SIG Generic I/O ModulesSIG Drives and Motion Control

SIG Human Machine InterfacesSIG Measuring Devices and Closed Loop

ControllersSIG IEC 1131 Programmable Devices

SIG EncodersSIG Public Transportation

SIG HydraulicsSIG Maritime Electronics

SIG MedicalSIG Railways


More:

CiACiA rulesCiA members list

CAN in Automation

http://www.can-cia.de/ao.htm [14.11.1999 13:11:09]



Events MarketingCAN in Automation is organizing several events each year.These are not only Seminars, Workshops and Exhibitions, butalso the most important international CAN Conference.

6th international CAN Conference:

The international CAN Conference is CiA’s most importantevent every year. Experts from all over the world speak aboutnewest CAN technologies and practical experiences on CANnetworks. It is accompanied by a table-top exhibition,workshops, seminars, etc.

Training and education:

Besides seminars and workshops CiA is organizing the CANSchools (in Germany) and offers In-house Seminars at areasonable price.

Meetings:

Usually only CiA members may attend the meetings of theseveral technical and marketing groups. However studygroups and inaugural meetings invite guests some times.

Exhibitions and fairs:

CiA is organizing joint stands in European countries as well asthe USA. Moreover CiA is attending at important fairs andexhibitions all over the world with CiA information stands.

Deadlines:

This page reminds CiA members of their "to do"s.


More:

CiAMeetingsDeadlines6th iCC programmeExhibitions and fairsTraining andeducation

CAN in Automation

http://www.can-cia.de/E.htm [14.11.1999 13:11:17]










CiA deadlines EventsNovember 8very last deadline for registration CiA joint stand BIAS 2000,Milan (Italy)

October 29very last deadline for registration for table top exhibition 6thiCC at Turin (Italy)


More:CiAEventsMeetings6th iCC programmeExhibitions and fairsTraining and educationsl

CAN in Automation

http://www.can-cia.de/ED.htm [14.11.1999 13:11:20]




Fairs and exhibitions Events

November 2 - 46th international CAN Conference, Turin (Italy)Table-top exhibitionbeside the sponsoring companies the following companies orderedone, two or more tables:Applicom (1), Arteco (1), Automata (1), Beckhoff (1), Dearborn (1),EMS Dr. Thomas Wünsche (1), esd (2), Fujitsu (1), i+ME Actia (1),Ixxat Automation (2), Janz Computer (2), Kvaser (1), Lumberg (1),MEN (1), Microtask (1), NSI (1), port (1), Rockwell Automation (4),Softing (3), Special Electronic Design (1), Warwick ManufacturingGroup (1), Toshiba (1), Weidmüller (2).For more information and registration download

November 23 - 25SPS/IPC/Drives 99, Nürnberg (Germany)CiA stand

February 23 - 26, 2000IBias 2000, Milan (Italy)CiA joint stand - sub-exhibitors:Arteco, Berghof, Janz, Softing


More:CiAEventsDeadlinesMeetings6th iCC programmeTraining and educations

CAN in Automation

http://www.can-cia.de/EEF.htm [14.11.1999 13:11:25]

http://www.can-cia.de/tabtop99.pdf

http://www.can-cia.de/tabtop99.pdf

http://www.mesago.de/sps/index_e.html




Conformance test DeviceNetPage contents:

What is Conformance Testing?More informations about the DeviceNet conformance test

What is Conformance Testing?

ODVA has established Independent Test Labs to verify conformanceof DeviceNet products to the DeviceNet Specification. The first TestLab was established at the Electronic Manufacturing Laboratory(EML) of the University of Michigan (Ann Arbor, MI USA). Wenow have two more Test Labs, one at Warwick ManufacturingCenter at the University of Warwick in Coventry, England and theother at ASTEMRI (Advanced Software Technology andMechatronics Research Institute) in Kyoto, Japan.

These sites function to promote and verify interoperability andinterchangeability of DeviceNet products, thereby providing anincreased sense of security for users of these products. The testingsites make use of Conformance Testing Software developed by theConformance Special Interest Group (SIG) within ODVA;participants are encouraged to purchase the test software fromODVA so that they may pre-test their products prior to submittingthem to one or the testing sites for official testing. Detailed testresults will be returned to the participant for review. Test results willalso be forwarded to ODVA, and ODVA will publish a list ofproducts that have passed.

More informations about the DeviceNet conformance test

More:

General introductionTechnicalintroductionSpecificationsFAQs




CAN in Automation

http://www.can-cia.de/hdc.htm [14.11.1999 13:11:50]



Conformance Testing Directory

What is Conformance Testing?

About the Test

Conformance Test Policy

ODVA Independent Test Labs

About the Conformance Test Software

Order Forms

Listing of Products Tested By ODVA Independent Labs

DeviceNet Interoperability Problem Reports

Frequently Asked Questions About Conformance Testing

[ ODVA Home Page] .[ Send e-mail to ODVA] .

[ Ask Dr. DeviceNet a Technical Question] [ODVA Catalog Request Form ] . [ODVA Services Information]

© Copyright ODVA 1997-99Most recent revision Sunday, August 8, 1999

webmaster

ODVA - The Open DeviceNet's Vendor Association

http://www.controlnet.org/ODVA/CONFTEST/conform.htm [14.11.1999 13:12:05]

http://www.controlnet.org/ODVA/CONFTEST/confor1.htm

http://www.controlnet.org/ODVA/CONFTEST/abouttes.htm

http://www.controlnet.org/ODVA/CONFTEST/ODVA_Conf_Test_499.pdf





http://www.controlnet.org/ODVA/CONFTEST/inopprob.htm

http://www.controlnet.org/ODVA/CONFTEST/faqctest.htm

http://www.odva.org/index.html

http://www.controlnet.org/ODVA/ODVA-FORMS/dn-form-email.html

http://www.controlnet.org/ODVA/ODVA-FORMS/dn-form-drdn.html

http://www.controlnet.org/ODVA/ODVA-FORMS/dn-catreq_form.html

http://www.controlnet.org/ODVA/ODVA-FORMS/orders.html


CAN General introduction CANPage contents :

What's CANThe Attributes of CAN

What's CAN ?

The Controller Area Network (CAN) doesn't try to reachheaven like the Tower of Babel. CAN is a serial bus systemespecially suited for networking "intelligent" devices as well assensors and actuators within a system or sub-system.

The Attributes of CAN

CAN is a serial bus system with multi-master capabilities, thatis, all CAN nodes are able to transmit data and several CANnodes can request the bus simultaneously. The serial bussystem with real-time capabilities is the subject of the ISO11898 international standard and covers the lowest two layersof the ISO/OSI reference model. In CAN networks there is noaddressing of subscribers or stations in the conventionalsense, but instead, prioritized messages are transmitted. Atransmitter sends a message to all CAN nodes (broadcasting).Each node decides on the basis of the identifier receivedwhether it should process the message or not. The identifieralso determines the priority that the message enjoys incompetition for bus access.

The relative simplicity of the CAN protocol means that verylittle cost and effort need to expended on personal training; theCAN chips interfaces make applications programmingrelatively simple. Introductory courses, function libraries,starter kits, host interfaces, I/O modules and tools areavailable from a variety of vendors permitting low-costimplementation of CAN networks.

Low-cost controller chips implementing the CAN data link layerprotocol in silicon and permitting simple connection tomicrocontrollers have been available since 1989. Today thereare more than about 50 CAN protocol controller chips frommore than 15 manufacturers announced and available.

The use of CAN in most of European passenger cars and thedecision by truck and off-road vehicle manufacturers for CANguarantees the availability of CAN chips for more than 10

More:

Technical introductionApplicationsSpecificationsConformance testFAQ's

ChipsHigh-speed tranceiver

Presentations:

Physical LayerData Link LayerImplementationsApplications

Page contents:TopWhats's CANThe Attributes of CAN

CAN in Automation

http://www.can-cia.de/cg.htm (1 von 2) [14.11.1999 13:12:37]










years. Other high volume markets, like domestic appliancesand industrial control, also increase the CAN sales figures. Upto spring 1999 there are more than 150 million CAN nodesinstalled.

One of the outstanding features of the CAN protocol is its hightransmission reliability. The CAN controller registers a stationserror and evaluates it statistically in order to take appropriatemeasures. These may extend to disconnecting the CAN nodeproducing the errors.

Each CAN message can transmit from 0 to 8 bytes of userinformation. Of course, you can transmit longer datainformation by using segmentation. The maximumtransmission rate is specified as 1 Mbit/s. This value applies tonetworks up to 40 m. For longer distances the data rate mustbe reduced: for distances up to 500 m a speed of 125 kbit/s ispossible, and for transmissions up to 1 km a data rate of 50kbit/s is permitted.

More:

Technical introductionApplicationsSpecificationsConformance testFAQ's


Presentations:


Page contents:TopWhats's CANThe Attributes of CAN



CAN in Automation

http://www.can-cia.de/cg.htm (2 von 2) [14.11.1999 13:12:37]










CAN Technical introduction CANPage contents:

How does it functionPrinciples of data exchangeNon-destructive bitwise arbitrationEfficiency of bus allocationMessage frame formatsDetecting and signalling errorsData reliability of the CAN protocol

Extended format CAN message

Implementations of the CAN protocol

OverviewCAN controller with intermediate bufferCAN controller with object storageCAN slave controllers for I/O functions

Physical CAN connection

How does it function

Principles of data exchange

When data are transmitted by CAN, no stations are addressed,but instead, the content of the message (e.g. rpm or enginetemperature) is designated by an identifier that is uniquethroughout the network. The identifier defines not only thecontent but also the priority of the message. This is importantfor bus allocation when several stations are competing for busaccess.

If the CPU of a given station wishes to send a message to oneor more stations, it passes the data to be transmitted and theiridentifiers to the assigned CAN chip ("Make ready"). This is allthe CPU has to do: To initiate data exchange. The message isconstructed and transmitted by the CAN chip. As soon as theCAN chip receives the bus allocation ("Send Message") allother stations on the CAN network become receivers of thismessage ("Receive Message"). Each station in the CANnetwork, having received the message correctly, performs anacceptance test to determine whether the data received arerelevant for that station ("Select"). If the data are of significance

More:

General introductionApplicationsSpecificationsConformance testFAQ's

page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller withintermediate buffer- CAN controller withobjectstorage- CAN slave controllersforI/O functionsPhysical CAN connection

CAN in Automation

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


for the station concerned they are processed ("Accept"),otherwise they are ignored.

A high degree of system and configuration flexibility is achievedas a result of the content-oriented addressing scheme. It is veryeasy to add stations to the existing CAN network withoutmaking any hardware or software modifications to the existingstations, provided that the new stations are purely receivers.Because the data transmission protocol does not requirephysical destination addresses for the individual components, itsupports the concept of modular electronics and also permitsmultiple reception (broadcast, multicast) and thesynchronization of distributed processes: measurementsneeded as information by several controllers can be transmittedvia the network, in such a way that it is unnecessary for eachcontroller to have its own sensor.

Broadcast transmission and acceptance filtering by CAN nodes

More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller withintermediate buffer- CAN controller withobjectstorage- CAN slave controllersforI/O functions

CAN in Automation



Principle of non-destructive bitwise arbitration

Non-destructive bitwise arbitration

For the data to be processed in real time they must betransmitted rapidly. This not only requires a physical datatransfer path with up to 1 Mbit/s but also calls for rapid busallocation when several stations wish to send messagessimultaneously.In real-time processing the urgency of messages to beexchanged over the network can differ greatly: a rapidlychanging dimension (e.g. engine load) has to be transmittedmore frequently and therefore with less delays than otherdimensions (e.g. engine temperature) which change relativelyslowly.

The priority at which a message is transmitted compared withanother less urgent message is specified by the identifier of themessage concerned. The priorities are laid down during systemdesign in the form of corresponding binary values and cannotbe changed dynamically. The identifier with the lowest binarynumber has the highest priority.

Bus access conflicts are resolved by bitwise arbitration on theidentifiers involved by each station observing the bus level bitfor bit. In accordance with the "wired and" mechanism, bywhich the dominant state (logical 0) overwrites the recessivestate (logical 1), the competition for bus allocation is lost by allthose stations with recessive transmission and dominantobservation. All "losers" automatically become receivers of themessage with the highest priority and do not re-attempttransmission until the bus is available again.

Efficiency of bus allocation

The efficiency of the bus allocation system is determinedmainly by the possible applications for a serial bus system. Inorder to judge as simply as possibly which bus systems aresuitable for which applications the literature includes a methodof classifying bus allocation procedures. Generally wedistinguish between the following classes:

Bus allocation on a fixed time schedule●

Allocation is made sequentially to each participant for amaximum duration regardless of whether this participantneeds the bus at this moment or not (examples: token


More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller withintermediate buffer- CAN controller withobjectstorage- CAN slave controllersfor

CAN in Automation



slot or token passing).Bus allocation on the basis of need●

The bus is allocated to one participant on the basis oftransmission requests outstanding, i.e. the allocationsystem only considers participants wishing to transmit(examples: CSMA, CSMA/CD, flying master, round robinor bitwise arbitration).

For CAN, bus allocation is negotiated purely among themessages waiting to be transmitted. This means that theprocedure specified by CAN is classified as allocation on thebasis of need.

Another means of assessing the efficiency of bus arbitrationsystems is the bus access method:

Non-destructive bus access●

With methods of this type the bus is allocated to one andonly one station either immediately or within a specifiedtime following a single bus access (by one or morestations). This ensures that each bus access by one ormore stations leads to an unambiguous bus allocation(examples: token slot, token passing, round robin, bitwisearbitration).Destructive bus allocation●

Simultaneous bus access by more than one stationcauses all transmission attempts to be aborted andtherefore there is no successful bus allocation. More thanone bus access may be necessary in order to allocate thebus at all, the number of attempts before bus allocation issuccessful being a purely statistical quantity (examples:CSMA/CD, Ethernet).

In order to process all transmission requests of a CAN networkwhile complying with latency constraints at as low a datatransfer rate as possible, the CAN protocol must implement abus allocation method that guarantees that there is alwaysunambiguous bus allocation even when there are simultaneousbus accesses from different stations. The method of bitwisearbitration using the identifier of the messages to betransmitted uniquely resolves any collision between a numberof stations wanting to transmit, and it does this at the latestwithin 13 (standard format) or 33 (extended format) bit periodsfor any bus access period. Unlike the message-wise arbitrationemployed by the CSMA/CD method this non-destructivemethod of conflict resolution ensures that no bus capacity isused without transmitting useful information.

I/O functionsPhysical CAN connection

More:

General introductionapplicationsSpecificationsConformance testFAQ's

Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageimplementations of theCAN protocol- overview- CAN controller withintermediate buffer- CAN controller withobjectstorage- CAN slave controllers

CAN in Automation



Even in situations where the bus is overloaded the linkage ofthe bus access priority to the content of the message proves tobe a beneficial system attribute compared with existingCSMA/CD or token protocols: In spite of the insufficient bustransport capacity, all outstanding transmission requests areprocessed in order of their importance to the overall system (asdetermined by the message priority). The availabletransmission capacity is utilized efficiently for the transmissionof useful data since "gaps" in bus allocation are kept verysmall. The collapse of the whole transmission system due tooverload, as can occur with the CSMA/CD protocol, is notpossible with CAN. Thus, CAN permits implementation of fast,traffic-dependent bus access which is non-destructive becauseof bitwise arbitration based on the message priority employed.

Non-destructive bus access can be further classified intocentralized bus access control●

decentralized bus access control●

depending on whether the control mechanisms are present inthe system only once (centralized) or more than once(decentralized). A communication system with a designatedstation (inter alia for centralized bus access control) mustprovide a strategy to take effect in the event of a failure of themaster station. This concept has the disadvantage that thestrategy for failure management is difficult and costly toimplement and also that the takeover of the central station by aredundant station can be very time-consuming. For thesereasons and to circumvent the problem of the reliability of themaster station (and thus of the whole communication system),the CAN protocol implements decentralized bus control. Allmajor communication mechanisms, including bus accesscontrol, are implemented several times in the system, becausethis is the only way to fulfill the high requirements for theavailability of the communication system.

In summary it can be said that CAN implements atraffic-dependent bus allocation system that permits, by meansof a non-destructive bus access with decentralized bus accesscontrol, a high useful data rate at the lowest possible bus datarate in terms of the bus busy rate for all stations. The efficiencyof the bus arbitration procedure is increased by the fact that thebus is utilized only by those stations with pending transmissionrequests.

These requests are handled in the order of the importance ofthe messages for the system as a whole. This provesespecially advantageous in overload situations. Since bus

forI/O functionsPhysical CAN connection

More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller withintermediate buffer- CAN controller withobject

CAN in Automation



access is prioritized on the basis of the messages, it is possibleto guarantee low individual latency times in real-time systems.

Message frame for standard format (CAN Specification 2.0A)

Message frame formats

The CAN protocol supports two message frame formats, theonly essential difference being in the length of the identifier(ID). In the standard format the length of the ID is 11 bits and inthe extended format the length is 29 bits. The message framefor transmitting messages on the bus comprises seven mainfields.

A message in the standard format begins with the start bit "startof frame", this is followed by the "arbitration field", whichcontains the identifier and the "RTR" (remote transmissionrequest) bit, which indicates whether it is a data frame or arequest frame without any data bytes (remote frame). The"control field" contains the IDE (identifier extension) bit, whichindicates either standard format or extended format, a bitreserved for future extensions and - in the last 4 bits - a countof the data bytes in the data field.

The "data field" ranges from 0 to 8 bytes in length and isfollowed by the "CRC field", which is used as a frame securitycheck for detecting bit errors. The "ACK field" comprises theACK slot (1 bit) and the ACK delimiter (1 recessive bit). The bitin the ACK slot is sent as a recessive bit and is overwritten as adominant bit by those receivers which have at this timereceived the data correctly (positive acknowledgement).Correct messages are acknowledged by the receiversregardless of the result of the acceptance test. The end of themessage is indicated by "end of frame". "Intermission" is theminimum number of bit periods separating consecutivemessages. If there is no following bus access by any station,the bus remains idle ("bus idle").

Detecting and signalling errors

Unlike other bus systems, the CAN protocol does not useacknowledgement messages but instead signals any errors

storage- CAN slave controllersforI/O functionsPhysical CAN connection

More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller withintermediate buffer- CAN controller with

CAN in Automation



that occur. For error detection the CAN protocol implementsthree mechanisms at the message level:

Cyclic Redundancy Check (CRC)●

The CRC safeguards the information in the frame byadding redundant check bits at the transmission end. Atthe receiver end these bits are re-computed and testedagainst the received bits. If they do not agree there hasbeen a CRC error.Frame check●

This mechanism verifies the structure of the transmittedframe by checking the bit fields against the fixed formatand the frame size. Errors detected by frame checks aredesignated "format errors".ACK errors●

As mentioned above, frames received are acknowledgedby all recipients through positive acknowledgement. If noacknowledgement is received by the transmitter of themessage (ACK error) this may mean that there is atransmission error which has been detected only by therecipients, that the ACK field has been corrupted or thatthere are no receivers.

The CAN protocol also implements two mechanisms for errordetection at the bit level:

Monitoring●

The ability of the transmitter to detect errors is based onthe monitoring of bus signals: each node which transmitsalso observes the bus level and thus detects differencesbetween the bit sent and the bit received. This permitsreliable detection of all global errors and errors local tothe transmitter.Bit stuffing●

The coding of the individual bits is tested at bit level. Thebit representation used by CAN is NRZ(non-return-to-zero) coding, which guarantees maximumefficiency in bit coding. The synchronization edges aregenerated by means of bit stuffing, i.e. after fiveconsecutive equal bits the sender inserts into the bitstream a stuff bit with the complementary value, which isremoved by the receivers. The code check is limited tochecking adherence to the stuffing rule.

If one or more errors are discovered by at least one station(any station) using the above mechanisms, the currenttransmission is aborted by sending an "error flag". This

objectstorage- CAN slave controllersforI/O functionsPhysical CAN connection

More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller withintermediate buffer

CAN in Automation



prevents other stations accepting the message and thusensures the consistency of data throughout the network.

After transmission of an erroneous message has been aborted,the sender automatically re-attempts transmission (automaticrepeat request). There may again be competition for busallocation. As a rule, retransmission will be begun within 23 bitperiods after error detection; in special cases the systemrecovery 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 bussystem if no measures for self-monitoring were taken. The CANprotocol therefore provides a mechanism for distinguishingsporadic errors from permanent errors and localizing stationfailures (fault confinement).

This is done by statistical assessment of station error situationswith the aim of recognizing a station's own defects and possiblyentering an operating mode where the rest of the CAN networkis not negatively affected. This may go as far as the stationswitching itself off to prevent messages erroneously recognizedas incorrect from being aborted.

Data reliability of the CAN protocol

The introduction of safety-related systems in automobilesbrought with it high requirements for the reliability of datatransmission. The objective is frequently formulated as notpermitting any dangerous situations for the driver to occur as aresult of data exchange throughout the whole life of a vehicle.

This goal is achieved if the reliability of the data is sufficientlyhigh or the residual error probability is sufficiently low. In thecontext of bus systems data, reliability is understood as thecapability to identify data corrupted by transmission faults. Theresidual error probability is a statistical measure of theimpairment of data reliability: It specifies the probability thatdata will be corrupted and that this corruption will remainundetected. The residual error probability should be so smallthat on average no corrupted data will go undetectedthroughout the whole life of a system.

- CAN controller withobjectstorage- CAN slave controllersforI/O functionsPhysical CAN connection

More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller with

CAN in Automation



Residual error probability as a function of bit error probability

Calculation of the residual error probability requires that theerrors which occur be classified and that the wholetransmission path be described by a model. If we determine theresidual error probability of CAN as a function of the bit errorprobability for message lengths of 80 to 90 bits, for systemconfigurations of, for instance, five or ten nodes and with anerror rate of 1/1000 (an error in one message in everythousand), then maximum bit error probability is approximately0.02 - in the order of 10-13. Based on this it is possible tocalculate the maximum number of undetectable errors for agiven CAN network.

For example, if a CAN network operates at a data rate of 1Mbit/s, at an average bus capacity utilization of 50 percent, fora total operating life of 4000 hours and with an averagemessage length of 80 bits, then the total number of messagestransmitted is 9 x 1010. The statistical number of undetectedtransmission errors during the operating life is thus in the orderof less than 10-2. Or to put it another way, with an operatingtime of eight hours per day on 365 days per year and an errorrate of 0.7 s, one undetected error occurs every thousandyears (statistical average).

Extended format CAN message

The SAE "Truck and Bus" subcommittee standardized signalsand messages as well as data transmission protocols forvarious data rates. It became apparent that standardization ofthis kind is easier to implement when a longer identificationfield is available.

intermediate buffer- CAN controller withobjectstorage- CAN slave controllersforI/O functionsPhysical CAN connection

More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of theCANprotocolExtended format CANmessageImplementations of theCAN protocol

CAN in Automation



To support these efforts, the CAN protocol was extended bythe introduction of a 29-bit identifier. This identifier is made upof the existing 11-bit identifier (base ID) and an 18-bit extension(ID extension). Thus the CAN protocol allows the use of twomessage formats: StandardCAN (Version 2.0A) andExtendedCAN (Version 2.0B). As the two formats have tocoexist on one bus it is laid down which message has higherpriority on the bus in the case of bus access collisions withdiffering formats and the same base identifier: The message instandard always has priority over the message in extendedformat.

CAN controllers which support the messages in extendedformat can also send and receive messages in standardformat. When CAN controllers which only cover the standardformat (Version 2.0A) are used on one network, then onlymessages in standard format can be transmitted on the entirenetwork. Messages in extended format would bemisunderstood. However there are CAN controllers which onlysupport standard format but recognize messages in extendedformat and ignore them (Version 2.0B passive).

The distinction between standard format and extended formatis made using the IDE bit (Identifier Extension Bit) which istransmitted as dominant in the case of a frame in standardformat. For frames in extended format it is recessive.

The RTR bit is transmitted dominant or recessive depending onwhether data are being transmitted or whether a specificmessage is being requested from a station. In place of the RTRbit in standard format the SRR (substitute remote request) bit istransmitted for frames with extended ID. The SRR bit is alwaystransmitted as recessive, to ensure that in the case ofarbitration the standard frame always has priority bus allocationover an extended frame when both messages have the samebase identifier.

Unlike the standard format, in the extended format the IDE bitis followed by the 18-bit ID extension, the RTR bit and areserved bit (r1).

All the following fields are identical with standard format.Conformity between the two formats is ensured by the fact thatthe CAN controllers which support the extended format canalso communicate in standard format.

- Overview- CAN controller withintermediate buffer- CAN controller withobjectstorage- CAN slave controllersforI/O functionsPhysical CAN connection

More:


Page contents:TopHow does it function- Principles of dataexchange- Non-destructive bitwisearbitration- Efficiency of busallocation- Message frame formats- Detecting and signallingerrors- Data reliability of the

CAN in Automation



Message frame for extended format (CAN specification 2.0B)

Implementations of the CAN protocol

Overview

Communication is identical for all implementations of the CANprotocol. There are differences, however, with regard to theextent to which the implementation takes over messagetransmission from the microcontrollers which follow it in thecircuit.

CAN controller with intermediate buffer

CAN controllers with intermediate buffer (formerly calledbasicCAN chips) have implemented as hardware the logicnecessary to create and verify the bitstream according toprotocol. However, the administration of data sets to be sentand received, acceptance filtering in particular, is carried out toonly a limited extent by the CAN controller.

Typically, CAN controllers with intermediate buffer have tworeception and one transmission buffer. The 8-bit code andmask registers allow a limited acceptance filtering (8 MSB ofthe identifier). Suitable choice of these register values allowsgroups of identifiers or in borderline cases all IDs to beselected. If more than the 8 ID-MSBs are necessary todifferentiate between messages then the microcontrollerfollowing the CAN controller in the circuit must complementacceptance filtering by software. CAN controllers withintermediate buffer may place a strain on the microcontrollerwith the acceptance filtering, but they require only a small chiparea and can therefore be produced at lower cost. In principlethey 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 controllerswith object storage (formerly called FullCAN) function like CANcontrollers with intermediate buffers, but also administer certainobjects. Where there are several simultaneous requests theydetermine, 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

CANprotocolExtended format CANmessageImplementations of theCAN protocol- Overview- CAN controller withintermediate buffer- CAN controller withobjectstorage- CAN slave controllersforI/O functionsPhysical CAN connection

CAN in Automation


RAM. Data to be transmitted are written into the appropriateRAM area, data received are read out correspondingly. Themicrocontroller has to administer only a few bits (e. g.transmission request).

CAN controllers with object storage are designed to take asmuch strain as possible off the local microcontroller. TheseCAN controllers require a greater chip area, however, and aretherefore more expensive. In addition to this, they can onlyadminister a limited number of chips.

CAN controllers are now available which combine bothprinciples of implementation. They have object storage, at leastone of which is designed as an intermediate buffer. For thisreason there is no longer any point in differentiating betweenbasicCAN and fullCAN.

CAN slave controllers for I/O functions

As well as CAN controllers which support all functions of theCAN protocol there are also CAN implementations possiblewhich do not require a following microcontroller. These CANimplementations are called SLIO (serial link I/O) acting as CANslaves and having to be administered by a CAN master.


The data rates (up to 1 Mbit/s) necessitate a sufficiently steeppulse slope, which can be implemented only by using powerelements. A number of physical connections are basicallypossible. However, the users and manufacturers group CAN inAutomation recommends the use of driver circuits inaccordance with ISO 11898. Integrated driver chips inaccordance with ISO 11898 are available from severalcompanies. The international users and manufacturers group(CiA) also specifies several mechanical connections (cable andconnectors).

CAN in Automation


Physical CAN Connection according to ISO 11898



CAN in Automation


Conformance test CAN

The CAN Conformance test plan standardized in ISO WD16845 specifies the methodology and the abstract test suitenecessary to check the conformance of any CANimplementation to the harmonized CAN specification. The testplan is a specific application of ISO 9646-1. The test planenvironment consists of a lower tester, the IUT(implementation under test), and the upper tester running on amicrocontroller, for example. Since the message storagingcapability, the hardware acceptance filter, and the CPUinterface are not standardized, the only link between lowertester and IUT are the PLS-Data.indicate andPLS-Data.request interfaces.

The abstract test suites are independent one another. Eachtest suite checks the behaviour of the IUT for a particularparameter of the CAN specification. The test cases aregrouped to received frame type cases, to transmitted frametype cases, and to bidirectional frame type cases. Each testtype is subdivided in six test classes:

Valid frame format class●

Error detection class●

Active error frame management class●

Overload frame class●

Passive error state and bus-off class●

Bit timing class●

The CAN Conformance test plan is implemented by twodifferent test service providers. These are the German"Fachhochschule Braunschweig/Wolfenbüttel" (University ofApplied Science) and the French company DassaultElectronique.

The German "Fachhochschule Braunschweig/Wolfenbüttel"under Prof. Dr. W. Lawrenz provides a certificate which ismainly used by the chip manufacturer and the Germanautomotive industry.

More:

General introductionTechnical introductionApplicationsSpecificationsFAQ's


Presentations:

Physical LayerData Link LayerImplementationsApplicationsMore:

General introductionTechnical introductionApplicationsSpecificationsFAQ's


Presentations:



CAN in Automation

http://www.can-cia.de/cc.htm [14.11.1999 13:13:05]



















CAN Applications CANPage contents:

OverviewThe need for serial communication in vehiclesUse of the CAN in vehiclesIndustrial application of the CAN

Overview

CAN networks can be used as an embedded communicationsystem for microcontrollers as well as an open communicationsystem for intelligent devices.

The CAN serial bus system, originally developed for use inautomobiles, is increasingly being used in industrial as well asbuilding automation, medical equipment and maritimeelectronics. If the requirements for passenger cars networksare compared with those for industrial field bus systems, thesimilarities are remarkable. In both cases some of the majorrequirements are: Low cost, the ability to function in a difficultelectrical environment, a high degree of real-time capabilityand ease of use.

Some users, for example in the field of medical engineering,opted for CAN because they have to meet particulary stringentsafety requirements. Similar problems are faced bymanufacturers of other equipment with very high safety orreliability requirements (e. g. robots, lifts and transportationsystems).

The need for serial communication in vehicles

Many vehicles already have a large number of electroniccontrol systems. The growth of automotive electronics is theresult partly of the customer's wish for better safety andgreater comfort and partly of the government's requirementsfor improved emission control and reduced fuel consumption.Control devices that meet these requirements have been inuse for some time in the area of engine timing, gearbox andcarburettor throttle control and in anti-block systems (ABS)and acceleration skid control (ASC).

The complexity of the functions implemented in these systemsnecessitates an exchange of data between them. Withconventional systems, data is exchanged by means of

More:

General introductionTechnical introductionSpecificationsConformance testFAQ's


Presentations:


Page contents:TopOverviewThe need for serialcommunication invehiclesUse of the CAN invehiclesIndustrial application ofthe CAN

CAN in Automation

http://www.can-cia.de/cga.htm (1 von 4) [14.11.1999 13:13:13]










dedicated signal lines, but this is becoming increasinglydifficult and expensive as control functions become ever morecomplex. In the case of complex control systems (such asMotronic) in particular, the number of connections cannot beincreased much further.

Moreover, a number of systems are being developed, whichimplement functions covering more than one control device.For instance, ASC requires the interplay of engine timing andcarburettor control in order to reduce torque when drive wheelslippage occurs. Another example of functions spanning morethan one control unit is electronic gearbox control, where easeof gear-changing can be improved by a brief adjustment toignition timing.

If we also consider future developments aimed at overallvehicle optimization, it becomes necessary to overcome thelimitations of conventional control device linkage. This canonly be done by networking the system components using aserial data bus system. It was for this reason that Boschdeveloped the "Controller Area Network" (CAN), which hassince been standardized internationally (ISO 11898) and hasbeen "implemented in silicon" by several semiconductormanufacturers.

Using CAN, peer stations (controllers, sensors and actuators)are connected via a serial bus. The bus itself is a symmetric orasymmetric two wire circuit, which can be either screened orunscreened. The electrical parameters of the physicaltransmission are also specified in ISO 11898. Suitable busdriver chips are available from a number of manufacturers.

The CAN protocol, which corresponds to the data link layer inthe ISO/OSI reference model, meets the real-timerequirements of automotive applications. Unlike cable trees,the network protocol detects and corrects transmission errorscaused by electromagnetic interference. Additionaladvantages of such a network are the easy configurability ofthe overall system and the possibility of central diagnosis. Thepurpose of using CAN in vehicles is to enable any station tocommunicate with any other without putting too great a loadon the controller computer.

Use of the CAN in vehicles

There are four main applications for serial communication invehicles, each having different requirements and objectives.

More:



Presentations:



More:

CAN in Automation












Networking controllers for engine timing, transmission, chassisand brakes. The data rates are in the range - typical ofreal-time systems - of 200kBit/s to 1Mbit/s.

Networking components of chassis electronics andelectronics, which make the vehicle more comfortable.Examples of such multiplex applications are lighting control,air-conditioning, central locking, and seat and mirroradjustment. Particular importance has to be attached here tothe cost of the components and wiring requirements. Typicaldata rates are around 50kBit/s.

In the near future, serial communication will also be used inthe field of mobile communication in order to link componentssuch as car radios, car telephones, navigation aids etc. to acentral, ergonomically designed control panel. The functionsdefined in the Prometheus project, such as vehicle-to-vehicleand vehicle-to-infrastructure communication will depend to alarge extent on serial communication.

At present, CAN can be used for the first three applications,but for diagnosis the preferred solution is an interfaceaccording to ISO 9141.

Industrial applications of the CAN

A comparison of the requirements for vehicle bus systems andindustrial field bus systems shows amazing similarities: Lowcost, operability in a harsh electrical environment, highreal-time capabilities and ease of use are equally desirable inboth sectors. The standard use of CAN in Mercedes-Benz's"S" Class and the adoption of CAN by US commercial vehiclemanufacturers for fast transmissions (up to 1 MBit/s) hasmade industrial users prick up their ears. Not onlymanufacturers of mobile and stationary agricultural andnautical machinery and equipment have chosen to use CAN,is has also been the choice of manufacturers of medicalapparatus, textile machines, special-purpose machinery andelevator controls. The serial bus system is particularly wellsuited to networking "intelligent" I/O devices as well assensors and actuators within a machine or plant.

The textile machinery industry is one of the pioneers of CAN.One manufacturer equipped his looms with modular controlsystems communicating in real time via CAN networks asearly as 1990. In the meantime several textile machinerymanufacturers have joined together to form the "CAN TextileUsers Group", which in turn is a member of the international



Presentations:



More:



Presentations:

Physical Layer

CAN in Automation













users and manufacturers group "CAN in Automation". Similarrequirements to those of the textile machinery are to be foundin packaging machinery and machinery for paper manufactureand processing.

In the USA a number of enterprises are using CAN inproduction lines and machine tools as an internal bus systemfor networking sensors and actuators within the line ormachine.

Some users, for instance in the medical engineering sector,decided in favour of CAN because they had particularlystringent safety requirements. Similar problems are faced byother manufacturers of machinery and equipment withparticular requirements with respect to safety (e.g. robots andtransport systems).

Apart from the high transmission reliability, the low connectioncosts per station are a further decisive argument for CAN. Inapplications where price is critical it is of essential importancethat CAN chips be available from a variety of manufacturers.The compactness of the controller chips is also an importantargument, for instance in the field of low-voltage switchgear.

Data Link LayerImplementationsApplications



CAN in Automation








Frequently asked question CANPlease send your questions to: [email protected]

coming soon

More:

General introductionTechnical introductionApplicationsSpecificationsConformance test


Presentations:




CAN in Automation

http://www.can-cia.de/cf.htm [14.11.1999 13:13:18]











Standardization NewsCAN-related standards

There are several official national and international standardization bodies aswell as user organizations and private companies dealing with open CAN-basedspecifications. The following will give an overview on these activities, but will notclaim for completeness.

StandardState

Organization Topic Main Applications

CAN Data Link Layer and Physical LayerIS 11898 (Nov.1993 + Amendment1 (1995)

<under review>

ISO TC22 SC3 WG1 TF1 +TF6

CAN Data Link Layerand Transceiver(s)

Automotive and GeneralPurpose

IS 11519-2

<will be withdrawn>

ISO TC22 SC3 WG1 TF1 +TF6

CAN Low-SpeedTransceiver and DataLink Layer

Car Body Electronics

CD 16845 ISO TC22 SC3 WG1 TF6 CAN ConformanceTesting

General

J2284 SAE CAN High-SpeedInterface

Automotive

Draft J2411 SAE Single-Wire PhysicalLayer

Car Body Electronics

CAN-Related Standards for VehiclesIS 11992-1, -2, -3

(under review)

ISO TC22 SC3 WG1TF4

CAN Low-SpeedTransceiver + ApplicationLayer

Truck & Trailer

CD 15765-1, -2, -3,-4

ISO TC22 SC3 WG1TF2

Diagnostics on CAN Automotive

CD 15031-3

(J1962)

ISO TC22 SC3 WG1TF5 (SAE)

OBDII Diagnostics Automotive

CD 16844-4, -5 ISO TC22 SC3 WG1TF7

CAN for TachographSystems

Truck and Buses

WD 11783 ISO TC23 SC19 WG1 J1939-based Serial Controland Communications

Agriculture and Forestry

CD 717617 ISO TC173 SC1 WG7 M3S Network Wheelchairs

CCP ASAM e.V. CAN Calibration Protocol Passenger Cars

J1939-01 toJ1939-81

SAE Serial Vehicle Network Truck and Buses

DIN 9684 DIN e.V. Landwirtschaftliches BusSystem (LBS)

Agriculture and Forestry

WDP-407(prEN61349-2)

CiA/VDV (CLC TC278WG3 SG1)

CANopen ApplicationProfile for PublicTransportation

Driver and PassengerInformation

WDP-4XX CiA CANopen SpecialInterest Groups

CANopen Device Profilesfor Off-Road Vehicles

Mobile Machinery

WDP-4XX CiA CANopen SIGRailways

CANopen Device Profilesfor Railways

Passenger-Trains andCargo-Trains

More:

Hot NewsCiA NewsCAN NewsletterPress Release

More:


CAN in Automation

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



CAN Kingdom Kvaser/CANHUG Application Layer andProfiles

Off-Road Vehicles andGeneral Purpose

New Work ItemProposal

ISO TC22 SC3 WG1(OSEK Group)

OSEK-NM, OSEK-COM Automotive

CAN-Related Standards for Industrial Automation and General PurposeControl Systems

WD 15745-2 ISO TC184 SC5 WG 5 Application Frameworkfor CAN-based Networks

Industrial Automation

DS-201...207 CiA IG CAL CAN Application Layer General Purpose

PrEN50325-4

(DS-301)

CLC TC 65CX/CiA IGCANopen

CANopenCommunication Profile

General Purpose

DSP-302 CiA CANopen SIGProgrammable Devices

CANopen Framework forProgrammable Devices

General Purpose

WD-304 CiA CANopen SIGSafety

CANopen Framework forSafety-relevant Systems

Safety-relevant Systems

DSP-4XX, WD-4XX CiA CANopen SpecialInterest Groups

CANopen Device Profilesfor Industrial Control

Industrial Automationand General Purpose

FDIS 62026-3

FDIS 62026-5

IEC TC17B WG3 DeviceNet Specification

SDS Specification

Low-voltage switchgearand controlgear

PrEN 50325-2

PrEN 50325-3

CLC TC 65CX DeviceNet Specification

SDS Specification

Low-voltage switchgearand controlgear

DeviceNet Release2.0

ODVA DeviceNet Specification Industrial Automation

SDS Version 2.0 Honeywell SDS Specification Industrial Automation

NMEA 2000 National MarineElectronics Association

J1939-based ApplicationLayer

Navigation Systems

WDP-3XX CiA IG MaritimeApplication

CANopen Framework forMaritime Application

Marine

CDA 101 Target Reliance Officeof DoD

CAN Kingdom-basedData Layer

Target Control Systemsin US Navy, USAF andArmy

To get more information you can visit the following Web sites:

CAN | CAL | CANopen | CEN | CENELEC | CiA | IEC | ISO | ODVA


More:


CAN in Automation

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

http://www.cenorm.be/

http://www.cenelec.be/

http://www.iec.ch/

http://www.iso.ch/



Press Releases 1999 NewsPage contents:

CAN Sales Figures6th international CAN ConferenceWorldwide unique Manufacturer Name for CANopenCertified CANopen ProductsISO 11898 under ReviewCANopen Version 4.0 with enhanced featuresCANopen SIG SafetyCANopen SIG HydraulicsCANopen Devices for RailwaysCANopen SIG Maritime ElectronicsCiA: 320 Members WorldwideCANopen in RailwaysCANopen in Off-Road VehiclesCiA Study GroupsCAN-based Higher Layer Protocol StandardizationCiA In-house SeminarsFramework for Programmable CANopen Devices

CAN Sales Figures

Erlangen, 1999-07-21. CiA has accumulated the entire CANprotocol controller manufacturers sales figures for 1998 andtheir estimations for the next years. Compared with the lastyears survey you can see that the result for 1998 is higherthan expected, 97 millions instead of 59.8 millions. These

More:

Hot NewsCiA NewsCAN NewsletterStandardization

Page contents:TopCAN Sales Figures6th iCCUnique CANopen NameCertified CANopenProductsISO 11898 under ReviewCANopen Version 4.0CANopen SIG SafetyCANopen SIGHydraulicsCANopen for RailwaysCANopen SIG MaritimeCiA: 320 MembersCANopen in RailwaysOff-Road VehiclesCiA Study GroupsHigher Layer ProtocolCiA In-house SeminarsDSP-302 Version 2.0

CAN in Automation

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


figures are very conservative, because CiA did not considersales figures from CAN chip manufacturers, which did notrespond to the questionnaire. Sales figures for 2000 and thefollowing years do not include all expected CAN nodes in carsproduced in USA and Far East. Also not included are newapplication fields such as domestic appliances and otherhigh-volume embedded systems. By beginning of this year,there were installed more than 140 millions of CAN controllers.

6th international CAN Conference

Erlangen (Germany), 1999-07-05. From 2nd to 5th November,CAN in Automation (CiA) international users andmanufacturers group is organizing the 6th international CANConference (iCC) in Torino (Italy). The iCC is accompanied byworkshops and seminars as well as a table-top exhibition withmore than 35 companies participating. In addition, there will beposter sessions and product presentations. Entrance to theexhibition, poster and product presentations is free. This mostimportant event for the CAN community is sponsored by theJackson group, an Italian publishing house, and several CANchip suppliers (Hitachi, Infineon, Mitsubishi, Motorola, andNEC).

Detailed iCC Program

Worldwide unique Manufacturer Name for CANopen

Erlangen (Germany), 1999-07-05. The recently publishedCANopen specification version 4.0 requires a worldwideunique manufacturer name. The CAN in Automation (CiA)international users and manufacturers group manages thesenames that identify uniquely a CANopen module. CiAHeadquarters located in Erlangen (Germany) assigns thesenames on request; the price for non-members is 128 Euro (forCiA members this service is free of charge). CANopen version4.0 is submitted for European standardization and is also thebase for the work item on passenger information system forpublic transportation. Originally developed for industrialcontrol, 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 deviceshave passed the CiA Certification for products compliant to

More:



CAN in Automation



CANopen Version 3.0. The CANopen conformance testingspecification was developed by CiA Members andimplemented by National Instruments and the TechnicalUniversity of Braunschweig. I/O modules from Beckhoff, thelinear position sensor from MTS, the adapter board forSiemens drives from Intulogic, the adapter modules fromHMS, and the drive controllers from Yaskawa and Omronhave been already tested successfully by the CiA TestLaboratory. The Conformance Testing software is available byCiA, National Instruments, and others. The test tool runs onPC-based hardware, which provides a COTI interface.

ISO 11898 under Review

Erlangen, 1999-05-17. The regularly required review andupdate of the ISO 11898 standard will include the featuresdescribed in the implementation guideline published by Bosch.In addition, the standard will specify different physical layers.Besides the high-speed transceiver, it will describe also afault-tolerant transceiver. Several clarifications have beenincluded, such as use of DLC, identifier restrictions, and bittiming requirements. The most important optional featureadded to the CAN standard will be the time-triggeredcommunication (TTC) option.The new ISO 11898 document will be completely restructuredand divided in two parts: ISO 11898-1 specifies the CAN datalink layer and the LLC sub-layer, ISO 11898-2 describes theMAU sub-layer of the so-called high-speed transceiver for datarates up to 1 Mbit/s. Later on, the specification of fault-tolerantlow-speed physical layer will be added as part 3 (ISO11898-3). The updated specification is compliant to the CANReference Models from Bosch (C Model and VHDL Model).This includes the clarifications described in the Addendum tothe Bosch CAN Specification 2.0 A/B.The Data Length Codes (DLC) in the range of 0 to 7 indicatedata fields of length of 0 to 7 bytes. All other DLCs indicatethat the data field is 8 bytes long. That means, the DLCs in therange of 9 to 15 can be used for application-specific purposes.However, the proper use of remote frames has to beguaranteed by the system designer.Another clarification is that the SRR bit with a dominant valueis ignored by the receiving nodes, but not for bit stuffing andarbitration. This is because a dominant value is neither a Biterror, 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 bitreceived as dominant is also not a Form error. Since the SRR

More:



CAN in Automation



bit is received before the IDE bit, a receiver cannot decideinstantly whether it receives a RTR or a SRR bit. That meansonly the IDE bit decides whether the frame is a Standard or anExtended frame.The harmonized CAN standard also clarifies that a dominantbit in the last bit of End of Frame (EOF) field will force thereceiver to transmit an Overload frame. The transmitterinterprets a dominant value in the last bit of EOF as the start ofan Error frame initiated by one of the receivers, transmits itselfan Error frame, and retransmits the corrupted message. Thisis why some message may be transferred doubled.Synchronization rule 4 in the CAN standard requires the HardSynchronization to be performed at every edge fromrecessive-to-dominant during Bus Idle. Additionally HardSynchronization is required for each received Start of Frame(SOF). A SOF can be received not only during Bus Idle, butalso during Suspend Transmission and at the end ofIntermission. Therefore, the reviewed CAN standard enablesthe Hard synchronization also for Suspend state and for theend of the Intermission state as the CAN Reference Modelsdo.The restriction regarding the identifier range in the former CANspecifications will be not more valid in the reviewed CANstandard. This means, CAN controller compliant with ISO11898 may support all identifiers in the range of 0 to 2047. Ifthe IDE bit is recessive, also the other identifiers have to besupported.The reviewed CAN specification specifies an optional BusMonitoring Mode. In this mode the CAN node is able toreceive valid data frames and valid remote frames, but itsends only "recessive" bits on the CAN bus and it cannot starta transmission. If the MAC sub-layer is required to send a"dominant" bit (ACK bit), overload flag, or active error flag, thebit is routed internally, so that the MAC sub-layer monitors this"dominant" bit, although the CAN bus may remain recessivestate. This mode can be used for automatic baud-ratedetection.The optional time-triggered communication based on CAN(TCC) requires a synchronization of CAN nodes. Any nodethat supports the TTC option needs to provide a time base.The time base is a cyclic upcounter of at least 16-bit witheither an internal or an external clock. Any message receivedor transmitted invokes a capture of the time base taken at theSOF recognition or at the sample point of the last bit of EOF.These optional hardware functions enable CAN user totransmit a data frame at a specific point of time. This trigger

More:



CAN in Automation



time is programmable. The trigger generation should be freelyprogrammable by the CPU in the range of at least 0 to (216 -1) x timer clocks. In order to achieve high accuracy - maximum±1 time quantum - these mechanisms have to be implementedin silicon. The time-triggered message do not compete withothers to access the bus, because the single-shot option(disabling of automatic retransmission after error detection)guarantees that the next time-slot is not used by retransmittedframes. Of course, an application using the time-triggeredcommunication based on CAN requires additionalspecification, but these are related to so-called higher layerprotocols. Such protocols have to be developed and will bedifferent for different application fields.

CANopen Version 4.0 with enhanced features

Erlangen, 1999-05-17. In summer 1999, CiA Interest GroupCANopen is going to release the version 4.0 of the CANopenCommunication Profile. It specifies some new functions suchas timer-driven PDO transmission, SDO block transfer, andheartbeat message. Besides these functional enhancements,the profile describes also all used functions of the CANApplication Layer (CiA DS-201 to DS-207) except the LayerManagement (LMT).The CiA DS-301 Version 4.0 document is completelyrestructured and meets the requirements of Cenelec. This is,because this specification is going to be submitted forEuropean standardization as part 4 of the prEN 50325 (ISO11898-based Controller-device interfaces) standard. Thespecification includes models for devices, communicationservices as well as the reference model according to ISO7498. The physical layer chapter recommends bit rates andcorresponding bit timing settings, and it gives some hints todesign a physical CANopen network. In addition, CiA willpublish the CiA DRP-302-1 CANopen Recommendation forcable and connector pin assignment. One of the mostimportant changes to the version 3.0 is the inclusion of all CALspecifications required by CANopen. So the CANopenapplication layer chapter describes data types and encodingrules.The version 4.0 is completely upward compatible to version3.0. However, in version 4.0 there are some optional functionsspecified, which do CANopen users and system integratorsrequire. One of the missing features was a timer-drivenProcess Data Object (PDO). In the timer-driven triggeringmode, message transmission is either triggered by the

More:



CAN in Automation



occurrence of an object-specific event or if a specified timehas elapsed without occurrence of an event. The time isdescribed in the PDO communication parameter set and it canbe configured via Service Data Objects (SDO).Optionally a segmented communication can be transmittedwith SDO Block Download or SDO Block Upload. These maybe used to achieve higher bus throughputs. In the standardSDO download and upload services each segment isconfirmed. In the SDO block services the Initiate SDO Blockmessage is confirmed. It is followed by a block of segments,which is confirmed by only one message. The maximumnumber of segments per block is 128. In order to verify thecorrectness of a SDO block transfer, client and servercalculate a CRC sequence (Cyclic Redundancy Checksum),this is exchanged and verified within the confirmed End SDOBlock message. The check polynominal can be calculatedfrom a formula or a table given in the CANopen specification.One of the minor changes is the renaming of the PreparedState into Stopped State. In the Stopped State, a device isforced to stop communication objects. It can only receiveNetwork Management Objects, and it can perform nodeguarding, if active. This state can be used to achieve certainapplication behavior specified by device profiles.The new Boot-up Protocol is used to signal that a NMT slavehas entered the node state Pre-operational after the stateInitializing. The Boot-up message uses the same identifier asthe Error Control Protocols, and contains one data byte withthe fixed value of zero. Version 4.0 specifies two Error ControlProtocols: The already used Node Guarding Protocol and thenew Heartbeat Protocol. One of these protocols has to besupported. The Heartbeat Protocol defines an Error ControlService without need for remote frames. A Heartbeat Producertransmits a Heartbeat message cyclically. One or moreHeartbeat Consumer receive the indication. The relationshipbetween producer and consumer(s) is configurable via theobject dictionary. The Heartbeat Consumer guards thereception of the Heartbeat within the Heartbeat ConsumerTime. If the Heartbeat is not received within the HeartbeatConsumer Time, a Life Guarding Event will be generated. Ifthe Heartbeat Producer Time is configured on a device, theHeartbeat Protocol starts immediately. If a device begins witha value for the Heartbeat Producer Time unequal to 0 theHeartbeat Protocol starts on the state transition fromInitializing to Pre-operational. In this case, the Boot-upmessage is regarded as first Heartbeat message. It is notallowed for one device to use both control mechanisms,

More:



CAN in Automation



Guarding Protocol and Heartbeat Protocol, at the same time. Ifthe Heartbeat Producer Time is unequal 0, the HeartbeatProtocol is used. It is recommended to use the HeartbeatProtocol in order to avoid remote frames.In order to reduce configuration effort for simple CANopennetworks, a mandatory default identifier allocation scheme isdefined. These identifiers are available in the Pre-operationalstate directly after the first initialization. If the device providesparameter storage capability, after configuration the identifiersmay be changed permanently. In this case, only after ResetCommunication the identifiers are set to their default values.The identifiers for Sync, Time stamp, and Emergencymessages as well as for PDOs may be modified by means ofdynamic distribution. Of course, a device has to provide thecorresponding identifiers only for the supportedcommunication objects. The identifiers for the NMT message,the Default SDO, and the NMT Error Control message mustnot be changed.The default ID allocation scheme consists of a functional part,which determines the object priority and a Node-ID-part, whichallows distinguishing between devices of the samefunctionality. This allows a peer-to-peer PDO communicationbetween a single master and up to 127 slave devices. It alsosupports the broadcasting of unconfirmed NMT objects, Sync,and Time-stamp message. In version 4.0, the pre-definedconnection set supports at maximum 4 Receive-PDOs and 4Transmit-PDOs. The CANopen Framework forSafety-Relevant Communication reserves the identifier rangefrom 257 to 384 for safety-relevant data objects specified.Using CANopen in that different application fields, suchindustrial control, off-road vehicles, medical equipment,building automation, maritime electronics, railways, and evenin omnibuses, requires some more data types and emergencyerror codes. The version 4.0 specifies now also the data typesUnsigned24, -40, -48, -56 and -64 as well as Integer24, -40,-48, -56 and -64.In the case of device internal failure detection, the device maytransmit an Emergency message. The Emergency objecttransmits the error code. The reviewed CANopencommunication profile specifies some more codes, inparticular those reporting failures and problems of the CANcontroller. The error code 8110 signals CAN overrun meaninglost of frame. That a node has switched from active in passiveerror mode is indicated by error code 8120. This is to informothers that network-wide data consistency is not moreguaranteed. The switch from passive into active error mode is

More:



CAN in Automation



indicated by the error code 8140. The error code 8130 istransmitted, if a node recovers from bus-off state.

CANopen SIG Safety

Erlangen, 1999-05-17. The CANopen Special Interest Group(SIG) Safety is specifying a CANopen Framework forSafety-relevant Systems. In the first proposal, Safety-RelevantData Objects (SDRO) are defined that are made by two PDOswith COB-Ids differing in two identifier-bits. The data content ofthe second PDO is bit-wise inverted. This serial redundancyshould avoid a redundant CANopen network. In addition, eachSDRO is assigned with a configurable time-out. The receivingnodes will switch to a failsafe state, if the SDRO is notcorrectly received within the configured time. In addition, theframework will specify so-called global emergency switchmessages transmitted in broadcast. The framework will alsospecify to use only the new heartbeat error controlmechanism.

CANopen SIG Hydraulics

Erlangen, 1999-05-17. The recently established CANopen SIGHydraulics is working on the CANopen Device Profile forProportional Hydraulic Valves based on the bus-independentVDMA-Profile. Later, the CiA WD-408 device profile willdescribe also hydraulic drives. The work draft proposal alreadyavailable for CiA members describes the application objectattributes, and defines the default mapping of the ProcessData Objects (PDO). The profile covers very simple valves aswell as more intelligent devices providing position or pressurecontrol functionality.

CANopen Devices for Railways

Erlangen, 1999-05-17. The Task Forces of the CANopen SIGRailways have started to develop CANopen device profiles forbrake control, door control, and gateways to train-buses, suchas WTB and EBAS. All these profiles are based on thecorresponding UIC specifications. The CANopen device profilefor door control is nearly ready; and it will also cover omnibusdoor controllers. The CANopen coach/trainbus gateway will besuitable for cargo trains as well as passenger trains includingtramways, metros, and any other light trains. The CANopenSIG Railways will coordinate the work on device profiles andwill establish further TFs (e.g. for air-conditioning) if required.

More:



CAN in Automation



CANopen SIG Maritime Electronics

Erlangen, 1999-05-17. The CANopen SIG MaritimeElectronics was established in April. The scope of the group isthe specification of a CANopen Framework for MaritimeApplications. It will specify additional network managementfunctionality as well as implementation guidelines forredundant CANopen networks. In addition, the SIG will definemaritime-specific device profiles, in particular gateways tomaritime-specific subsystems such as engine control,fire-fighting systems, etc. The publication of the CANopenframework is scheduled for end of this year.

CiA: 320 Members Worldwide

Erlangen, 1999-01-12. The CAN in Automation (CiA)international users and manufacturers group, founded in 1992,was joined by 320 companies and non-profit institutes (1999,January 1st). The trade organization promotes the CAN(Controller Area Network) serial bus system. Besides generalmarketing activities, CiA Headquarters organize technicalconferences, workshops, and in-house seminars. Members ofthe non-profit association specify higher-layer protocols suchas CAL (CAN Application Layer) and CANopen as well asadditional physical layer recommendations, e.g. baud-rates,bit-timings, and pin assignments of connectors. In the CiAOffice located in Erlangen (Germany), seven secretariesprovide worldwide technical, marketing and productinformation intelligence.(Remark: daughter companies and subsidiaries areautomatically CiA Members and will not be countedseparately).

CANopen in Railways

Erlangen, 1999-01-12. The CAN in Automation (CiA)international users and manufacturers group has establishedthe CANopen Special Interest Group (SIG) Railways. Thisgroup coordinates the standardization of CANopen DeviceProfiles for railway applications. The profile specification willbe done in several Task Forces. The SIG has establishedTask Forces for traction, brake, and door control. It is intendedto submit CANopen profile specifications to Europeanstandardization bodies.

CANopen in Off-Road Vehicles

More:



CAN in Automation



Erlangen, 1999-01-12. On behalf of the VDMA (VerbandDeutscher Maschinen- und Anlagenbauer) working group forbuilding machine, the University of Magdeburg haspre-developed some CANopen Device Profiles. The profilesfor diesel engine, electronic gear, joystick, slope control, andhydraulics were handed over to the CAN in Automation (CiA)international users and manufacturers group in order to reviewthese documents and to become CiA standards. Thehydraulics profile should be harmonized with thebus-independent profile framework developed by the VDMAworking group for fluid control. Beginning of February, CiA isgoing to establish related CANopen SIGs (Special InterestGroups).

CiA Study Groups

Erlangen, 1999-01-12. The CAN in Automation (CiA)international users and manufacturers group is calling forStudy Groups (SG) on "OSEK and CANopen" as well as"Maritime Electronics". Users of the CANopen Profile Family,especially off-road vehicle manufacturers, bus and truckmakers, as well as some industrial device providers requesteda standardized operating system interface for CANopenimplementation. In passenger cars OSEK-OS is the mostsuccessful operating system specification for real-timeapplications. In the according SG the possibility to combineOSEK-OS and CANopen will be discussed.Several providers of maritime electronics have already usedCAN-based network for ship automation. The CiA SG MaritimeElectronics will discuss the standardization requirements andthe already existing efforts done in the NMEA2000 project. SGmeetings are also open for non-members.

CAN-based Higher Layer Protocol Standardization

Erlangen, 1999-01-12. CAN-based higher layer protocols forindustrial and general-purpose control applications are wellestablished. DeviceNet and Smart Distributed System (SDS)are already submitted to IEC and Cenelec in order to becomeinternational resp. European standards. CANopen is alsosubmitted for European standardization. The CAN-basedJ1939 protocol, mainly used in trucks and off-road vehicles, isalready SAE standard. The American standard will not besubmitted to ISO for international standardization, because theEuropean truck manufacturer will accept J1939 as it is. On the

More:


Page contents:Top6th iCCUnique CANopen NameCertified CANopenProductsISO 11898 under ReviewCANopen Version 4.0CANopen SIG SafetyCANopen SIGHydraulicsCANopen for RailwaysCANopen SIG MaritimeCiA: 320 MembersCANopen in RailwaysOff-Road VehiclesCiA Study GroupsHigher Layer ProtocolCiA In-house SeminarsDSP-302 Version 2.0

More:


CAN in Automation




other hand, there could be an overlapping with the ISO 11992standard, which is the CAN-based truck-trailer interface.OSEK/VDX, the higher-layer protocol for passenger cars, isnot yet submitted to ISO for international standardization.

CiA In-house Seminars

Erlangen, 1999-01-12. Last year, CiA started to offer in-houseseminars on CAN technology. Topics were CAN protocol andimplementations, CAN physical layer options, CANapplications, and CAN-based higher-layer protocols. CiAtrainers educated several hundred engineers. Due to thesuccess of these in-house seminars and the continuingdemands, CiA will also offer this service in 1999. The price for1-day seminar is 450 EUR plus travel and hotel expenses.

Framework for Programmable CANopen Devices

Erlangen, 1999-01-12. The CAN in Automation (CiA)international users and manufacturers group has updated theDSP-320 Framework for Programmable Devices. The currentversion 2.0 includes now chapters, which describe some newmanagement objects such as the NMT start-up, the SlaveAssignment, NMT Request. In addition, the CANopenConfiguration Manager services were expanded, and theMultiplexor PDO specification was clarified. The DSP-302specification also introduces some new configuration objectsfor these Multiplexor PDOs.



More:


Page contents:Top6th iCCUnique CANopen NameCertified CANopenProductsISO 11898 under ReviewCANopen Version 4.0CANopen SIG SafetyCANopen SIGHydraulicsCANopen for RailwaysCANopen SIG MaritimeCiA: 320 Members

CAN in Automation



CANopen in RailwaysOff-Road VehiclesCiA Study GroupsHigher Layer ProtocolCiA In-house SeminarsDSP-302 Version 2.0

More:



CAN in Automation



More:



More:


CAN in Automation





CAN in Automation


Documents

can_org (1)