24afc51672
The point list handed over in August named the points PS_STN_WET_WELL_LEVEL and the like. Those were never CI Server names. They came from gen_scada_points.py on the PLC side, which describes its own output as "a starting point for CI Server configuration, not a CI Server import file", and the CI Server generator ignored them entirely - it names points from its own address-keyed table. The names appear in no .qli export, and nowhere else in the WRPS project at all. This is the corrected delivery. ci-server-points.csv is keyed on the CI Server ITEM each point feeds, with the Modbus station and the point name beside it, so all four namespaces are visible in one row: LIT-101 instrument tag %QW0 PLC symbol and address WRPS_PLC:STN_LEVEL CI Server point - station, colon, point name AID.WRPS.STN.LEVEL CI Server item - what the historian is keyed on The 49 rows were joined onto the .qli exports by function code and Modbus address: 49 matched, 0 unmatched. The item and point names are read from the exports, not invented here. The six .qli files come too, unchanged. gen_historian_items.py needs them, and until now they existed only on one laptop behind a --wrps path - so the one file the rules say must never be hand-edited could be regenerated by exactly one person. 84 KB buys the team that back. These are uncontrolled documents: no revision, no effective date, no approval. The README says so, says how to ask for a fresh set, and records the two things that bite - that PS_ survives legitimately as four poll group names, and that his_group.qli and the live export disagree about the sample rates, with the live one winning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3 KiB
CI Server as-built configuration — delivered inputs
These files are inputs, not outputs. Nothing here is edited in this repository.
They are the WRPS CI Server configuration as built, handed over manually. They are
not controlled documents: no revision, no effective date, no approval. They are
copies, and the assistant never reads them at runtime — they are the source
scripts/gen_historian_items.py derives db/seed/historian_items.csv from.
| File | What it is |
|---|---|
ci-server-points.csv |
The 49 Modbus points as configured, keyed on the CI Server item they feed, with the station and point name beside it |
wrps_item_df.qli |
@ITEM_DF — the 49 items, units, formats |
wrps_section_df.qli |
@SECTION_DF — the six AID.WRPS.* sections |
wrps_modbus_point_df.qli |
@MODBUS_POINT_DF — the 49 point definitions on station WRPS_PLC |
item_his.qli |
which items are historised, and in which group |
export_his_group.qli |
the live historisation rates, exported from the running server |
his_group.qli |
the intended rates from the source project — see the warning below |
Four namespaces, and which one is which
LIT-101 instrument tag the field device
%QW0 PLC symbol/address the register the PLC writes
WRPS_PLC:STN_LEVEL CI Server point Modbus station : point name
AID.WRPS.STN.LEVEL CI Server item what the historian is keyed on
The historian is keyed on the item, and only the item. Modbus carries register numbers, not names, so the point layer and the item layer are free to differ.
PS_* is not one of these namespaces. An earlier delivery of ci-server-points.csv
carried names like PS_STN_WET_WELL_LEVEL in place of the item name. Those were a
proposal derived from the PLC register map that CI Server never adopted — the point
names it actually uses are the ones above. They caused a real defect in this repository
and must not reappear. The only legitimate PS_ names are the four Modbus poll
groups in the poll_group column: PS_STATUS_BITS, PS_PUBLISHED, PS_SETPOINTS
and PS_SIM_CONTROL. Those are live configuration.
Two rates disagree, and the live one wins
his_group.qli says WRPS_ONE_SEC is a 1 second group paired with a 60 second
WRPS_ONE_MIN. export_his_group.qli, taken from the running server, says
WRPS_ONE_SEC runs at 5 seconds and the second group is WRPS_THIRTY_SEC at
30 seconds. The live export is what the historian actually did, so it is the
default. A measure that assumed 60 seconds was wrong by twelvefold — never hardcode a
sample interval, read scan_interval_seconds from the item.
Refreshing these
Ask for a fresh delivery of the CI Server configuration, replace the files here, then:
python scripts/gen_historian_items.py
Re-run pytest api/tests, reload pg-ai, and re-run the Phase 1 gate in
scripts/verify.sh. Do not hand-edit db/seed/historian_items.csv — it is generated.