search

HPInc / HP-Digital-Microfluidics

HP Digital Microfluidics Software Platform and Libraries
MIT License
3 stars 1 forks source link

OpenDrop dispensing crashes #189

Closed EvanKirshenbaum closed 8 months ago

EvanKirshenbaum commented 8 months ago

When I run the last command, w : dispense drop, I get the following error: 

python tools/interactive.py opendrop
Interactive cmd: w = well #3
  Interactive cmd val (WELL): Well[3]
   INFO|monitor|Setting tick to 100.0 ms
Interactive cmd: w's volume = 20 drops
Asserted Well[3] contains 40 μl of unknown. Capacity only 12.0 μl
  Interactive cmd val (VOLUME): 40.0 μl
Interactive cmd: w : dispense drop
Drop at Pad(14,6): None
   INFO|engine|Clock Thread exited
Exception in thread Clock Thread:
Traceback (most recent call last):
  File "C:\Users\huberma\AppData\Local\Programs\Python\Python310\lib\threading.py", line 1009, in _bootstrap_inner
    self.run()
  File "C:\microfluidics\thylacine\mpam\src\mpam\engine.py", line 585, in run
    new_queue = self._process_queue(queue, tag = "post-tick")
  File "C:\microfluidics\thylacine\mpam\src\mpam\engine.py", line 514, in _process_queue
    new_delay: Optional[Ticks] = fn()
  File "C:\microfluidics\thylacine\mpam\src\mpam\drop.py", line 971, in <lambda>
    board.after_tick(lambda: future.post(pad.checked_drop))
  File "C:\microfluidics\thylacine\mpam\src\mpam\device.py", line 459, in checked_drop
    raise TypeError(f"{self} has no drop")
TypeError: Pad(14,6) has no drop

image

Pad 14,6 seems to be the top gate and since it's complaining, I'm wondering if something is wrong with the orientation. I can't use the terminal from the matplot lib version, I was wondering if you could try on your machine and see if it's just my machine and I messed up the code?

Originally posted by Mark Huber in https://github.com/HPInc/HP-Digital-Microfluidics/issues/185 [comment by Mark Huber on Jul 12, 2022 at 4:05 PM PDT]

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 13, 2022 at 10:11 AM PDT. Closed on Jul 13, 2022 at 11:00 AM PDT.
EvanKirshenbaum commented 8 months ago

This issue was referenced by the following commit before migration:

EvanKirshenbaum commented 8 months ago

I think I know what it is, could it be that the coordinates from the terminal don't get converted? When I type in d = drop @ (1,1) in the terminal of the opendrop, the drop appears in the top left, on the joey in the bottom left corner. That would explain why the board is expecting the drop to be at the top instead of at the bottom?

Migrated from internal repository. Originally created by Mark Huber on Jul 13, 2022 at 10:15 AM PDT.
EvanKirshenbaum commented 8 months ago

Normally, I wouldn't worry too much about an OpenDrop issue, but this is blocking Mark Huber working on reimplementing the monitor GUI (#52).

Initial testing indicates that the problem is with WellMotion.iterator(), with gate_status somehow being reset to NOT_YET without the well's exit pad being turned on, hence the droplet still sitting in the gate, as shown in the picture above, and not being available on the exit pad.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 13, 2022 at 10:17 AM PDT.
EvanKirshenbaum commented 8 months ago

It turns out that when I got rid of WellGroups back in February (#62) and reworked how WellMotion's iterator() worked, it imposed new rules on the transition sequences that I implemented for Joey, but not for OpenDrop. In particular, it is important that when you get to the DISPENSED state, the gate needs to be off. Adding a step toward the READY state fixed this poblem.

Migrated from internal repository. Originally created by @EvanKirshenbaum on Jul 13, 2022 at 11:00 AM PDT.