Heater-Shaker Module

The Heater-Shaker Module provides on-deck heating and orbital shaking. The module can heat from 37 to 95 °C, and can shake samples from 200 to 3000 rpm.

The Heater-Shaker Module is represented in code by a HeaterShakerContext object. For example:

hs_mod = protocol.load_module(
    module_name="heaterShakerModuleV1", location="D1"

New in version 2.13.

Deck Slots

The supported deck slot positions for the Heater-Shaker depend on the robot you’re using.

Robot Model

Heater-Shaker Deck Placement


In any deck slot in column 1 or 3. The module can go in slot A3, but you need to move the trash bin first.


In deck slot 1, 3, 4, 6, 7, or 10.

OT-2 Placement Restrictions

On OT-2, you need to restrict placement of other modules and labware around the Heater-Shaker. On Flex, the module is installed below-deck in a caddy and there is more space between deck slots, so these restrictions don’t apply.

In general, it’s best to leave all slots adjacent to the Heater-Shaker empty. If your protocol requires filling those slots, observe the following restrictions to avoid physical crashes involving the Heater-Shaker.

Adjacent Modules

Do not place other modules next to the Heater-Shaker. Keeping adjacent deck slots clear helps prevents collisions during shaking and while opening the labware latch. Loading a module next to the Heater-Shaker on OT-2 will raise a DeckConflictError.

Tall Labware

Do not place labware taller than 53 mm to the left or right of the Heater-Shaker. This prevents the Heater-Shaker’s latch from colliding with the adjacent labware. Common labware that exceed the height limit include Opentrons tube racks and Opentrons 1000 µL tip racks. Loading tall labware to the right or left of the Heater-Shaker on OT-2 will raise a DeckConflictError.

8-Channel Pipettes

You can’t perform pipetting actions in any slots adjacent to the Heater-Shaker if you’re using a GEN2 or GEN1 8-channel pipette. This prevents the pipette ejector from crashing on the module housing or labware latch. Using an 8-channel pipette will raise a PipetteMovementRestrictedByHeaterShakerError.

There is one exception: to the front or back of the Heater-Shaker, an 8-channel pipette can access tip racks only. Attempting to pipette to non-tip-rack labware will also raise a PipetteMovementRestrictedByHeaterShakerError.

Latch Control

To add and remove labware from the Heater-Shaker, control the module’s labware latch from your protocol using open_labware_latch() and close_labware_latch(). Shaking requires the labware latch to be closed, so you may want to issue a close command before the first shake command in your protocol:


If the labware latch is already closed, close_labware_latch() will succeed immediately; you don’t have to check the status of the latch before opening or closing it.

To prepare the deck before running a protocol, use the labware latch controls in the Opentrons App or run these methods in Jupyter notebook.

Loading Labware

Use the Heater-Shaker’s load_adapter() and load_labware() methods to specify what you will place on the module. For the Heater-Shaker, use one of the thermal adapters listed below and labware that fits on the adapter. See Loading Labware on Adapters for examples of loading labware on modules.

The Opentrons Labware Library includes definitions for both standalone adapters and adapter–labware combinations. These labware definitions help make the Heater-Shaker ready to use right out of the box.


If you plan to move labware onto or off of the Heater-Shaker during your protocol, you must use a standalone adapter definition, not an adapter–labware combination definiton.

Standalone Adapters

You can use these standalone adapter definitions to load Opentrons verified or custom labware on top of the Heater-Shaker.

Adapter Type

API Load Name

Opentrons Universal Flat Heater-Shaker Adapter


Opentrons 96 PCR Heater-Shaker Adapter


Opentrons 96 Deep Well Heater-Shaker Adapter


Opentrons 96 Flat Bottom Heater-Shaker Adapter


For example, these commands load a well plate on top of the flat bottom adapter:

hs_adapter = hs_mod.load_adapter("opentrons_96_flat_bottom_adapter")
hs_plate = hs_adapter.load_labware("nest_96_wellplate_200ul_flat")

New in version 2.15: The load_adapter() method.

Pre-configured Combinations

The Heater-Shaker supports these thermal adapter and labware combinations for backwards compatibility. If your protocol specifies an apiLevel of 2.15 or higher, you should use the standalone adapter definitions instead.

Adapter/Labware Combination

API Load Name

Opentrons 96 Deep Well Adapter with NEST Deep Well Plate 2 mL


Opentrons 96 Flat Bottom Adapter with NEST 96 Well Plate 200 µL Flat


Opentrons 96 PCR Adapter with Armadillo Well Plate 200 µL


Opentrons 96 PCR Adapter with NEST Well Plate 100 µL


Opentrons Universal Flat Adapter with Corning 384 Well Plate 112 µL Flat


This command loads the same physical adapter and labware as the example in the previous section, but it is also compatible with API versions 2.13 and 2.14:

hs_combo = hs_mod.load_labware(

New in version 2.13.

Custom Flat-Bottom Labware

Custom flat-bottom labware can be used with the Universal Flat Adapter. See the support article Requesting a Custom Labware Definition if you need assistance creating custom labware definitions for the Heater-Shaker.

Heating and Shaking

The API treats heating and shaking as separate, independent activities due to the amount of time they take.

Increasing or reducing shaking speed takes a few seconds, so the API treats these actions as blocking commands. All other commands cannot run until the module reaches the required speed.

Heating the module, or letting it passively cool, takes more time than changing the shaking speed. As a result, the API gives you the flexibility to perform other pipetting actions while waiting for the module to reach a target temperature. When holding at temperature, you can design your protocol to run in a blocking or non-blocking manner.


Since API version 2.13, only the Heater-Shaker Module supports non-blocking command execution. All other modules’ methods are blocking commands.

Blocking commands

This example uses a blocking command and shakes a sample for one minute. No other commands will execute until a minute has elapsed. The three commands in this example start the shake, wait for one minute, and then stop the shake:


These actions will take about 65 seconds total. Compare this with similar-looking commands for holding a sample at a temperature for one minute:


This may take much longer, depending on the thermal block used, the volume and type of liquid contained in the labware, and the initial temperature of the module.

Non-blocking commands

To pipette while the Heater-Shaker is heating, use set_target_temperature() and wait_for_temperature() instead of set_and_wait_for_temperature():

pipette.aspirate(50, plate["A1"])
pipette.dispense(50, plate["B1"])

This example would likely take just as long as the blocking version above; it’s unlikely that one aspirate and one dispense action would take longer than the time for the module to heat. However, be careful when putting a lot of commands between a set_target_temperature() call and a delay() call. In this situation, you’re relying on wait_for_temperature() to resume execution of commands once heating is complete. But if the temperature has already been reached, the delay will begin later than expected and the Heater-Shaker will hold at its target temperature longer than intended.

Additionally, if you want to pipette while the module holds a temperature for a certain length of time, you need to track the holding time yourself. One of the simplest ways to do this is with Python’s time module. First, add import time at the start of your protocol. Then, use time.monotonic() to set a reference time when the target is reached. Finally, add a delay that calculates how much holding time is remaining after the pipetting actions:

start_time = time.monotonic()  # set reference time
pipette.aspirate(50, plate["A1"])
pipette.dispense(50, plate["B1"])
# delay for the difference between now and 60 seconds after the reference time
protocol.delay(max(0, start_time+60 - time.monotonic()))

Provided that the parallel pipetting actions don’t take more than one minute, this code will deactivate the heater one minute after its target was reached. If more than one minute has elapsed, the value passed to protocol.delay() will equal 0, and the protocol will continue immediately.


Deactivating the heater and shaker are done separately using the deactivate_heater() and deactivate_shaker() methods, respectively. There is no method to deactivate both simultaneously. Call the two methods in sequence if you need to stop both heating and shaking.


The robot will not automatically deactivate the Heater-Shaker at the end of a protocol. If you need to deactivate the module after a protocol is completed or canceled, use the Heater-Shaker module controls on the device detail page in the Opentrons App or run these methods in Jupyter notebook.