And I studied the DeviceNet spec. And I studied the DeviceNet spec some more. Probably for 3 months in a row I camped out there every morning. It got to the point where I could tell someone what page to find the Duplicate Mac State Machine or the I/O State Transition Table. Instead of knowing something really fun or widely applicable I became an expert in one of the most arcane and smallest niche technologies in the world.

This all came back to me last week when Richard in far away Australia asked me about the difference between UCMM enabled and Group 2 Only DeviceNet devices. Wow, “Haven’t thought about that for a while!” I said.

And it’s true. It’s something that we don’t often deal with anymore. When you build EtherNet/IP devices, you just support unconnected and connected messaging. It’s no big deal.

But it is a big deal for DeviceNet. DeviceNet is designed to support for small, cheap, slow, under-resourced kinds of devices. How sophisticated do you want your photo eye or proximity switch or valve? Not very. Small, cheap and slow works perfectly well in a lot of applications.

Well, not so fast. It’s hard to be small, cheap and slow if you have to process all the messages running around a 500K baud network. Slow is a huge problem when you have a network of 64 devices all of them transmitting every 5msecs or so. That’s a whole ton of messages coming into your communication port every few milliseconds.

To get around this problem, the DeviceNet architects created a connection type that allows the CAN Message Filters to eliminate all the messages coming from or going to any other DeviceNet node. When these filters are set properly, a device only sees those messages that are pertinent to it.

Devices that only receive these specific messages are labeled as Group 2 Only Server devices. These devices only support connected messaging and something called the Predefined Master/Slave Connection set.

That was a mouthful. Let’s take it in pieces. Connected messaging. That’s messaging where two devices agree to open a connection with the expectation of transferring some number of messages over some period of time.

The opposite of that is Unconnected Messaging. Unconnected Messaging is messaging in which there is no expectation of sending any more than a single request. Now, that request may be to open a connected connection but even that message is still a single request.

The software component that manages this connection is known as the Unconnected Message Manager (UCMM). It accepts messages to open and close connections, processes them and returns responses as required.

DeviceNet devices are either UCMM capable or UCMM incapable. UCMM capable devices are devices that can support the UCMM and can receive requests to open and close fully capable connections. UCMM incapable devices are devices that don’t support the UCMM but instead support something called the Predefined Master/Slave Connection set.

The Predefined Master/Slave Connection set (why is there no acronym for this?) specifies a group of messages that lost cost, very low resourced, slow devices can use to support DeviceNet. This connection set describes a minimum set of messages that can be used for all the basic functionality of a DeviceNet device; allocation of connections, duplicate MacID processing, and Explicit and I/O data transfer.

The messages of the Predefined Connection set are organized such that a low level CAN device can use it’s filter to filter out all messages except the ones that it really needs to process. Messages to open or close connections on other devices, other device I/O messages or UCMM messages are all blocked from the Group 2 Only Server processor. And that’s the beauty of this feature. Low level, low cost, slow processors can be used to implement these devices because they won’t have to process thousands and thousands of messages that are not pertinent to its operation.

UCMM capable devices on the other hand must provide that kind of processing. Every single message from every device on the network might be processed, at least on a limited basis, in a UCMM capable device [The DeviceNet software actually has ultimate control of the CAN filters and can choose to only close the filters to only receive a set of known messages from certain devices.]

UCMM devices are generally higher resourced, higher performance kind of devices. These devices are capable of supporting not only the Predefined Connection set but an almost limitless number of other types of connections with resources and bandwidth as the ultimate limiting factors.

UCMM devices can support multiple, simultaneous connections. UCMM devices can open up peer connections with other UCMM devices. There are a lot of possibilities that a UCMM makes available.

But here’s a word to the wise – none of that means much. Unless you are building a device where two of your own devices need to connect and transfer data there is not much other use for UCMM enabled devices. This is mostly because DeviceNet doesn’t define the application layer data transfer over these connections. So, you’ll never be able to just open a connection with some other DeviceNet device and transfer data.

The ONLY place I have ever seen this used effectively is in a “poor man’s” universal barcode scanner. In this application, four scanners surround an object each with an open connected connection to the other three scanners. First one to read a barcode sends a message to the three others telling them to stop scanning. Each barcode reader is a UCMM capable device and only, repeat only, functions in this way because it’s a single vendor’s equipment with that vendor defining the application layer message that shuts off scanning.

