Auto/Codesys-Library-Atom-Modbus
6
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Threaded version 0.7

Browse Source
This commit is contained in:
snkbyte
2026-10-06 23:50:02 -06:00
parent fe5dcbe715
commit 490c9bdc5b
21 changed files with 891 additions and 1010 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/BUILD-AND-USAGE.md
+45 -52
View File
@@ -1,68 +1,61 @@
# Build and deployment
# Build and upgrade to atMb 0.6
## Build native C
## Build on ARM64 Linux
From the repository root on the target Linux machine:
From the repository root:
```sh
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
mkdir -p artifacts/arm64
cp component-source/component/out/libCmpAtomModbus.so artifacts/arm64/
```
`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.
Run these commands on an ARM64 build machine. On an x86 laptop, ordinary gcc
builds x86 output; use the appropriate cross-compiler instead.
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.
## Cross-compile ARMv7 hard-float on the laptop
## Update the CODESYS library
```sh
sudo apt install gcc-arm-linux-gnueabihf binutils-arm-linux-gnueabihf make m4 dos2unix
make -C component-source/component SDKDIR="$(realpath ExtensionSDK)" clean
make -C component-source/component SDKDIR="$(realpath ExtensionSDK)" CC="arm-linux-gnueabihf-gcc -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard" all
mkdir -p artifacts/armv7hf
cp component-source/component/out/libCmpAtomModbus.so artifacts/armv7hf/
arm-linux-gnueabihf-readelf --version-info artifacts/armv7hf/libCmpAtomModbus.so
```
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 makefile supplies `-pthread` during compilation/linking. Always clean between
architectures. Check `file`, ELF attributes, NEEDED libraries and GLIBC symbol
requirements against the target. Adding pthread can change the required glibc
version; the previously checked binaries do not establish compatibility of this build.
The WL2000 runtime was ARMv7/VFPv3-D16 hard-float. The UC20 OS was ARM64/glibc 2.39;
its runtime architecture/component support still needs target verification.
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.
## CODESYS
## Runtime deployment
1. Keep the prior working `.library` and PLC application for rollback.
2. Create a fresh library project named `CmpAtomModbus.library` and import
`library/atMb-Threaded.export`. Importing into an old project does not delete
renamed/removed objects; a fresh project avoids duplicate old methods.
3. Preserve Project Information title `CmpAtomModbus`, namespace `atMb`, and
Standard/SysTime references. Verify library version 0.6.0.0 in Project Information.
4. Add a C Implemented Library object and attach the **new 0.4.0.0** component for
each exact target device. Do not attach files from `backup/`.
5. Compile, install the library and update application references. Rename application
diagnostic accesses using `RENAMED-MEMBERS.json`. `ClientTCP`/`ClientRTU` and
request function-block names remain the same.
6. Use a full download and verify the runtime loads component 0.4.0.0. If manually
preloading an old component, remove/replace that preload during maintenance so
it does not conflict with the embedded component.
7. Start on a bench with the default worker settings; verify unplug/replug, device
reboot, disabled client and PLC stop/start behavior before 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.
The C ABI layout/signature is unchanged (0x709EE65B, API 0.2.0.0). Component version
is 0.4.0.0. Command 41 capability checking prevents this IEC export operating with
an old component; it does not eliminate target/compiler compatibility checks.
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](USER-GUIDE.md): examples, polling, RTU, slave, timeout and recovery.
- [API reference](API-REFERENCE.md): all objects from the last supplied working export.
- [Validation](VALIDATION.md): exact scope of checks performed.
Host validation: `make -C component-source test`. Host frame/function compilation
used the supplied SDK and generated headers; a fresh SDK/M4 build and the IDE
compile were not available in the execution environment.