Are you DLR Ready?

I love Engineers. I’m an Engineer. All my good friends from Engineering school are (guess what?) Engineers. My brother is an Engineer (he’s a good one – I just play one on the phone). I even have a bunch of cousins and inlaw types that are Engineers.

But gosh guys, do you always have to jump on the new thing like it’s the cure for cancer, a delicious, fat free pecan sundae or a surefire way to attract super-model type women?

I am trying not to whine but there is a lot of noise right now about DLR (Device Level Ring) and it’s starting to wear on me. Possibly because I don’t have as much patience as I did in the old days.

OK, what’s DLR? Well, it starts with a device that has two Ethernet ports. That’s right, two ports meaning it has a switch inside. That’s not hard anymore. Switch technology, in case you’ve never opened up one of your switches, has been shrunk down into a chip. Yeah, one single chip. The metal in the housing and the connectors for your switches cost tons more than the electronics does.

So, if you have a device with two RJ45 connectors and an Ethernet switch you too can join the fast growing DLR crowd.

Did I say fast growing? Well, let’s just say “growing” or maybe “nascent”, which means just coming into existence, is a better word. It’s not growing but I’ll get to that later.

DLR is pretty simple in concept. Instead of connecting your Ethernet devices to a switch, you simply daisy chain them as you did with RS485. Every DLR device has an “input” RJ45 and an “output” RJ45. The first RJ45 ties to the previous device and the second RJ45 ties to the next device. When you hook all this together it’s a ring.

So, what’s the advantages of DLR? Cost is the obvious one. If you’re a machine builder and you want to minimize your networking costs, you eliminate all your switches with DLR. You use about half the cabling and your entire wiring is simpler and easier to maintain.

Plus you have some additional diagnostics and greater uptime. If there is a cable break, the ring finds an alternate way around the loop to get the message to its destination.  [By the way , I have always wondered about this, people always use this example all over the place – Do cables break a lot?]

So, on the surface it seems like a great technology that’s going to not only improve uptime but save us Machine Builders a bunch of money.

Well, not so fast Jose!

Let’s look at the money. That switch inside every device is $5 or so, last time I looked. And I need another connector and a slightly bigger board and a few other odds and ends. Looks to me like the cost of each device is going up by $10, probably 25, 30 or more to the end user. That’s 320 additional dollars to the list price (assuming $20 per unit) for 16 Ethernet devices. I’ve eliminated the 16 port switch but raised the costs for every device on the ring. Yes, I’ve saved cabling but it’s not clear to me that this is such a great deal.

Now, the real problem with rolling this out now. There are two kinds of DLR; let’s call them fast and slow DLR.

Fast DLR is implemented in hardware. You’ll need an ASIC if you want Fast DLR. Slow DLR is implemented in software. Most people don’t even know there are two options. And they certainly have no idea which they need in their applications.

Now, the real problem is testing. Not many devices available to test with. Not sure what the status of ControlLogix’s DLR implementation is but I don’t think it’s available. Also, the ODVA doesn’t have its test apparatus and test procedures ready for testing at the time of this writing.

So, it’s pretty hard to complete a DLR implementation with no devices to test with and no way to certify your device. Chicken – egg thing is applicable.

But there is still a rush given the number of calls I’m getting. Probably it’s either Engineers who want the next new thing or managers/marketers writing specs without knowing much about the technology.

Maybe they’re just early to the party. And there will be a party. DLR will assume its place in the Industrial Ethernet world and lots of Machine Builders will probably support it.

But that day isn’t here yet.


  1. Tony Jones says

    Hi John,
    The new Electronic Marshalling (CHARM) I/O for Emerson’s ‘S’ series DeltaV uses DLR. The base for the redundant I/O card (CIOC) has redundant ethernet ports that can be daisy chained together. The bases are available with copper or fibre connection.
    I wasnt aware there were two kinds of DLR (fast and slow) and I will try to find out which one has been implemented.
    Thanks for the update.

  2. Kuba Ober says

    On-device Ethernet switches can’t be merely categorized as hardware- or software-based. That’s meaningless as there are some very fast CPUs out there (like XMOS XS-1 or the multitude of task-specific CPUs inside of Hilscher’s NetX chips) that can do all the ethernet network processing, including realtime industrial protocols like IEEE-1588, Sercos III or EtherCAT in software. Yes, you’ve heard it right.

    What matters then is whether the switch is store-and-forward or fixed-latency. Store and forward is the standard fare of enterprise switches, and is what you get in those “switch-on-a-chip” solutions. The packet needs to be received in its entirety before anything starts coming out of the other port. This is slow already. Whether you classify the packet using the FPGA or a router stack in the OS kernel is then of secondary concern, since the “store” part is irreversible: no matter how fast your FPGA’s packet classifier or the OS kernel, the packet must be received before anything gets done. Well, perhaps some work on the packet can start before the packet is fully received, but no transmission gets started before the packet ends.

    Fixed latency switching is what you have, conceptually, in Sercos devices (both II and III), as well as EtherCAT and similar protocols that modify the packet as it passes through. There is a fixed time between a bit coming on the input port and the bit leaving the output port. When all you have is three ports to deal with, the delay can be kept around 500ns or so. That makes long device chains feasible while still maintaining sane end-to-end latency in spite of many nodes being on the line.

    As for verification of the devices: you’ll need some hardware in the loop, if for nothing else than to timestamp the packets on all the ports so that you know how fast the switch is. One solution to that is Beckhoff’s ET2000 multport probe, but there must be others I’m sure. If you’re in a pinch, you could make the equivalent of a two port ET2000 using an XMOS XC-3 development board. If you’re quick on the uptake, you could have it running over a weekend. That probably sounds like an ad for XMOS, but I’m just a *very* happy user of their kit.

Leave a Reply

Your email address will not be published. Required fields are marked *