My advice – do it fast and simple, use the Predefined Master/Slave Connection set. There’s more to this but I have to go. I’m kind of hungry for a big cup of coffe and a Crossan’wich…

A lot of the time they are taking a group of serial RS485 Modbus RTU devices moving that data to some higher level system using networks like EtherNet/IP, DeviceNet, Modbus TCP, BACnet IP or even PROFIBUS.

Why Modbus RTU? There are lots of good reasons. Mostly because there are literally hundreds of thousands of Modbus RTU devices in applications in a whole host of industries. You’ll have to remember that this electrical specification (RS485) and protocol have been around for about 40 some years. 40 years! Devices can really proliferate in all that time.

[By the way – I once met a guy that worked for Modicon in Boston in the 70s. He claimed to be part of the group that invented it. I don’t know if I believe him. He seemed kind of young. If you are someone who really was part of this effort or know something about it, contact me.]

And there is no reason to believe that the number of devices won’t keep growing. Modbus is still the lowest cost, easiest to implement most adaptable communication option you can put on your device. As long as you have a UART and a small bit of Flash you can have Modbus RTU. So, why not?

But once you’re on Modbus RTU how do you move that data over to DeviceNet, CANopen, EtherNet/IP, Modbus TCP, BACnet/IP or some of these other protocols?

There are a couple of architectural issues to consider in these kinds of applications. One of them is do you want each Modbus device to show up on the other network as its own entity? For example, you could build a box that takes up to 32 Modbus devices and makes a connection for each of those devices on the other network.

Siemens Profinet IO gateways do this. You get a TCP/IP connection with a different IP address for each device on the other side of the Profinet IO gateway.

In most cases, this is pretty impractical. It eats up bandwidth, processor resources and connections. That’s not very attractive. Instead, all of the read registers are grouped together, all the write registers are grouped together and the Modbus devices end up looking like a single device with lots of data.

The only time this isn’t done is with one of my favorite networks, Modbus TCP. With Modbus TCP you can use the UID field to talk to a specific device on the other side of the gateway. From the Ethernet side you connect to a single IP address but specify a value in the UID field that targets that command to a specific device on the Modbus RTU side. That works very well for lot of gateways.

If you’re building one of these gateway devices, use the Contact US form and send me a message. I’ve got a few other ideas for you.

John

Some automation people seem to think that certification is a “magic bullet”. If my device passes ODVA certification testing and I have that little certificate on my wall, my product is functionally sound. I won’t have any field problems.

That couldn’t be more wrong.

The DeviceNet certification process or the EtherNet/IP certification process is really just about the networking component of your product. It has nothing to do with your I/O, your logic or the overall functionality of your product.

Certification simply indicates that your product seems to play nice on the network as far as the kinds of messages you send out under specific circumstances. It doesn’t imply any kind of functional performance.

In fact the ODVA Certification process doesn’t look at your I/O data. It simply checks that your unit is sending the right number of bytes and that it appropriately handles network abnormalities. It makes sure that your device closes connections on timeouts, properly handles missing fragments of fragmented messages, resends messages when required, properly opens and closes connections. There are literally hundreds and hundreds of such things that an EtherNet/IP or DeviceNet device must do. The day long certification test tries most of them but not all.

Your application code in your product can be absolutely crap and you can still pass certification. If you have a valve device and half the time you don’t open the valve when you receive a DeviceNet I/O bit to open, you’ll still pass certification. It doesn’t matter to the test what you do or don’t do with the data you receive from the network.

YOU STILL NEED TO TEST YOUR DEVICE. Certification should be only a small part of your overall test strategy. Even if you get a daughtercard or software or some other network component from a reputable vendor you should still plan on a multi part test strategy. The vendor will certify their part but it will be up to you to validate your application logic in conjunction with the networking component.

This kind of testing will usually mean setting up a Rockwell PLC and thoroughly exercising your code just like it will be used by your customer. You should know up front that this won’t be inexpensive. The Rockwell PLC and software you need to drive it are very expensive. But that’s the price of being in the game.

If you have any specific certification questions, give me a call. We can do a pre-certification test on your product and shepherd it through the ODVA Lab for you. That’s usually a lot better than paying hundreds of dollars an hour to work with the ODVA Lab guys on a sophisticated network problem that you may not really understand.

