simatic-ax

SIMATIC AX port

This directory contains the Siemens SIMATIC AX port of moqui-plc.

Disclaimer: this port produces a semi-finished build artifact for Siemens PLCs, not a deployment-ready application. It must be adapted and validated on a real physical PLC before any production use. This requirement is especially critical for the Motion profile, where Technology Objects (axes, kinematics groups) must be defined and configured in TIA Portal — a compile-only result on s7generic/llvm does not constitute functional validation of motion behavior.

The canonical, vendor-neutral source remains the IEC 61131-3 tree under:

../iec61131/moqui/

The AX source tree under src/ is generated from that canonical tree, except for a limited set of manually maintained Siemens-specific overrides.

Current status

Both build profiles compile with 0 errors on s7generic and llvm targets.

Process profile (validated baseline)

• framework initialization and configuration management;
• logging and diagnostics required by the process application;
• generic actuator and PID abstractions;
• the complete mantle-hvac application;
• file-based AX recipes generated from the canonical CODESYS recipe files;
• a textual AX task configuration bound to MoquiStart.

Motion profile (compile-complete)

The Motion profile adds the complete PLCopen Motion Control layer:

• Axis.st — single-axis FSM covering power, homing, jog, absolute/relative/additive/superimposed moves, gear-in, gear-in-pos, cam-in, phasing, position/velocity/acceleration profiles, touch probe, parameter read/write;
• AxisGroup.st — coordinated multi-axis FSM over a kinematics group (linear, circular, direct absolute/relative moves);
• compile-only compatibility stubs (AxisMotionCompat.st, AxisGroupCompat.st) for Siemens Motion Control types and PLCopen FBs that have no AX standard-library equivalent.

Both files are manual overrides and are never regenerated by the staging script. A compile result is not equivalent to Motion functional validation — runtime testing in TIA Portal with configured Technology Objects and kinematics is a separate milestone.

What is missing compared to IEC 61131-3

The only intentional gap versus the canonical IEC source is MQTT. The intended Siemens integration path is OPC UA; the AX OPC UA adapter is not yet part of this source tree.

The logging identity contract is nevertheless identical to the canonical IEC implementation: loggerName is the exact owning Device.deviceId; an empty source denotes a device-scoped event and a non-empty source is the exact pre-existing Parameter.parameterId. The HVAC ParameterLogger runs after DeviceManager and samples the 29 modeled numeric parameters on clks.clock1minute.

Directory layout

simatic-ax/
├── apax.yml
├── apax-motion.yml       profile template for the Motion build
├── apax-process.yml      profile template for the Process build
├── apax-lock.json
├── README.md
├── src/
│   ├── configuration.st
│   └── moqui/
│       ├── framework/
│       └── runtime/component/mantle-hvac/
└── src-manual/           manually maintained AX overrides (not regenerated)
    └── framework/src/main/org/moqui/motion/

The corresponding canonical source is located in:

iec61131/moqui/
├── framework/
└── runtime/component/mantle-hvac/

Porting model

The port uses three categories of source files.

Generated files

Portable IEC 61131-3 files are staged automatically from ../iec61131/moqui with only the syntax and compatibility changes required by AX.

The converter must preserve, wherever possible:

• file names and directory structure;
• POU, DUT and variable names;
• comments;
• indentation and blank lines;
• declaration order;
• FSM structure;
• PLCopen Function Block call order.

Manual AX overrides

Some files depend on Siemens libraries or AX-specific runtime behavior and are maintained manually under src/moqui. The staging script preserves these files instead of regenerating them.

Important overrides include:

• logging and diagnostic adapters;
• file-based recipe access;
• PID and clock adapters;
• selected application files already adapted for AX;
• framework/src/main/org/moqui/motion/Axis.st;
• framework/src/main/org/moqui/motion/AxisGroup.st.

The authoritative override list is defined in:

../scripts/ax_port/policy.py

Excluded files

The AX build deliberately excludes:

• MQTT sources;
• CODESYS JSON serialization backends;
• test fixtures and examples that require IDE-configured hardware;
• pick-and-place and robot-arm examples;
• AxisTestSuite and AxisGroupTestSuite;
• OPC UA sources until the AX adapter is implemented.

These exclusions affect only the AX staging tree. They do not remove files from the canonical IEC source.

APAX dependencies

The project currently declares:

@ax/simatic-1500-clocks
@ax/simatic-1500-fileaccess
@ax/system-strings

The deprecated @ax/simatic-1500-motioncontrol-native-v7 package (ABI 7.0.0) was removed because it is incompatible with STC ABI 8.0.0. The Motion profile uses compile-only stubs in src-manual/ instead. When Siemens publishes an ABI-8-compatible motion library it can be re-added to apax.yml.

Build profiles

Process profile

Stages the validated non-Motion process/HVAC subset:

apax prepare-process-build
apax build-process

Equivalent explicit commands:

python ../scripts/prepare-ax-process-build.py --profile process
apax build

The process profile is the regression baseline and must continue to pass HvacTestSuite.

Motion profile

Stages the process subset, the six public Motion DUT/enum files, and preserves the manual Axis and AxisGroup overrides:

apax prepare-motion-build
apax check-motion-overrides
apax build-motion

The Motion build targets both s7generic and llvm. A successful compile does not replace functional testing in TIA Portal with configured axes and kinematics.

Full profile

The Python staging script also defines a full profile for future work:

python ../scripts/prepare-ax-process-build.py --profile full

It is not the validated production profile and may include portable files whose Siemens adapters are not complete.

Recipe backend

CODESYS .txtrecipe files remain the canonical engineering format. AX runtime recipes are exported into compact files under:

src/moqui/runtime/component/mantle-hvac/data/

Files include:

• index.csv: available recipe/configuration index;
• recipe-schema.csv: numeric field identifiers and type contract;
• *.axrecipe: runtime values using id;type;value rows.

The AX runtime backend is implemented in:

src/moqui/framework/src/main/org/moqui/device/DeviceConfigCmds.st

The PLC runtime supports loading configurations. Creation, persistence and deletion of engineering recipes remain external responsibilities.

Conversion and validation scripts

From the repository root:

scripts/prepare-ax-process-build.py   official AX staging command
scripts/audit-ax-fidelity.py          checks comment and indentation drift
scripts/check-motion-overrides.py     tracks canonical and AX Motion hashes
scripts/export-ax-recipes.py          exports AX runtime recipe files
scripts/export-codesys.py             extracts IEC61131 source from CODESYS project archives
scripts/ax_port/                       shared policies and transformations
scripts/tests/                         Python regression tests

Run the Python checks with:

apax test-port-scripts
apax audit-fidelity

Expected validation sequence

For process changes:

apax test-port-scripts
apax prepare-process-build
apax audit-fidelity
apax build

Then run HvacTestSuite using the established AX test procedure.

For Motion changes:

apax test-port-scripts
apax prepare-motion-build
apax check-motion-overrides
apax build-motion

Then validate the configured Technology Objects and kinematics in TIA Portal.

Generated and local directories

Do not commit local package caches or build output:

.apax/
bin/
obj/

They are recreated by APAX and are already covered by .gitignore.

Porting principles

1. iec61131/moqui remains the semantic source of truth.
2. Generated AX files receive only necessary syntax and documented compatibility changes.
3. Manual overrides are explicit and preserved across staging.
4. No refactoring is performed merely to reduce repeated PLC code.
5. MQTT is not part of the Siemens target.
6. Motion examples and tests that depend on graphical TIA Portal configuration are not generated.
7. A compile result is not equivalent to Motion functional validation.