Do you remember the term data highway? That’s what they called the internet way back when. It’s also what Allen-Bradley decided to call one of its early proprietary networking protocols: Data Highway, shortened to DH. And believe me when I tell you, when it was introduced, it was stunning and revolutionary. Now, not so much. It’s kind of ho-hum, obsolete and nostalgic.
However, if it moves your data, we need to know about it. And if we know about it, we want everyone to know about it. So, here’s our DH+ tech page.
Data Highway was developed by Allen-Bradley in the glory days of programmable controllers (the 1970s) as a proprietary network connecting A-B PLCs, remote IO systems, PCs and HMIs. Prior to DH, every sensor and actuator required an I/O point on a PLC card and a minimum of two wires from the device to the I/O connection on the PLC input card. Data Highway was one of the first technologies to move field connections closer to the machine and out of the control cabinet.
While it wasn’t the first I/O bus in manufacturing, it was the first I/O bus supported by Allen-Bradley programmable controllers (PLC2s and PLC3s at the time). Data Highway reduced wiring expenses, simplified I/O architectures and made the term “blue hose” ubiquitous in manufacturing plants around the world.
Unfortunately, Data Highway came to be one of those terms that referred to several specific technologies. Here are some of the more noteworthy.
The technology was protected under trade secret and patent protection until the late 1990s, an era that was anything but “open source.” In those early days, the business plan was to develop some proprietary technology, patent it, lock your customers into it and profit from it, competition free, for many years. Of all the DH technologies, DH+ was the one that was adopted most widely. (DH-485 achieved some success connecting connected Allen-Bradley’s SLC programmable controllers.)
DH+ is still used in many legacy manufacturing applications. Like much of the legacy technology in older manufacturing plants, there is no real incentive to replace it. Replacing controllers, wiring, I/O cards and the rest means downtime, expensive upgrades, integration costs, documentation and, often, retraining a maintenance staff. All that expense to make the same product means that technologies like DH+ will continue to exist until there is a more pressing reason to upgrade the entire manufacturing cell or manufacturing line.
Today, DH+ enabled PLCs and devices are highly coveted. Manufacturing systems using DH+ are unable to buy new controllers, devices and I/O from Allen-Bradley, so there is a strong secondary market for those legacy devices.
Because it’s on everyone’s mind, I’ll ask the question: How does DH+ compare to Ethernet? Let’s take a look.
BAUD RATE – Ethernet is exceptionally fast and gets faster every day. 1GB and 10GB are currently supported with 100GB on the horizon. DH+ supports a set of much lower baud rates; 57.6, 115.2K and 230.4K baud. Unlike Ethernet, there are no switches allowing devices with slower baud rates to participate in the network. All DH+ devices must use the same baud rate.
CABLING – CAT5 and CAT6 cabling are typical cables for Ethernet systems. CAT5 consists of four twisted pairs of copper wire. It’s probably the cabling you used at the office before you started using wireless connections. CAT5E and CAT6 are enhanced cabling types that provide higher bandwidth and up to 10Ghz speed. DH+ uses very simple cabling with one twisted pair surrounded by a shield.
CABLE LENGTH – CAT5 is typically rated for less than 400 feet, far less than the 10,000 feet of trunk cable supported by DH+. This is the one area where DH+ has an advantage over Ethernet though Ethernet backbones render that benefit superficial.
SUPPORTED CONTROLLERS – DH+ supports all the original Allen-Bradley PLCs, the PLC2 and the PLC3. Some controllers in the PLC5 line supported DH+, others support Ethernet while still others support both.
NUMBER OF DEVICES – DH+ networks are limited to 64 devices while Ethernet networks are virtually unlimited.
DEVICE ADDRESSING – Ethernet uses the standard dot decimal addressing while a station number between 0 and 63 is used to address a DH+ device. It is illegal to have duplicate station numbers on either network.
COST – With a limited number of possible customers, DH+ was a pricey solution in its day and, at first, only used by the biggest of Allen-Bradley customers. Ethernet, on the other hand, is a mass consumer product used by millions and it is inexpensive because of the commercial volume.
NETWORK ARCHITECTURE – The network architecture for Ethernet is much more sophisticated than the network architecture for DH+. Ethernet uses a layered approach to communication using a physical layer, a data link layer, a network layer and an application layer. DH+ use few layers (physical layer, link layer and application layer) and the DH+ layers are much less sophisticated than Ethernet layers.
NETWORK COMMUNICATIONS – Ethernet and its switch infrastructure allow maximum network throughput with many devices being able to send messages simultaneously. DH+ is more like the original version of Ethernet where only one device can talk while the rest listen.
NETWORK MASTERSHIP – Ethernet itself does not use the concept of a network master though some Ethernet application layer protocols do. With Ethernet, any device can send messages to any other device at any time. In DH+, there is a strict protocol where only the device holding the token can send messages. Devices receiving messages hold their response until the token rotates to them, at which point they issue the response to the message previously received. DH+ being many years older than Ethernet is not nearly as fast, sophisticated or flexible. However, it supported the manufacturing applications of its time very well.
TOPOLOGY – A DH+ physical network is organized as a daisy chain of DH+ devices or as a trunk line with drops. Most systems use the less complicated, daisy chain organization.
CABLING – Both the daisy chain and trunk architectures use a baseband shielded twin axial cable. The usual cable specified for Allen-Bradley systems was blue and DH+ cable came to be referred to as “blue hose” though, in principle, any twisted pair cable could be used.
TERMINATION – The “art” of installing and operating a DH+ network is in the termination resistors. Like RS-485 systems, termination resistors are typically placed at each end of the network. With DH+, there is more of an art to placing termination and it depends on the number of nodes, how the network is wired, the baud rate and other factors. Many control engineers have pulled out their hair over DH+ termination.
SIGNALING – DH+ messages are encoded on the wire using half-duplex Manchester encoded binary. Half-duplex means that only one device transmits while all other devices listen. Most, if not all, RS-485 communication systems are half-duplex including Modbus RTU and BACnet MSTP.
The signaling mechanism for DH+ is unique, using a technology known as Manchester encoding and sometimes called phase encoding. It is a mechanism for encoding each bit of data on the wire as either a low to high transition or a high to low transition. In Manchester encoded systems, there is a line transition for every bit on the wire.
An advantage to Manchester encoding is that the existence of the guaranteed transitions means that the network can be self-clocking. In a self-clocking system, a receiver can easily detect and align to the input data stream and it can identify when it is misaligned. The disadvantages of this clocking scheme are that it consumes more bandwidth than simpler encoding schemes and that it becomes problematic at high baud rates.
DATA ENCODING – Bytes on a DH+ network are classified as either data bytes or control bytes. Control bytes are the data bytes that begin and terminate a message transmission. Data bytes are the bytes between the leading control byte(s) and the trailing control byte(s).
The zero bit that is inserted when there are five consecutive 1 bits prevents an electrical distortion of bus signals.
TRANSCEIVERS – The DH+ network is a multi-drop RS-485 network where each device has a differential RS-485 transceiver and the link between devices is comprised of twisted pair cabling and termination resistors.
A transceiver control signal at each device puts the bus transceiver in one of two modes: receive or transmit. In receive mode, data bits from the bus are processed by the device. In transmit mode, data bits from the Link Layer are transmitted on the DH+ network.
Data Highway Plus (DH+) transfers messages containing Programmable Controller Command and Control (PCCC) packets from one Allen-Bradley controller to another Allen-Bradley controller. The DH+ link layer is the software that manages bus communication between the (up to) 64 devices on the DH+ link.
The DH+ link layer uses rotating mastership to manage access to the bus. Devices can only initiate communications with another node when they have the token.
In an operating DH+ network, every node is identified by a unique device number, a number from 0 to 63. The token is passed from one node to the next higher numbered node and, when there is no higher numbered node, to the lowest number node to start another sequence of rotating mastership through the network.
Tokens are passed using the token pass message. The token pass message rotates mastership from the current token holder to the next online device. The device listed in the token pass message sends an ACK byte to the current token holder to accept the token. Once the token is accepted, the new token holder can either send some number of messages to other network devices or it can just pass the token to its successor node. (Since there are no published specifications, it’s not clear how many messages a device can send or how long a device can hold the token.)
An unusual aspect of DH+ messaging is that devices only receive messages when they don’t have the token. Devices initially respond to a received message with an ACK or a NAK. The application layer response, the actual response to the message, happens later when that node gets the token. When it assumes mastership, it sends the application layer response to the original message. For example, when Node 5 gets the token, it sends a read request for some data to Node 35. Node 35 responds with a simple ACK or NAK. Later, when Node 35 gets the token, it sends the response message with the requested data to Node 5.
On each loop through the network, a single Search for Successor (SOS) message is sent for a node number not currently online. This process starts with the first node to come online. It sends an SOS for the node with a node number one higher than its current node number. If no node responds, it sends an SOS for the node two higher than its current node number. This process continues until another node responds to the SOS at which point it becomes the successor to the first node.
When a second node joins the network, it gets the token and searches for a successor with a node number one higher than its node number. This continues as new nodes are found and the search for successor messages are issued for their nodes. There is one SOS, using a node number one higher than one used in the last loop, on every loop through the network. All nodes notice the search for successor numbers and each initiates the search message when the next search node is for a node number higher than its node number but lower than the next successor. The search for new successors continues forever on each network loop and enables DH+ nodes to come online and easily become part of the network.
There is also a process for network power up. The first node to come online issues a Claim Token Offering (CTO). The CTO is issued twice and if no other node is online, that node begins the SOS process to find other nodes.
Allen-Bradley never released the specifications for DH+ except to licensed partners. Much of the timing for sending CTOs, SOSs and other messages can only be learned from analysis of a working network. Buyers of DH+ automation equipment should be aware that various devices from various manufacturers may not work perfectly on this network unlike some of the networks that have conformance tests and open, published specifications.
So far, we’ve discussed the physical and link layer but made much mention of the application layer. That’s because the application layer isn’t really part of DH+.
DH+ is not an application layer protocol. DH+ does not specify the contents of the messages it carries. The application layer instructs the receiving node to perform some action. It is like the IP protocol in Ethernet. The IP protocol moves messages from one Ethernet node to the next Ethernet node and has no information and doesn’t care what the contents of the messages are.
The DH+ application layer is the same application layer used by DF1, the serial protocol for moving messages in and out of Allen-Bradley programmable controllers. It has many names but is most often referred to as the Programmable Controller Command and Control protocol (PCCC).
PCCC is a command and reply type protocol that enables sending and receiving of messages checking diagnostic status, changing operational modes, echoing messages and many other functions. There are different variants of PCCC for different versions of Allen-Bradley PLCs, but most PCCC messages follow the structure seen in Table 1.
|Field Name||Size (bytes)||Description|
|Serial Number||4||Serial Number|
|PCCC Data||Variable||Data relevant to FNC|
Table 1 – PCCC Field Descriptions
Most of these fields are self-explanatory. The interesting ones and the ones that confuse people are the CMD and FNC fields. The CMD field specifies a generic command type while the FNC code specifying a more specific operation within that command type, illustrated in Table 1.
|Command Code||Function Code||Description|
|0x0F||0xAA||Protected typed logical write with three address fields|
|0x0F||0xA2||Protected typed logical read with three address fields|
|0x0F||0x8F||Apply Port Configuration|
|0x0F||0x11||Get edit resource|
|0x0F||0x12||Return edit resource|
Table 2 – PCCC Command and Function Codes
In addition to the PCCC messages, there are DST/SRC bytes which specify the message source and destination. These bytes are sometimes referred to as part of PCCC but in DH+ they are part of the link layer communications discussed previously.