How PDComm is built
Every PDComm product is built the same way: one independent native library per protocol, with language bindings and simulators on top of it.
Native libraries (C ABI)├── pdcomm_ffi SECS/GEM├── pdcomm_modbus_ffi Modbus└── pdcomm_opcua_ffi OPC UA ▲ ├── C++ headers, .NET bindings, Qt/MFC helpers ◀── your application └── Simulators (GUI, headless, MCP)Native libraries and the C ABI
Section titled “Native libraries and the C ABI”Each protocol implementation lives in one shared library: a .dll on Windows, a .so on Linux, and a .dylib on macOS. The library exposes its features as C functions, and this C application binary interface (ABI) is the base for every other language.
| Product | Library | C headers |
|---|---|---|
| SECS/GEM | pdcomm_ffi |
pdcomm.h, pdcomm_tcp.h, pdcomm_gem*.h, pdcomm_secs1.h, and others |
| Modbus | pdcomm_modbus_ffi |
pdcomm/modbus/pdcomm_modbus.h |
| OPC UA | pdcomm_opcua_ffi |
pdcomm/opcua/pdcomm_opcua.h |
The libraries are independent of each other, so you take only the SDKs you need, and one application can use several of them.
Each product’s C ABI has its own calling style: SECS/GEM uses structures and handle functions, Modbus passes one JSON command per operation to pdcomm_modbus_call, and OPC UA uses handles and polling functions. Some rules are shared:
- Functions that can fail return a status code: 0 means success, anything else is an error.
- For output of unknown length, you ask for the size and then copy. If your buffer is too small, nothing is written and you learn the size you need.
- You release every handle you create exactly once, with its release function.
- Each library reports its ABI version at run time; check it when your application starts.
- Starting new communication needs a PDComm license for the product’s module. Each library checks its own license sources, and connections that are already running are never stopped. See Install and check a license.
The shared status codes, buffers, and diagnostic logging functions are in the common API reference. For product-specific rules, see each product’s API reference.
Language bindings
Section titled “Language bindings”- C++: header-only wrappers that hold handles in RAII objects and report errors as exceptions.
- .NET: assemblies that call the C ABI through P/Invoke. The SECS/GEM binding targets .NET 10; the Modbus and OPC UA bindings target .NET 8.
- Qt and MFC: Modbus and OPC UA come with helper headers for Qt and MFC applications. The Qt helpers exchange values in Qt types such as
QJsonObject. Make long calls, such as connecting or sending a request, from a worker thread rather than the GUI thread.
Simulators
Section titled “Simulators”The simulator of each protocol runs on the same native library and has three front ends:
| Front end | Use it to |
|---|---|
| GUI | Play the peer device on screen and watch the messages. |
| Headless | Run without a screen, driven by JSON commands on standard input or by scenario files, for automated tests and CI. |
| MCP | Let AI tools drive the simulator through the Model Context Protocol (MCP). |
A simulator talks to the program you develop in place of the real peer. When development is done, run acceptance tests with the real equipment.
Virtual serial ports let you test serial communication without devices. Diagnostic logs record what the SDKs and simulators do. pdcomm-docs searches these docs from a terminal or an AI tool.