This article includes the following information about SmoothieError hard limits:

  1. Description

  2. Source for error trigger

  3. Axes of errors

  4. Table of axes

  5. General cases


A hard limit occurs when a limit switch was unexpectedly hit while the OT-2 was not homing. Essentially, it is when an endstop triggers when it is not supposed to (e.g. outside of a home).

The error message will mention the axis that failed, like “hard limit +X.”

Note: Hard limits are normal after tip pickup. The Opentrons App won’t show an error message in these cases. But the “hard limit” message will still show up in the logs, immediately after the tip pickup. Those specific "hard limit” log messages can be safely ignored.

Source for error trigger

There are several possibilities for the source of the hard limit:

  1. Pipette plunger is stuck/not operating properly

  2. Poor pipette attachment and/or electrical noise/static friction build up

  3. Faulty pipette

  4. Bent/broken limit switch

  5. Electronic board malfunction/broken communication cable

    1. Typically a result of a faulty motor controller board, but could also be an error with the central routing board, Raspberry Pi, or any of the connecting cables.

Axes of errors

When examining the G-code of a hard limit, like this one:

M907 A0.1 B0.5 C0.05 X0.3 Y0.3 Z0.1 G4P0.005 G0B3.5 returned ALARM: Hard limit -B

The main piece of information you should focus on is the last part: -B. This shows the axis/component at the time of the error and indicates + or - (unlike homing fails, which do not display + or -) and, thus, you can start your troubleshooting there.

Read the G-code and double-check that the direction of the axis makes sense. For example, a "hard limit -X" should be impossible, because the X-axis limit switch is on the right, not the left. A direction that doesn't make sense indicates there is likely an issue that needs to be further investigated.

Table of axes

Axis Name


Limit Switch Location


Gantry right (+X) and left (-X).



Gantry back, away from front window (+Y) and forward, towards front window (-Y).



Left pipette mount up (+Z) and down (-Z).



Right pipette mount up (+A) and down (-A).



Left pipette plunger up (+B) and down (-B).



Right pipette plunger up (+C) and down (-C).


General cases

1. Axes B/C - Pipette plunger

The robot is halting during calibration/running a protocol and throwing an error message like this:

2M907 A0.1 B0.3 C0.3 X0.3 Y0.3 Z0.8 G4P0.005 G0B2.5 returned ALARM: Hard limit +B

In the above case, the left pipette plunger is throwing the error (B-axis):

  1. Remove the pipette and inspect it to see if there is anything obviously physically wrong with it (any rattling noises inside if you gently shake it, for example).

  2. Reattach to the left mount to see if the error persists

    1. If it works, most likely the cause was electronic noise/static build up that was dissipated when the pipette was removed.

  3. If the error continues, try running the protocol on the OT-2 (see below) and then home the OT-2 from the Opentrons App. Note that you may need to run this protocol 2-3 times if the first attempt was unsuccessful.

    1. Afterwards, rerun the original protocol to be sure the pipette is functioning properly.

      1. If the original protocol is really long, you might want to consider making a quick test protocol in Protocol Designer that has the pipette pick up a tip and do a transfer with your labware. protocol:

metadata = {
"apiLevel": "2.8"

from opentrons import protocol_api
from opentrons.drivers.smoothie_drivers.driver_3_0 import SmoothieDriver

def run(protocol: protocol_api.ProtocolContext):
protocol.comment("B and C motors are performing the unstick axes commands")
if not protocol.is_simulating:
for i in range(3):

Continuing from the above example where the pipette was first mounted on the left when it was throwing the error...

4. If the error persists after running Try attaching the pipette to the right mount and then home the robot from the Opentrons App. Additionally, you could go through the calibration steps or run a protocol after swapping which mount the pipette was originally on to test if the error is still occurring.

If a hard limit occurs on the right mount (would be on the C-axis in the error message): The pipette is most likely the source of the error, unless both mounts are experiencing a hardware error. The pipette may need to be replaced in this case as we typically don’t want you to have to open the pipette.

If the pipette works perfectly on the right mount: Most likely the error is the left mount (faulty hardware) and will require hardware troubleshooting.

To be completely sure which case is occurring, you can also test another pipette on the left and right mount to see if it has the same behavior.

2. Axes Z/A - Pipette mount

The robot is halting during calibration/running a protocol and throwing an error message like this:

M907 A0.1 B0.3 C0.3 X0.3 Y0.3 Z0.8 G4P0.005 G0Z168.08 returned ALARM: Hard limit +Z

In this above case, the left pipette mount is throwing the error (Z-axis). The troubleshooting will be very similar to that mentioned for the pipette plunger, except that the investigation will involve the homing limit switches for the pipette mounts. You should follow the same steps from 1-4 (exclude step 3 as that is plunger specific).

3. Axes X/Y - Gantry

The robot is halting during calibration/running a protocol and throwing an error message like this:

M907 A0.1 B0.3 C0.3 X0.3 Y0.3 Z0.8 G4P0.005 G0X168.08 returned ALARM: Hard limit +X

In this above case, the gantry is hitting the X-axis limit switch incidentally. The X and Y limit switches can be found on the back, right corner near the top of the Z-stage/gantry, each one labeled X and Y, respectively, on a white tab:

For these error messages:

  1. Check that all shipping brackets are removed.

  2. Inspect the X/Y limit switches to see if they are broken/bent.

  3. Inspect the electrical cables to see if they are properly connected or damaged in any way.

  4. Press the X/Y limit switch a few times manually and try homing again. Sometimes the switch can get “stuck” and keep the motor controller board in a failure state, throwing this error.

  5. If the error still presents, proceed to hardware troubleshooting.

Additional resources:

If you have any questions, please reach out to us at or through our live chat!

Did this answer your question?