DeviceNet: The Do-All Fieldbus for Low and Mid-Level Factory Networking

Origin: Allen-Bradley, 1994

Based on CAN (Controller Area Network) technology, borrowed from the automotive industry, and the RS485 electrical specification.

Maximum Number of Nodes: 64

Connectors: Popular ‘Mini’ 18mm and ‘Micro’ 12mm waterproof quick-disconnect plugs and receptacles, and 5 pin phoenix terminal block.

Distance: 100M to 500M

Baudrate: 125, 250 and 500 Kbits/sec

Maximum Message size: 8 bytes of data per node per message

Messaging formats: Polling, Strobing, Change-of-State, Cyclic, and others; Producer/Consumer based model

Supporting Trade Organization: Open DeviceNet Vendor Association, www.odva.org

Typical Applications: Most commonly found in assembly, welding and material handling machines. Single-cable wiring of multi-input sensor blocks, smart sensors, pneumatic valves, barcode readers, drives and operator interfaces. 

Advantages: Low cost, widespread acceptance, high reliability, and efficient use of network bandwidth, power available on the network.

Disadvantages: Limited bandwidth, limited message size and maximum length.

DeviceNet and Ultra-Reliable CAN Technology

When the developers of DeviceNet sought a bulletproof technology for critical factory networking purposes, they opted for a ready-made solution from the automotive industry. Bosch developed CAN in the early 1980’s for eliminating large and expensive wiring harnesses in Mercedes automobiles.

CAN was developed so that the primary control components in an automobile – braking components, airbags, lights, electric windows and door locks, etc. – could be connected with a single cable instead of a bundle of cables 3" thick. (Sound familiar?)

Automotive manufacturers found that if a wiring harness is faulty, it’s sometimes cheaper to scrap the entire car than to troubleshoot the wiring harness. In a network, you can do wiring in software, and the added hardware cost is more than paid for by labor savings. The same applies to automated equipment in a factory.

Robustness in the Extreme

Of course in a vehicle, it’s literally a life and death situation. Network errors are simply NOT TOLERABLE, regardless of origin. CAN lives up to the rigorous requirements, with a statistical probability of less than one faulty message per century.

DeviceNet: A Software Appication Layer on top of CAN

CAN itself is a low-level message arbitration protocol implemented on inexpensive chips which are available from multiple vendors and manufactured by the millions. In order to have a fully functional network protocol, an additional software layer must be added. DeviceNet can be thought of as a sophisticated set of ‘macros’ for CAN messages, specifically suited for automation. SDS and CAN-open are automation networks also based on CAN. (Another popular standard, J1939, was created by the Society of Automotive Engineers. It is CAN application layer used in trucks and buses.)

DeviceNet: Versatile, Available, and Competitive.

DeviceNet is a versatile, general purpose Fieldbus designed to satisfy 80% of the most common machine- and cell-level wiring requirements. Devices can be powered from the network so wiring is minimized. The protocol is implemented on many hundreds of different products from hundreds of manufacturers, from smart sensors to valve manifolds and operator interfaces.

Work Smarter, Not Harder

One of DeviceNet's major benefits is its multiple messaging formats, which allow the bus to 'work smart' instead of work hard. Synergetic supports these formats as described below, and they can be mixed and matched within a network to achieve the most information-rich and time-efficient information from the network at all times:

Messaging Types

Polling: The scanner individually asks each device to send or receive an update of its status. This requires an outgoing message and incoming message for each node on the network. This is the most precise but least time efficient way to request information from devices.

Strobing: The scanner broadcasts a request to all devices for a status update. Each device responds in turn, with node 1 answering first, then 2, 3, 4 etc. Node numbers can be assigned to prioritize messages. Polling and strobing are the most common messaging formats used.

Cyclic: Devices are configured to automatically send messages on scheduled intervals. This is sometimes called a 'heartbeat' and is often used in conjunction with Change of State messaging (see below) to indicate that the device is still functional.

