From a Primer List to a Runnable 96-Well PCR Plate
10 min read · Updated August 11, 2026
You have 96 reactions: a colony-screening plate, a genotyping panel, a set of assembly junctions to check. The design work is done and what is left is bookkeeping — which reaction goes in which well, which primer pair, which template, and then either an afternoon of pipetting or a robot file.
It is bookkeeping that goes wrong often, because the plate map, the robot protocol and the picklist are usually made in three places and only agree until someone edits one of them. This guide covers what those files actually contain, what in them is real and what is a placeholder you have to replace, and how to check a generated protocol before it touches a plate.
One layout, three files
The failure this is worth designing against: a plate map in a spreadsheet, a robot protocol written from it by hand, and a picklist exported from something else. Every one of them is correct on the day it is made. Then a reaction is added, two of the three are updated, and a plate comes off the deck with one column shifted.
The fix is to derive all three from the same assignment. A layout tool that also emits the robot files guarantees they agree, and that is most of its value — the well assignment itself is trivial arithmetic.
Well order is worth stating explicitly rather than assuming. The common convention, and the one used here, is row-major: A1, A2 through A12, then B1, and so on to H12. Column-major fills — A1, B1, C1 — are also common, particularly where an eight-channel pipette works down a column. Neither is more right, but a plate map and a protocol built on different conventions will look almost correct, which is worse than looking wrong.
What a generated Opentrons protocol contains
A generated protocol is a plain Python file using the Opentrons Protocol API. Two things determine whether it is worth anything: whether the labware names are real, and whether the volumes are honest about being guesses.
The labware load names are exact strings that must match Opentrons' own definitions — opentrons_96_wellplate_200ul_pcr_full_skirt for the destination plate, opentrons_96_tiprack_20ul for tips, opentrons_24_tuberack_nest_1.5ml_snapcap for templates, nest_12_reservoir_15ml for bulk reagents, p20_single_gen2 for the pipette. A typo in any of these is not a subtle failure; the protocol will not load. It is worth checking them against the Opentrons labware library rather than trusting a generator, and worth confirming the API level in the metadata matches what your robot's software supports.
The volumes are the part that must not be trusted. In a generated file they should be named constants at the top, clearly labelled — a master mix volume, a primer volume, a template volume, and a water volume that tops each reaction up to the total. Those are placeholders standing in for your polymerase manufacturer's actual recipe, and the only correct action is to replace them before running.
Two behaviours worth reading in the generated code rather than assuming. Reactions that share a template label should share one source tube, which is what makes a 96-reaction plate need far fewer than 96 tubes — and there is a limit, because a 24-tube rack holds 24 templates, so a plan with more distinct templates than that has to overflow somewhere and you need to know where. And a well with no template — a no-template control — should be topped up with extra water so it still reaches the same total volume, rather than silently ending up short.
Always simulate before you run
Opentrons ships a simulator, and running opentrons_simulate on a protocol file before it goes near hardware catches the entire class of errors that a generator can produce: unknown labware, deck slot conflicts, a pipette that cannot reach a volume, tip counts that exceed the rack.
This costs seconds and is the single highest-value check on any generated protocol, including one you wrote yourself. A protocol that simulates clean can still be wrong about your reagents; a protocol that does not simulate is wrong about the robot.
What an Echo picklist actually is
An acoustic liquid handler does not aspirate. It moves droplets out of a source well into a destination well with sound, in nanolitre increments, and it takes instructions as a flat CSV where every row is one transfer. That is the whole format: source plate, source plate type, source well, destination plate, destination well, transfer volume in nanolitres, and usually a name or comment column.
The consequence is that one reaction is several rows. A four-reaction plate at five transfers each — forward primer, reverse primer, master mix, water, template — comes to 20 rows. A full 96-well plate is a few hundred, which is exactly the kind of file nobody should be writing by hand.
Two fields in any generated picklist are placeholders that you must replace with your own values.
- The plate type code. Something like 384PP_AQ_BP identifies a specific plate in the instrument's own Plate Type Library, and the correct code depends on your consumables and your fluid class. A wrong code is not a rounding error — acoustic transfer is calibrated per plate type and per fluid.
- The volumes. A generated picklist has to assume a reaction scale; a common miniaturised one is a 5 µL reaction built from 2,500 nL master mix, 250 nL of each primer, 250 nL of template and 1,750 nL of water. That is a reasonable default and it is not a standard. Rescale it to your own protocol before running, keeping the proportions your enzyme needs.
Source plates and where things live
The other thing a picklist encodes is the physical arrangement of the source side, and it is easy to skim past. Primers, master mix, water and templates each come from somewhere, and the file names those wells.
In a sensibly generated file each distinct template label gets one well on a template source plate, laid out row-major across a 384-well plate — A1 through A24, then B1 — and every reaction using that template draws from the same well. Forward and reverse primers get their own source plates, one well per reaction. Master mix and water usually share a plate in different wells, which is why you will see the same source plate name twice per reaction with different wells and volumes.
Before you run anything, read the source columns and physically lay out the plates to match. A picklist is a set of coordinates; it has no way of knowing that your primers are in a different order than it assumed.
What automation does not fix
Being blunt about this, because the failure is common enough to be predictable: a robot executes a bad plan faster and more consistently than you would have.
Primer design errors scale with the plate. If a pair mis-primes, it mis-primes in all 96 wells, and you have spent a plate of master mix finding out. Check specificity in silico before the plate exists — an in-silico PCR run over the intended template will show you unintended products and their sizes — and confirm the pairs' melting temperatures are close enough to share one annealing temperature, because a plate has one thermal program and every reaction on it must tolerate the same one.
Layout errors survive automation too. A control that is in the map but not on the deck is still missing, and a plate map that has drifted from the protocol produces a clean run of wrong reactions. Deriving all three files from one assignment removes that class of error; nothing removes the class where the assignment itself was wrong.
A checklist before the plate exists
- Check every primer pair in silico against the template you will actually add, and look at the predicted product sizes — you will need them to read the gel anyway.
- Confirm the melting temperatures across all pairs are close enough for one annealing temperature, since the plate gets one program.
- Fix the well order convention — row-major or column-major — and make sure the map, the protocol and the picklist all use it.
- Include the controls in the layout, not in your head. A no-template control that is in the file gets water added automatically; one that is not is just an empty well.
- Replace every placeholder volume with your polymerase manufacturer's actual recipe.
- Replace the plate type codes with the exact ones from your instrument's library.
- Count distinct templates against your tube rack capacity before you generate anything.
- Simulate the protocol. Then lay out the source plates to match the file, not to match your memory of it.
The tool
SeqBench's PCR Plate Planner takes a list of reactions — name, forward primer, reverse primer, optional template label — assigns them row-major across a 96-well plate, and draws the map. From that same assignment it exports a downloadable Opentrons Python protocol and a Beckman/Labcyte Echo picklist CSV, so all three always agree.
It is deliberately explicit about what is real in those exports and what is not. The Opentrons labware and pipette load names are exact strings confirmed against Opentrons' own documentation and labware definitions; the volumes are labelled placeholder constants at the top of the script, with a header telling you to simulate before running. The Echo picklist reproduces the standard column layout and assumes a 5 µL acoustic-scale reaction, with the plate type left as a placeholder code to be swapped for the one in your own library. Reactions sharing a template label share a source well, and a well with no template is topped up with water so every reaction reaches the same volume.
It is a bridge from a finished design to a file a robot can read, not a validated protocol for your instrument and reagents — which is the honest description of every protocol generator, and the useful thing is that the three files cannot drift apart.
Frequently asked questions
What order should reactions go into a 96-well plate?
Either row-major (A1, A2 … A12, then B1) or column-major (A1, B1, C1 …) — both are common, and column-major suits an eight-channel pipette working down a column. What matters is that your plate map, your robot protocol and your picklist all use the same one, because a mismatch produces a plate that looks almost right. Deriving all three files from a single well assignment is the only reliable way to keep them consistent.
Can I run a generated Opentrons protocol as-is?
No. Treat the labware names and API level as real and the volumes as placeholders. A generated protocol carries a master mix, primer, template and water volume as named constants that stand in for your polymerase manufacturer's actual recipe, and they must be replaced. Then run opentrons_simulate on the file before it goes near hardware — that catches unknown labware, deck conflicts and volumes the pipette cannot handle in seconds.
What are the columns in an Echo picklist?
One row per transfer: source plate name, source plate type, source well, destination plate name, destination well, transfer volume in nanolitres, and usually a name or comment field. Because each row is a single transfer, one PCR reaction takes several rows — forward primer, reverse primer, master mix, water and template is five, so four reactions come to 20 rows and a full plate runs to a few hundred.
What volumes should an acoustic-dispensed PCR use?
There is no universal answer, which is why any generated picklist is making an assumption you have to check. A commonly used miniaturised scale is a 5 µL reaction from 2,500 nL of master mix, 250 nL of each primer, 250 nL of template and 1,750 nL of water. Rescale to your own protocol, keeping the proportions your enzyme requires, and remember that acoustic transfer is calibrated per plate type and fluid class — so the plate type code matters as much as the numbers.
How many template tubes do I need for a 96-reaction plate?
As many as you have distinct templates, not 96 — reactions sharing a template draw from one tube. The constraint is the rack: a 24-tube rack holds 24 distinct templates, so count them before generating a protocol. A generator should tell you when a plan exceeds that and what it did with the overflow; a well whose template did not fit will usually be topped up with water instead, which is a silently wrong reaction if you do not notice.
Do no-template controls need anything special?
Only that they end up at the same total volume as everything else, which means the missing template volume has to be replaced with water. Put the control in the layout file rather than adding it by hand — a control that exists in the plan gets handled automatically and appears in every derived file, and one that lives only in your head is an empty well by the time the plate is on the deck.
What should I check before committing 96 reactions?
Specificity and annealing temperature, in that order. Run each pair through an in-silico PCR against the template you will actually add, so unintended products show up before the plate exists rather than as an unreadable gel afterwards, and note the expected product sizes since you will need them to read the result. Then check the pairs' melting temperatures are close enough to share one annealing temperature, because a plate runs one thermal program.
Related references
Related tools
Lay out PCR reactions on a 96-well plate and export a runnable Opentrons protocol or Echo picklist.
Enter a template and two primers to predict the PCR product, its size and position.
Estimate primer Tm, GC% and molecular weight from a sequence.
Design ranked PCR primer pairs from a template, with Tm, GC and dimer checks.
Apply one operation to every record in a multi-FASTA and export a single CSV/TSV table.
Nearest-neighbor Tm, ΔG, hairpins and primer dimers for any oligo or primer pair.