DAP Systems in a Network
The Case of the Disappearing Device Drivers
We have seen another data acquisition equipment supplier
boasting of a library with over 5000 device
drivers, all on one CD for your convenience! Should we laugh
or cry? By that standard, a DAP-based system is deficient by...
roughly 4999 device drivers.
How Did They End Up With So Many?
There are many reasons. But when the design approach is to wrap
a hardware product around the latest new converter device, for
better or worse, every design is different so every product is
different. In order to operate it — well, ring up another
device driver for the CD.
But in DAP systems the devices are wrapped around the system
Devices are driven by DAP embedded controllers,
configured by the DAP onboard processor, and operated completely
independent of the host. Host driver functions reduce to
device-independent smart buffering and message passing, covering
all DAP models.
You Can't Operate Device Drivers From Networks
Device drivers in the host system must be limited to operating
one device. If they tried to operate communications networks or disk
drives or file systems as well, it would be such a mess that the
host system would never recover.
Server processes are not subject to the same restrictions,
however. They can use a variety of file systems, networking
protocols, API's, and of course devices (through device drivers).
The DAPcell services are provided at the process level, not the
device level. And that is how they can control multiple, different
DAP devices, even log data directly to a remote disk server without
Advantages of Networked Data Acquisition Processors
- Network identity
Your DAPcell software assigns a
local DAP address, and your workstation provides a network node
address. Between the two, devices on different workstations are
addressable across a network. In your software applications,
just specify the full network path to the remote DAP.
- "Will my virtual instruments explode?"
No, not if you are minimally careful.
DAPcell services work as well within a GUI environment as in any
other software, but at a very high level of efficiency. If you
expected real-time processing of all of the data from a DAP
operating at full rate, consider full body armour.
- Remote access and control
Transfers to remote locations across
a network are fast, but seldom time-deterministic, so don't
forget about transfer delays. If you prepare your applications
so that all time-sensitive control processing is covered
entirely in the data acquisition processors, the rest is
- Leveraging remote resources
Huge data files? You are probably
not going to pack a 6 terabyte data set onto your local
workstation disk drive. But a disk array at a remote location
will have no problems.
- Long term operations
Devices don't last forever. Suppose
you have a DAP in service for eight years, then a power supply
goes out taking the DAP with it. You can substitute a current
generation DAP product, for less cost than the original, and
just ignore its expanded capacity.
- Limits of scale
Of course, there are limits to
everything. How large a data acquisition network can you build?
Sooner or later, you will run out of money to install more
network hardware and workstations. And when you do, that's the
end of the show.
- Custom applications and DAPIO
systems can get very big, the software problem remains very
small. The DAPIO programming interface provide service access
through a DLL. Simply call the functions to establish a
connection, poll for status, request or send data.