-
Notifications
You must be signed in to change notification settings - Fork 140
Open
Description
Context
STARChatterboxBackend overrides query methods (like head96_request_tip_presence, core_check_resource_exists_at_location_center, request_presence_of_carriers_on_deck, etc.) with hardcoded return values. This works for basic simulation but doesn't let users customize simulation behavior for different scenarios without subclassing.
Proposal
Add a standardised pattern where query methods accept a mock_response parameter with a sensible default, allowing users to configure simulation parameters per-instance. For example:
async def head96_request_tip_presence(self, mock_response: int = 0) -> int:
return mock_responseDesign questions to resolve
- Per-call vs per-instance: Should
mock_responsebe a method parameter (configurable per call) or an instance attribute set at init/setup time (configure once, return consistently)? - Signature compatibility: The base class signatures don't have
mock_response, so this parameter is only usable when calling directly onSTARChatterboxBackend. Is that acceptable, or do we need a different approach? - Scope: Which methods should get this treatment? All query methods, or only the ones that return parsed data?
- Naming convention:
mock_response,simulated_value(already used bychannel_dispensing_drive_request_position), or something else?
Affected methods (current hardcoded returns)
head96_request_tip_presence()→0core_check_resource_exists_at_location_center()→Truerequest_presence_of_carriers_on_loading_tray()→[]request_presence_of_carriers_on_deck()→[]request_tip_presence()→ tip tracker staterequest_z_pos_channel_n()→285.0channel_dispensing_drive_request_position()→0.0(already hassimulated_valueparam)request_iswap_initialization_status()→Truerequest_pip_height_last_lld()→list(range(12))
Note: channel_dispensing_drive_request_position already implements this pattern with simulated_value — that could serve as the starting point for a consistent convention.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels