Instrumentation Data I/O

Instrumentation Data I/O

The data an instrumentation system collects or
generates comes in a variety of formats and
fulfills a wide range of needs.

● We’ll start this chapter with a discussion of

interface formats and protocols, defining the
basic concepts we will need to know for the
upcoming software examples.
 Data I/O Interface Software
● Over the years, computer interface hardware
has evolved from simple devices using serial
communications and I/O registers mapped into
a computer’s memory address space to
complex subsystems with their own built-in
processors, onboard logic, advanced protocols,
and complex API definitions.
 Data I/O Interface Software
● As the complexity grew, the number of unique
interface methods and protocols also began to
grow. As you might imagine, if a large system
had to support more than just two or three
unique interfaces, each with its own unique way
of doing things, this could result in a significant
hassle.
 Data I/O Interface Software
● Early on, people began to realize that it didn’t make much
sense for each device to have a custom interface, especially
when many devices shared common internal functions and
had similar capabilities.

● In order to rein in the impending chaos and establish

consistent interfaces across different application domains,
various industry standards 395 organizations were formed.

● These organizations began to define guidelines and rules for

interfaces and the software that would use them. These could
then be applied to different types of equipment in a wide
variety of situations.
 Data I/O Interface Software
● The Electronics Industries Association (EIA)
published its initial definition of RS-232 in 1962,
and after several revisions, it is still in use today.
● Various common standards have also been
developed by other organizations, such as the
American National Standards Institute (ANSI),
● The Institute of Electrical and Electronics
Engineers (IEEE),
● And the Interchangeable Virtual Instrument (IVI)
Foundation.
 Interface Formats and Protocols
● Regardless of the type of connector used for a
particular interface, or even the way in which data
moves through an interface, the key thing is that data
is moving between a host system (the master
controller, if you will) and whatever devices or
instruments are connected to it.
 Interface Formats and Protocols
Naturally, when it comes to data acquisition and
instrument control, there are multiple ways to
get there from here.

● One approach is to use custom software with

common interfaces to external instruments,
such as serial and USB interfaces.
 Interface Formats and Protocols
● Another way is to utilize industry-standard
drivers and protocols that provide a consistent
API across a range of physical interfaces,
including serial, USB, GPIB, and bus-based
hardware.
Interface Formats and Protocols
The simplest way to interface a computer with the
real world is through a serial or parallel port
interface of some sort. The apparent simplicity is a
result of the physical simplicity: the computer
already (usually) has a serial or parallel interface of
some sort, so the physical connection is typically
just a cable.
Interface Formats and Protocols
This shows how it works
with a generic CPU that does not
provide a separate I/O bus for
peripherals (such as the
Motorola 68000 family),
and a CPU that incorporates a
bus specifically for I/O functions
(like the Intel process-
ors found in most modern Pcs).

The top figure shows the

combined Memory and I/O
address Space.

While the buttom one shows

the Separate Memory and I/O
Spaces.
 Interface Formats and Protocols
● When working with I/O hardware that uses
registers, a piece of software called a driver is
employed to handle the low-level details of the
interface.

● The driver provides an interface to programs that

use the hardware, and it typically handles things
like interrupts and bulk data transfers in a more
or less transparent fashion.
 IVI—Interchangeable Virtual
Instrument
● In the instrumentation industry, the IVI suite of
standards is becoming commonplace for
Windows platforms, and many instrument
manufacturers now provide IVI-compliant
drivers.
● That block diagram shows the
overview of the IVI architecture.
Python Interface Support Packages
● There are several I/O support packages available
for Python to help with the implementation of
various types of interfaces in Python applications.
These include serial, parallel port I/O, USB, and
VISA-type instrumentation interfaces, including
GPIB.
● In this section we will take a quick look at three
different packages, all of which aim for easy
portability between platforms (Windows and Linux,
primarily).
Python Interface Support Packages
PySerial
● The pySerial package, written and maintained by
Chris Liechti, encapsulates the functionality
necessary to communicate with a serial port from
a Python program.
● A single class, Serial , provides the necessary
functionality with the same set of methods for all
platforms, and once installed it is straightforward
to use.
PySerial
 pyParallel
● pyParallel
(http://pyserial.sourceforge.net/pyparallel.html)
is a companion project to pySerial by the same
author. The purpose of pyParallel is to
encapsulate access to a parallel port by a
Python program in a platform-independent
manner
 PyVISA
● The PyVISA package provides a Python API for
an IVI-standard VISA driver on Windows, or an
IVI-compatible VISA driver for Linux systems. It
uses a driver DLL or library file provided by an
instrument vendor.
Data I/O: Acquiring and Writing Data
Basic Data I/O
When considering data acquisition, there are
basically two types of data sources:
● external instruments

● data acquisition hardware installed in the

computer itself
Blocking Versus Nonblocking Calls
One way to describe the behavior of a function
or method is in terms of how quickly it will
return after it has been invoked. Some only
return after a result of some type is obtained,
while others may return immediately without
waiting for something else downstream to
produce a particular response.
Blocking Versus Nonblocking Calls
● Blocking is the calling code must wait for a
response.

● Nonblocking is the calls return immediately

( usually with response that indicates success
or failure)
 Data I/O Methods
Types of Data I/O methods:
● On-demand data I/O - If your software uses on-demand
calls to read data, they should be blocking calls, and your
software should always check the return codes.

● Polled data I/O – a function that attempts to get data from

a specific data acquisition device by continually polling the
port (using the ReadNonBlocking() function call) until valid
data appears.
● Handling Data I/O Errors
 Faults, Errors, and Failures
Here are some terms commonly used when
discussing and describing fault-tolerant systems.
Although these are common terms, often used
interchangeably, they have special and specific
meanings when used in a fault-tolerant context:

● Fault - A defect in the code, the electronics, or the

mechanisms of a system. A fault only becomes
apparent when it is encountered and an error
occurs. A fault that is not encountered is called a
latent fault.
 Faults, Errors, and Failures
● Error - Errors are generally categorized as
being either fatal or nonfatal in terms of the
continued operation of the software.

● Failure - The nonperformance of an expected

action as the result of an error, typically
expressed as a deviation from the required
behavior as defined in the system specification.
 Classes of errors
● A nonfatal error might be something like an
intermittent communications channel, perhaps
due to noise or other perturbations in the
medium, or someone’s foot occasionally kicking
a connector under a desk.
● A fatal error is one that requires significant
intervention if the system is to continue
functioning.