Methods Overview

In this overview we will explain high‑level protocol structure, specific labware requirements, how to handle worklists for programmatic and specialized transfers, and the importance of specifying a deck layout for the method. We hope this will give a brief understanding to beginners about the rationale behind design choices when setting-up or running a protocol.

Protocol

The protocol or method is the sequence of programmed events to happen that occur after the run has been started by the user. Typically, a set of scheduled pop-up GUIs will occur asking the user to choose how many samples they want processed, the temperature of the incubator, time-intervals between reads etc. These are often meant to reflect changes in the magnitude of samples or other general parameters such as temperature in the specified run, not about the specific workflow of each run, such as which plates are being pipetted nor the size of the plates - these are design considerations better specified using the worklist structure or an entirely different protocol. In practice, this means specifying how many samples you’ll run, what dilutions or master mixes you’ll prepare, what your positive and negative controls are, and how you’ll read out results (e.g., fluorescence, absorbance). Framing the protocol in this way helps ensure that the method meets your experimental goals before you translate it into labware definitions or worklists.

Labware

The Labware section catalogs every physical item the STAR will handle: tip racks (with catalog numbers and filtered/sterile designations), plate types (e.g., 96‑well polystyrene, deep‑well), tube racks, reservoirs, and any on‑deck modules (shakers, heater–coolers, barcode readers). Each item will specify the manufacturer’s name, part number, and any custom calibration offsets you’ve determined during deck setup. Be sure to note orientation constraints (e.g., A1 corner alignment), maximum volumes for each labware type, and any special handling instructions (e.g., pre‑wetting tips, priming reservoirs). Having all labware definitions clearly specified prevents errors during protocol import and ensures the robot’s geometry matches your physical setup. These labware definitions will almost always be used using the predefined library, however, users can add their custom labware by specifying their proper dimensions by adding a new labware class in the method editor.

Worklist

The worklist specifies specific liquid‑handling instructions using a CSV or table that enumerates each aspirate and dispense step in order. Columns include source labware and well, destination labware and well, transfer volume, tip change flags, mixing instructions (e.g., mix 3× with 50 µL), and any pause or user‑intervention notes. By structuring every pipetting action in a simple, tabular format, there is an unambiguous command set that the STAR can execute without further interpretation. Worklists can be generated following the outlined instructions seen in the example later, then validated in Venus to check for syntax errors or volume inconsistencies. Once imported, you can preview the sequence in simulation mode to confirm that tip usage, liquid classes, and deck movements all behave as expected before running the actual protocol.

Layout

The Layout section defines exactly where each piece of labware and accessory sits on the STAR deck. Numbered positions (e.g., Deck Slot 1–8) are assigned to tip racks, plates, reservoirs, and modules, with diagrams or screenshots from Venus to illustrate orientation. A well‑planned layout groups related items (e.g., all reagents on the left, sample plates on the right), balances throughput against accessibility, and leaves clear space for tip loading and waste disposal.Considerations include avoiding deck collisions (e.g., gripper arm interference), ensuring modules (like shakers or heater–coolers) have sufficient clearance, and placing high‑use items within easy reach of the pipetting head. Documented is any nonstandard placements or custom fixtures so that setup is repeatable across users and shifts.

Method Editor

Within the method editor for protocols, one can find the Venus software code for how samples are being processed, which volume of reagents are being used, and what the key steps and controls are. It should describe sample types (e.g., cell lysates, purified DNA), reagent volumes, incubation times, and any mixing or temperature‑control steps. The scripting details liquid classes (aspirate/dispense speeds, tip touch parameters, air gaps), deck movement speeds, and error‑handling behaviors (e.g., retry counts, pause‑on‑liquid‑low). Outlined are any custom scripting elements—like conditional loops for serial dilutions, pauses for plate‑reader integration, or calls to barcode‑scan routines. Notes should be included on simulation versus run modes, logging verbosity, and how to interpret on‑deck status indicators or error messages. These low‑level details are important to ensure pipetting performance can be reproduced, audited, and debugged if issues arise during automated runs.