- THE MAGAZINE
- WEB EXCLUSIVES
If you’re an integrator, I bet you’re like me: You hate cables. Every system I’ve ever worked on has had one-or maybe two or three-big, fat cable bundles somewhere. These wiring harnesses are a pain to draw on schematics, a pain to physically wire, and necessitate way too many connectors, terminal blocks, and choices about wire gage, color and labeling. In fact, in many systems, the physical wiring of the components to each other takes more time than the actual design. And it is very difficult to change.
Lately, more and more integrators have been moving to remote I/O solutions, using CAN bus, Ethernet, RS-85, and proprietary communications network technologies from vendors like Rockwell Automation. Recently, I had a chance to design with a different approach: wireless.
Of course, we’re all familiar with the proliferation of wireless technology-it’s why I can be sitting in the lobby of my hotel while submitting this column. It is almost taken for granted that businesses and factories will have some sort of wireless access for connecting machinery and people to each other, their e-mail and the Internet at large. But what about for machine components?
The standard 802.11 WiFi networking is used heavily in many networking applications. This allows an IP-based device, such as a remote data acquisition or I/O unit, to be addressed and communicated with, as if it were part of a much broader network-namely, the Internet. As long as routers and firewalls are configured correctly and addresses are allocated properly, I could write a control application that ran on my laptop and acquired data from anywhere in the world while controlling actuators anywhere else.
Interesting? Sure, but not necessarily a design that we would want to deploy.
Another set of standards warrants consideration. Zigbee, or, more correctly, 802.15.4, is a relative newcomer to the wireless networking scene. It uses low-power, spread-spectrum radios, typically in the 2.5 gigahertz (GHz) frequency band, to interconnect devices in ad hoc networks. Why is it different from WiFi?
• It is specifically designed to require much less power than WiFi.
• It includes its own ad hoc networking hierarchy in which nodes may be a primary, an endpoint or an intermediate router/endpoint.
• It continuously reevaluates signal strengths and reassigns routes and traffic to avoid failed (or powered-down) nodes.
• Nodes are addressed by a unique MAC address assigned during manufacture-every node is unique and cannot be mistaken for another.
• The communications protocol stack (typically this is what is referred to as Zigbee) is much simpler than TCP/IP and is therefore much easier to implement on small microcontrollers.
I’m currently designing a system that requires redundancy and extreme reliability for a wind turbine monitoring and control application. We have a data acquisition station that monitors weather, a motor control system that aims the turbines, and a master controller that makes decisions and commands operation. Since each station must be doubly redundant, there really are six nodes on our network, and if any one fails we need to be able to seamlessly continue operation. Designing a wired system in which a failed node can never take down the whole network is complicated, whether one uses Ethernet, CAN or even RS-485. But with wireless, a failed node simply goes silent or is ignored in all communications. A failed node might transmit continuously, generating lots of noise, but spread-spectrum radios presume that the channels are always full of noise anyway.
We also achieve much better electromagnetic interference (EMI) resistance (and in wind power, EMI comes in many forms from power line hum through inevitable lightning strikes) and avoid hundreds of feet of shielded cabling, which, if you haven’t looked lately, has gotten very expensive. And since the wireless acquisition systems use very little power, we can consider running them off AA batteries and keeping the batteries topped off with photovoltaics-making the system truly wireless, even down to the power input. This isn’t just an affectation: The need for clean, reliable DC power at a remote system creates a significant vulnerability in any redundant design, and having a self-powered, wirelessly-connected acquisition box dramatically enhances overall system availability.
Picture a plastic NEMA 4X enclosure with sensor cables coming into it from remote sensors, a PV array on one side, and… no other wires penetrating the box!
Many companies, such as Digi, Microstrain and National Instruments, make complete Zigbee-based wireless systems for remote I/O. For the more hands-on integrators, Atmel, Digi, Freescale, Jennic, MeshNetics, NEC, Panasonic, Rabbit and TI are just some of the players making modules in the $20 to $30 range that often include not just the radio but a C-programmable microcontroller so that a simple postage-stamp-sized board can be added to some custom I/O and turned into a Zigbee-ready embedded system. While I’m still a newcomer to the field like most integrators, I’d certainly recommend starting with the $500 Jennic evaluation kit that contains five AAA-powered evaluation boards, seven Zigbee radio modules, and a fantastic set of C-based development tools with enough sample code and documentation to get you started on becoming a Zigbee expert.
Ned Lecky is the owner of Lecky Integration (Little Falls, NY). For more information, call (518) 258-5874, e-mail email@example.com, or visit www.lecky.com or his new blog at www.visionsensorsmag.com.