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

Phase 3 PR 44 -- pymodbus validation + IPv4-explicit transport bugfix #43

Merged
dohertj2 merged 1 commits from phase-3-pr44-pymodbus-validation-fixes into v2 2026-04-18 21:39:25 -04:00
Conversation 0 Commits 1 Files Changed 6 +110 -50
dohertj2 commented 2026-04-18 21:19:56 -04:00
Owner
Copy Link

Summary

Follow-up to PR 43 (pymodbus swap). Validates pymodbus 3.13.0 end-to-end on the dev box and fixes four real bugs surfaced when running it.

  • pymodbus config shape -- removed unknown device-level _* keys; replaced blanket write range with per-block ranges; relocated coils to 1024+ so they do not collide with uint16 entries in pymodbus shared cell array.
  • ModbusTcpTransport dual-stack IPv6-first bug -- new TcpClient() resolves localhost to ::1 first, timing out against IPv4-only Modbus servers (including pymodbus and most PLCs). Now resolves via Dns.GetHostAddresses, prefers IPv4, dials explicitly. Same fix in ModbusSimulatorFixture.
  • Smoke-test HR address -- shifted HR[100] -> HR[200]; standard.json HR[100] is the auto-incrementing register so write-then-read would race. HR[200..209] is scratch in both profiles.
  • Tag-name sync -- renamed DL205_Smoke_HReg100 -> Smoke_HReg200 across DL205Profile.cs + DL205SmokeTests.cs (was causing BadNodeIdUnknown).

Validation

  • standard.json + dl205.json boot clean
  • DL205SmokeTests 1/1 pass against both profiles
  • ZB.MOM.WW.OtOpcUa.Driver.Modbus.Tests 52/52 pass (dual-stack fix non-breaking)
  • Solution build clean

Test plan

  • pymodbus simulator boots both profiles
  • Smoke round-trip against standard.json
  • Smoke round-trip against dl205.json
  • Modbus unit suite green
