Adds the GEM "Documentation" Fundamental capability: the equipment now
self-reports which GEM capabilities it supports, and the host can
discover the DVID namelist with the same shape used for SVIDs.
Catalog (data/messages.yaml -> generated messages.hpp)
S1F19 W header-only Get GEM Compliance Request
S1F20 <L,3 <A SOFTREV>
<A EQPTYP>
<L,a <L,2 <U1 CCODE> <A CDESC>>>>
Get GEM Compliance Data
S1F21 W <L,n <U4 VID>> DVID Namelist Request (n=0 = all)
S1F22 <L,n <L,3 <U4 VID>
<A VNAME>
<A UNITS>>> DVID Namelist Data
Codegen emits CapabilityEntry and GemCompliance structs. S1F22 reuses
S1F12's StatusName struct (same wire shape; dedup avoids redefinition).
Equipment data dictionary (data/equipment.yaml)
device: Adds `equipment_type: "EQUIPMENT"`
for the S1F20 EQPTYP field.
capabilities: New section. List of
- {code, name} (CCODE, CDESC) pairs honestly
reflecting what the codebase
implements: 1, 2, 3, 5, 6, 7, 8,
9, 11, 12, 14 (partial), 15.
dvids: New section, same schema as
svids:. Demo populates two:
- WaferCounter (U4, units wafer)
- ChamberPressure (F4, units Torr)
Loader (src/config/loader.cpp + include/secsgem/config/loader.hpp)
EquipmentDescriptor gains equipment_type and capabilities (vector of
(uint8_t, string) pairs). load_equipment now reads `capabilities:`
into the descriptor and `dvids:` into model.dvids.
Server (apps/secs_server.cpp)
router.on(1, 19) returns S1F20 with desc.software_rev,
desc.equipment_type, and desc.capabilities converted to
vector<CapabilityEntry>.
router.on(1, 21) returns S1F22 built from model.dvids.all().
Client (apps/secs_client.cpp)
Two new demo steps after Request Online and before SVID discovery:
S1F19 -> S1F20: logs SOFTREV, EQPTYP, and every (CCODE, CDESC)
the equipment claims.
S1F21 -> S1F22: logs each DVID with units.
Tests
tests/test_messages.cpp Round-trip S1F19/F20 with a 3-entry
capability list; round-trip S1F22 with two
DVIDs.
tests/test_loader.cpp Asserts equipment_type, the capabilities
list contains CCODE 14 (Spooling), and the
two DVIDs land in model.dvids.
COMPLIANCE.md
"Documentation" Fundamental moves from ⬜ to ✅.
S1F19/F20 + S1F21/F22 rows in the coverage matrix flip to ✅.
The "what would it take" list drops the documentation-messages bullet.
Verified
- Tests: 77 cases / 444 assertions pass.
- Demo: client logs the full capability list received from the
equipment, including CCODE 14 "Spooling (partial; S2F43/F44 +
S6F23/F24)" — the equipment honestly reports its partial
implementation rather than overclaiming.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
+4
-5
@@ -70,7 +70,7 @@ Legend:
|
||||
| Event Notification | ✅ | E30 §6.6 | S6F11/F12 | Equipment-initiated, host-acknowledged. |
|
||||
| On-Line Identification | ✅ | E30 §6.7 | S1F1/F2 | MDLN + SOFTREV. |
|
||||
| Error Messages | 🟡 | E30 §6.9 | S9F* | HSMS Reject.req covers the transport-level case. S9F1/F3/F5/F7/F9/F11/F13 are now in the message catalog and round-trip-tested. `Connection` automatically emits **S9F7** when a peer's primary or reply body fails SECS-II decode (connection stays up; the caller of `send_request` sees `Error::IllegalData`), and **S9F9** when its outgoing request times out at T3 (alongside the existing `Error::Timeout`). **Not wired**: S9F3 (unknown stream) and S9F5 (unknown function) — these belong in the `Router`'s fallback path; today the fallback returns SxF0 only. |
|
||||
| Documentation | ⬜ | E30 §6.10| S1F19/F20 (GEM compliance), S1F21/F22 (data variable namelist) | Not implemented. |
|
||||
| Documentation | ✅ | E30 §6.10| S1F19/F20, S1F21/F22 | Equipment self-reports its GEM-compliance level via S1F20 (SOFTREV, EQPTYP, list of (CCODE, CDESC) per E30 Appendix A) and its DVID namelist via S1F22. Both populated from `data/equipment.yaml`. |
|
||||
| Control (Operator-Initiated) | ✅ | E30 §6.2 | — | `ControlStateMachine::operator_online/offline/local/remote`. |
|
||||
|
||||
---
|
||||
@@ -107,8 +107,8 @@ Legend:
|
||||
| S1F13 / S1F14 | H↔E | ✅ | `messages.hpp` | ✅ in demo |
|
||||
| S1F15 / S1F16 | H→E | ✅ | `messages.hpp` | ✅ in demo |
|
||||
| S1F17 / S1F18 | H→E | ✅ | `messages.hpp` | ✅ in demo |
|
||||
| S1F19 / S1F20 | H→E | ⬜ | — | — |
|
||||
| S1F21 / S1F22 | H→E | ⬜ | — | — |
|
||||
| S1F19 / S1F20 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||||
| S1F21 / S1F22 | H→E | ✅ | catalog | ✅ round-trip + demo |
|
||||
| S2F13 / S2F14 | H→E | ✅ | `messages.hpp` | ✅ in demo |
|
||||
| S2F15 / S2F16 | H→E | ✅ | `messages.hpp` | ✅ round-trip |
|
||||
| S2F17 / S2F18 | H→E | ✅ | `messages.hpp` | ✅ round-trip |
|
||||
@@ -196,8 +196,7 @@ The honest list, in priority order:
|
||||
2. **Finish S9 wiring**: route Router-level "unknown stream/function" through
|
||||
S9F3/F5, and emit S9F11 (Data Too Long) with the 4-byte length prefix
|
||||
in place of MHEAD when the incoming frame is oversized.
|
||||
3. **Implement Documentation messages** S1F19/F20 (GEM-compliance) and
|
||||
S1F21/F22 (data variable namelist) — needed for E30 conformance.
|
||||
3. *(done in this revision)*: S1F19/F20 + S1F21/F22 — Documentation.
|
||||
4. **Implement EC range validation** in `set_equipment_constant_value`
|
||||
so out-of-range sets return EAC=4 instead of being silently accepted.
|
||||
5. **Implement Limits Monitoring** (S2F45–F48, S6F45/F46) if the
|
||||
|
||||
Reference in New Issue
Block a user