Skip to content

STARChatterboxBackend: configurable mock responses for query methods #934

@BioCam

Description

@BioCam

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

  1. 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)?
  2. 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?
  3. Scope: Which methods should get this treatment? All query methods, or only the ones that return parsed data?
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions