Just completed an analysis of the new EDS changes that have been made to RsLogix 5000. Here’s what I found:

Quick Summary

Despite the marketing hype as to the value of EDS values prior to 2012 there was no advantage to constructing EDS files with complete product data. Few, if any, tools were able to use these kinds of EDS files in the way they were intended.

Now with V20 of RsLogix 5000 this has all changed. This White Paper describes the changes and how device vendors can take advantage of these changes.

EDS File Overview

Electronic Data Sheets (EDS) are simply ASCII files that describe how a device can be used on an EtherNet/IP network. It describes the objects, attributes and services available in the device.

At the minimum, an EDS file conveys the identity information required for a network tool to recognize the device. For EtherNet/IP Scanners, the EDS File conveys information on the EtherNet/IP Adapters I/O messages. It details the specifics of the Input Message produced by the EtherNet/IP Adapter and the Output message consumed by the Adapter.

The amount of information stored in an EDS file varies from device to device. Some manufacturers store the minimum amount of information in the EDS file while other devices store all the details of every object and attribute in the device.

EDS files are sometimes shipped with a device in some media format like a CD or made available on the device manufacturers website. Some devices with extended data storage contain the EDS file internally within the device.

EDS File Structure

File Section – Administers the EDS file. Sometimes the URL keyword provides a link to a website where the latest version of the EDS can be found.

