Selecting I/O Units
I/O units typically are referred to as local or remote, a reference loosely interpreted to mean distance. I like to think of local as directly (or nearly directly) connected core processor peripherals. PCI- and ISA-enabled peripherals are good examples of local devices. A remote I/O unit usually has some kind of communication medium, such as a serial (RS-232 or RS-485) cable, wireless, infrared, Ethernet, FireWire or USB (to name a few). These remote interfaces have devices that may connect to the local core processor of the controlling computer but modify the data in such a way that it is transferred via another medium to its destination. This medium acts as an extension cord that extends the distance from the core processor bus to the device. This distance may be as short as a meter or as long as kilometers.
Remote vs. local I/O is important when considering the expense of additional cables to a control location. If I were to design a local control system using a set of PCI I/O cards, every point of I/O would have a cable installed. Consider a 1,000-point system with 1,000 cables. Just imagine the expense if an electrical contractor quoted an installation cost of $100 US per cable (the total would be $100,000 US)! In such a case, remote I/O allows a single wire such as CAT 5 (Ethernet) to be run to distributed I/O units. While 1,000 cables are still required for installation, the signal cable distance is shorter, decreasing the labor and materials cost of installation. In more unusual projects I've worked on, remote I/O implementation also provided incredible savings in cable weight. In one project, I recall estimating that we saved approximately 1,000kg of mass by just converting the system to remote I/O.
Shorter sensor and effector cables routed to a nearby I/O unit also are easier to test, debug and maintain. For example, if the cables run through a complex vehicle such as a ship or an airplane, a suspected wire failure might require physical cable tracing. If the wire length is 500 meters, each meter of wire may require inspection. If an I/O unit is located next to sensors and effectors, the communication media cable from the control computer to the I/O unit is still 500 meters, but it may be an Ethernet fiber bundle. The sensor and effector cables to the I/O unit may be only meters long. Clearly, debugging a couple of meters of wire is easier than several hundred meters.
Analog signals also may be affected by electrical noise, which places additional and undesirable signals into the analog data. Devices switching on and off may cause electrical noise. Power cables too close to sensitive signals also may create anomalies in I/O unit readings. Typically, the shorter the wire, the lower the probability of receiving electrical noise. Digital media cables such as copper Ethernet are susceptible to electrical noise too. Digital media typically employs a method of data validation that detects when data corruption occurs, but it still can be a problem.
Nonmetal technologies such as fiber are not susceptible to noise because they use light and not electrons. When installing a system it is useful to perform a site survey to evaluate potential sources of electrical noise. Plan for cables to be a significant distance from high-energy cables (power conductors, RF transmitters and so on) and high-energy systems (such as anodizing systems, high-voltage switching equipment and high-energy control hardware).
Modularity is all about selecting channels or points of I/O. While most I/O units support either all digital points or all analog points, some support both types. Mixed systems, as we call them, allow the designer to pick a single unit and select all the points required. As most systems require both analog and digital points, mixed I/O units optimize the cost-effectiveness of the design and reduce size and weight.
In addition, modularity improves life-cycle maintenance. An I/O unit with removable points may require a few seconds to replace a component and restore system operation. Replacing an entire I/O unit is much more costly in labor and downtime. Modularity also allows smaller, cheaper components to be stocked as spares should a replacement be necessary, also reducing downtime.
- Reducing Boot Time in Embedded Linux Systems
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Use Linux as a SAN Provider
- diff -u: What's New in Kernel Development
- NSA: Linux Journal is an "extremist forum" and its readers get flagged for extra surveillance
- Great Scott! It's Version 13!
- RSS Feeds
- Linux Systems Administrator
- Technical Support Rep
- Senior Perl Developer