I have a bunch of customers using our software to build gateways devices.

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

I need, really need, to discuss DeviceNet and EtherNet/IP certification once again.

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.

There is a natural tendency to go small and cheap when you pick a microprocessor. After all, why spend $3.50 on the micro if you can only spend $2.75. Over 100, 1000 or 10000 units that starts to add up.

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.

I really admire you system integrator guys. There are guys that do more complex work, like electrical designers. There are guys that have to work with huge emotional swings like outside sales guys.  There are guys that have to work under pressure; guys like me that run small businesses, but there aren’t many people that see it all like System Integrators.

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.

It’s the hot and sticky part of summer here in the upper Midwest. Lots of high temps, high humidity and finally, baseball games, picnics and boating. When you live in a cold climate you take advantage of summers, you absorb summers, and you revel in the heat.

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 write this in the car on the way to Illinois. Meeting with a Motion Control Distributor today.

I’ve brought Drew Baryenbruch, our marketing director, along with me on this trip. Drew is real smart about marketing industrial products but more than that he doesn’t mind driving. And I HATE to drive. It’s just such a waste of time, monotonous and frustrating. But I have to watch Drew pretty closely – he’s already taken one wrong turn.

The Motion guys were seeing today brought me an interesting application. They have some CANopen devices that are, of course, out of Europe. As is typical with European manufacturers they build in one of two protocols; Profibus DP or CANopen.

Profibus DP is a very impressive network. High speed, reliable, easy to use. But expensive. VERY expensive. Because it runs at 12Meg, it needs a low level ASIC and that ASIC isn’t cheap. The connectors are specially designed (no power on the bus) and very costly also. The biggest factor in using Profibus is that it’s easy to connect a Profibus DP device to a Siemens S7 PLC. If the application has an S7 – Profibus is usually the best choice.

CANopen is the other heavily used European sensor bus protocol. Were Profibus is almost exclusively used in Manufacturing applications, CANopen is used more in non-industrial and medical applications. You’ll find tons of CANopen in hospitals and medical devices. There are patient beds that use CANopen to send signals to all the motors around a bed.

CANopen is what our distributor friend here has. I had our super smart engineering staff come up with a board for them that adapts that CANopen connection on their device to Modbus TCP, EtherNet/IP and DeviceNet. That makes the device much more saleable in the US.

This is a pretty common occurrence for us. When we build  EtherNet/IP Circuit boards, DeviceNet Circuit boards and Modbus TCP circuit boards we customize the device for the target network. When you interrogate the device you get all the identify information that is specific to their company and the objects that are specific to their application. You can’t get that kind of device representation with an off-the-shelf interface module like Anybus.

Another common request for us is to meet some sort of hard, footprint requirement. For example, Aquasensors needed a very tiny footprint DeviceNet board. And as far as I know the board pictured here is the smallest DeviceNet board ever made.

Picture of aquasensor board with quarter

AS I always say: “RTA is the Burger King” of industrial automation development. You get it your way…guaranteed.

Johnr

The previous article in this series discussed the characteristics of the physical part of the radio including the frequencies, data rates, power and bandwidth of the radio. Now we are going to address the organization of the information on the “wire” or air in this case.

This part of 802.15.4, and really any other networking technology, is termed Media Access and the low level software that implements the Media Access is called the MAC or Media Access Controller. A MAC is responsible for both organizing the data received from the application into low level data frames, synchronizing access to the medium, checking for errors and a myriad of other things.

One of the tasks of an 802.15.4 MAC is to present the device to the network as one of the two types of devices defined by the 15.4 specification; a Full function Device (FFD) or a Reduced Function Device (RFD).

Reduced Function Nodes have very limited capabilities. RFDs are single purpose end device nodes like a temperature sensor or a light switch. These devices are often battery powered as they need only communicate intermittently. Reduced function Nodes can only communicate with a single Full function Nodes (FFD). FFD nodes can have device capabilities like RFDs but unlike RFDs they can extend the network by serving as network coordinators.

One way nodes can be organized is a Peer Network as shown in Figure 1. Any FFD can communicate with any other node in range. Each RFD associates with one and only one FFD. The PAN coordinator provides the interface and structure for the entire network.

A network containing only FFDs is a true peer network with the capability for any FFD to communicate with any other FFD in range. Figure 2 illustrates an FFD network composed of Full Function Devices.

There are two types of network coordinators; coordinators and PAN coordinators. Both are FFDs. Coordinators are FFDs that provide links or associations to other FFDs and RFDs. There can be multiple coordinator devices in a PAN but only one PAN coordinator. The PAN coordinator (Red Node in the diagrams) is the “owner” of the PAN and provides the PAN ID that uniquely identifies the network to the outside world.