This is especially true of people that like working with Microchip parts. Microchip has some very nice, small, right-featured, easy-to-use parts that you can incorporate into a design. I know. We’ve used them.

I think that there are a couple of problems with this approach. One, it just limits you so much down the road. Every single time I’ve opted for the small, cheap micro it has come to bite me you-know-where later on.

The story is always the same. We make X and the there is a customer or a series of customers that like X and use it. It’s not massive business but good, consistent business.

Some other customer finds out about X and says can you do Y. Now Y is NEVER less featured and slower with a smaller I/O count. It’s always more and we have to re-spin the board and now have multiple revisions to contend with and we don’t get any scale of manufacturing on it.

The biggest constraint with these small parts is in the communications. Generally, you start out with Modbus RTU. Simple, small little RS485 protocol. But then, a customer wants Z and that needs DeviceNet or Modbus TCP or EtherNet/IP if the processor has an Ethernet MAC.

More trouble. Do we have the Flash and RAM for those things? Probably. We’ve been able to squeeze our software into a lot of these small parts. But you always lose something when you do that. You lose the ability to do multiple connections. You may not be able to support all the features that your customer needs.

In the need, it just makes sense to spend a little more up front, get the Flash and RAM that can carry you through a number of years of new product iterations. Now that might mean just 512K/64K but it sure doesn’t mean 32K/4K. With just 512K of Flash and 64K of RAM you can implement any of the Ethernet protocols and have lots of room for web pages.

It’s really the long term more prudent option.

A key distinction that you have to make in your implementation is what level of reliability and ruggedness does your device and/or application require? You need to know how your device will be used, what kind of throughput is required, where it will be used…etc. The following is a quick summary of the ODVA standard but is not adequate for product development.

If your device simply exists in a clean, lab environment, or enclosed cabinet with no requirements for high speed operation (>100mb) a Commercial implementation will be adequate. In this type of implementation, you can use off-the-shelf components, support 10mbps and 100mbps and use a standard, non-sealed RJ45 or Fiber connector. Requirements for these kinds of devices can be found in the ANSI 802.3 and TIA 568 standard.

Devices meeting these commercial standards are often found in industrial environments. They usually perform well if the physical environment is not subject to temperature, vibration, shock, noise and other environmental extremes. The ODVA Physical Layer specification recognizes devices meeting commercial implementation standards as acceptable for use within the guidelines of the EtherNet/IP specification. However, products meeting these commercial standards are not eligible for the industrial conformance checkmark. These products are eligible only for the commercial conformance checkmark.

The ODVA specification goes to great pains to warn EtherNet/IP developers away from Commercial implementations. They prefer that developers follow the industrial standards and protect devices to the maximum against shock, vibration and other environmental extremes. They go to great pains in the specification to warn that commercial components and a commercial implementation can “degrade system performance” however the vast majority of EtherNet/IP device developers have followed the commercial implementation without problems.

Product developers, with requirements that exceed the 802.3 or 568 standards, should follow the Industrial implementation standard. Volume 2, Chapter 8 of the EtherNet/IP Physical Layer standard defines this standard. The standard defines the vibration, shock, humidity, temperature and EMI requirements for an Industrial Implementation.

These standards are all based on published standards. Vibration is based on IEC 60068-2-6. EMI is based on the IEC 61000-6 and IEC 61000-4. Temperature and Humidity standards are based on the IEC 60068-2 standard.

The ODVA Physical Layer specification also details the kinds of cabling that meet the Commercial and Industrial standards. The types of shielded and unshielded cables, the typical impedance, the wire color codes and the acceptable losses are all detailed by this standard. Sealed and unsealed RJ45 housings are both acceptable under the Industrial standard. Codings for the sealed housings are specified in the standard.

For more information on Physical Layer specifications you should contact the ODVA at its Ann Arbor, Michigan office. They can provide the most complete details on how to meet the Industrial standard.

Data highway is pretty ancient technology. It was designed and built by Allen-Bradley in the late 70s. I think it was the first network ever used by an Allen-Bradley Programmable Controller and maybe any Programmable Controller. There was a lot of this stuff deployed in the 80s and 90s. Hundreds of thousands of nodes. Big numbers.

