All data acquisition devices must be able to cope with numerous configuration options, but every device is different. Which channels must be sampled? How fast? When does sampling start, or end? And so forth. The question is... does the solution make the problem harder than it has to be?
Simple for hardware == harder for you?
In an unintelligent solution, device operation is controlled by application code directly, using special driver functions to access device configuration and data registers. The variety of devices poses immense complications. The host driver software can address the problems in three ways.
1. Low-level drivers. One device, one driver. The direct match for the hardware means precise device control, but with severe hardware device dependency and timing problems.
2. Multi-drivers. Multi-function driver applications use an internal knowledge base to map quasi-generic driver functions to the required internal device operations. Many subtle compromises remain: configuration switches, option parameters, and device-dependent side effects.
3. Mega-drivers. High-level application wrappers hide the multi-drivers and embody additional configuration knowledge. Though much easier to use, the cost is dependence upon a heavyweight GUI environment. That might be more than your application really needs.
Without DAPL: Host Drivers Control Hardware Devices
All of these approaches have the disadvantage that control functions must be compiled into your software application. To change your acquisition configuration, you must rebuild your application code. All of these approaches have the disadvantages of complex host software, either to deal with the drivers, or to deal with the GUI package that hides them.
Smarter hardware, smarter software == easier for you?
In contrast, the consistent architecture of the DAPL system makes it possible to avoid most hardware dependency problems by disallowing them at design time. The DAPL system can account for the rest. The hidden host drivers see only one kind of hardware. The application server software sees only one kind of hardware. Your application just sees the data. The difficulties are there, but they do not burden your software applications. The configuration has the simplicity of a device-specific driver, the generality of a mega-driver, and the independence of a host system process.
With DAPL: Embedded Driver, Process-Level Interaction
Device-Independent Script for DAPL Onboard Drivers
You can use DAPstudio to help compose and test the configuration scripts. Configuration commands for the DAPL system can be collected in human readable form as a text file. Your ability to develop, test, and maintain the data acquisition configurations independently makes development and validation of your application software easier.
The DAPL command interpreter makes all this possible. The DAPL system provides the translations into hardware-dependent forms that you never see and never want to. All of the configuration commands are stable and consistent for all Data Acquisition Hardware. The application software just sends the configuration. The DAPcell process just transfers it. This keeps the DAP services as simple as possible, and your application coding as simple as possible.
