Clio Liu
13a05d0135
The PLC program from the old repo's 04-plc/, flattened into one folder and
checked against the running system.
Verified during the move:
- build.py regenerates register-map.csv byte-identically (69 points)
- polled the live PLC: the SIMULATION build is what is deployed and
running, %MW21=2 wet weather, values moving, run hours accumulating
- addresses, %MW HR1024 segmentation and %QW17/%QW7 signedness all
match the map
Corrections against the old repo:
- 10_globals.st header cited WRPS-CTL-002 (the FDS); it means CTL-003
- build.py wrote the map to its parent directory; now beside itself
- deploy/README.md was a single-file folder; now DEPLOY.md
- dropped the empty editor-devices/remote/
- README no longer claims the simulation build is uncompiled - it is
the one running
Two open items are now stated plainly rather than buried:
- none of the 20 acceptance tests in CTL-003 have ever been run
- the OpenPLC Editor lived only on the retired dev-ubuntu host, so
there is currently NO route to deploy a new program (DEPLOY.md 0)
Documents the setpoint distinction: IO_MUX seeds %MW defaults once at
first scan, operators retune them live, and that tuning exists only in
the container volume - a restart reverts it.
|
||
|---|---|---|
| .. | ||
| servers | ||
| configuration.json | ||
| pin-mapping.json | ||
| README.md | ||
Editor devices/ — reference copy, NOT generated
These files are the hand-made half of the OpenPLC Editor project. Everything
else in the project (project.json, pous/) is generated from src/ by
../gen_project.py; devices/ is not, because it is configured through GUI
dialogs and holds machine-specific settings.
They live here so the setup is not lost when the Editor project is recreated —
which it will have to be, because the machine that held it has been retired. See
../DEPLOY.md §0.
This is a reference copy, not the live one. DEPLOY.md §A is the procedure
for reproducing it through the GUI; these files show what the result should look
like.
Captured 2026-08-14, from the working setup that first served Modbus data.
| File | What it is |
|---|---|
configuration.json |
Device board (OpenPLC Runtime v4) and runtime address |
pin-mapping.json |
Board pin map — Editor default, unused by this program |
servers/Modbus01.json |
The Modbus TCP server definition — the file that enables the runtime's modbus_slave plugin |
Two things to know before reusing these
configuration.json says localhost, and that is now wrong. It was correct
when the Editor and the runtime were on the same host. The runtime is now on
yau-sls-poc-lin001, so a new Editor installation must point at 10.0.0.17,
port 8443.
servers/Modbus01.json says networkInterface: 0.0.0.0, and that is correct —
leave it alone. It looks like it contradicts the container publishing port 502
on 10.0.0.17 only, but the two settings operate at different layers:
| Layer | Setting | Effect |
|---|---|---|
| PLC runtime, inside the container | 0.0.0.0:502 |
the Modbus slave listens on all of the container's own interfaces |
| Docker, outside the container | 10.0.0.17:502:502 |
only the host's LAN address forwards to it |
Narrowing the runtime's own bind address gains nothing and risks the slave not
listening at all. The Docker publish is the security control. See
../../02-environment/.
What is deliberately absent
There is no remote/ directory. Remote Devices is the Modbus master
configuration — it would make the PLC poll someone else, inverting the
architecture invariant, and its IO groups claim %IW addresses that collide with
the field inputs in src/10_globals.st.
CI Server needs no entry in the PLC project at all. It is the client; it simply connects.