DeviceNet
DeviceNet is an open communications protocol used in industrial automation to interconnect I/O and control devices. DeviceNet was originally developed by Allen Bradley (now owned by Rockwell Automation), and was the first public implementation of CIP. The DeviceNet specification is now maintained and managed by the Open DeviceNet Vendors Association (ODVA), which oversees technical developments and provides conformance testing for vendors of DeviceNet equipment. DeviceNet uses CAN in its data link layer. The diagram below shows the relationship between CIP, DeviceNet and the OSI reference model.
The DeviceNet implementation of CIP uses CAN in its data link layer
DeviceNet uses only a subset of the CAN protocol (it uses only the standard 11-bit Message ID, and does not implement data request frames). The physical layer is an extension of the physical layer definition described in the ISO 11898 CAN specification. The extension specifies support for up to 64 nodes per network, and the provision of overvoltage and miswiring protection. Data rates for DeviceNet networks are defined as 125, 250, and 500 kbps, for maximum network lengths of 500, 250 and 100 metres respectively. In order to utilise the CAN protocols, message data length is generally restricted to eight bytes (if required, longer messages may be sent as a series of message fragments), and the introduction of a master/slave communication profile to improve scalability. These features allow the use of small, inexpensive microcontrollers, which is important for small applications such as photo-detectors and proximity sensors, where costs must be kept low. These specialisations allow DeviceNet to reside in small microchips with limited memory.
Network topology
The devices on the network are linked together using a 4-wire DeviceNet cable, which allows separate connections for data (CAN-high and CAN-low) and power (Vcc and Ground). Network nodes with limited power requirements may thus be powered directly from the network (the trunk-line current rating is 8 amps). Shielding is provided to give a degree of noise immunity. The topology employed in DeviceNet networks is essentially a bus topology referred to in the specification as a trunk-line/drop-line topology that provides separate twisted-pair buses for signal and power distribution. The illustration below shows how a DeviceNet network topology might be configured.
Example DeviceNet network topology
A DeviceNet network requires a 0.25W 120Ω terminating resistor at each end of the trunk-line, between the CAN-H and CAN-L signals. DeviceNet devices attached to the network that have their own power supply should be electrically isolated. A DeviceNet network may have up to 64 nodes, with MAC IDs ranging from 0-63. The type of cable used for trunk-lines or drop-lines will determine the maximum total network length and data rates that can be achieved. The table below shows the permutations possible for cable types, cable lengths, and data rates.
| Data rates | |||
|---|---|---|---|
| Cable Types | 125 kbps | 250 kbps | 500 kbps |
| Round thick trunk cable | 500m | 250m | 100m |
| Round thin trunk cable | 100m | 100m | 100m |
| Flat trunk cable | 380m | 200m | 75m |
| Maximum drop length | 6m | 6m | 6m |
| Maximum cumulative drop length | 156m | 78m | 39m |
When the network is powered on, each device on the network sends out a Duplicate MacID Request Message. The message includes the DeviceNet Vendor ID (assigned by the ODVA) and the device serial number. The combination of Vendor ID and serial number is guaranteed to be unique for every DeviceNet device. If two or more devices attempt to access the network at the same instant, the device with the lowest Vendor ID/serial number combination will be given priority. The procedure involves the transmission of two consecutive Duplicate MacID Request Messages, with a delay of one second between them. During this delay, any online device with the same MAC ID as the device requesting access to the network must issue a Duplicate MacID Response Message. If the device requesting access to the network receives such a response, it transitions to the offline state. If not, the device will transition to the online state. If a device wishes to leave the network, it can broadcast a Device Shutdown Message, which signals to the other devices on the network that it is transitioning to the offline state.
Explicit messages are routed via the explicit message router inside each DeviceNet device. If the explicit message contains an invalid class, the router will reject the message and return an error code to the requester, otherwise it will pass the message to the target object for processing. The response from the target object is returned to the requester, again via the router.
How DeviceNet uses the CAN identifier
The 11-bit CAN identifier is used to define the Connection ID. DeviceNet divides the CAN identifier into four groups. The first three groups each contain two fields. Each group has a 6-bit MAC ID field, group 1 has a 4-bit Message ID field, while groups 2 and 3 both have a 3-bit Message ID field. The combination of MAC ID and Message ID forms the Connection ID. Nodes in a DeviceNet system are responsible for managing their own identifiers. The diagram below shows the DeviceNet allocations within the 11-bit CAN Identifier. Note that the start bits for each group are such that a group 1 message will always have a higher priority than a group 2 message, while a group 2 message will always have a higher priority than a group 3 message, and so on. Group 4 messages are reserved for offline communications.
DeviceNet Allocations of the 11-Bit CAN identifier field
Device configuration
The devices (or nodes) on a DeviceNet network are configured either as master devices, slave devices, or peer devices (in some cases, a device may engender all three modes of operation simultaneously). Master devices (sometimes referred to as scanners or client devices) are usually either programmable logic controllers (PLCs) or personal computers (PCs). Master devices "own" any number of slave devices, but a slave device can only be "owned" by one master at any one time. A master device receives input information from slave devices and sends output information to slave devices. In order to establish ownership of a slave device, a master device must undertake an allocation process involving a set of handshaking messages. These messages are collectively referred to as the Predefined Master Slave Connection Set, and allow the master device to request control of the slave device and configure it to transmit a particular set of data at a data rate specified by the master device.
The master allocation sequence
- The master issues an unconnected open request message to the slave. If the slave device supports unconnected messages, it allocates an explicit message connection and replies to the master with a message that contains a connection ID, and indicates the type of messaging the slave can support.
- If the slave does not support unconnected messages, it will ignore the open request message.
- If a slave fails to answer the original open request message within one second, the master issues a second open request message. Slaves that don't support unconnected messaging will continue to ignore the open request message.
- If both open request messages are ignored, the master waits a further one second, then issues a group 2 only connection request, which attempts to establish an explicit or I/O connection (or both) using the group 2 only port, which has the function of supporting the simple allocation of slave devices. Slaves that fail to respond to group 2 only connect messages are assumed to be in the faulted condition. A master may periodically retry the allocation sequence, but there is no specific requirement for it to do so.
- Once an explicit connection is established, the master can use it to establish and configure the I/O connection. Once the I/O connection has been configured, the master may explicitly delete the explicit connection, which is no longer required.
Master-slave communication
A slave may deny an allocation request from a master if it is already allocated to another master, or if the master requests an unsupported connection type. If the allocation request is accepted, the master will configure the I/O connection. The most important attributes of the I/O connection are the Expected Packet Rate and the Produced and Consumed connection paths. The Expected Packet Rate specifies the rate at which the master intends to scan the slave device (if the master subsequently fails to maintain this scan rate, the slave enters a timed-out state, and must be explicitly re-activated by the master). The Produced and Consumed connection paths are the paths to the application objects where data is generated or stored, respectively (usually one of the assemblies supported by the slave device). Scanning can start once the slave device has been configured. During scanning, the master device produces data for the slave?s output assembly (identified by the Consumed Connection path) and consumes data generated from the slave?s input assembly (identified by the Produced Connection path). The triggers for slave device output include network polling, change-of-state events, and timer events.
Slave devices, sometimes called adaptors or servers, receive and transmit application specific data to and from a master device. Slave devices by definition implement the Predefined Master Slave Connection Set, and must support at least one or more of the following I/O Message transport types:
- Polling - a master device transmits I/O data to the slave at a rate that must exceed the expected packet rate specified when the I/O connection was configured (this will depend on how many slave devices the master device has in its scan list). The slave responds by immediately returning the data in its input assembly.
- Cyclic - a master device transmits I/O data to the slave at a rate that must exceed the expected packet rate specified when the I/O connection was configured, as before. The slave may respond immediately, or (more typically) returns the data in its input assembly at intervals specified by the master during configuration.
- Change-of-state (COS) - a master device transmits I/O data to the slave at a rate that must exceed the expected packet rate specified when the I/O connection was configured, as before. The slave may respond immediately, or (more typically) returns the data in its input assembly only when the data has changed, or in response to an interrupt from its heartbeat timer.
Slave devices that support change-of-state operation use the device heartbeat message to let the master device know they are still operational. If no change-of-state message containing new data is produced within a specified interval (the heartbeat interval), the slave will send a device heartbeat message.
A master device (typically a PLC) implicitly informs a slave device of its current operating mode with each I/O scan. If the scan message includes at least one byte of I/O data, the slave device can assume that the master device is in run mode. If the Master device is in idle mode, it sends an I/O message with zero bytes of data (known as an idle mode message). In response, the slave device implements whatever functionality is required of it when its master device is not in run mode. The DeviceNet specification does not define any specific behaviour for a slave device in such a situation.
DeviceNet devices may be configured in hardware (e.g. using DIP switches) or using software configuration tools that access the internal configuration of the device over the DeviceNet network, or via a separate communication port. A software configuration tool acting as a master device will seek to allocate a target device as a slave in order to configure the device. It will request an explicit message connection in order to send configuration data to the device, after which it will release the connection. If the device is currently allocated by another master device, that device can effectively act as a proxy for the slave by relaying messages from the configuration tool to the slave, and responses from the slave to the configuration tool.
Error states
DeviceNet devices can assume any of the following states:
- Non-existent - the device has shut down due to an internal error or a remote command.
- Unallocated - the device has joined the network but is not currently "owned" by a master device, or timed-out messages have failed to arrive on one or more connections with the master device (usually a recoverable error).
- Faulted - the device has detected an internal error or received a duplicate MacID response message. This is not a recoverable error.
- Busoff - the device has detected significant network errors and has removed itself from network operation (this usually indicates a hardware failure in the device circuitry).
I/O messaging
Input data is transmitted (or produced) by a slave device and received (or consumed) by a master device. Output data is transmitted by a master device and received by a slave device. I/O data in a device is held in one or more assemblies, and all I/O messages carry an I/O assembly between a master and a slave device. The input assembly object identifies the data produced by the device, while the output assembly object identifies the data consumed by the device. A device can have multiple input and output assemblies.