Clio Liu
55279ca78f
Adds what the folder was missing for someone picking it up cold.
as-built/ the STruC++ output copied out of the live container - the C++
the PLC is actually executing, plus program.st and the Modbus
buffer config. The running image was made with docker commit
and exists in no registry, so this is the only other copy of
the compiled form.
Verified while copying: the deployed program.st matches
build/wrps.st generated from src/. Identical POU structure,
ZERO differences in non-declaration lines. src/ is genuinely
canonical and the running PLC agrees with it.
VERSIONS.md every version read from the running system, not from
documentation: runtime v4.1.10, STruC++ 0.6.2, Editor
4.2.11, Debian 12, g++ 12.2, pymodbus 3.11.2, CI
Server R1.03. Plus which plugins are enabled -
ethercat is on for no reason - and a v3-vs-v4 table,
since most OpenPLC guidance online is for v3 and the
%MW HR1024 change silently produces wrong data.
GETTING-STARTED.md three questions answered in a page: how to modify the
program, how to stand up a new PLC container from
scratch, how to move this one. Includes the compose
file, the Editor steps that are not generated and are
always missed, and a symptom-to-document table.
|
||
|---|---|---|
| .. | ||
| conf | ||
| strucpp_runtime/include | ||
| c_blocks.h | ||
| configuration.cpp | ||
| debug-map.json | ||
| defines.h | ||
| generated.hpp | ||
| generated_debug.cpp | ||
| pou_CONTROL.cpp | ||
| pou_FB_DUTY_SELECT.cpp | ||
| pou_FB_HEADROOM.cpp | ||
| pou_FB_LEVEL_CTRL.cpp | ||
| pou_FB_PUMP.cpp | ||
| pou_IO_MUX.cpp | ||
| pou_SIMULATION.cpp | ||
| program.st | ||
| program.st.map.json | ||
| README.md | ||
as-built — what is actually running
Copied out of the live openplc-runtime container on 2026-09-02, from
/workdir/core/generated/. This is the compiled artefact set the running PLC was
built from — the ground truth, as opposed to ../src/, which is the intent.
Warning
Do not edit anything in this folder and do not build from it. It is a snapshot for reference and recovery. The editable source is
../src/.
Why keep it
The running PLC is a docker commit image. The compiled program lives in the
container's writable layer, not in a volume and not in any registry. If that image
is lost, and the OpenPLC Editor is still unavailable (../DEPLOY.md §0), this
folder is the only remaining copy of the compiled form of the program.
It is also the proof of what is deployed: you can read the C++ the PLC is actually executing, rather than inferring it from the ST.
Contents
| File | What |
|---|---|
program.st |
The ST as the Editor serialised and uploaded it |
generated.hpp |
STruC++ declarations for every POU and global |
pou_CONTROL.cpp etc. |
One C++ file per POU — the compiled logic |
configuration.cpp |
The task configuration: plc_task, 100 ms, three program instances |
generated_debug.cpp, debug-map.json |
Variable maps for the Editor's debugger |
program.st.map.json |
Line map from the generated C++ back to program.st |
strucpp_runtime/include/ |
The STruC++ runtime headers the build needs |
conf/modbus_slave.json |
The Modbus buffer layout — qw_count: 1024 is why %MW0 is HR 1024 |
conf/ethercat.json |
0 bytes. Emitted by the Editor by default; it is what leaves the EtherCAT plugin enabled for no reason. |
c_blocks.h, defines.h |
Small generated headers |
Built 2026-08-14. Loaded as libplc_1786668930820554523.so.
Verified against ../src/ on 2026-09-02
program.st was compared with build/wrps.st generated from ../src/, after
stripping comments and normalising whitespace:
POU structure identical - FB_PUMP, FB_DUTY_SELECT, FB_LEVEL_CTRL,
FB_HEADROOM, CONTROL, IO_MUX, SIMULATION,
CONFIGURATION Config0, three task instances
Non-declaration lines 0 differences, in either direction
Declaration lines differ in formatting only - the Editor requires one
declaration per line, and holds VAR_GLOBAL in
project.json rather than in the ST
The deployed program is this repo's source. ../src/ is canonical, and the
running PLC agrees with it.
Using this for an emergency change
If the Editor is unavailable and something must change now, the container can rebuild from these files without any external toolchain — g++ 12.2 and Make are inside it:
# on yau-sls-poc-lin001
docker exec -it openplc-runtime bash
# edit core/generated/pou_*.cpp
./scripts/compile.sh # rebuilds build/new_libplc.so
Caution
This is break-glass, not a workflow. You would be editing generated C++, which immediately diverges from
../src/, and the next proper deployment silently discards your change. The PLC also stops while it reloads. If you do it, record what you changed and port it back into../src/the same day.
Prefer restoring the Editor. See ../DEPLOY.md §0.