One real-time driver for industrial DAQ
Made for every ADDI-DATA device.
ADDI-PACK is the unified data acquisition driver framework for ADDI-DATA hardware. Windows and Linux from a single codebase, deterministic by architecture, ready to feed your Automation Layer, MES, ERP and AI systems through open APIs and language bindings.
Download ADDI-PACK v2026.06.1
Free with every ADDI-DATA device.
Thirteen cards. Every other ADDI-DATA device is on the way.
Five driver families, ten physical cards (PCI and PCIe), full Windows + Linux parity from day one. Other ADDI-DATA devices still ship with our proven legacy drivers but if your device matters to your project, tell us. Customer demand drives the order in which we migrate the rest of the portfolio.
| Cards covered | Windows | Linux |
|---|---|---|
| Digital APCI/APCIe-1032; 1500; 1564; 2032; 2200 | APCI-1648; 1696 | APCIe-1532 | ● Shipping | ● Shipping |
| Analog xPCIx-3001; 3002; 3003; 3009; 3010; 3016; 3021; 3110; 3116; 3120; 3121; 3126; 3200; 3300; 3501; 3521; 3600; 3660 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Digital xPCIx-1016; 1516; 2016; 040 | APCI-1532 | CPCI-1500; 1564 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Counting xPCIx-1710; 1711; 1712 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Length xPCIx-3701-3702 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Serial interface xPCIx-7300; 7300-3; 7420; 7420-3; 7500; 7500-3; 7800 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Motion control APCI-8001; 8008 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
Need your device on ADDI-PACK?
We prioritize migrations based on customer demand. If your project depends on a device not yet supported, tell us and we will factor it into the next release window.
One operation. Three languages. Identical behaviour.
Read all digital inputs from an ADDI-DATA device. Same call across Python, C++ and C, pulled straight from the real ADDI-PACK samples.
digital_input.cpp
// Production C++17
#include <addi-data/addi-pack/cpp/digital_io_interface.hpp>
using namespace addidata::addipack;
auto dev = DeviceDiscovery::getDevices().front();
auto digital = dev->digitalIo();
uint32_t value = digital->readAllDigitalInput();
std::cout << "DI: 0x" << std::hex << value;
digital_input.c
// Native C — embedded path
#include <addi-data/addi-pack/api.h>
uint8_t n = 0;
AddiDataGetNumberOfDevices(&n);
AddiDataDeviceStruct devs[8];
AddiDataGetDeviceList(devs);
uint32_t value;
AddiDataReadAllDigitalInputs(devs[0].id, &value);
printf("DI: 0x%08X\n", value);
digital_input.py
# Python 3.8+ binding
from addipack import DeviceDiscovery
device = DeviceDiscovery.get_devices()[0]
digital = device.digital_io()
value = digital.read_all_digital_input()
print(f"DI: {value:#010x}")Why this matters. Every line your application team writes against ADDI-PACK survives the move from R&D bench to production line, no rewrites, no port, no re-validation cycle.
That is the difference between a 6-month integration and a 6-week one.
Production-ready today. Built for industrial uptime.
Native installers: Win32/64; Debian/Ubuntu (.deb); Red Hat (.rpm)
DKMS rebuilds the kernel module on every kernel upgrade.
RTX 64 support is on the immediate roadmap, with Linux RT ; Xenomai ; VxWorks targets planned beyond
Modern C++ core with one polymorphic backend per platform.
Python bindings auto-generated from the same headers.
.NET and additional bindings on the roadmap, all sharing the same underlying API.
Python bindings auto-generated from the same headers.
.NET and additional bindings on the roadmap, all sharing the same underlying API.
Hardware counters, timers and watchdogs; synchronized digital I/O across cards.
Real-time triggering and event counting handled in kernel mode, no software jitter on the critical path.
Same log format, same ADDI_LOG_LEVEL control, same tooling on Windows and Linux.
Your maintenance team learns one workflow for the whole fleet.
Versioned, backward-compatible APIs survive version bumps.
Compatibility DLLs keep legacy 1.x applications running unchanged.
RTX64 hard real-time on Windows is on the immediate roadmap; Linux RT (PREEMPT_RT), Xenomai and VxWorks targets follow.
One API across all of them.
One stack. Both kernels. Every language your team writes in next.
Every layer above the kernel is shared. A polymorphic C++17 backend handles the OS differences so your application code stays identical from Windows to Linux and so each new RTOS target (RTX, Linux RT, Xenomai, VxWorks…) and language binding plugs into the same proven core.
Your application
Python prototype · C++ production · LabVIEW · MATLAB
↓
Python bindings
nanobind · auto-generated
C / C++17 public API
Stable, versioned, ABI-compatible
Compatibility DLLs
Legacy 1.x apps run unchanged
↓
Shared ADDI-PACK core: one source tree, all platforms
↓
Windows KMDF driver
Signed · WHQL-ready · shipping
Linux kernel module
DKMS · auto-rebuild · shipping
RTX / Linux RT / Xenomai
Hard real-time · roadmap
↓
ADDI-DATA hardware
A public commitment to where we are going next.
ADDI-PACK is a long-horizon investment. Here is what is already in your hands today, what we are working on through 2026, and where the platform is heading by 2027.
- 13 PCI/PCIe cards across 5 driver families, all cross-platform Windows + Linux
- Native Windows 10/11 (KMDF) and Linux (DEB & RPM, DKMS)
- C, C++17, Python 3.8+ bindings (more on the way)
- Signed installers, CI/CD-tested
- RTX 64 release: hard real-time on Windows
- Migration of high-demand counting, serial and analog DAQ cards
- Additional language bindings (.NET / C# first)
- Day-one support for new Linux LTS releases
- Config Tools: no-code device discovery & setup
- Full ADDI-DATA portfolio coverage including MSX-E and dataloggers
- Additional RTOS targets (Linux RT, Xenomai, VxWorks…)
- OPC UA / MQTT / EtherCAT plugins
- Native MSX-AIRIS integration for predictive maintenance
Roadmap items are indicative of priorities, not contractual commitments. Specific delivery windows are coordinated through customer agreements and quarterly product reviews.
If you are on a legacy KMDF driver today, nothing breaks.
Existing customers can keep running their current drivers as long as needed. When you are ready, ADDI-PACK is designed to slot in alongside, not replace your existing setup.
Keep your legacy driver
running
Every per-board KMDF driver we have shipped over the years is still available, signed, and supported.
No forced migration.
Install ADDI-PACK
side-by-side
ADDI-PACK does not conflict with legacy installations.
Run both, validate at your own pace.
Use compatibility DLLs for existing apps
Drop-in replacements for our 1.x DLLs let your existing C++/LabVIEW/Delphi applications run on the new stack without code changes.
Adopt the new API where it makes sense
New features, new platforms, new code: write against the unified API.
Old code: keep it. Mix freely.
Legacy driver downloads
For cards not yet in ADDI-PACK, our legacy KMDF and Linux drivers remain the supported path.
