dohertj2/lmxopcua
1
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(focas): record Phase 10 deploy outcome — v3 binary live + probe healthy; live tags blocked by separate OtOpcUa data-plane issue

Browse Source
This commit is contained in:
Joseph Doherty
2026-06-25 17:04:44 -04:00
parent 5f0a52864c
commit 20b2df9241
1 changed files with 19 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans/2026-06-25-focas-pdu-v3-implementation-plan.md
+19 -2
View File
@@ -29,12 +29,29 @@ finding doc's **Resolution** section.
| 7 | PMC framing | DONE — `end = start + width - 1`; **parameter framing BLOCKED** (EW_FUNC across 14 variants — see finding) |
| 8 | probe truthfulness | DONE — `FocasDriverProbe` runs a real wire session (initiate + cnc_statinfo) |
| 9 | docs + version matrix | DONE — this plan, the finding doc, `FOCAS.md`, `focas-version-matrix.md` |
| 10 | deploy to wonder + e2e | PENDING — awaiting go-ahead (production box) |
| 11 | commit + push | commit DONE on `feat/focas-pdu-v3`; push PENDING go-ahead |
| 10 | deploy to wonder + e2e | DONE (binary live, driver speaks v3) — but live-tag verify BLOCKED by a separate OtOpcUa data-plane issue (see below) |
| 11 | commit + push | DONE — `feat/focas-pdu-v3` @ `5f0a5286` committed + pushed to gitea |
**Only genuinely open v3 item:** `cnc_rdparam` (EW_FUNC on every framing — needs a reference FWLIB
trace or is restricted on this control). Deferred; the deployed config uses macros, not parameters.
## Phase 10 outcome — v3 binary LIVE, but a separate OtOpcUa data-plane issue blocks tag values
Deployed the Release driver DLL to `E:\ApiInstall\OtOpcUa\` (backup `_focasbak-pre-v3-20260625T164909.dll`),
restarted `OtOpcUaHost` (clean), and re-deployed in the AdminUI (deployment `12e0d528`, Sealed/In-sync).
**`DRIVER STATUS: HEALTHY` now reflects a real FOCAS v3 session** (the rewritten probe does initiate +
`cnc_statinfo`) — i.e. the deployed binary genuinely speaks v3 to the Makino, which was impossible before.
**However**, the live OPC UA equipment tags (`parts-count`/`parts-required` = `MACRO:3901/3902`) still read
`Bad_WaitingForInitialData` via `read` and a 30 s `subscribe`, and a recursive browse shows ONLY the two
UNS-projected macro tags — **no FixedTree (Identity/Axes/Timers/…) nodes** — identical to before the v3 fix,
and unchanged by host-restart / re-deploy / driver-`Restart`. A box-side watch saw no 250 ms-cadence
connection to the CNC (only the periodic probe), so the driver's **data poll loop isn't running** while its
probe loop is. This is a **separate, pre-existing OtOpcUa data-plane / Equipment-projection issue**, not a
FOCAS-protocol problem (the wire client is proven by the healthy real-session probe + exhaustive dev-box
reads). Follow-on: investigate why the driver's DiscoverAsync FixedTree build + equipment-tag value source
don't run/surface on this single fused admin+driver node (poll-group engine / monitored-item sampling /
whether the Equipment projection exposes driver FixedTree auto-nodes at all).
---
## Phase 1 — Capture every v3 data-PDU response (live, do first)