Hi everyone, I’m new to using both the Hamilton instrument and Pyhamilton, so I’ve been just testing out simple pipetting sequences.
I set each of the aspiration positions to aspirate from the same tube, but in the middle of the aspiration sequence, I get a timeout error on the terminal from Pyhamilton and the trc file shows “System.Net.WebException: Unable to connect to the remote server”. So after the aspiration sequence finishes, the method basically freezes and doesn’t continue with the remaining steps. With shorter steps, my test methods are able to run just fine. I also get this error if I run the method step-by-step and don’t progress to the next step within that 60s limit.
Is there a way to prevent the timeout from triggering?
“System.Net.WebException: Unable to connect to the remote server”
This occurs if your Python client crashes, so in these cases you should check what the error is in the command prompt stack trace.
It sounds like you are getting a timeout error because the aspiration is taking >60 seconds. There are a few ways to address this. You could extend the length of the timeout in liquid_handling_wrappers.py to a more appropriate number. You could also split up the aspiration into multiple steps/ sequences.
PyHamilton supports using sequences in the same way as Venus but also allows for integer based indexing of wells and containers. I find this much more intuitive and user friendly because I don’t have to add sequences to the deck ahead of time and then reference these in my script. Instead, I write scripts that directly reference indices on labware. Temporary sequences are then constructed by PyHamilton in the universal method on the fly.
You might have to add classes for resources that aren’t already in PyHamilton, such as racks of tubes. We have EppiCarrier32 and FalconCarrier 24 in deckresource.py. Here is example code for one of these:
class EppiCarrier32(DeckResource):
def __init__(self, layout_name):
self._layout_name = layout_name
self._num_items = 32
self.positions = [str(i+1) for i in range(self._num_items)]
self.resource_type = DeckResource.types.VESSEL
self._items = [Vessel(self, i) for i in range(self._num_items)]
def well_coords(self, idx):
self._assert_idx_in_range(idx)
return int(idx)//32, int(idx)%32
def _alignment_delta(self, start, end):
[self._assert_idx_in_range(p) for p in (start, end)]
xs, ys = self.well_coords(start)
xe, ye = self.well_coords(end)
return (xe - xs, ye - ys, [DeckResource.align.VERTICAL] if xs == xe and ys != ye else [])
def position_id(self, idx):
return self.positions[idx]
Thanks so much for these suggestions! The command prompt trace shows that the error is purely due to the timeout, rather instead of other reasons for the Python client crashing, so I’ll try extending the timeout length. Seems like that would be the most straightforward approach, and might mitigate other issues down the road if we have slower aspiration speeds set for different liquid classes.