They’re old and gray. Hunched over. Slowly shuffling along. Nothing like the hot new guys that we’ve come to know over the last 10 years or more. But these are the guys we cut our teeth on. The guys we’ve argued with, cussed at and if not loved, at least have come to honor and respect.

Of course I’m talking about DH+ and RIO. The old stalwarts of Allen-Bradley industrial automation. Maybe they’re not as old as the ageless Modbus but they sure have the wrinkles and weather-beaten skin befitting their age.

For you young pups, I’ll stop now and go through a bit of history. Long ago, when PLCs were a new thing there were lots of discussions and theories about how to network sensors and actuators. Those were the days of proprietary systems. Customers put a line in and they bought all Allen-Bradley or all TI, or all Westinghouse or all Modicon (long before Groupe Schneider).

Everything used a proprietary and “secret” interface. Only close partners could be part of the system.

And it was great. Really great. FOR THE VENDORS THAT IS. Not so much for the customers. The customers just sucked it up, bent over and paid to play with the system they were given. Very little choice in those days. But, to be fair, there wasn’t near as much automation as there is today.

In those days, it was a lot of switches, some early Motor Controls, a few valves and some photoeyes. Not a lot to network together.

This is the environment where AB introduced DH+ and RIO and literally created industrial networking!

DH+ is a peer network with a floating master. The bus master floats between different nodes. When a node get mastership it can send messages.

The physical layer is proprietary with differential signaling. That means that bits are passed by the difference in potential between the two signal lines. You can do a network with a lot of nodes and up to 10,000 feet long. Each drop can be up to 100 feet so you can cover a huge area with it. At its heart, it uses PCCC, the Programmable Control language that all AB PLCs understand.

Remote IO is similar to DH+ but with a more defined purpose. RIO simply moves I/O points from remote racks to a central processor. DH+ is more of a generic interface than RIO.

So, why do we need to bother with these antiques? Can’t we just forget them and go on? No, the answer is an EMPHATIC NO.

There are hundreds and hundreds if not thousands of miles of DH+ and RIO networks around the US [yes, primarily the US since that is where AB is the strongest and where the longest history of networking devices is]. These networks aren’t going to be ripped out just because of the gray hair and pearl handled, coffee stained cane. People need to keep these things running.

Just yesterday I talked to a major manufacturer that wanted to know how they could keep support for their DH+ and RIO products well into the conceivable future. Why, because they have lots and lots of existing applications that they don’t want to rip out. And it’s that way all over the place.

So, if you’re a vendor of sensors and actuators it might be tempting to dismiss these old guys but don’t be so quick. There are sales out there. And since a lot of your competitors won’t support this stuff you can get higher than normal margins for it.

It’s a good place to be!

STOP THE PRESSES! Major advancement in automation technology is upon us…Rockwellis introducing a Micrologix processor with USB.

Can you believe it? Isn’t it everything you and I have been waiting for with “baited” (whatever that is) breath?

Why next week we might hear that apples are coming to market with another shade of red; TVs with digital tuning and cars with radial tires.

I mean, really, I don’t mind USB. I just don’t think it has much place on the factory floor. Let me explain.

1.       It has no legs – 16feet is about it. You have to be really close to the equipment to get connected. Why do I want to walk halfway across my plant to plug my laptop into this processor? Why can’t I access it from my desk.

2.       There are a number of different standards. One side is, of course, the controller side and the other is the adapter. You have to make sure that you’re the end that your customer needs you to be. And there’s a bunch of different standards. USB 1.0, 2.0 and 3.0. Some of them incompatible depending on the implementation. It’s really not as simple as the Marketing guy saying “we need to support USB” and you doing it.

3.       And then there are power considerations. These USB devices will want power and you have to support it. How much? Well, it varies…

Lots of ways to screw up with USB. That’s one of the reasons I don’t like it.

But I understand why they are doing it. PCs don’t have serial ports anymore. In the effort to get the price of a PC to less than a candy bar, they’ve eliminated the serial port and most everything else. I’m sure over the last 5 years they have had a host of customers asking for USB. And now, they’ve “quickly” responded.

TOO LITTLE. TOO LATE.

