The first model-driven, no-code/low-code approach to industrial automation where the PLC program is a projection of a universal data model — not a hand-drawn control diagram.
Moqui Framework for PLC is an IEC 61131-3 framework for building machine and process applications around reusable motion, device, logging, diagnostics, and MQTT components. What makes it different from a conventional function-block library is that the orchestration on top of those components — the state machines, the sequencing, the operating modes — is AI-assisted and generated from the moqui-device data model, not drawn by hand in a vendor IDE.
Generating PLC code from a model is not new in itself: tools like Simulink PLC Coder have produced IEC 61131-3 from control diagrams and state charts for years. They all start from a control model — a block diagram or a state machine drawn specifically to be compiled down.
moqui-plc starts somewhere else: from a universal data model. The
devices, parameters, requests, and state machines already live in the same
relational schema that governs maintenance, configuration, recipes, audit, and
lifecycle — the Silverston-lineage model inherited through OFBiz/Moqui. The PLC
program is a runtime projection of that model, the same way
moqui-device-gateway projects the
same model into Apache Camel edge routes.
That is the claim worth making: not one more code generator fed by a diagram, but
the first no-code/low-code automation where the controller is generated from the
enterprise model of the plant itself — so the running PLC, its maintenance
history, its configuration governance, and its audit trail are all faces of one
source of truth, instead of separate artifacts kept in uneasy sync. The orchestration logic
is produced from the Moqui StatusFlow
entities (defined in BasicEntities.xml of moqui-framework) combined with the
moqui-device model, through model-driven templates an AI agent fills against the
declared data — under human approval, with the change tracked. The field engineer
still adds the genuinely site-specific edges (InputSignalUpdate,
OutputSignalUpdate, physical terminal mapping): the skill is not removed, it is
focused on what only a human at the machine can decide.
A whole plant reduces to a small set of reusable function blocks — a Hardware Abstraction Layer — parameterised by data:
Axis: a single-axis wrapper around PLCopen Motion Control Part 1/2 function blocks for servo drives and motors.AxisGroup: a coordinated multi-axis wrapper around PLCopen Motion Control Part 4 for robot and kinematic groups.Actuator: a bistable device controller with handshake-based enable/disable sequencing and diagnostics.ActuatorGroup: a demand-driven group controller for multiple bistable actuators, with staging, anti-cycling delays, and wear-balancing rotation.ProcessPid: for modulating devices.SignalMgmt: signal conditioning, scaling, debouncing, and filtering. ...
Typical robot use cases include conveyors with cutters, pick-and-place cells, tripod/robot-arm kinematics, and coordinated axis groups driven through a common FSM-oriented application layer.
The repository also contains mantle-hvac, an application example showing how the
framework can be used outside robotics to orchestrate HVAC equipment, device
rules, and supervisory state machines on top of the same reusable PLC components.
iec61131/moqui/framework/src/main: reusable framework POUs, DUTs, GVLs, and utilities.iec61131/moqui/framework/src/test: motion, device, and pick-and-place test suites.iec61131/moqui/runtime/component/mantle-hvac: example runtime component built on the framework.
The IEC 61131-3 source exports under iec61131/moqui can be imported into any
compliant IDE (CODESYS, Siemens AX, etc.). The repository also includes
moqui.projectarchive, a ready-to-open CODESYS project archive that can be used
for demos, manual validation, and automated test execution.
MoquiStart is the entry-point orchestrator: it initializes clocks, diagnostics,
logging, input/output processing, configuration loading, and then dispatches the
application Main POU.
DeviceConfigMgmt uses Recipe_Management.RecipeManCommands to load device
configurations at runtime. The CODESYS IDE Recipe Manager deploys recipe files to
PlcLogic/ (device root) with the naming recipes<Name>.<Definition>.txtrecipe,
while RecipeManCommands searches relative to the application directory
(PlcLogic/<AppName>/).
To bridge this gap, DeviceConfigCmds calls SetStoragePath before every
ReloadRecipes. The path is configured via deviceConfigStoragePath in
MoquiConf.gvl (default: 'recipes').
The default value is '../', which points to PlcLogic/ (one level above the
application directory PlcLogic/<AppName>/). This matches where CODESYS IDE
automatically deploys recipe files when the Recipe Manager Storage "File path"
field is left empty. Recipe files are named <RecipeName>.<Definition>.txtrecipe
(no prefix).
Do not set a prefix in the Recipe Manager Storage "File path" field — leave it
empty. A non-empty prefix (e.g. recipes) becomes part of the filename, which
would require SetStoragePath to include that prefix as well and creates
unnecessary complexity.
After changing deviceConfigStoragePath, rebuild and redeploy. The CODESYS File
Manager (Tools → Files) can be used to inspect or move recipe files on the
runtime.
To open the CODESYS project for testing, you need to download the CODESYS IDE from:
Use moqui.projectarchive to open the full demo project directly in CODESYS.
This archive is the recommended starting point when you want to explore the
framework behavior, run the included test suites, or prepare a local demo
environment without importing the source tree manually.
To be able to carry out automatic tests or start the framework, it is necessary to connect the CODESYS tasks to the appropriate PLC PROGRAM.
To run the pick and place (pnp) test suite, you need to link:
TestTripodPlanningTask-->TestTripodPlanningPickAndPlaceTestSuiteTask-->PickAndPlaceTestSuite
To run the robot arm with 6 DOF test suite, you need to link:
TestRobotArmPlanningTask-->TestRobotArmPlanningAxisGroupTestSuiteTask-->AxisGroupTestSuite
- moqui-device — the device data model and status flows this framework generates from.
- moqui-math — the dual math model: trajectories, controllers, model lifecycle.
- moqui-device-gateway — projects the same model into Apache Camel edge routes.
CC0 1.0 Universal.