One real-time driver for industrial DAQ
Cross-platform by design.
Built to bridge OT and IT.
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.03.4
Free with every ADDI-DATA device.
How it works
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.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}")
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%08Xn", value);
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.
What ships
- Native installers for:
- Win32,
- Win64,
- 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.
Single CMake tree drives Windows KMDF compilation and Linux kernel-module DKMS packaging. Drivers are signed for Windows Secure Boot.
For production & quality
ADDI-PACK ships kernel-mode drivers built for industrial uptime. The same code that runs in your R&D lab is what holds your machines together at 3 AM on a Sunday.
Hardware support
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 | APCI-1648; 1696 | ● 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; 1532; 2016; 2200; 040 | CPCI-1500; 1564 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Zähler xPCIx-1710; 1711; 1712 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Längenmessung xPCIx-3701-3702 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Serielle Schnittstelle xPCIx-7300; 7300-3; 7420; 7420-3; 7500; 7500-3; 7800 | ● Use KMDF Legacy Driver | ● Use Linux Legacy Driver |
| Achsensteuerung 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.
Architecture
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
↓
Polymorphic C++ 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
Roadmap
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.
- 10 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)
- Compatibility DLLs for legacy 1.x apps
- Full Doxygen + Sphinx documentation
- 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
- Broader binding catalog (Delphi, Java, Rust…)
- 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.
Migrating from legacy drivers
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.