The 15.4 standard does not define how the PAN ID is selected. Any FFD can decide to chose a PAN ID and become a PAN Coordinator. Other FFDs and RFDs can then associate with it and “grow” a wireless network. [If that sounds somewhat haphazard you need to remember that we are discussing the very lowest level software layer here. There are other higher layers that provide much more structure.]

A PAN coordinator and most FFDs are typically powered nodes while RFDs are often battery powered. The PAN coordinator will usually have access to a wired network and be the interface from wire to air. The FFDs and PAN coordinator may also have more computational capabilities then the RFDs which may do nothing more than pass their data to the next coordinator.

PAN coordinators address the devices associated to its network using a unique 64-bit address that is predefined by the device vendor. Alternatively, the PAN coordinator can assign a 16-bit short address to the device and address it with that address.

A second way of organizing a network is a Star network (Figure 3). In a Star network all nodes talk to a central coordinator and that coordinator synchronizes communications with other nodes. In a Star network there is only one coordinator and that is the PAN coordinator.

Star networks are limited geographically and numerically while a Peer network is theoretically unlimited. The PAN Coordinator in a Star network can only associate with a limited number of devices while coordinators of a Peer network could in theory extend the network continuously. Peer networks with higher level routing software form the basis of complex mesh networks with self organizing and self healing capabilities but those capabilities are not part of the 15.4 standard.

This is an area that generates a lot of confusion for the novice. There is no routing or organizing of nodes in a 15.4 network. Yes, it’s possible to have a very graphically diverse network of devices but there’s no mechanism in 15.4 to move information through the network.

An RFD can only transmit to its coordinator while an FFD can transmit to any node within “earshot”. To actually move data and route it around the network requires a higher level protocol, like Zigbee™. Zigbee adds the network and transport infrastructure required to support information transfer around a true Peer or Mesh network.

To associate with a network, nodes have to explicitly join a network by making themselves known to a Coordinator node that is already part of the network. If there are multiple networks available a node has the option to join any one of them. That’s where the PAN ID comes in. A node will typically be preconfigured to join a network with a specific PAN ID.

That does not mean that the node is associated with that network forever. Built into the 15.4 Media Access (MAC) is an association/disassociation strategy. This mechanism supports those applications where nodes are part of one network for a while and then leave to join some other network (think of a part moving through multiple production cells). Or an FFD can choose to start its own new network declaring itself the PAN Coordinator.

There’s a lot more to an 802.15.4 MAC and we’ll look at more of those important features in the next article.

John Rinaldi is the Technical Sales Manager for Real Time Automation in Brookfield, Wisconsin. RTA specializes in industrial and building automation software, hardware, systems and specialty controllers. He can be reached on 262-439-4999 or through the RTA website, http://www.rtaautomation.com/forms/contactus.html.

Zigbee is a trademark of the Zigbee Aliance.

There is a lot of discussion going on now about the evolution of the PC market. I remember years back (sounds like I’m getting old) when the first PCs came out. They had these single length ISA slots and then incredibly long double-length ISA card slots. We use to buy cards for those things all the time.

At that time it was common that you bought a video card and had to plug it into one of those slots. That was before anyone had video circuitry right on there motherboard. So part of the fun of the assembly process was to install these ISA cards. It was maddening. They were sometimes hard to install because the end of the card with the DB15 on it had to fit in the slot on the external part of the PC. It gives me the shudders to think about it. If the computer was shaken a bit and things didn’t work you’d not only reboot it but you went and unplugged and re-plugged all these cards. I feel like Fred Flintstone telling you about it.

During the ISA card era DeviceNet ISA cards started showing up. These actually worked pretty well except that they were dang expensive (even today’s still are). These guys usually had two DeviceNet ports and had direct access to the PC over the ISA bus. People could write programs for Windows that would talk to the card and transfer data over the network.

Needless to say the ISA card era died when bus speeds increased so much that the ISA technology was obsolete. Walla – here’s PCI. PCI stood for Peripheral Component Interface. There was a very expensive chip set that you could use to create PCI cards. At least now the cards weren’t a foot long. Everything had kind of shrunk in a PC and the interface cards were no exception. Now they were only 5 or 6 inches long. Now companies not only made DeviceNet cards, you could get ControlNet cards, Profibus cards and a whole lot of other ones. So people retooled their application to use the new PCI cards and off they went.