The trend now is to smart phones, IPADs and a host of other wireless devices. They should have just skipped right past USB and made their controllers work seamlessly with these devices. You can bet that in the bowels of Mayfield Heights they are right now thinking about writing specifications for wireless access to those controllers. [I am sure I’m being a bit unfair here – it takes a long time to get anything done in any huge corporation]

OK, here’s what really frosts my cookies about this. Lots and lots of their customers are going to be confused by this. They’re going to think that RA has just introduced some magic way to access PLCs. That the USB port is the magic bullet for uploading and downloading programs and doing data table read and writes.

Believe me it won’t be. It’s going to be the same as a serial port.

On the serial ports, you need a DF/1 protocol to send PCCC messages. And with those messages you can read or write any data item in the controller.

Now those PCCC messages are going to have to be sent over USB. So all the programs that used a serial port before, can switch to a USB port, remove the DF/1 (I’m betting) and send the same messages as they sent before.

This is going to be just another minor improvement in their product lines. Nothing like a major advancement that I’m hearing from some customers.

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.

STOP THE KILLING!   IT MUST STOP AND STOP NOW!

Once again I get another product with over the top functionality, complexity for complexities sake and with references to web pages that our crowded with information and hard to read.

OK, I know where a lot of this comes from and it’s not always from you product developers. A lot of times it’s from the Marketing folks up on the 14^th floor or on the other side of the building/country/planet. As soon as one potential customer says “hey, it would be neat to have…” they add a new requirement to the product plan. And, of course, that adds time. Time to development, testing, training and everything else.

I know that this is a real difficult in your big organizations where there are tons of marketers supposedly studying competitor offerings, surveying customers and analyzing sales trends. They have “evidence” to support all these requirements. We know what that evidence really is.

I’ve been there. When I was at Allen-Bradley (before it became Rockwell) our Engineering team either did projects where we had the vaguest possible requirements or we had very detailed, almost nonsensical requirements.

The ones with the vaguest possible requirements became pyramids of functionality. We piled every possible cool technology we could think of into the product. We increased its size, cost and complexity until it became virtually unsalable in the market.

Perversely, I worked on one of those projects and then left the company. After leaving I started supporting that product and writing software for it and made hundreds of thousands of dollars because of that complexity pyramid. I’m not smart enough to think that sort of thing or deceitful enough – so don’t go thinking I planned that out ahead of time.

Even in our little shop this monster rears its ugly head. And when it does I have to be the big, burly mean policeman that protects our customers from these sorts of disasters. When I see it I say STOP. It’s one of the few times where I throw my weight around.

Most everybody in our office just does what needs to be done. There’s no job descriptions and God knows I don’t do much “management”. Things just sort of get done. People see what has to be done and do it.

But about 6 weeks ago I looked at some web screens for one of our products and I was shocked by  the complexity and chaos on the screen. Nothing was organized in the way that I thought would make sense to a user. Lots of extra steps. Lots of nonsense.

And it’s my fault. I didn’t get involved early enough. I let the Engineers go. And they were kind of pissed when I pulled the reins back, told them that this sucked and we were going to start over. There are probably still some hard feelings.

But you’ll be the judge. Within a week or two we are going to start shipping the first products with the new user interface and a bunch of additional features that many of you have been asking for. I’ve done the best I could to make it simple, easy to use but still provide you with the additional stuff you’ve said you needed.

The first products out of the gate our converter to move Modbus RTU registers to BACnet and our converter to move Modbus registers to MicroLogix, PLC5s and SLCs.

I’m looking forward to finding out what you think.

I’m just amazed. Completely amazed. Last time I looked it’s 2011. Soon to be 2012.

I don’t like to talk about my age much – who does – but I actually started programming on an IBM mainframe with Fortran in 1976. To do that you had to know JCL (Job Control Language). JCL was the wrapper that enclosed your Fortran card deck. Yes, I said CARD DECK.

For you young’uns in the audience you sat down at a key punch machine and entered your Fortran program line by line and each line was punched out on a IBM punched card.

(This sounds so silly as I write it) You then carried that stack of cards over to a window into the computer room and handed your cards to the “computer operator” who sometime later, depending how much he liked you, submitted them into the machine.

An hour or so later you found your results at the output window. Many, many times you had a single letter mistyped so you replaced that card and did it all again. 1 minute update – another 2 hour wait for results. What nonsense but in those days it was prestigious to say you programmed a computer.

