This commit is contained in:
Jonas Bengtsson
2026-10-07 17:13:51 +02:00
parent 1c64aeb071
commit 2aa040e757
11 changed files with 749 additions and 29 deletions
+58
View File
@@ -62,6 +62,12 @@ opcda-diagnozer list-tags "Simulation Items" "Bucket Brigade" # equivalent
opcda-diagnozer list-tags --recursive "Simulation Items" # whole subtree
opcda-diagnozer list-tags # every tag on the server
# read tags right now (validation tool) — no config needed with --server
opcda-diagnozer read --server Matrikon.OPC.Simulation.1 "Bucket Brigade.Int1"
opcda-diagnozer read --json "Bucket Brigade.Int1" "Bucket Brigade.Real8"
opcda-diagnozer read # the config's tags
opcda-diagnozer read --source cache "Bucket Brigade.Int1" # server cache, no device trip
# validate config
opcda-diagnozer check-config
@@ -89,6 +95,17 @@ device path is either one dotted string (`"Simulation Items.Bucket Brigade"`) or
several quoted branch names — use the latter when a branch name itself contains a
dot. On flat-namespace servers (`organization: flat`) every tag hangs directly off
the root; `list-tags` without a device lists them all.
Every connecting verb (`read`, `probe`, `list-devices`, `list-tags`) accepts
`--server PROGID` and `--host HOST` to **override the config's `opc` section** —
point a one-shot check at any server without touching the deployed config.yaml.
With `--server` given, no config file is needed at all; without it, the config must
exist (and `probe`/`read` read the config's tag list unless tags are passed).
`read` prints one row per tag with the decoded quality and the device timestamp;
a non-GOOD or failing tag makes the exit code non-zero, so it doubles as a
scriptable health check. `--source cache` reads the server cache instead of
forcing a device round-trip.
### Configuration example (`config.example.yaml`)
```yaml
@@ -188,6 +205,47 @@ Notes:
(`py install 3.14 -a x86`) or the installer from python.org ("Download Windows
installer (32-bit)").
## Building the Windows executable
`scripts/build_exe.ps1` packages the CLI as a standalone **32-bit** console exe
with [PyInstaller](https://pyinstaller.org) — no Python installation needed on
the target host:
```powershell
& ".\.venv\Scripts\python.exe" -m pip install pyinstaller # once
.\scripts\build_exe.ps1 # dist\opcda-diagnozer\
.\scripts\build_exe.ps1 -Onefile # single exe alternative
.\scripts\build_exe.ps1 -Clean # fresh rebuild
```
The script refuses to run from a 64-bit interpreter (the exe must load the
32-bit OPC DA wrapper DLLs, SPECIFICATION §11), re-verifies the produced PE
really is 32-bit, embeds the project version in the exe properties, declares
the hidden imports the code loads lazily (pywin32 COM, browse modules, the
Phase 3 service host), and smoke-tests the artifact (`--version`,
`check-config`, `list-servers --source registry`) after building. It also
installs PyInstaller into the venv automatically if it is missing.
If your policy blocks the script, run it with
`powershell -NoProfile -ExecutionPolicy Bypass -File scripts\build_exe.ps1`.
Deployment notes:
- The **default config path** of a frozen exe is `config.yaml` **next to the
exe** — not the working directory. A Windows service starts with
`CWD = C:\Windows\System32`, so the relative default would silently point
there; the exe-dir default keeps the deployment layout simple
(`C:\Program Files\OPCDA-Diagnozer\{opcda-diagnozer.exe, config.yaml}`).
- The exe is a console application that hosts every CLI verb, including the
future `run` / `probe` / service verbs. The Phase 3 Windows service
(`install` verb) will point `sc.exe` at this same exe with the service-host
entry point.
- The Automation Wrapper DLL (`OPCAutomation.dll`) is **not** bundled — it is
a machine-installed COM component (registered in the registry), exactly like
the OPC DA servers the tool connects to. Only Python code and its
dependencies are frozen.
- `onedir` is the default (faster startup, AV-friendlier); `--onefile` trades
startup time for a single file. `--clean` removes `build/` + `dist/` first.
## Documentation
- [Specification](docs/SPECIFICATION.md) — detection rules, event model, operational behavior, acceptance criteria