Change of State: Devices only send messages to the scanner when their status changes. This occupies an absolute minimum of time on the network, and a large network using Change of State can often outperform a polling network operating at several times the speed. This is the most time efficient but (sometimes) least precise way to obtain information from devices because throughput and response time becomes statistical instead of deterministic.

Explicit Messaging: The explicit-messaging protocol indicates how a device should interpret a message. Commonly used on complex devices like drives and controllers to download parameters that change from time to time but do not change as often as the process data itself.  An explicit message supplies a generic, multipurpose communication path between two devices and provides a means for performing request/response functions such as device configuration. 

Fragmented Messaging: For messages that require more than DeviceNet's maximum 8 bytes of data per node per scan, the data can be broken up into any number of 8 bytes segments and re-assembled at the other end. This requires multiple messages to send or receive one complete message.

UCMM (UnConnected Message Manager): DeviceNet UCMM interfaces are capable of peer-to-peer communication. Unlike the plain-vanilla Master/Slave configuration, each UCMM capable device can communicate with another directly, without having to go through a master first. 

UCMM devices must accept all generic CAN messages, then perform filtering of irrelevant or undesired message types in the upper software layer. This requires more RAM and ROM than ordinary Master/Slave messaging. 

Synergetic Provides Powerful DeviceNet Connectivity Solutions:

Master Technology: If you are planning to design a DeviceNet master scanner, we can supply the sourcecode written by Allen-Bradley in ANSI C, which implements the DeviceNet protocol. Synergetic is a Rockwell Design Partner for the DeviceNet Master sourcecode. The license permits you to make and sell an unlimited number of DeviceNet devices for a one-time license fee. (See the license agreement for specific details.)

PC Adapter Cards: We have PC/ISA, PC104, PCI, PCMCIA, STD32 and VME* Masters and Slaves for DeviceNet. They use the same configuration tools, hardware and software interface as all of our other Fieldbus interfaces (DeviceNet, Profibus, Interbus, etc…).

DeviceNet Detective
This Do-All hand-held configuration and diagnostic tool is the fastest way to troubleshoot a network.  Indispensible wherever real people (not technical wizards) need to make a network go and keep it going!

*Call for availability

Troubleshooting Tips:

DeviceNet devices are addressed one of two ways: 1) DIP switches; 2) Internal software, configured via commands from the master. The default node address for software configured devices is 63, and the default baudrate is 125K Baud. It is best to connect nodes one at a time to the network and immediately reset the baud rate and node number ("MAC ID") of each to a number other than 63. You should avoid using 63 as a node number on the network because of the likelihood of having two nodes trying to use that address.

Also, make sure you apply 24 volt power to the cable! According to the DeviceNet specification, all transceivers on the bus are powered by the network, not the Device they’re attached to—including the master.

Synergetic’s DeviceNet Solutions

Embedded Master and Slave Modules: Our COMMUNICATOR modules are credit-card sized boards that you can design into your controller, PLC, operator interface, drive, barcode reader, signal processor or other device that you wish to convert to Fieldbus. The same dual port memory, software drivers and configuration tool as our PC card is used regardless of the bus.

COMMMUNICATOR modules require a custom user hardware design with the COM module mounted as a daughter board and the Fieldbus connector on your hardware board. All other Fieldbus components are on the COM module. After designed, all other COM modules can be plugged into the same socket.

Turn-Key Slave Modules: The ANYBUS-S DeviceNet module allows you to design instant ControlNet, Profibus, Interbus, and other Fieldbus connectivity into your product in a matter of weeks. Now you don’t have to be a DeviceNet expert to manufacture a DeviceNet-compatible product!

A custom hardware design is required, and all Fieldbus components, including connectors, are on the Anybus board. After designed in, all Anybus cards in the same family can be interchanged as different Fieldbuses require.
 

Synergetic Product Matrix  Related Links & Contacts

Copyright 1999 Synergetic