Selecting I/O Units

Selecting and communicating with I/O units. The I/O unit physical layer interface. Understanding the wide perspective.

The next topic is connectivity, or the physical medium the I/O unit uses to communicate with the host. Connectivity applies to remote I/O, as local I/O is in the form of an adaptor card. Connectivity determines the auxiliary costs in the installation of any system. Connectivity methods also determine the reliability, expanse, throughput and upgradability of the system.

One of the very first questions I ask in any application is, ``What's the distance between the I/O unit and the control computer?'' The answer to the question may be a meter, or thousands of meters, or considerably more. Ethernet provides excellent expanse up to kilometers. RS-485/RS-422 may extend to one kilometer. FireWire is short distance and so is USB. The media must simply go the distance.

The next question I ask is, ``How fast or how large is the volume of data to and from the I/O units?'' This question usually narrows the selection range of communication options to one or two choices. High-volume, large-data transactions usually fall into Ethernet. Low-transaction data sizes and slow data requirements fall into the serial RS-485/RS-422 options. If the distance requirement is very short, the PCI bus for adaptor cards may be suitable. FireWire and USB options are just emerging as connection options in the automation arena.

I'll admit, there's also the all-encompassing limit of cost: selection of the connectivity media is always limited by the budget. Ethernet in many cases is an installed infrastructure, and taking advantage of the installed network can reduce costs. A new Ethernet installation appears costly due to the addition of infrastructure.

Installing a twisted-pair wire for RS-485 is initially inexpensive because infrastructure is not required, but there's a trade-off in additional flexibility. Adding another device may overload the communication bandwidth and require installation of another twisted-pair wire, adding additional costs.

Installing a gigabit Ethernet fiber backbone is costlier initially, but other devices may share the Ethernet segment. Such a high-bandwidth connection is capable of carrying significant other traffic (such as an office network) simultaneously, providing long-term flexibility. Specific infrastructure selection also may provide communication redundancy, an additional feature most automation systems require. Ethernet hardware is standard, with parts readily available through any office network provider.

Many simple-wire technologies are cheaper than Ethernet but are limited in flexibility. While initial costs are a driving factor in the installation life cycle, modifications prove more expensive and perhaps impossible. At times it's worth investing the extra resources to know that flexibility and expansion are possible. It takes a broad perspective and insight to see this, but as specific networking technologies permeate into every aspect of the industry, it pays to surf the wave (so to speak). Higher initial costs may be absorbed into a long-term system plan.

One little point needs to be mentioned. When I talk about expanse, it's not the distance from point A to point B (the shortest path). Instead, I'm referring to the physical path: the installed cable distance. I've designed implementations where the physical path was over 20 times the shortest-length path! Make sure you know the real distance.

Data Protocol/Software Support

Every I/O unit has a data protocol, which organizes data in the messages that request or send values or commands to and from the I/O unit. Data protocols could be a string of binary data, ASCII-readable messages or a combination of both. Message protocols can be tedious, since byte manipulation or creating ASCII sequences in the protocol may take time. Learning the protocol functionality and understanding its limitations may itself prove time consuming.

PCI and ISA cards have a data protocol plus a device driver. The device driver provides a pipe between the application and the hardware. Device drivers may be difficult for those unfamiliar with register-level hardware. Device drivers also may increase project risk or costs due to additional labor. The best solution is to select a device that already has a device driver. Be careful of using locally connected hardware too, since ``bus wars'', the frequent change of the expansion bus available on your computer, may make your hardware suddenly obsolete. Remote hardware typically has greater longevity in the communications infrastructure and therefore promotes long-term support and computer architecture flexibility.

Linux supports the most diverse hardware architectures. This diversity can cause compatibility issues. However, I express concerns about data protocol support only if I'm using an older-generation mainframe or a system that deviates from a modern desktop architecture. In these cases I always make certain that the method of communicating with the hardware is very well documented and assisted with source code (even before selecting the hardware). I like understanding the methodology and features of the data protocol, but I also am concerned about long-term support of my systems. Source code assists support. I would be very disappointed to find out that I had to write additional software in a tightly budgeted project. Such setbacks are expensive and jeopardize a project. Make certain that the code supports the target Linux architecture and kernel version.