Well here we go again… Now PCI is getting obsolete. PC manufacturers are loading the motherboards with everything they can eliminating the need for PCI’s. There’s no need for fancy video drivers or serial port cards. It’s just extra real estate and extra expense.

But that presents a real problem for the people using the PCI interface cards for networking. Now they have to retool their applications for USB. Now high speed USB (Rev 2.0) is pretty fast but it’s no where near as fast as a bus interface like PCI. Some applications that really took advantage of that are just going to be out of luck in a few years.

I happened to call Dell today. They tell me that they now have only 2 tower boxes that have PCI slots and can’t say for sure that they’ll have any in 2010. So, if you are one of the lucky ones that got to retool your application twice already your in luck, you’ll get to do it again. This time for USB.

Better stop depending on the PCI card today. It’s going the way of the serial port meaning missing in action. Luckily RTA will have some nifty USB products in the future to save your <you know what>. Keep watching. Same Bat Channel. Same Bat Station.

Sometimes I think I am the last to find out about stuff. Not trivial stuff, some fairly important stuff. The latest is ENOCEAN (www.enocean.com).

I traveled a lot in Europe. Probably 15 times over the last 10 years. I’ve been all over, from Italy to Ireland to Holland and lots of places in between. On those travels I’ve always wondered about the slot where you have to stick your hotel room key card. Sticking it in the slot makes all the lights and everything else powered up on the room. It’s kind of cool and I always wondered about it.

I may be the last to understand it but I just discovered that most of that stuff is something called ENOCEAN. That’s a self powered wireless standard that is some really cool technology.

It truly is self powered wireless. When you get to your room you slide your hotel card through the slot. It turns out that sliding it down the slot provides just enough power to read the strip, validate the key code and open the door. When you get in the room the same thing happens at the docking station where you put your card. It wirelessly signals the rest of the room to activate all the outlets. Every outlet has a wireless receiver with relays that get turned on when you store your card and turned off when you remove your card.

I think it is pretty interesting technology and I’m going to learn more about it. It’s too bad it took me so long to find out about it.

Alright I’ll admit it. I’m kind of stubborn. I think everyone is to a certain extent. It’s one of the curses of growing older. By that I mean getting past 15. At 15 we all start to get used to things as they are and every year are less and less inclined to want to see/think/hear new thoughts, do things differently and accept new ideas.

This is most apparent with certain business ideas. I’m a tree kind of guy. I don’t really understand the forest. But if there’s a tree to prune, something to plant, some branches to shape I’m right there – know everything about it, think about it all the time and understand it really well. In other words, I’m a detailed guy who doesn’t always see the big picture.

Someone like Bill Lydon is the opposite. You probably know Bill. In the last ten years I can count on one hand the people that tell me they don’t know Bill. He’s a forest person if there ever was one. He has a good handle on what all the different kinds of trees are in the forest, where they grow best, why they’re there and what the forest is going to look like in ten years. He gets in trouble talking about how to shape a tree. He’s the big picture guy if I ever knew one.

Bill really knows Industrial and Building Automation. I know a lot of the details but Bill knows the industries, the people and companies in them; who’s doing what and why. He tells me things that I should do but generally I avoid his advice for a long time until it gets to a point where I have to agree that he was right in the beginning. Kudos for me – I usually admit when I’m wrong.

Well, one of the things I’ve been resisting is wireless. I can understand it’s attractiveness but it just wasn’t something I was comfortable with. I admit that I kind of projected my personal biases on the industry as a whole and that’s really bad. I’m now ready to admit that my hesitation was wrong and that does and will have a significant place in automation both industrial and building.

We all know the value proposition of wireless. No Wire. Don’t have to buy it. Don’t have to install it. Move it anytime you want. It’s not a novelty anymore. Almost everyone is using it to some extent in almost every industry. On and on and on.

Of course, you pay for that all that installation simplicity by more complex integration. You’ve got to deal with architecture issues and placement and physical limitations. Bandwidth issues. Lots of stuff that’s a lot simpler with wire.

And then there are the interface issues. At some point you’ll need to get back to wire. You’ll need to go from something like Zigbee, Broadband or mesh and get back to EtherNet/IP, Modbus TCP or BACnet. If we’ve learned anything over the past 20 years, we never coalesce on a single standard. We’ll always have this alphabet soup of standards. But I won’t complain about that. That’s how I’ve made my living the last 15 years!

But I now admit I was wrong. Wireless is here to stay and it’s going to have an important role on the factory floor. I’ve stopped resisting and am ready to move forward and get unwired.

I think I see a tree I can start working on.