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.
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
|The Many Paths to a Solution||Sep 21, 2016|
|Synopsys' Coverity||Sep 20, 2016|
|Naztech's Roadstar 5 Car Charger||Sep 16, 2016|
|RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop||Sep 15, 2016|
- Android Browser Security--What You Haven't Been Told
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Nativ Disc
- The Many Paths to a Solution
- Naztech's Roadstar 5 Car Charger
- Synopsys' Coverity
- Securing the Programmer
- RPi-Powered pi-topCEED Makes the Case as a Low-Cost Modular Learning Desktop
- Identity: Our Last Stand
- Glass Padding
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide