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
- Back up
library/CmpAtomModbus.libraryand open it in CODESYS. - Retain Project Information title
CmpAtomModbusand namespaceatMb. - Retain the Standard and SysTime references required by the IEC code.
- 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. - 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.