## Summary Follow-up to PR 43 (pymodbus swap). Validates pymodbus 3.13.0 end-to-end on the dev box and fixes four real bugs surfaced when running it. - **pymodbus config shape** -- removed unknown device-level `_*` keys; replaced blanket `write` range with per-block ranges; relocated coils to 1024+ so they do not collide with uint16 entries in pymodbus shared cell array. - **ModbusTcpTransport dual-stack IPv6-first bug** -- `new TcpClient()` resolves `localhost` to `::1` first, timing out against IPv4-only Modbus servers (including pymodbus and most PLCs). Now resolves via `Dns.GetHostAddresses`, prefers IPv4, dials explicitly. Same fix in `ModbusSimulatorFixture`. - **Smoke-test HR address** -- shifted HR[100] -> HR[200]; standard.json HR[100] is the auto-incrementing register so write-then-read would race. HR[200..209] is scratch in both profiles. - **Tag-name sync** -- renamed `DL205_Smoke_HReg100` -> `Smoke_HReg200` across `DL205Profile.cs` + `DL205SmokeTests.cs` (was causing BadNodeIdUnknown). ## Validation - standard.json + dl205.json boot clean - `DL205SmokeTests` 1/1 pass against both profiles - `ZB.MOM.WW.OtOpcUa.Driver.Modbus.Tests` 52/52 pass (dual-stack fix non-breaking) - Solution build clean ## Test plan - [x] pymodbus simulator boots both profiles - [x] Smoke round-trip against standard.json - [x] Smoke round-trip against dl205.json - [x] Modbus unit suite green
dohertj2 added 1 commit 2026-04-18 21:19:57 -04:00
Phase 3 PR 43 — followup commit: validate pymodbus simulator end-to-end + fix three real bugs surfaced by running it. winget-installed Python 3.12.10 + pip-installed pymodbus[simulator]==3.13.0 on the dev box; both profiles boot cleanly, the integration-suite smoke test passes against either profile. 02fccbc762 
Three substantive issues caught + fixed during the validation pass:
1. pymodbus rejects unknown keys at device-list / setup level. My PR 43 commit had `_layout_note`, `_uint16_layout`, `_bits_layout`, `_write_note` device-level JSON-comment fields that crashed pymodbus startup with `INVALID key in setup`. Removed all device-level _* fields. Inline `_quirk` keys WITHIN individual register entries are tolerated by pymodbus 3.13.0 — kept those in dl205.json since they document the byte math per quirk and the README + git history aren't enough context for a hand-author reading raw integer values. Documented the constraint in the top-level _comment of each profile.
2. pymodbus rejects sweeping `write` ranges that include any cell not assigned a type. My initial standard.json had `write: [[0, 2047]]` but only seeded HR[0..31] + HR[100] + HR[200..209] + bits[1024..1109] — pymodbus blew up on cell 32 (gap between HR[31] and HR[100]). Fixed by listing per-block write ranges that exactly mirror the seeded ranges. Same fix in dl205.json (was `[[0, 16383]]`).
3. pymodbus simulator stores all 4 standard Modbus tables in ONE underlying cell array — each cell can only be typed once (BITS or UINT16, not both). My initial standard.json had `bits[0..31]` AND `uint16[0..31]` overlapping at the same addresses; pymodbus crashed with `ERROR "uint16" <Cell> used`. Fixed by relocating coils to address 1024+, well clear of the uint16 entries at 0..209. Documented the layout constraint in the standard.json top-level _comment.
Substantive driver bug fixed: ModbusTcpTransport.ConnectAsync was using `new TcpClient()` (default constructor — dual-stack, IPv6 first) then `ConnectAsync(host, port)` with the user's hostname. .NET's TcpClient default-resolves "localhost" to ::1 first, fails to connect to pymodbus (which binds 0.0.0.0 IPv4-only), and only then retries IPv4 — the failure surfaces as the entire ConnectAsync timeout (2s by default) before the IPv4 attempt even starts. PR 30's smoke test silently SKIPPED because the fixture's TCP probe hit the same dual-stack ordering and timed out. Both fixed: ModbusSimulatorFixture probe now resolves Dns.GetHostAddresses, prefers AddressFamily.InterNetwork, dials IPv4 explicitly. ModbusTcpTransport does the same — resolves first, prefers IPv4, falls back to whatever Dns returns (handles IPv6-only hosts in the future). This is a real production-readiness fix because most Modbus PLCs are IPv4-only — a generic dual-stack TcpClient would burn the entire connect timeout against any IPv4-only PLC, masquerading as a connection failure when the PLC is actually fine.
Smoke-test address shifted HR[100] -> HR[200]. Standard.json's HR[100] is the auto-incrementing register that drives subscribe-and-receive tests, so write-then-read against it would race the increment. HR[200] is the first cell of a writable scratch range present in BOTH simulator profiles. DL205Profile.cs xml-doc updated to explain the shift; tag name "DL205_Smoke_HReg100" -> "Smoke_HReg200" + smoke test references updated. dl205.json gains a matching scratch HR[200..209] range so the smoke test runs identically against either profile.
Validation matrix:
- standard.json boot: clean (TCP 5020 listening within ~3s of pymodbus.simulator launch).
- dl205.json boot: clean.
- pymodbus client direct FC06 to HR[200]=1234 + FC03 read: round-trip OK.
- raw-bytes PowerShell TcpClient FC06 + 12-byte response: matches FC06 spec (echo of address + value).
- DL205SmokeTest against standard.json: 1/1 pass (was failing as 'BadInternalError' due to the dual-stack timeout + tag-name typo — both fixed).
- DL205SmokeTest against dl205.json: 1/1 pass.
- Modbus.Tests Unit suite: 52/52 pass — dual-stack transport fix is non-breaking.
- Solution build clean.
Memory + future-PR setup: pymodbus install + activation pattern is now bullet-pointed at the top of Pymodbus/README.md so future PRs (the per-quirk DL205_<behavior> tests in PR 44+) don't have to repeat the trial-and-error of getting the simulator + integration tests cooperating. The three bugs above are documented inline in the JSON profiles + ModbusTcpTransport so they don't bite again.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
dohertj2 merged commit 5ee9acb255 into v2 2026-04-18 21:39:25 -04:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#43
Delete Branch "phase-3-pr44-pymodbus-validation-fixes"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?