It’s still around in lots of factories around the world. If you do any kind of integration it’s likely that you will need to either get into a DH+ network or replace parts of one. So, let’s dive into what exactly DH+ is.

ELECTRICAL INTERFACE – DH+ uses Transformer Coupled Differential Signals meaning that stations do not have to be at the same ground potential (That’s a really good thing). Two wires are used to carry data and that data is represented by voltage differences between the two wires; known as differential signaling. Because the data is encoded differentially, noise that is common to both wires is ignored. Signal Level for these differential signals is typically 8-12 volts peak to peak. The Baud Rate is 57.6 kilobaud with Half Duplex transmission (when one node transmits, all other nodes go into receive mode)

TOPOLOGY – DH+ uses trunk lines with drops. That means that there is a main cable and at points along this trunk there is a small drop line that attaches a device to the DH+ network.

MEDIA – DH+ used Baseband Shielded Twin Axle Cable. In this case baseband simply means that all devices on the media are using a single frequency.

MEDIA ACCESS – DH+ uses a proprietary token passing protocol. In this protocol, every device knows its successor, its successor’s successor and its predecessor. It receives a message that indicates that it has the token. When it has the token it can send one or more messages to other devices on the network. After sending the message it passes the token to its successor. If the successor disappears it passes the token to its successor’s successor. Failing that it has to find another successor node. This protocol is referred to as a link layer protocol as it manages and maintains the network link. New nodes join the network when current nodes find them during periodic searches for additional successors.

PACKET – What’s in the DH+ packet. That’s another old protocol, PCCC (Programmable Controller Control and Command Language). Those are also proprietary messages that PLCs use to access the data tables of other PLCs.

We have plans to create a DH+ Device Converter. If you’d like to influence how the thing works, hit the contact button from any one of our product pages and let me know what you think.

John

You guys are really unbelievable. You usually work right at the job site under the scrutiny of the customer. You start up a machine and if it barfs right there, you’re customer, his boss and possibly his CEO are either going to see it or hear about it. You’ve got immense pressure to complete the project early and under budget. You’ve got competitive pressures. How in the world do you bid a machine build and figure out how long it will take to build all the pieces but program it and get it running at speed? It’s really beyond me.

And then there are the technical issues. You have so much to deal with. You have I/O hardware – there’s new stuff out all the time. There are lots of different PLCs – Rockwell is bringing out a new Micrologix this year. Do you use that guy or not? It’s going to be cheaper but will it be ready? Will it work? If you don’t use it, will the guy bidding against you use it to lower his bid?

The business has really changed over the years and will change more in the coming years. You now have a huge networking and IT component to your jobs. Everything is more complex. Everything must be connected. And a lot of connections have to be made to PCs and back end systems like MRP and ERM stuff.

I don’t know how you do it or I know I could never do it. What I can do is to provide you with the tools to make your job a little easier. That means stuff like our EtherNet/IP No Royalty Tag Client source code. You can get our EtherNet/IP software for Linux or Windows . It gives you an easy way to move tags in and out of CLX PLCs. You can reduce costs on your PC controllers by eliminating RSLinx and OPC. Instead of ongoing costs, you can pay as you go until it’s paid for and then you get that interface for free. Click on ELIMINATE RSLINX to get more information.

Or you might want to try our system integrator gateway solutions. We specialize in the right products that make your life easier and get the job done faster. Here’s the story from an old Rockwell guy:

“As part of my duties at Rockwell I had on occasion to connect ASCII device to our Programmable Controllers. And I DREADED IT! I usually had to spend 8 hours or more to get something to work right. Well, one day I bought a 435NBA module from RTA and assumed the same would apply. I cleared my schedule for the whole day. I cleared my desk so I would have room for manuals and tools and access to web pages with information. I got my coffee and sat down at 8AM prepared for a long hard day. AT 8:10AM I WAS DONE! I couldn’t believe it. It was the most incredibly simply device I have ever used. WOW! Thank you RTA.”

That’s the kind of story I hear all the time. You have a tough job and RTA is hear to make your life a little easier.

If you have any specific questions, hit the contact us button from one of our web pages and I’ll get back to you.

