Files
Codesys-Library-Atom-Modbus/docs/BUILD-AND-USAGE.md
T
2026-09-30 22:41:23 -06:00

3.4 KiB

Build and deployment

Build native C

From the repository root on the target Linux machine:

sudo apt install build-essential m4 dos2unix python3
make -C component-source/component SDKDIR="$(realpath ExtensionSDK)" clean
make -C component-source/component SDKDIR="$(realpath ExtensionSDK)" all
file component-source/component/out/libCmpAtomModbus.so
make -C component-source test

component-source/component/ is the active SDK build directory. Its CmpAtomModbus.c includes the protocol source files as one translation unit. The removed generated/ directory contained original unimplemented stubs; it was not used by this makefile. Preserve the active CmpAtomModbusItf.m4 and CmpFrame.c; they define ABI registration and cleanup.

The makefile registers component version 0.3.0.0. The supplied external atMbCall_cext API retains signature 0x709EE65B and API version 0.2.0.0. Do not change the external parameter layout or regenerate it just because the library title/version was edited. Full SDK/M4 builds must be checked on the target.

Update the CODESYS library

  1. Back up library/CmpAtomModbus.library and open it in CODESYS.
  2. Retain Project Information title CmpAtomModbus and namespace atMb.
  3. Retain the Standard and SysTime references required by the IEC code.
  4. In its C Implemented Library object, update the native binary for the exact device target with the newly built libCmpAtomModbus.so. Use the component naming/settings already present in the working project.
  5. Compile the library, save/install it in Library Repository and update application references. Test with a full download for native component changes.

The working .library is preserved unchanged in this cleanup. Updating a separate .so file does not automatically update the binary embedded inside the library. The standalone artifact is retained for deployment/build comparison; rebuilding it does not imply it is identical to the currently embedded implementation.

Runtime deployment

Use the established embedded-library deployment or a manual bench installation; avoid loading two versions of the same component simultaneously. The earlier Pi setup manually loaded /usr/lib/libCmpAtomModbus.so with Component.1=CmpAtomModbus under [ComponentManager] in /etc/CODESYSControl_User.cfg. When switching to embedded deployment, remove only that manual preload entry during maintenance and restart the runtime as required.

For a manual installation, stop the runtime before replacing its component and restart afterwards. Check /var/log/codesyscontrol.log for the loaded component and version; /var/opt/codesys/codesyscontrol.log was stale on the development Pi. No deployment or runtime restart is performed by this cleanup.

Different Linux targets

Build natively on the desired CPU or use a matching cross-toolchain. ARM64, ARM32 and x86-64 outputs are distinct. SDK, CODESYS runtime interface and libc compatibility also matter. A successful host protocol test does not validate native component loading into every runtime version. RTU support uses Linux termios/ioctl; verify serial permissions, driver behavior and physical timing on the target.

Further documentation

  • User guide: examples, polling, RTU, slave, timeout and recovery.
  • API reference: all objects from the last supplied working export.
  • Validation: exact scope of checks performed.