Unfortunately there is no standard API for DAQ meaning that the software becomes hardware-dependent. CP_BI adds an abstraction layer that allows to avoid this dependency. CP_BI does not substitute manufacturer's drivers, it uses them and hides proprietary API from the programmer. CP_BI is implemented in a DLL, but it is also possible to make it a part of the source code (not recommended). CP_BI was designed for streaming multi-channel data, so its API and performance were optimized accordingly.
Note: current implementation of CP_BI supports DAQ samples represented as 16-bit signed integers, but it should not be hard to add other sample sizes.
| Manufacturer | Board Name | Board ID |
| National Instruments | AT-MIO-16E-2 | 1001 |
| National Instruments | DAQPad-6020E for USB | 1002 |
| National Instruments | DAQPad-1200 | 1003 |
| -- | Board Simulator | 2001 |
| Data Translation | DT9801 | 3001 |
Board Simulator is a software simulator of AT-MIO16E-2, but unlike the real board it reads data from a file. Quite helpful in debugging.
Complete list of the supported boards along with their capabilities can be found in the configuration file (XML).
CP_BI notifies the caller of new data via a callback (prototyped in CallbackPtr()) or a message, or both. On notification the user should lock the received block by calling IBoardInterface::DaqLockBlock and retrieve the data using provided API calls, e.g. IBoardInterface::DaqGetBlockData after that the block should be unlocked: IBoardInterface::DaqUnlockBlock. Note that if a continuous stream of data is required, user must check that the blocks are consecutive: locking a block for too long can lead to loss of data and missing blocks. Also if there was an error on block acquisition the error code is stored in the block header.
To stop DAQ use IBoardInterface::DaqStop(). When done - call IBoardInterface::DaqBoardRelease() and delete the instance of the IBoardInterface class.
If you want to download a compressed-html single-file help, you can get it here.
1.3-rc3