ValueError: Rails must be between 1 and 30

PyLabRobot User Discussion
1

My Hamilton STAR has 55 rails. When I try to do anything on rails > 30 I expect that the robot moves to this position but instead I get an error. How is it possible to do something on rails > 30?

Error

ValueError: Rails must be between 1 and 30.

Code

from pylabrobot.liquid_handling import LiquidHandler
from pylabrobot.liquid_handling.backends import STAR
from pylabrobot.liquid_handling.resources.hamilton import STARLetDeck

backend = STAR()
lh = LiquidHandler(backend=backend, deck=STARLetDeck())

lh.setup()

from pylabrobot.liquid_handling.resources import (
    TIP_CAR_480_A00,
    PLT_CAR_L5AC_A00,
    Cos_96_DW_1mL,
    HTF_L
)

tip_car = TIP_CAR_480_A00(name='tip carrier')

tip_car[0] = HTF_L(name='tips_01')

lh.deck.assign_child_resource(tip_car, rails=3)

plt_car = PLT_CAR_L5AC_A00(name='plate carrier')
plt_car[0] = Cos_96_DW_1mL(name='plate_01')

lh.deck.assign_child_resource(plt_car, rails=43)

lh.summary()

tiprack = lh.get_resource("tips_01")
lh.pick_up_tips(tiprack["B1:C1"])
2

It looks like you’re defining the deck layout on a STARlet deck, which only has 30 positions

3

And what is the deck layout for STAR?

4

I believe it’d be deck=STARDeck() but @Stefan correct me if I’m wrong.
You can also make your deck layout in method editor and call the .lay file directly

5

STARDeck() does not exist in the repository. Creating an own deck sounds interesting. Let’s see…

6

Interesting, I’ve always imported my own deck layout file that I created in the method editor, and this has worked fine, so I’d try that route.

7

Currently figuring out what the method editor is, haha. You mean the method editor from the MLSTAR software?

8

Yes correct, should be this icon on your desktop
image
It should be installed when you install Venus, and if configured for a STAR your layout files will be as well.

9

Yes I found it. And this is the file which I can import into my Python code and set it to deck lh = LiquidHandler(backend=backend, deck="FileFromMethodEditor.lay"?

I did it like described but still getting an error, so thats probably the wrong way of doing it.

10

I guess this thread among others should better be located in the Hamilton section @system @Stefan

11

I’ve done it by importing the LayoutManager function in the intial import and then referencing the deck file

from pyhamilton import (LayoutManager)

lmgr = LayoutManager('FileFromMethodEditor.lay`)

and then referencing the

lmgr variable to populate the deck with labware

I’m sure there’s a different way about this but this is how I’ve approached importing the correct deck

13

I am working with Mac and cannot use pyhamilton since it’s windows dependent… I tried importing the layout manager from pylabrobot.liquid_handling.resources import LayoutManager but this also did not work. @rickwierenga Do you know a workaround for the issue?

14

Thanks for bringing this up.

Just to clear this up: PyHamilton is a library that uses Hamilton’s VENUS as an intermediary communication layer and uses certain VENUS resources such as lay files (with the LayoutManager class). This is what @LordNorm is mentioning.

PyLabRobot is a new, hardware agnostic library. It includes PyHamilton as one of 2 backends to Hamilton robots, in addition to the hardware agnostic STAR backend. The STAR backend communicates directly over firmware. This is what you have seen in the Mac demo and is the only way to control the Star without Windows.

PyLabRobot can import lay files, but it only supports tip racks, plates and carriers. It does not load the relations between those. I wrote it so that people who have lay files can still use those, but would not recommend it for new layouts if not using PyHamilton. Here’s how it is used:

from pylabrobot.liquid_handling.backends import STAR
from pylabrobot.liquid_handling.resources.hamilton import STARLetDeck
lh = LiquidHandler(backend=STAR(), deck=STARLetDeck())
lh.load_from_lay_file("deck.lay")

Rather, I recommend people define resources using pylabrobot.liquid_handling.resources.

To address some points in this thread explicitly:

This would be a good solution. As @maxhager mentioned, this is indeed something that does not yet exist in the library. I’ll create it later today.

This not valid use of the API. The deck parameter expects a Deck object, not a string.

There is no LayoutManager in PyLabRobot. In fact, layouts are not managed by any single component, but rather exist as a tree of Resources that manage their child resources.

Hope that clarifies things.

1 Like
15

STARDeck is now available in PyLabRobot.

When developing STARLetDeck, I had to use a somewhat arbitrary origin, that I copied to STARDeck. It’d be great if someone with access to a STAR could run a simple test (just try to pick up a tip, for example) to confirm it works. Thanks in advance!

1 Like
17

I am running in some issues now.

In hamilton_decks.py the line

if resource.location.x + resource.get_size_x() > self._x_coordinate_for_rails(30) and \
      rails is not None:

needs to support STARDeck() now so I guess it should be

if resource.location.x + resource.get_size_x() > self._x_coordinate_for_rails(54) and \
      rails is not None:

instead. After changing the value a new error occurs:

ValueError: Location (955.000, 000.000, 000.000) is already occupied by resource 'tip carrier'.

18

Thanks for sharing. You are partially right, 54 should be self.num_rails. I just updated that.

The second error you mention is due to the resource you are assigning overlapping with a resource named tip carrier that’s already assigned.

19

Yes, right. I did not recognised that I assigned my tip carrier to the same position like the plate carrier.

I tested it. It works on rails 54 on Hamilton STAR with

if resource.location.x + resource.get_size_x() > self._x_coordinate_for_rails(60) and \
      rails is not None:

in hamilton_decks.py. Every value < 60 in this if block fails when assigning something to rail 54.

20

What is the width (size_x) of the resource you are assigning?

If the deck has 55 rails, assigning a carrier that is >1 rails wide to rails 54 should raise an error.