There are also OPC Servers. OPC  uses native Microsoft technology to move data between applications. With that technology, one application can consume data generated by another application. If for example, you have a database collecting user names that accessed your stockroom. With this technology you could automatically transfer today’s access list to a Microsoft Word document. It’s relatively easy to get data from one MS application to another MS application.

But what about those of us that want to use Linux. How can a Linux application read and write data in a ControlLogix or CompactLogix? Or even access some of the Legacy PLCs like PLC5E or SLCs? Rockwell provides nothing for that.

In that case, you have to take a look at our Linux EtherNet/IP Tag Client software. This is ANSI C software that runs as a task in your Linux application. Your App simply opens a connection to the PLC, fills in a structure with the Tags (variable identification in the PLC) you want to read (or write) and sends that structure to the Tag Client Software. You get a callback when the operation is complete.

The beauty of this software is two fold. One, since it is ANSI C, it compiles using any IDE. And two, the API is so simple, it is really easy to use. Most customers get everything running in an hour or two.

One of the things that many callers seem to want to take advantage of right now is CoDeSys. They all have the same basic reason that I had when I started with CoDeSys. There really is too much programming to do and not enough programmers around with the right training to do it all.

That’s a trend that we are going to continue to see in the future. There is going to be much less custom, grind it out, cowboy C code development and more high level structured programming. And yes, that applies to small microprocessor systems too.

You see this trend in both Industrial and Building Automation. In fact, it is more prevalent in Buildings. That’s probably because the kinds of functions needed in buildings are more standard. All buildings have dampers. All buildings have air handlers, elevators, plumbing systems. There are temperature sensors, fire systems, air exchangers and the rest. The ways that all those things interact is pretty standard. People like Tridium came up with JACE and have been off to the races ever since.

Industrial is kind of a different story. Every machine is pretty customized. It’s a pretty different process to make diapers than it is to make detergent or car fenders. The kinds of sensors and actuators used in each process are different. The way that these kinds of automation devices communicate is different. There are all those networks to deal with; EtherNet/IP, DeviceNet, Profibus, Modbus TCP and all the rest.

The big problem that I hear a lot about is getting more done, faster, in a more standard way. I reading a book now called the Checklist Manifesto. You might want to pick it up. It’s written by a doctor who tried to discover how to standardize the process of medical care. It’s very interesting. Medical care is ruled by THE physician responsible for the patient. This is equivalent to the Master Builder of old; the ones that built the Vatican, Notre Dame, the Louve and the US Capitol. This doctor discovers that checklists are what ensure that very complicated and complex projects are done with the right technology, in the right way at the right time. A very interesting and good read.

To get more done in a faster more standard way in our industry requires tools like CoDeSys. It eliminates all that background noise that gets in the way of making the automation device do what you want it to do when you want it done.

We’re going to see more and more of IEC 61131-3 tools like CoDeSys in the future. And that’s a good thing!

I’ve been working lately with a Machine Builder/Integrator in the HVAC business. There’s a couple of interesting points about this application.

One is that I constantly forget that many, many of the people that use our products are not Ethernet experts. It’s just another technology that they have to deal with. This morning I explained the different between a hub, switch and router again. We all have to remember, no matter what our business is, that our business is very intimate to us but very foreign to our customers. They don’t know the terminology, systems and operation of that slice of the world.

Another is that point above about the number of ways to get things done. These people are doing a HVAC Tent System that has 14 80-Ton Compressors each with a bunch of drives, soft starters, HVAC Controllers and such. They need to connect this stuff up to the main Tent controller. I designed a network of Modbus TCP subnets that make sense for this system but I know that there is probably another 5 or 10 ways to do it. I’m probably not doing it the cheapest way but this will work and it will be reliable.

One interesting aspect of this system is that these systems will be located all over the world and they want to monitor them from Michigan. This raises the issue I’ve been talking about for a long time; the need for remote monitoring. Remote monitoring of data and archiving operational data is becoming more and more important.

I spoke with another customer just a few days ago that has a machine with PLC controls that really is a stand-alone unit. They need to record data but can’t count on having an Ethernet network nearby. They don’t need if often enough or critical enough to go cellular or satellite so they are going to use some of our standard product with an 8 megabyte SD card. That’s something that you’ll see on our website in a few weeks.

Well, gotta go. The weeds out front have gotten to the point where the neighbors are picketing the house.