A few years later, as a first year Electrical Engineering student I got to enter MACHINE CODE into a DEC PDP something by toggling each line of machine code into the machine. I won’t tell you what debugging that code was like.

Which brings me to Ladder Logic. Not sure how I feel about Ladder. I understand it. I understand why it is the way it is. I understand its advantages. All that’s a given.

I just don’t understand why the tools for programming industrial automation devices aren’t better than they are. If programming computers has gone from my entering machine code line by line to Windows Web Services why aren’t automation tools also that much better?

Today again we had two calls on our 435NBX product. That’s the one that moves ASCII Barcodes into PLCs. The ladder for these products is really, really simple. In the PLC there is a string that you designate to receive the ASCII barcode, scale data or other text. That string always has a length.

If the length is zero, we move the barcode into the string and the length becomes non-zero. The Ladder guy detects a non-zero length, processes the barcode and sets the length back to zero. We then send the next one.

This is really simple. It requires about two lines of ladder but we have a number of customers that are sometimes challenged by even this minor amount of programming.

Now I know that there are other things going on here. One is that the most junior guy on the project is assigned to this part of the project. It’s not glamorous or fun so he gets it. So, we are talking to the most inexperience guy.

But still, why can’t the people who build these kinds of controllers and the software that programs them make them easier to use? It just amazes me over and over again.

It’s 2011. Almost 2012. When can we get better tools?

I remember when I had this roommate. Let’s call him Mark. Great guy. One of the best in the world. A Quaker as a matter of fact. Only Quaker I’ve ever known. But there were one or two things that just bugged the hell out of me. It’s that way in every relationship.

Here’s an interesting question. What if you had a double? A complete copy of yourself and you lived with yourself as a roommate. Would you enjoy living with you? Or would you get irritated with yourself?

Well, now I have had a relationship with Modbus for a number of years. I love Modbus. Not ashamed to admit it. I’ve known Modbus for going on 20 years now and have profited greatly from the relationship. But just like all relationships there are some rough spots. Some things I just don’t like.

The real big hassle with Modbus is the data types. It is very unpleasant accessing data that is typed using 16-bit unsigned registers. If you’re not familiar with what I’m talking about, here’s some examples. If  you have a 32-bit speed value, that has to be in two Modbus registers. The order of the bytes in Modbus is clear, it’s MSB (Most Significant Byte) first. But what’s the order for the words. Is it the low word first or the high word first? I don’t know it could be either.

Now with 64-bit values, it gets even worse. 4 times worse. And that’s just analog.

What about discretes? It’s one thing if they are using coils to represent discretes but a lot of developers like to pack 16 discretes into a single Modbus Integer. So which is bit zero? The first bit or the last? Probably the first.

It’s a mess. It’s hurt my relationship with Modbus but we’re still together and going to be together for the foreseeable future. I just don’t want to end it over these little aggravations. I’ve just decided to live with it.

I’ve decided to add typing to all our Modbus device converter gateways. So instead of just saying that you have 4 registers at address 40100 (40 thousand – another irritant), you would say I have two 32 bit integers or two floats or one 64-bit float or four integers or whatever.

That actually buys us a lot. Using our new auto mapping feature we can then automatically map those 32-bit analog values right to BACnet in our Modbus Master BacNET gateway. It will also work well in our ControlLogix to Modbus gateway and the gateway we have to move Modbus Slaves to an EtherNet/IP Scanner.

So I’ve found a way to deal with some of the irritations and I’m still in the relationship. Really don’t see a way to get out. It still works even though it gets tiresome and stale. Even though I do have relationships with Profinet IO, DeviceNet, EtherNet/IP and others, Modbus will always be first with me.

A lot of these blogs are about my faults. Probably because there are so many. It’s human nature. We all worry more about the things we don’t do well than praising ourselves for what we do well.

Over the years I have noticed that I have become less and less detailed oriented. In the old days I seemed to know everything there was to know about our business. I knew all the purchase orders, all the invoices, all the customers, even most of the code.

Now I don’t seem to have a handle on much of anything unless I make a concerted effort to learn (relearn?) it.

