Your first experiment virtual demo
A dilution series of a blue dye: 24 samples at four strengths
- Samples
- 24
- Volume each
- 1.2 mL
- Target accuracy
- ±2 %
Guided virtual experiment. No physical robot is involved.
Design and test liquid-handling experiments before running them on a robot.
VialBot provides a transparent software foundation for robotic liquid handling, where experiments are planned, simulated, and independently checked. Every computational decision is supported by traceable evidence, with clear explanations of successful outcomes, failures, and unresolved uncertainties.
REPLAY OF A SIMULATED RUN
loading the run…
How it works
One experiment, four steps
The same four steps run for every experiment, from a single transfer to a 24-vial series.
- 1
Design
Say what you want: which liquids, how strong, how much of each, and how exact it must be.
- 2
Plan
VialBot works out every volume, picks the pump or the pipette for each liquid, orders the moves and writes the commands. A second, independent calculation re-checks each stage.
- 3
Simulate
A virtual copy of the robot performs every command, with realistic device errors and, if you choose, a failure.
- 4
Verify
An independent checker reads only the run's tamper-evident notebook and says, for each vial, PASS, FAIL or UNKNOWN, with the evidence.
Status
What has been validated?
Software checks are not hardware tests. This is where VialBot stands today.
24vials planned, made and checked in the replay at the top of this page
11 / 11promises of the qualified case met in simulation
0doses ever sent twice, across the staged failures
- Qualified in simulationThe Q1 dye-dilution case meets all its claims on the virtual robot.met
- Controlled bench qualificationNot yet ready: VialBot has exchanged messages with a real controller (HW-001), but the driver that moves the robot has not been tested yet.not yet ready
- Physical qualificationNot established: nothing has yet been dispensed and measured on real hardware.not established
Start here
Start with an example
Each one runs the real engine on the server. Nothing is a recording.
2 minutes · guided
Your first run
A 24-vial dilution series of blue dye, made with a pump and a pipette, in four guided steps.
Start the guided run → what if…Break it on purpose
Make the robot miss a tip, lose its cable or run out of dye, and see what it does, and what it cannot know.
Stage a failure → 9 short chaptersWatch the story
The qualified run, explained for readers who are new to laboratory automation.
Watch the story → a refusalWhy a request is refused
137 µL within ±1 µL with no pipette: the engine shows why no plan can deliver it, alternative by alternative.
See the witness →Reading a result
Four verdicts, and where every number comes from
PASS
The evidence shows the requirement is met, within the model.
FAIL
The evidence proves the requirement is not met.
UNKNOWN
There is not enough evidence to say, for example when a reply never arrived. Not a failure.
NOT RUN
Not reached, because an earlier stage stopped the run.
Numbers marked simulated come from the virtual robot; numbers marked assumed come from a datasheet. Neither is a measurement of a real device.
Go deeper
When you want more
How it worksThe method: seven stages, each re-checked by an independent calculation.
Evidence & resultsThe proof: what was tested, how, and what is not established.
Hardware & deploymentReal hardware: the first measurement on an Arduino, and the path to the bench.
DocsThe reference: guides, the programming interface, the glossary and the decisions.
How it works
From a request to verified vials
VialBot-Core runs every experiment through the same seven stages. Each stage does one job, writes down what it decided, and is re-checked by a separate calculation (an oracle) before the next one starts. Read the plain version first; open the expert view of any stage for its full evidence.
What does "checked twice" mean?
Every planning stage works out its answer; then a separate calculation, written differently, works it out the other way round. If the two disagree, the run stops before anything moves. A stage cannot quietly get something wrong.
The seven stages
For experts
Every block of a real run, with its evidence
The same five questions for every block (B0 to B7) of the workbench's current run, the 24-colour palette unless you have run something else: what it was given (its inputs and what it depends on), what it produced (its decision), how it was checked (its own check and the independent check), the evidence (and how to reproduce it), and what is not established (its limits).
Watch the engine work
The eight blocks on one experiment, in one minute
The 24-colour palette: the request becomes a recipe, a device plan, a schedule, checked movements and commands; the virtual VialBot executes them; the checker states what the evidence establishes. Every number is quoted from the run.
Architecture
Three cores, eight blocks, an independent check after every one
Each block returns a result, evidence that the result satisfies its requirements, and an explanation when it fails. Its oracle re-derives the claim by a different computation; the checker (B7) audits the whole run from the ledger alone. Open any block for its evidence.
When the engine refuses
A witness, not an error message
The documented example from the design: 137 µL ± 1 µL with the pipette unavailable, run when this page opened.
For every decision
Four questions, always answered
- 1What did the engine decide?
- The chosen recipe, device plan, schedule and protocol, per transfer.
- 2Why did it decide that?
- Every alternative considered and the rule that eliminated it, with the numbers.
- 3What independently verifies it?
- An oracle per block that recomputes the claim differently, and a checker that reads only the ledger.
- 4What remains unknown?
- Stated as such: an unacknowledged dose, an uncalibrated device, a sensor the robot does not have.
For experts
How the evidence fits together
Request → recipe → allocation → operation → command → event → reconstruction → verdict → witness, for the current run. Filter to a block or a transfer and open a node for its attributes and its neighbours.
Select a node.
Try VialBot
Your first run, in four steps
A prepared experiment on the real engine, with nothing to configure. Every number you will see comes from the run you start here.
simulated · not a physical measurement
Try VialBot
Design your own experiment
Start from a documented scenario, change the liquids, the vials, the hardware or the evidence, stage a failure if you like, and run all eight blocks on the virtual VialBot. Every block, passing or failing, opens with its evidence.
Experiment
Formulation
Stocks
| id | species : concentration | available | deck slot | pump |
|---|
Target vials
| vial | slot | final volume | species : target | tol µL | α |
|---|
Species as dye:0.5 mM; several separated by ;. Units are explicit (µL, mL, mM, mg/mL).
Hardware, evidence and policy
Fault injection and oracle bypass
For a guided investigation of a single failure, use Investigate a failure.
Expert: specification as JSON
Blocks and gates
Open any block, passing or failing: what it was given, what it produced, how it was checked, the evidence, and what is not established.
Virtual deck
Top view of the bed (mm). Vial fill is the nominal state replayed from acknowledged commands; the carriage shows the selected step.
Operation timeline
Try VialBot
Investigate a failure
Inject one failure into the current experiment and compare it with a fault-free run: which layer detected it, what information was available, why execution was held, what remains physically unknown, and what must happen next.
VChem · the virtual laboratory
Make a solution on the virtual bench
Pick a test tube, add solutions from the bottles, then weigh the tube and read its colour. The robot does the pipetting on screen; the real engine plans and checks every addition underneath, and the instruments read what is really in the tube. The bench keeps its state: each addition is made against the tubes as they stand, and only what the robot really did changes them.
New · the 3D lab
Walk into the laboratory
The same bench in first person: pick the bottle and the tube, send the robot, carry the tube to the balance and the
spectrophotometer, then write the report and export the protocol. Mouse and keyboard, touch, or a headset.
Start here
Your first experiment: make 1 mL of blue dye at 0.1 mM, in three steps: prepare, observe, verify. Then break it on purpose and see how the failure is caught.
Experiments, without code
Choose an experiment and set a few numbers; the robot makes every tube on the bench. Then analyse it, read the report, and take the workflow to your own robot or bench.
1Pick a test tube
2Add a solution
The pipette draws 10–300 µL per stroke; the pump doses 10 µL pulses of blue dye. The robot makes it as soon as you add; the engine refuses what cannot be done.
3Measure the tube
4Analyse, report, take it with you
Once tubes are made: the report fits and judges the experiment (and reveals an unknown), and the workflow can be exported for an Opentrons, for PyLabRobot, for a VialBot, or for a person at a bench. Every file says it comes from the requested volumes of a virtual run.
Three ready experiments
Two complete experiments and one failure, each stating what the engine and the instruments are expected to find. Run one here, or from the board in the room; the engine's answer says whether it went as expected, check by check.
More: examples, the seed, a staged failure, the pipette's calibration
Examples
The seed fixes the simulated scatter: the same additions with the same seed reproduce every run and the bench digest; change it to see another realisation. "Run the bench again" repeats the same additions.
Calibrate the pipette on the virtual balance
Weigh what the pipette delivers at 20, 100 and 300 µL, ten times each; fit three models of the pipette; judge them on ten more weighings at other volumes.
virtual bench
simulated · not a physical measurement
The engine's verification record of this run (the five questions)
Evidence & results
What has been shown, how, and what has not
VialBot's claims are scoped: each one says what was tested, on what, and what it does not establish. This page is the summary; the pages below hold the full evidence.
loading the evidence…
Q1 case studyThe qualified dye-dilution series: the story, a live run, three experiments, the claims and the full report.
Fault coverageEvery failure the engine is tested against, who must detect it, and the gaps it declares.
BenchmarksFour planning strategies on the same experiments: accuracy, time, tips and detection.
Limits and scopeWhat each verification level covers, and what the software cannot establish.
Evidence & results
Fault coverage
Every registered failure with where it is injected, the layer declared to detect it, the codes and evidence it must produce, the required response, and the declared gaps (what only a sensor or a balance could see). The test suite pins this table.
Evidence & results
Benchmarks: planning strategies A–D
Does joint, uncertainty-aware allocation and scheduling of the pump and the pipette improve accuracy and throughput while keeping execution verifiable? Four comparable strategies run on the same specification and the same virtual device.
Objective minπ ( T(π), W(π), Ntips(π) ) lexicographically, subject to P(|Vdelivered − Vtarget| ≤ ε) ≥ 1 − α (arm D), device ranges, material availability, geometry and the resource schedule. Arms A–C judge the tolerance on the nominal volume only. The optional coupled policy ("D+") evaluates three allocation objectives against the resulting schedule and keeps the best verified plan.
Evidence & results
Limits and scope
Independent software verification is not physical validation. Passing every computational check does not establish that a real pipette delivered the correct quantity.
What has been verified, and at which level
What each block cannot see
Q1, explained
Watch the case, step by step
Two ways to watch. Guided story: the virtual VialBot replays the exact commands of the qualified run, in nine short chapters written for anyone. Run it live: the whole case is planned, checked, executed and audited again, now, with a new random seed and your settings, and the robot performs that run in front of you. Drag the view to look around.
Each run plans, checks, executes and audits the whole case on the server with a new random seed, so the small differences between runs are real. The robot then performs exactly that run, and the results appear vial by vial.
Try it yourself
Three small experiments with the model
Each runs in your browser on the same device model the qualification used, and shows next to it what the full campaign measured. Move a slider and watch the cause become the effect.
Hardware & deployment
Hardware communication and deployment
Before VialBot moves anything, it must hold a reliable conversation with the controller that will drive the robot. Stage 1 tests that conversation: here with a simulated controller, and on your own computer with a real one. Nothing on this page moves hardware.
Deployment path
From software to the bench, one stage at a time
Each stage must be shown before the next one begins. Only the first is available today, and it has now been shown on real hardware (HW-001).
- 1CommunicationVialBot and its controller understand each other. Shown on real hardware: HW-001, Arduino Uno R3
- 2Controlled motionOne axis at a time, supervised, with limits and an emergency stop. Not started
- 3Liquid handling on the benchPipette and pump volumes measured on a balance. Not started
- 4Qualified deploymentThe qualified case run on the robot, with evidence. Not started
Stage 1 does not change the readiness levels shown elsewhere on this site. Communication is a prerequisite of bench qualification, not part of it: a passing check says nothing yet about motion, volumes or the robot itself.
Measured on real hardware
Hardware qualification record
Every test made on real hardware, with its conditions, its measurements and its report. The numbers are computed from the stored report each time this page loads, and its record is checked for tampering at the same moment.
loading…
Stage 1
Communication lab
VialBot holds a short conversation with the controller and checks eight things: the handshake, the controller's identity and status, a series of round trips, message discipline, error handling, session continuity and a clean reconnection. Choose a scenario and press Run: the conversation plays back message by message, then the results show what held and what did not.
idle · the link is closed
Checks
Who is on the other end
Not identified yet: the controller names itself when VialBot asks INFO.
Settings
Pings: how many round trips the fourth check times. Reply deadline: how long VialBot waits for each reply before recording it as unanswered. Round-trip limit: 95 % of the round trips must be at most this long. Seed (simulator only): the simulator's random choices; the same seed gives the same conversation.
The conversation
→sent: from VialBot to the controller←reply: from the controller to VialBot◷no reply in time⊘set aside: received but not accepted◆simulator: what a staged fault did; no check reads it
- Press Run: every message between VialBot and the controller appears here, in time order, with the raw line that crossed the cable.
The results
The verdict, the evidence and the explanations appear here once the conversation has played back.
The eight checks
On your computer
Connect a controller
The same eight checks run against a real board through a small service on the computer the board is plugged into. The public website never reaches your hardware.
- Load the communication firmware. Open
firmware/vialbot_comm/vialbot_comm.inoin the Arduino IDE and upload it to the controller. It speaks protocol 1 and nothing else: communication only. VialBot never flashes firmware for you. - Start the local service on the computer the controller is plugged into:
On Linux the port is usuallyuv run --group hardware python -m vialbot_local serve --serial COM5/dev/ttyACM0;uv run --group hardware python -m vialbot_local portslists the ports it can see.--serial faketries everything with a built-in fake device, without hardware. - Open
http://127.0.0.1:7871/#hardware/labin a browser on that computer and choose Your controller. - Without a screen, for example on a Raspberry Pi, run the check from the command line. It prints the verdicts and
writes the same report (
comms_report.jsonandcomms_report.md) to the folder named by--out:uv run --group hardware python -m vialbot_local check --serial /dev/ttyACM0 --out vialbot-comms-report --confirm-communication-only
Why this is safe
- Bound to your computer only. The service listens on 127.0.0.1 and refuses any other address.
- Other websites cannot start a check. Every request must be addressed to this computer (Host check); the request that runs a check must also come from this page (Origin and Sec-Fetch-Site checks) and carry a token issued to this page; the page cannot be shown inside another website.
- Only the protocol. It sends the four protocol commands (HELLO, INFO, STATUS, PING) and two fixed test messages, nothing else: no command line, no firmware flashing, no motion.
- No staged faults on hardware. Fault injection exists only in the simulator.
- The port is open only during a check. It is opened when a check starts and closed when it ends.
Scope
What this shows, and what it does not
What a pass shows
VialBot and the controller communicate as protocol 1 requires: they agree on the protocol, every reply is matched to its request, nothing is sent twice, errors are refused cleanly and the link can be reopened.
What it does not test
Motors, pumps, pipetting or the robot. The communication firmware drives no actuator, so a pass says nothing about motion or volumes.
Simulated evidence
A run against the simulated controller is evidence about VialBot's software: how it talks, waits, refuses and recovers. It is labelled simulated, never measured.
Real links vary
Round-trip times on a real link depend on the computer, the USB adapter and the board. A result on one computer does not carry over to another; run the check where the robot will run.
What comes next
Stage 2, controlled motion: one axis at a time, supervised, with limits and an emergency stop. It has not started.