From 5be48b6bbbe4db7b15e67f8c30c5015edcbaa86c Mon Sep 17 00:00:00 2001 From: Clio Liu Date: Wed, 2 Sep 2026 17:34:58 +1000 Subject: [PATCH] fix: CI Server on cicore1 is R1.05, not R1.03 Corrected in README.md, CLAUDE.md, 02-environment/README.md and 03-plc/VERSIONS.md. The @VERSION 1.03.00 header inside the .qli files is the quickload FILE FORMAT version, not the CI Server release. Left alone. This also sharpens a caveat that was previously stated wrongly. The EQP-E-DUP_ITEM rejection - an item import fails if two items share an IO_ADDRESS - was observed on 2026-08-14 on the DEVELOPMENT machine, which ran R1.03. Production runs R1.05, where it has never been tested. The design still works around it by publishing level and speed in % only, and that workaround costs nothing; but anyone wanting a second unit for a measurement should try it on R1.05 before assuming they need a second PLC register to carry it. --- 02-environment/README.md | 2 +- 03-plc/VERSIONS.md | 16 +++++++++++----- 04-scada/modbus_points/README.md | 6 +++++- CLAUDE.md | 2 +- README.md | 2 +- 5 files changed, 19 insertions(+), 9 deletions(-) diff --git a/02-environment/README.md b/02-environment/README.md index d4df402..c3856d4 100644 --- a/02-environment/README.md +++ b/02-environment/README.md @@ -5,7 +5,7 @@ Two machines. One runs the PLC, the other runs the SCADA. Both sit on the | Role | Hostname | LAN | Notes | |---|---|---|---| -| **SCADA** — Yokogawa CI Server R1.03 | `yau-poc-cicore1` | `10.0.0.21` | Windows. Polls the PLC over Modbus TCP. | +| **SCADA** — Yokogawa CI Server R1.05 | `yau-poc-cicore1` | `10.0.0.21` | Windows. Polls the PLC over Modbus TCP. | | **PLC** — OpenPLC Runtime v4 in Docker | `yau-sls-poc-lin001` | `10.0.0.17` | Ubuntu 22.04 on Azure, public IP `20.211.144.151`. **Shared, live host** — see below. | Also on the network: an Active Directory domain controller at `10.0.0.5` diff --git a/03-plc/VERSIONS.md b/03-plc/VERSIONS.md index 24d5045..b567063 100644 --- a/03-plc/VERSIONS.md +++ b/03-plc/VERSIONS.md @@ -39,7 +39,7 @@ differently — that is said explicitly. | Component | Version | Where | |---|---|---| -| **Yokogawa CI Server** | R1.03 | `yau-poc-cicore1` (`10.0.0.21`) | +| **Yokogawa CI Server** | R1.05 | `yau-poc-cicore1` (`10.0.0.21`) | ## Versions that actually matter @@ -67,7 +67,13 @@ See `register-map.csv`, which carries resolved addresses. `qw_count: 1024` is *why* `%MW0` is holding register 1024. Change that file and every SCADA address moves. -**CI Server R1.03 vs R1.05.** One R1.03 behaviour is load-bearing here: an item -import is rejected if two items share an `IO_ADDRESS` (`EQP-E-DUP_ITEM`). The SCADA -design works around it by publishing one unit per register. If you move to R1.05, -re-check that before assuming the workaround is still needed. +**One CI Server behaviour is load-bearing, and it was observed on a different +release.** An item import is rejected if two items share an `IO_ADDRESS` +(`EQP-E-DUP_ITEM`). The SCADA design works around it by publishing one unit per +register — level and speed in % only, not in both % and engineering units. + +That rejection was seen on **2026-08-14 on the development machine, which ran +R1.03**. Production `yau-poc-cicore1` runs **R1.05**, where the constraint has +never been tested. The workaround is harmless either way, but if you need a second +unit for a measurement, try it on R1.05 before assuming you need a second PLC +register for it. diff --git a/04-scada/modbus_points/README.md b/04-scada/modbus_points/README.md index d41e73b..9a3cbd5 100644 --- a/04-scada/modbus_points/README.md +++ b/04-scada/modbus_points/README.md @@ -131,7 +131,8 @@ HMI masks. > [!IMPORTANT] > **One item per I/O address — a register carries exactly one unit.** Publishing > level in m *and* % as two Modbus points on the same `IO_ADDRESS` was tried on -> 2026-08-14 and CI Server R1.03 refused the item import: +> 2026-08-14 on the development machine (R1.03) and CI Server refused the +> item import: > > ``` > EQP-E-DUP_ITEM, I/O address of item already defined @@ -142,6 +143,9 @@ HMI masks. > for the same measurement needs a second **PLC** register publishing it, not a > second view of one register — a register-map change, not a SCADA change. > Level and speed are therefore published in % alone. +> +> **Not retested on R1.05**, which is what production runs. The workaround costs +> nothing, but if you need a second unit, try it before assuming you cannot. **Setpoints are written in %.** A setpoint entered as 70.0% arrives at the PLC as 4200 mm. One decimal of % is a 6 mm step, so not every mm value is reachable — diff --git a/CLAUDE.md b/CLAUDE.md index ba6ae53..f29664a 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -38,7 +38,7 @@ is polled by CI Server. Treat everything on those machines as production. | Role | Host | Address | |---|---|---| -| SCADA — CI Server R1.03 | `yau-poc-cicore1` | `10.0.0.21` | +| SCADA — CI Server R1.05 | `yau-poc-cicore1` | `10.0.0.21` | | PLC — OpenPLC Runtime v4 container | `yau-sls-poc-lin001` | `10.0.0.17`, public `20.211.144.151` | SSH alias `lin001` → `azureuser@20.211.144.151`. `10.0.0.17` is only routable from diff --git a/README.md b/README.md index c95ab76..67c6077 100644 --- a/README.md +++ b/README.md @@ -17,7 +17,7 @@ polled over Modbus TCP by CI Server, with operator displays that command it. | Role | Host | Address | |---|---|---| -| **SCADA** — Yokogawa CI Server R1.03 | `yau-poc-cicore1` | `10.0.0.21` | +| **SCADA** — Yokogawa CI Server R1.05 | `yau-poc-cicore1` | `10.0.0.21` | | **PLC** — OpenPLC Runtime v4, in Docker | `yau-sls-poc-lin001` | `10.0.0.17` | **Architecture invariant:** OpenPLC Runtime is the Modbus TCP **server** (slave) on