That’s probably true of all of us. There is a lot more to keep a handle on now. I now carry around a phone that is more sophisticated with more functionality than the IBM mainframe at my first job. Learning everything about that phone would take a week. Then there is my IPAD, laptop, various websites and a zillion other things. Even my Blu-ray has a myriad of complexity that I haven’t started to understand.

So, I don’t blame customers that call us and ask for help figuring out solutions for their factory or business automation systems. I have complete sympathy. We know they are running around in overload mode too. [I remember when I was a kid watching “Lost in Space”. The robot would get overloaded and flash all his lights, waive his arms and then shut down. He’s lucky – he could shutdown.]

A lot of what people ask about is the Rockwell MicroLogix line. There are a lot of processors and we have a lot of products that can add functionality to that line. They just aren’t sure what they need or if the product they pick out can help them with their current problem.

Let’s review the basics of the offerings from Rockwell:

Our engineers have added a lot of functionality to this processor family. More than I can talk about here but here’s a few of our most popular products.

Move ASCII Data to MicroLogix – Barcodes, Scale, RFID and other ASCII data can be easily captured and put into a Logix data table.

Move Modbus Data into MicroLogix – Scan a series of Modbus RTU devices and exchange those registers with file I/O in the MicroLogix

Move BACnet Data into MicroLogix – Exchange BACnet Client data with files in your MicroLogix PLC.

These are only some of the options for you and your MicroLogix PLCs. See the entire list of MicroLogix PLC Gateways here.

It’s tough keeping track of all this with everything else on your mind. I know I can’t do it. Hopefully this will help and anytime you have a question, just give us a call. We’ll be glad to help.

I started this out by talking about all my faults. The one fault I don’t have is being stingy with the time of our applications and development engineers so give them a call.

We live in a world of acronyms. They’re all around us and that will never change.

My brother in-law that cardiologist has his own. NASA, an organization with an acronym for its name has as many of them as anybody. Policemen, firemen, priest and yes, even strippers use acronyms.

There’s a three letter one I want to focus on today. That one is DF/1. It’s interesting that when I pulled out my old DF/1 manual from sometime in the 80’s and there is no definition of DF/1. Every AB manual has a section called “Abbreviations”. The DF/1 manual abbreviation section doesn’t list DF/1. I can only presume it means “Data File” but it maybe it means “Darn Fun 1”. Possibly the engineers like it so much they presumed there would be a Darn Fun 2 or 3 or more.

DF/1 is really misunderstood. Most people think it is a higher level data protocol. That somehow it has some commands that move mysteriously move data in and out of a PLC. No, that’s not true. Not true at all.

DF/1 is simply a link layer protocol that moves a packet from point A to point B. One of the two points is an Allen-Bradley PLC.

In many ways, it is identical to the IP protocol on the internet. The IP protocol just moves packets, usually TCP packets, from a source to a destination. Nothing fancy, it’s a truck that moves things from one place to the other.

So, what does it move? What is this mysterious packet that DF/1 is moving in and out of PLCs?

Well that would be the PCCC messages. Ah, yes, another acronym. This one means Programmable Controller Command and Control messages. This is a message that indicates a read or a write of some File (remember old PLCs from AB use Files as their internal data structure) in the PLC. So, just like IP, DF/1 is moving packets that contain another protocol that actually contains actionable messages.

A couple of other things about this guy that you should know. Most of the ports on the PLC that are used for DF/1 communications are RS232 so you have to be pretty close (within 50 feet) to get this to work without problems. It was used a lot in the old days for sending new programs into the PLC.

And lastly, as with everything else there are two types of DF/1 communications. There’s Full Duplex which means that the two (and only two) devices are sending data at the same time. That’s of course more efficient than Half Duplex in which you have multiple devices on a RS485 link and one device talks while all the other listen.

Later this year we’ll have a suite of Df/1 product available. Until then you can keep checking the Gateway Product Catalog page for more information on all our products.

I read the other day that there is a Russian dog trainer that doesn’t really train dogs. He actually trains their owners.

His philosophy is that people aren’t communicating with the dogs in ways that the dog understands. Say for example, you keep yelling “NO” at a dog. The dog starts to think that his name is NO.

Instead of using English, this trainer teaches the owners to talk to their pets in the same way that a mother dog would. Low growls when they do something wrong. High pitched squeals to indicate positive affirmations.