Device Section – Provides keying information that matches the EDS to a particular revision of a device. The first four attributes of the Identity Object (Object #1) are used by network tools to verify that this EDS file (Vendor, Model,…etc) matches the information found in the device. The network tool will not connect to a device unless all four Identity Object Parameters match.

Some people mistakenly believe that the Major and Minor Revision numbers are included in this match but that is not true.

The ODVA recommends that the icon for the device be specified in the EDS so that users can have a graphical way of distinguishing devices.

Device Classification Section – Classifies the EDS for an EtherNet/IP network. The Device Classification Section is required for all EtherNet/IP devices.

Connection Manager Section – Identifies the CIP connections that are available in the device. This section indicates to the EtherNet/IP Scanner the Triggers and Transports available in the device. If a device supports multiple connections then every connection must be detailed in this section.

Only connections that are specified in this section can be used in an EDS-based configuration tool.

Assembly, Params and ParamClass section – These sections are filled in as needed. For values that are limited to a limited to a defined set of values, Enumeration can be used to specify those values. Value ranges can be specified here also for Configurable parameters.

Capacity Section – This section indicates the number of connections available in the device and the connection speeds

Port Section – This section describes the Ethernet port. It is only applicable to devices that perform CIP routing. It is unnecessary for devices containing a single CIP port.

Configuration Data

EDS Files also support definition of the Configuration block. The Configuration data block is simply a series of data words that are downloaded to device on power up or reset. These blocks provide one-time initialization of an EtherNet/IP device.

EDS File Checker

The ODVA (Open Device Vendor Association) provides a tool, called the EDS Checker, to validate the configuration of EDS Files. That tool is available on the ODVA website, www.odva.org.

Changes in V20 of RsLogix 5000

After many years, V20 of Rockwell’s RsLogix 5000 programming tool added support for EDS Files. Here’s a list of the changes:

Configuration Support

This version of RsLogix provides the capability for an end user to configure a device using the Enumeration, Ranges and other limitations imposed on a configuration parameter as specified in the EDS file.

Prior to this version, end users typically had to use a vendor tool, a web page, a built in display or some other mechanism to configure a device. Now configuration of all devices can be done from within one, identical tool.

Configuration Data Block Support

Configuration data blocks can now also be defined by RsLogix 500 if it is exposed as a meaningful data structure in the EDS File.

Module Discovery

You can now browse for devices on the network with supported EDS files and add them into the I/O scan list with a single button press. You no longer need to know the catalog number, slot number or network address to add a device to the I/O tree.

What’s still Missing

One disappointment. We were disappointed to learn that, unlike the configuration data, the EtherNet/IP Servers Input and Output Assemblies are still defined as a block of data and not exposed in the EDS file in a meaningful way.

My place in the Industrial Automation industry is being a sort-of Networking Guru. Talking to you about Modbus TCP, EtherNet/IP, Profinet IO and all the rest. Telling you about our Industrial Gateway product line, our Building Automation Gateway products and all the rest.

I do these things even though I’m not the bits and bytes kind of guy like a Kevin Knake from HMS (the guys brilliant). I’m not a Systems guy like a Carl Henning at the PI (Profinet Interface Organization). It’s really true that Carl knows more about complex automation systems than I’ll ever know. Carl’s way smarter than me too.

But I know my tiny, tiny piece of the world pretty well. And moreover I’m able, I think, to explain things in a way that is easy to understand. Because I’m not the bits and bytes guy or the systems guy I can take what I learn from them and bring it to you guys in a way that’s hopefully interesting and educational. That’s what I try to do and I hit the mark on it more often than I miss.

Well in last month’s newsletter I strayed pretty far from that. Almost as far as you can get. After visiting Matt Kuzel in Ann Arbor, MI, I got to thinking about our Fathers. He lost his recently. I lost mine a few years ago. I wrote an opening to the newsletter called “Two Fathers”.

The response has been exceptional. It’s struck a nerve with many of our readers.

I’ve had guys write me about their dad, how much they miss him and what he meant to him. I’ve had congratulations for being sensitive to the feelings of another guy who recently lost his Dad. And I’ve had a couple of instances where guys called their Fathers after reading the newsletter to tell them how much they love them and thank them for all they’ve done.

Those last one brought some tears to my eyes.

This article made me think some about the future. And in my case, what my step-grandchildren that I love dearly are going to remember about me and my life. So even though I’ve managed to touch a few lives here, I’ve been touched more. I’ve changed more. I’m more aware.

And for that I’m very thankful!

John

PS – If you aren’t getting our newsletter you can get the printed copy by calling Jessica on 262-439-499 or using the contacts button on the RTA Home page. For the email version, just click RTA Newsletter.

For your convenience, I’m posting the article here:

Two Fathers….

I had a chance recently to spend some time with a really great guy and friend of mine in Ann Arbor, Michigan, Matt Kuzel. If you don’t know Matt, you should. He’s the owner of Huron Net Works. He a great engineer and knows the CAN physical layer about as well as anyone.  He’s especially skilled at DeviceNet development (www.huronnet.com) and can probably quote from the DeviceNet specification by memory.

I’ve know Matt, well it seems like forever. I especially remember being with him on September 11, 2001. ODVA had a DeviceNet event at the GM Tech Center starting at 8AM that morning. Matt was speaking when the first tower fell. People had pagers then and one by one, everyone’s pager was going off while Matt spoke. That day’s, of course, a life experience that we all share.

I was sad to learn that Matt had recently lost his Father. Cancer took Matt’s dad. Old age took mine. It was painful and difficult as it was for me. But amid all that emotion there was joy and rememberances that united us.

Both our Fathers, while coming from totally different backgrounds, lived rich full lives. My dad was born on a rural Italian Tobacco farm during World War 1. Things were pretty primitive. No plumbing. No electricity. No newspaper. Little connection with the world outside his town and even seeing other townspeople was pretty unusual. Dad spent a lot of his youth sleeping in the fields protecting the sheep herd from predators.

 But in 1934, with less than $25, the clothes on his back and 2 years of elementary school education dad set out for America. It was the last day he would see his parents for over 32 years. Leaving the farm took him to America; a wrecking company job gathering bricks from the destroyed buildings for 16 cents an hour, a World War II Army service in the Pacific; an eventual mechanics job at Miller High Life and a family life with a wife and two sons.

Unlike my dad, Matt’s dad was an educated man. A high school education. An Electrical Engineering degree. Service in World War II in the European Theatre. He lived his life as an entrepreneur, an avid skater and inventor. He had any number of innovations including the plans for a portable tool storage/recharger station for home work benches. That last one is especially poignant as he conceived of it during one of his last rounds of chemo.

Matt’s dad was organized. Really Organized. A list maker all his life he instilled that life trait onto Matt. Matt too makes a lot of lists. He also need to keep everything organized. You’ll know this to be true if you ever visit Huron Net Works which is just down the road from ODVA headquarters in Ann Arbor. Everything is in its place. I always wonder how anyone can work in a place that organized.

It’s tough to lose a parent especially guys like these two. I, at least, got a good story out of it. The morning of the funeral there was a lot to do. I had to run a number of errands, chauffeur people here and there and get lots of things organized. The one thing I didn’t do was to put gas in the car (That probably would have been on one of Matt’s lists). You probably have an idea where this is heading.

Well after the funeral mass, I get in my car with my mother which is parked just behind the hearse. My brother and his four kids are behind us as are about 70 cars. Yes, 70 cars. Dad was an engaging, gregarious, lovable guy and had many, many friends. A number of my cousins referred to him as their second father.

So, I get in the car, look down and the needle isn’t on the E. If fact, it’s not touching the E at all. IT’S ABOUT A ¼” BELOW THE E!!! Oh my God. What am I going to do?

The one thing I’m not going to do is to tell my Mother. No way. No how. Not going to say anything about it. I can’t tell her that we might just run out of gas during her husband’s funeral procession. And I didn’t think I could lead the procession through a gas station.

All I could do was pray.

And pray I did. I prayed for each and every block. I thanked God for every intersection, every sign, every McDonalds, Burger King, Wendys. “Please God, thank you for that block. Can I have another one?”. I prayed like my life depended on it.

And it worked (Well, at least I am going to say it worked).

We finally arrived at the cemetery. And I am the most relieved, happiest, smiling guy every to arrive at that cemetery. Probably any cemetery. I somehow dodged that bullet but the image of 70 some cars stopped behind me as the hearse goes on haunts me to this day.

I now often laugh about that day but it will always be the day I buried my Father as Matt buried his more recently. But we’ll never bury their memories. Though they were totally different kinds of people; one gregarious with an exception love for people and one more intellectual with a passion for gadgets and solving problems.

What they shared with us is more important than their differences. A love of God. A love of life. An encompassing love for their families and friends. Matt said it best in an email to me, “And what is great is that these are the things that we got to inherit…And better still, we get to pass them on”

One of the hats I wear here at RTA is the “I’ve got a weird question – can you help me” hat. I get all the strange and oddball application questions that Drew doesn’t want to answer.

One of the ones that I see a lot is how do I get data from “here” into my PC application where “here” can be a PLC, a Modbus flow meter, a CANopen pump or pretty much anything else. The guy usually wants to simply archive some data or get it into Excel and create a graph. [The more advanced ones want to do Automation using one of the cool Automation tool but it’s still the same general case]

There’s lots of ways to go on this and I have my preference as you will see.

In the bad old days we did this using the serial port. We would have to write a driver and then build a CSV file (comma delimited file) and then open the CSV file with Excel. That won’t fly anymore for lots of reasons but mostly because most PCs no longer have serial ports. Few people want to take the time to write software like that. It’s not fun and it’s a maintenance nightmare.

But if we did go that route now would we use the USB port or Ethernet port? If writing code is an option, you can code a driver to operate over either of these ports or buy one from somebody like us. Your code could then integrate into the Microsoft architecture and pass live data to programs like Excel or Word.

With the USB port you would probably buy one of those USB to serial converters for about $50 or so and your code would send and receive to the device over a serial link. The USB port would look like a serial port to your code. If your device is Ethernet based, you would do much the same thing only you would send and receive over a Sockets interface using the TCP/IP stack.

There are several ways to link your program to Excel once you are sending and receiving messages to your device. I am not an expert on Windows interprocess communication so I’ll leave that part of it to others. Heavens knows there are enough books and web pages dedicated to that topic.

But there is a best way. It’s been the best way for about 10 years now. That’s to use an OPC Server. An OPC server contains the application layer protocol interface for an external device and an interface to DCOM; one of Microsoft’s interprocess communication standards.

All Microsoft products have a DCOM interface and it’s easy to point an entry in a MS product like Excel at some piece of data in the OPC Server and have it show up in your excel spreadsheet. Really simple. Just a matter of getting the syntax of the link correct.

Now the downside of the OPC Server is that it’s going to cost you anywhere from $300 to $1200 every time you want to setup a new PC with this data capture mechanism. If you’re shipping a lot of these it could add up to real money.

It’s in these high volumes where the cost of doing your own interface which accomplishes all the same function as an off-the-shelf OPC server is more cost effective. Your best bet in these cases is to buy a royalty free Modbus TCP Client, a Royalty Free Modbus RTU Master or something more sophisticated. Check with me if you’re not sure what you need.

It’s old and of no use. Nobody wants it around anymore. No, that’s not what they’re saying about me around the office. [At least I hope not].

I’m talking about serial communication. Remember that? RS232? RS485? If you’re more than 30 years old you remember PCs with RS232 serial ports. You had to get the lines connected right. Remember the days of null modem cables? Connect the Tx to the Rx and the Rx to the Tx. Sometimes you had to connect the CTS to the DTR. You were never quite sure. You played with the baud rate, parity and wiring for about 2 days until you found the right combination.

The best tool for that nonsense was a breakout box. That’s a box where you can easily rewire serial interfaces. I remember all my serial breakout boxes fondly. I spent many a night with my breakout boxes.

Recently I did a couple of YouTube video on serial communications. In the first video I talked about mechanics of serial communications; what a UART is, how bytes become bits on the wire, how bits are framed into bytes and how they moved along the wire. In the second video I took it a little further and discussed the differences between RS232 and RS485.

These ideas for these videos came from an automation engineer in Egypt, Mustafa Salah. Mustafa always asks a lot of good questions. As with many people around the world Mustafa still deals with lots of serial communications and the problems implementing and troubleshooting those kinds of communications in automation systems.

Mustafa reviewed the two videos and sent a few good questions; questions that need to be discussed so I am going to take some time here to address his questions.

Question: RS-485 Noise suppression. I understand that the RS-485 is differential but how can this affects the noise suppression?

Answer: The key is that RS-485 is differential. A bit is detected by the voltage difference between the two RS-485 lines. If that potential is 5 volts, as it is in typical RS-485 systems, and there is a 10 volt spike due to some machinery, both lines are affected by the noise. The key idea is that the difference in potential is still 5 volts. Relative to a ground line, they may have been at 5 volts and zero volts prior to the spike. During the spike they are at 15 volts and 10 volts; but still with a 5 volt differential that can be properly recognized by the receiver. That is why RS485 is much more noise immune than the ground referenced RS232.

Question: How do you do RS-485 echo suppression?

Answer: One of the electrical characteristics of RS-485 is that bit signals are reflected when they reach the last node of a multi-node network. The reflected signals screws up the next bit signal transmitted by the transmitter and it becomes impossible to communicate. To eliminate echo suppression it is important to have a 120 ohm terminating resistor at both ends of the RS-485 network between the two signal lines. That 120 ohm resistor dissipates the signal and prevents the echoing. Sometimes software enables that resistor.

Question: How do I connect multiple RS-485 networks together (I mean in case I have more than 1 network)?

Answer:  The short answer is that you probably don’t. An RS-485 network is a half duplex network. That means that there is one and only one transmitting device at a time. There are two ways these networks can operate. In one mode, they have a Master device that transmits and the other devices listen and respond when spoken to by the Master. That’s the way that Modbus works. If you have a network like this you aren’t going to connect it to another network because you’d then have two masters and there isn’t a way for the two masters to take turns talking.

The other way these networks can work is by some sort of time sharing arrangement where there is a token passing arrangement where each the node with the token is the temporary master. This is pretty uncommon because there have to be ways to detect nodes that have gone offline, inserting of new nodes and lots more. DH485, the Rockwell network that SLC processors used for a long time uses this kind of token passing.

Question: What serial topologies are used?

Answer:  There are really just two; point-to-point and multi-drop. RS232 uses point-to-point. The Tx of the first device goes to the Rx of the second device. The Tx of the second device goes to the Rx of the first device. In Rs485 it is a little more complicated but not much. The two wires of RS485 sometimes labeled A and B or A and A’ or whatever are just multi-dropped from one node to the next. The terminology is not standard here but the high side line is wired from one node to the next to the next. The same is done for the low side line. The key idea here is that internally, the node that transmits turns off its transmitter when the last bit goes out and immediately turns it receiver on so that get the response message.

I’ve run across other ways of wiring RS485, like wheel and spoke, and they can work but you should avoid them. They’ll work in limited circumstances depending on the number of nodes connected, the kind of wiring you use and lots of other things. You’re asking for trouble if you don’t use multidrop with RS485.

For those of us that think, breathe and talk Ethernet all day long it is sometimes hard to remember that serial communications is alive and well. And a lot of the new people coming on board are very, very unfamiliar with it.

If you’ve brought any high school or even college students around the plant lately they will be stunned to know that there was life before Ethernet. Serial, what’s that? There was a 9 pin connector on laptops and PCs? What was that for? What is it? Why would anyone use serial?

The “Serial” in serial communications refers to the fact that bits are put on the wire one after another. Now that’s hardly a revelation unless you live in the packet world of Ethernet. But even in that world bits are put on a wire one after another after another.

What we are really referring to when we talk about serial communications is sending bits on a low speed wire where groups of bits are framed into bytes and specific bit patterns are used to identify the beginning and end of those bytes.

Serial communication also refers to the electrical interface used to propagate those bits across the wire. The most common way to do that is with RS232, RS422 or RS485 electrical interfaces. These interfaces govern the voltage levels and wiring for communications between nodes.

RS232 is commonly used for point-to-point wiring; one node directly connected to another node. And more to the point, each transmitter connected to the receiver on the other node. RS232 typically uses  + or -12VDC signals biased to a ground reference to send data from one node to another.

RS232 is ideal for small packets of short distance communication between two nodes where the speed of transmission isn’t of great importance. The disadvantages of serial communications are its lack of noise immunity and short distance. Because signals are referenced to a ground, any noise can distort the electrical signals and cause short term communication errors.

Ground loops are another problem with serial communications. If the ground potential between two nodes are different, current will flow from one node to another. We see this problem with our module that sends ASCII data into PLCs on occasion. The ground loops cause current to flow through the receiver and since these receivers aren’t designed for this type of current load and they burn out.

RS485 and RS422 are used to avoid some of the problems of RS232. Both RS485 and RS422 use differential signaling. Differential signaling means that the difference in potential between two lines is used to identify bits on the wire. The sender either creates a potential or eliminates the voltage potential. In one case the receiver detects a one and the other a zero. RS485 uses two lines to move data from a sender to a receiver while RS422 uses four lines.

There are two advantages of RS485 and RS422 are greater noise immunity and support for multiple nodes. Because a receiver only measures the potential between two lines, noise induces identical electrical pulses on both lines but doesn’t change the potential between the two lines. Essentially the noise is canceled out.

The ability to have multiple nodes is one of the reasons why RS485 and RS422 are used in serial communications networks like Modbus RTU. These networks rely on a single Master device sending data to a single slave and that slave responding.

RS485 is ideal for that. (RS422 less so since it requires more lines). A Modbus RTU Master sends data on the two data lines while all Modbus RTU Slave devices listen. The Modbus RTU Slave recognizing itself as the destination of the message now becomes the sender and sends the response. The Modbus RTU Master becomes a listener after finishing transmission to get the response from the Modbus RTU Slave. Transmissions like this are known as Half Duplex communications.

So even if you’re thinking, breathing and talking Ethernet all day long, remember two things. One, there’s an awful lot of serial communications around and it isn’t going away soon and two; all communications including Ethernet is at its heart serial.

One of the things that I kind of enjoy doing is traipsing around the world.

I’m writing this from Italy but a week or so ago I was in Germany. Hit the Embedded World Show 2012. It’s an annual event for the people doing embedded work. Lots of technology. Lots. Most of it pretty high end. Saw a few things that you’d might like to know about.

3S – Ran into some of my old friends from 3S again. They are just growing like crazy. If you don’t know about these, they’re the ones that make CoDeSys. To simplify it, it a logic engine that you can embed in just about anything. I’ve been out to their facility and it was impressive. Now I’ve heard that they’ve added a 2^nd and 3^rd building. They’re the absolute leaders in IEC 61131-3.

NXP – These guys had a lot of interesting stuff in their booth. A washing machine that does all sorts of calculations and energy savings and what not. Looks to me that a lot of these household equipment vendors are trying to chuck the front panels off their machines and have everybody use their cell phones to drive them. That would save them a ton of money. Don’t know if they can do it. In their booth a found the AoA stuff. That’s Droid Add-on-Accessory technology. It’s a way of bridging comms from a Droid application to another network. Interesting – didn’t know about that.

IXXAT – These guys are a competitor of ours in some regards but they have exactly what I need for a project I am thinking about. They’ve got a dual Ethernet Profinet IO board that is perfect for a number of my applications. Problem is that with a lot of these German companies, the technology is fabulous but the price is out there too.

USB – I searched hard for USB stuff but couldn’t find much at all in the low end or even middle range equipment. All the high end boards and PC replacement boards have it but that’s about it. Seems odd to me that none of the low level stuff is using USB. It’s pretty much like CAN except that you have to have a Master and between the Master code set and all the power considerations it gets a little messy. The slave side is a pasta (piece of cake for you guys in the US).

Lantronix – Really seem to have good wireless solutions for OEM applications. I am much more impressed with them than Digi though I visited with both. Digi is just so unfocused. They have a little of everything you might need. Their real focus appears to be the high end, cloud data collection stuff.

NABTO – I had to stop here twice cause I couldn’t understand. These guys are focusing on two things. One is moving the HTML code out of low level sensors so that really dumb sensor devices can have slick web interfaces and providing a layer of security on the factory floor for these devices. Don’t know how they are going to succeed at it. You need a plug in on your browser (where the real HTML code is kept). You need a base station for the security in the middle of the whole thing. Lots wrong with what they are doing but no time here to go into it.

Extreme DB Fusion – Here was the coolest product I found. Hope it works like they say. They are focusing on providing database functionality for small, embedded devices. It is such a cool idea. Guess what 90% of their applications are? Configuration data! That’s such a big headache and not having to write, test and maintain that code is really a God send. I’m going to test their stuff and see how well it works.

Next I stopped at WizNet (Korean company) – It’s a really simple idea. They’ve started with their own TCP/IP stack and embedded it in a chip. Then they added a Phy. They added a Micro. Went form 2in1 to 3in1 to 4in1. It has its place in low level systems but don’t think I would trust it in a highly reliable, mission critical application. But for something down and dirty like a sensor, it could be the right tool.

Bunch of other cool stuff. Ate a bunch of German Sausage. Drank a lot of dark beer. Oogled the German girls. Pretty much my standard trip to Nurnberg.

In Italy now – Have more for you in a few days.

John

All of you out there use switches. And a lot of you, I know you’re out there, use unmanaged ones because “Gee John”, they’re awful cheap.

But disclaimer time first. This is another place where I just don’t have a dog in the hunt. Don’t care what switch you use. Knock your brains out. Get one of those really expensive, high end, gold plated, can never fail switches. Or get yourself the 99₵ ones that come with wriggle’s gum. [Alright for those of you that like to email me about every little thing, Wrigley’s ISN’T including switches with packs of gum – YET].

But in the immortal words of Carl Henning, junior deputy sheriff of Profinet International, either “get a managed switch” or regret is later.

I heard this today and guess what, Carl is right. Carl is right about most things but on this he is even more right.

What’s a Managed and an Unmanaged switch? An unmanaged switch is like your dog. Dogs are pretty easy to care for. They need water, food and a little exercise. Simple and uncomplicated. Just like I like it.

An unmanaged switch doesn’t have any configuration. There isn’t any options. There isn’t any additional data available. It is a basic switch; look at an incoming packet, see where the packet is headed and ship it out the port that has the destination.

A managed switch is more like your girlfriend. Lots of options. Lots of possibilities. The only difference – besides the obvious physical ones – is that that your girlfriend’s options and configuration changes on a regular basis.

A managed switch has options and a mechanism to allow you to get to a menu where you can configure the switch to your liking. Some weird ones have a serial interface (and they’re in the Ethernet business) and a command line interface. Others use a web server which I personally like.

You can do all sorts of cool things with a managed switch. You can setup VPNs (Virtual Private Networks), set priorities on different ports, setup ranges…etc. The list is really endless.

The diagnostic features are the ones that you will really like. Two in particular are my favorite.

The first is port mirroring. With mirroring you can tell the switch to dump all the traffic on one port on another port. Why would you want to do that? Simple, when you are having trouble with something and want to diagnose network traffic, there is no other way to listen to the traffic. I mean, on what port are you going to put the analyzer?

The second is diagnostics. Different switches keep all sorts of valuable statistics on your network traffic. This becomes really important when you are trying to optimize your traffic.

There’s a bunch of other reasons but if you are using our ASCII to Logix product, Modbus TCP to BACnet or any of our other Ethernet products please do yourself a favor; ignore all the weird things going on in the world for a few moments and run out and get yourself a Managed Switch.

You’ll be happier and so will your vendors.

It’s time for me to eat a little crow I’m sorry to say. I eat lots of things. Weird things. Spicy things. Things I’d be embarrassed to tell you about.

I’ve eaten chicken from street vendors in Thailand. I’ve eaten the strangest Crepes you can imagine in France. I’ve eaten everything I could get my hands on in Milan. And, of course, I’ve eaten every type of Italian seafood; octopus, oysters, scallops, Scungilli and smelts (yes - with the heads).

But today I have to eat crow. Not a lot of it but some.

If you’ve read any of these rants, I have been complaining about EDS files for what now, 10 years, 15 years…maybe more. Ever since DeviceNet came out. I was in the 2^nd boot camp AB had in Detroit (1995) when they introduced DeviceNet and I think that I complained about EDS (Electronic Data Sheet) files about 1 hour into the bootcamp.

The issue has always been that EDS files are a nice idea but of no value to anyone. None. No one. Just valueless.

You had to have one to pass conformance so we would doctor up an EDS file with a header and a few other minor attributes and send it in for conformance. What a waste.

Well, I’m eating crow today because that’s all changed. Yup. It’s a new ball game.

Version 20 of RsLogix 5000 will be able to read and use your EDS files for DeviceNet and EtherNet/IP applications. Yes, RA finally did it. After telling us for years (and I mean lots of years) that RsLogix would support EDS files. The day is finally here. [No help for you Modbus guys by the way]

Effective with that version, your customers can use RsLogix 5000 to configure your devices, define data types for your I/O blocks, automatically scale incoming data and more. All the hype that ODVA has been throwing out to users that don’t understand the practicalities of EDS files is being converted to reality.

Hallelujah!

This looks like it’s going to make the end users job a lot easier. Before I go too far let me add a disclaimer here.

End Users could really benefit with this enhancement. If your a PLC guy that’s reading in scale data over an EtherNet/IP I/O connection you’ll be able to build a data structure, a UDT (user defined type) that describes your data. You’ll be able to scale data, configure what I/O Assembly you want to use and do a host of things that vendors used to make work arounds to do. FINALLY!

You may even be able to setup the RPI (packet interval) using the EDS.

Stay tuned. I have my ace EtherNet/IP guru working on this. We’ll soon publish a white paper describing what is does and what it doesn’t do and what you might need to your EDS files to make them compatible with RsLogix 5000 [Send me an email through the CONTACT US link to get on the list for the white paper].

I am just amazed! WOW! What’s next? If RA can finally implement EDS files in RsLogix there’s no telling what might happen. In 9^th grade Debbie D promised me she’d go out with me if I did her Algebra homework [Debbie was a gorgeous 9^th grader]. She never did but could that come true now?

Wait here. I have to run get my cell phone and check for messages…

Our new Lonworks product is, by definition, pretty different than anything else that we’ve ever attempted. I hate to say it but it is more complex because the Lonworks network is in some ways more complex than most of the other networks we support.

Everyone knows I hate complexity and crusade against it. I’m going to try to tell you today how we’ve tried to simplify this beast but first a little background.

Lon is different than most everything we do because the data on the network is predefined (and type limited). There are about 100 SNVTs (Standard Network Variable Types). These guys are the predefined types of variables that can exist on the network. They are the only pieces of data a device can send or receive over the network.

For example, there is a variable type called continuous level for metering applications. A device can send or receive variable(s) of that particular type. What’s cool about that is that since the type is well known there is little confusion about the byte order, data range and all the other variable attributes. It’s all fixed.

Now, if a device is monitoring 3 levels, it can make 3 variables available on the network of type Continuous Level. One, three or thirty Lon devices can receive those levels whenever they are published by the monitoring device.

The Lon Integration tool, LonMaker, provides the system integrator with the ability to connect input variables in one device to output variables in another device. That process is called a network binding.

LonMaker is the enforcer on the network. It makes sure that you don’t blindly bind a temperature to a pressure.

Once the binding happens, any changes to an output variable in the node originating the data are reflected in the input variable(s) bound to that output variable. So, if a Level X1 variable (Continuous Level type) is published with a level of 30, that value is passed to the nodes with input variables bound to the Level X1 variable. And that might for example, trigger one of the devices receiving that data to open a valve or start a heating process or whatever.

So, how does our gateway going to handle the Lon universe of hundreds of variables of up to 100 different types?

Again, we’ve tried to make it easy. We’ve come up with a small set of configurations that support different types of applications. For example, we example we have a temperature group. The temperature group has 22 input variables and 22 output variables of various types that you might use in an application.

Here’s the list of our basic configurations with the number and types of SNVTs in that configuration. The SNVT number is in parenthesis:

Our goal is to make this easy on you to move data between a Lon device and some other network. So, please understand that this list is only our starting point. If you or another one of our customers needs ten input temperatures for an application we will change the configuration.

We’ll either expand the default configuration (we’ll never reduce it and obsolete a working application) or we’ll create a configuration just for your application.

So, for you Lon devotees out there, do these configurations make sense? Is this something that you can use? I’ll be looking forward to your feedback.

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!