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.
52 lines
2.4 KiB
Markdown
52 lines
2.4 KiB
Markdown
# 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.
|