A host couldn't drive the new messages through the HostHandler class —
only the server side knew how to dispatch them. Adds six new senders
plus a unit test that walks each through a real loopback connection:
* send_legacy_remote_command -> S2F21
* send_event_report_request -> S6F15
* send_individual_report_request -> S6F19
* send_annotated_report_request -> S6F21
* send_pp_load_inquire -> S7F1
* send_delete_pp -> S7F17
Suite: 296 cases / 1571 assertions.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Replaces the simplified <L,3 PRJOBID PPID MTRLOUTSPEC> demo body with
the full SEMI E40-0705 §10.2 shape:
<L,5 PRJOBID MF PRRECIPEMETHOD
<L,2 PPID <L,n <L,2 RCPPARNM RCPPARVAL>>>
<L,n MTRLOUTSPEC>
<L,n <L,2 PARAMNAME PARAMVAL>>>
ProcessJob now carries the extra fields (MaterialFlag, ProcessRecipeMethod,
RcpVar[], ProcessParam[]) so a tool's recipe engine can later consume
the recipe-variable overrides and per-job process parameters. Server
S16F11 dispatch populates them via the new ProcessJobStore::set_e40_extras
helper after a successful create.
MaterialFlag + ProcessRecipeMethod enums live in their own tiny header
(`e40_constants.hpp`) so process_jobs.hpp (the store) can use them
without dragging in messages_helpers.hpp (which would create a circular
include via data_model.hpp).
The simplified 3-arg HostHandler::send_create_process_job convenience
remains; it constructs a sensible-default PRJobCreateRequest internally.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds a typed substrate-event callback to HostHandler that decodes the
canonical E90 CEIDs from incoming S6F11 messages into the matching
SubstrateState / SubstrateProcessingState enum values. Host
applications now get strongly-typed substrate observability without
having to maintain their own CEID-to-state lookup.
using SubstrateEventHandler =
std::function<void(uint32_t ceid, SubstrateState location,
SubstrateProcessingState processing)>;
void set_substrate_event_handler(SubstrateEventHandler);
Axes not addressed by a given CEID stay at NoState — the handler
distinguishes "this CEID updates the location axis" from "this CEID
updates the processing axis" so the host can keep its own per-
substrate FSM in sync.
Closes Tranche E — E90 Substrate Tracking end-to-end (FSM + Store +
CEIDs + server emission + host observer).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Fleshes out the host-side message surface so the demo client app no
longer has to inline message construction. Senders added (each is a
one-line wrapper over the codegen builders + Connection::send_request):
Remote command: S2F41/F42, S2F49/F50
Alarm management: S5F3/F4 enable, S5F5/F6 list, S5F7/F8 list-enabled,
S5F13/F14 recover, S5F17/F18 recover-abort
Process programs: S7F3/F4 send, S7F5/F6 request, S7F19/F20 EPPD
Spool: S6F23/F24
Terminal: S10F1/F2 single, S10F5/F6 multi
E40 Process Jobs: S16F11/F12 create, S16F5/F6 command, S16F13/F14 dequeue
E94 Control Jobs: S14F9/F10 create, S14F11/F12 delete, S16F27/F28 command
CommandParameter is reused from store/host_commands.hpp rather than
inventing a parallel ParamPair — host and equipment talk in the same
struct now.
Closes the outbound side of the host-mode menu. The remaining piece
is an integration test that drives this against the equipment server
end-to-end (B4).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Adds the five GEM event-subscription primitives the host needs to drive
the equipment's data-collection lifecycle (E30 §6.11):
S1F3/F4 selected status data
S1F11/F12 status variable namelist
S2F33/F34 define reports
S2F35/F36 link event reports
S2F37/F38 enable/disable events
Each is a one-line wrapper over the codegen builders + Connection's
send_request, surfacing the codegen-generated DefineReportEntry /
LinkEventEntry structs to callers behind a {id, [vids]} pair API.
This is the minimum surface a host needs to walk a fresh equipment
through "define report -> link CEID -> enable" and start receiving
S6F11 event reports — the same pattern the existing demo client does
inline. B3 lands the RCMD / recipe / job / terminal senders that
build on top.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
GEM host-side counterpart to the existing equipment server: wraps an
HSMS Connection (Active mode), installs an inbound dispatch table that
auto-acks the messages a host is expected to passively accept, and
exposes the GEM workflow primitives.
Inbound dispatch:
S5F1 Alarm Report observe (alarm handler) + S5F2 Accept
S6F11 Event Report observe (event handler) + S6F12 Accept
S6F25 Spool Data Ready S6F26 Accept (host policy: pull on demand)
S10F1 Terminal Display observe + S10F2 Accepted
S9F* Equipment errors observe (s9 handler); no ack (one-way)
Workflow shortcuts:
establish_communication() S1F13 -> S1F14
go_remote() S1F17 -> S1F18
go_offline() S1F15 -> S1F16
Plus a low-level send_request() escape hatch so the senders coming in
B2/B3 don't have to friend the connection internals.
Drive-by: event_reports.hpp was missing `<optional>` (worked transitively
through the equipment-side include chain but not when included from the
host-side standalone).
secsgem-py has `gem/hosthandler.py`; this mirrors its surface for the
inbound-ack and lifecycle parts. Outbound senders land in B2/B3.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
raphael