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_response
Design questions to resolve
- Per-call vs per-instance: Should
mock_response be 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 on STARChatterboxBackend. 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 by channel_dispensing_drive_request_position), or something else?
Affected methods (current hardcoded returns)
head96_request_tip_presence() → 0
core_check_resource_exists_at_location_center() → True
request_presence_of_carriers_on_loading_tray() → []
request_presence_of_carriers_on_deck() → []
request_tip_presence() → tip tracker state
request_z_pos_channel_n() → 285.0
channel_dispensing_drive_request_position() → 0.0 (already has simulated_value param)
request_iswap_initialization_status() → True
request_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.