Selecting I/O Units
We've reached the end of the wire on the analog side. The last item on the wire is the sensor, or effector, which is subject to errors as well. It's important to mention these errors because they affect the value the I/O unit reports or sends. It's a ``garbage in, garbage out'' affair. I'll quickly review the possible measurement errors.
Sensors and effectors are affected by the same accuracy and linearity issues as analog-digital converters. Measurement accuracy is typically a calibration issue. Calibration is a procedure to verify that the measurement corresponds to the reported value. Drift is long-term deviation that causes errors in the measurement value. Drift may be caused by degradation of a sensor's components or life-cycle fatigue of a system. Sensor and effector performance also may be subject to environmental factors such as temperature or humidity. It's important to read the specifications for a sensor or effector and thoroughly understand them.
I also look at measurement error as the limit I need to convert or display my data. Displaying the number precisely and accurately is important. If I have a sensor reporting a value such as mathematical pi (3.14159...and onward irrationally) and the sensor's precision is only two decimal places, I should display only 3.14. Representing the rest of the number beyond two decimal places is a guesstimate or an unqualified representation.
It is also important to determine the expected accuracy. I specify my I/O hardware to be slightly more accurate than my sensors and effectors (up to the limit of the customer specification). This way the sensor and effector errors are the measurement limit and not from my signal conditioning or conversion hardware. However, these concerns are less founded with the availability of high-resolution/accuracy I/O unit hardware.
For some reason, most control system specifications list an item requiring the volume of conversions over time (samples per second) or how new the data is when reported. Because of the conversion process and buffering of the converted data, there may be a delay between the actual analog signal value and the reported value, or the analog-digital converter may have a maximum conversion rate.
Fortunately, this is an area that technology has improved dramatically. I recall delay specifications that used to describe throughput in milliseconds but now describe it in sub-microseconds. A large percentage of monitoring systems do not require very fast conversion rates. As we'll see later, however, the communication infrastructure between my I/O unit and the host computer may cause a significant delay.
A number of features affects the suitability of an I/O unit for a given application: isolation, remote vs. local placement, modularity, connectivity, and protocol and software support. I'll discuss each of these features before talking about steps to implement a system.
Because the I/O unit is the interface between the computer and the physical world, it has a two-sided nature. For the I/O unit, physical world data appears as electrical signals, either voltage or current. On the other side, the I/O unit exchanges digital data with the computer. The I/O unit's connection with the sensors and effectors is referred to as the field connection. The side of the I/O unit that connects with the computer is referred to as the computer or control side. At the interface of these two sides are electronics and isolation.
Connected to the field side of the I/O unit are the sensors and effectors that send an electrical signal to, or receive a signal from, the I/O unit. This signal has a value in current or voltage that correlates with the phenomenon it is measuring or driving. The I/O unit's computer or control side is connected to some kind of data bus or communication technology.
What happens if a high-voltage wire shorts out with another on my I/O unit? If the wire shares a common metal connection with my control computer, simply put, the computer is history. Damaging electrical phenomena may be caused by faulty wiring, water leaks, failing devices, lightning, static discharge and ground potential. But good system design can contain possible damage from electrical phenomena, even a direct lightning strike.
Many I/O units eliminate a metal connection between the field and control sides of the I/O unit. Weird science at work? No, not really. By using optical, capacitive and magnetic technologies, an electrical circuit can be isolated yet connected. A magnetic circuit can supply power from the control side to the field side without a metal connection. An optical link can provide a data interface between the control side and the field side. Capacitive isolation uses electron charge coupling to transfer signals between two isolated plates. This elimination of the metal connection between the two sides of the unit is referred to as electrical isolation or simply isolation.
In the event of an extreme situation (a lightning strike) the field side will be destroyed. That's inevitable. The electrical barrier imposed by the isolation also may be compromised, although it takes thousands of volts to do so. Communication media may provide additional isolation, however. Copper Ethernet, for example, provides an additional layer of isolation because media transformers ensure that the patch cord is isolated from the host and the infrastructure. Optical Ethernet is even more isolated. Optical Ethernet segments can be made to contain and survive a direct lightning strike (with a little ground planning in appropriate places).
Isolation is critical to prevent general electrical phenomena from damaging the I/O unit and the computer controls. Isolation is critical to at least contain the damage an extreme event will cause. Electrical anomalies are unavoidable over the life of a system, but with planning, even the highest energy events are survivable.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Build a Skype Server for Your Home Phone System
- Validate an E-Mail Address with PHP, the Right Way
- Why Python?
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
1 hour 25 min ago
- Reply to comment | Linux Journal
1 hour 33 min ago
- Understanding the Linux Kernel
3 hours 48 min ago
6 hours 18 min ago
- Kernel Problem
16 hours 21 min ago
- BASH script to log IPs on public web server
20 hours 48 min ago
1 day 23 min ago
- Reply to comment | Linux Journal
1 day 56 min ago
- All the articles you talked
1 day 3 hours ago
- All the articles you talked
1 day 3 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?