I thought this was really fascinating. It got me thinking about how simple things usually have a lot of complexity beneath the surface that just isn’t recognized.

Take Modbus for example. We have a lot of Modbus products. We have a product that moves Modbus to BACnet IP. Another that converts Modbus RTU data to Ethernet/IP. Another that moves ASCII Barcode data into Modbus registers. All really cool products but there is more complexity beneath the surface than you would think.

Take the Modbus to ASCII product. Simple? Well, not really. How do you want these series of bytes to look in Modbus registers. Here’s a couple of ways to store the letters “RTA” in 2 (or 3)  Modbus registers:

The reason we have this particular problem is that a long time ago, Motorola and Intel didn’t agree on what is called “Endian” behavior in the first microprocessors. If I remember right, Motorola wanted Big Endian (High half first) and the other wanted Little Endian (Low half first). So numbers like 1234 hexadecimal are either stored 34 in the first byte of memory or 12 in the first byte of memory. And it’s made everything more difficult ever since.

It gets worse as the numbers gets larger. Double words, values like 12345678 hexadecimal now have an Endian issue and a word order issue. Two words of memory could look like [5678 1234] or [7856 3412] or [1234 5678] or [3412 7856]. And for 64 bit numbers we have even more combinations, 16 of them in fact.

So, how do we sort this all out? Well, that’s why in our new gateway products we have automatic swapping of digits and we make you tell us what the data types are. If we know for example that you have double words, we can make sure we get the data to your destination with all the bytes in the right place.

Modbus is the worst for all this because everything is 16-bit unsigned integers or simple bit representation. Bits aren’t as bit a problem with the 16-bit unsigned are. They can be ASCII, bytes, integers, double integers, floats or other weird types.

So, just like teaching the dog owners to talk in ways that the dogs can understand we’re hoping that our new product will all you to talk to us in ways that we can understand. And move your data where you need it, when you need it and HOW you need it.

USB is one of the best things to ever happen to computing. It standardized how we connect all sorts of things to PCs. Before USB there was ALWAYS trouble getting two devices to communicate.

In the bad old days we had DCE devices and DTE devices. For those of you who don’t know the difference between those two was which pin was the transmit pin and which was the receive pin. In one case, and I can’t remember which is which, Pin 2 was transmit and Pin 3 was receive. On the other one it was reversed.

What a nightmare that was. We had 9 pin connectors, 25 pin connectors and the DCE/DTE to fight through. Gender changers. Null modem cables. 25 pin to 9 pin converters. I am starting to shake just thinking about it.

Well, USB has changed all that. Anything targeted to connect to a PC has been USB for a long while now. And USB is really great technology. Here’s 5 things about USB that you might find interesting:

1.       USB is a master slave system with one master and lots and lots of possible slaves (127).

2.       There are three layers to USB Host Controller software. The first reads and writes registers in the USB controller. The second implements the USB protocol. The third provides the device control for the target device

3.       A device that is connected over USB is assigned a COM port within the Windows OS and looks to the application just like one of the old serial ports from the bad old days.

4.       The USB spec includes an Audio Class in which a USB device looks like a sound card. You can get a MIDI interface and an audio interface to a sound manager using USB.

5.       There are products that connect USB to WiFi and to Ethernet.

So what about USB and embedded systems? Well, of course, the first issue is that USB is mostly, if not exclusively, Windows based. And we use PCs on the factory floor but usually for specialized controllers or hefty HMIs. USB can connect devices to these PCs but only if the data doesn’t need to go to a PLC or DCS first.

And that’s the problem that a customer of mine had last week. He was bringing a barcode into a canned software app and needed to move that barcode to both the canned app on the PC and into the PLC for processing. And that was just too much of a stretch for USB technology. There isn’t any device I know of that can be both a USB Host controller (to get the barcode) and multiple USB devices (so it could be sent to two places).

The other problem is that it’s darn hard to connect a USB device to a PLC. But RTA is working on it. Within the next month or so RTA will have a product to move USB data right into the data table of a PLC and other products that move USB data onto various industrial networks.

Hopefully that will make a great technology even better and bring more flexibility and productive to the plant floor. And that’s exactly what we try to do here.

John