machineagency / sonication_station Goto Github PK

specifically:

• when parking a tool right before completing a task

The option of the duty cycle is not present as an argument to sonicate_well(). At the moment, a duty (ratio on/off) cycle is achievable by just calling the horn to run in another well, however, the power option to zero or a pause feature is needed.

Expose power option as an input when using prompt mode else leads to error due to missing argument when running protocol.

Currently, we need to manually bookkeep offsets across multiple Duet macros. This is cumbersome and prone to error once the machine is deployed into a production environment (i.e: the lab).

Alll boilerplate macros should be defined automatically from a set of high-level variables. These variables include:

• the tool's XYZ offset
• any travel region limitations based on the tool's size
• any speed limitations for this tool

When the RPi boots, the GPIO pins are configured as inputs, which means the voltage at the gate of the 2N7002 is left floating, which may turn the sonicator on. A 10K pulldown resistor on the PCB should fix this problem.

polling the machine model and updating is slow.

Consider changing to patch mode?

Check all config contents.
What is the tallest plate? Add like 3-5mm of space in between, and we're good.

Starting from an sd card flashed with DuetPi, this script should:

• update DuetSoftwareFramework packages and update firmware
• install tool change scripts in the proper /opt subfolder
• install a Python virtual environment (Miniconda, virtualenv)
• install the python code (run any setup.py, pip-install any packages)

The pausing of the horn and all other equipment as a command called in a protocol.

Loading Behavior when no file specified:

• if a config was initially specified, reload from here

Saving Behavior when no file specified:

• if a config was initially specified, save to there

At the moment the only argument fed concerning wells during labware set up is the number of well, which references a static dictionary with the number of wells to a set row and column configuration. It would be useful to be able to specify the number of rows and columns allowing for greater labware flexibility.

Even if autoclean Boolean set to False, autoclean protocol from config file is executed. Only occurs in prompt mode.

When interrupting a protocol running in prompt mode the sonication horn stays on after the keyboard interruption. The horn stays on to the same setting that was present during the keyboard interruption. Currently, the only way to stop the horn is to turn the entire machine on and off completely.

The tool holder cad files need to be uploaded to this repo.

Every time the machine controller is run, a log file should be created with timestamps.

To save buttonpushing on the keyboard, rapid to the corners of the well plates when dialing in a plate by ID. This number doesn't have to be exact.

When setting up labware during the height calibration with the sonication tool the traveling height is very close to a setup plate of 20mL scintillation vial. If any other labware was used that was higher the sonication would crash.

Since many protocols deal with hazardous experiments, it would be ideal when terminating a protocol for any reason that an autoclean protocol would be preformed. This to ensure the probe is placed back in a clean state.

When in prompt mode if one sets a plate through setup_plate, then follows this with sonicate_wells() to test the arm will crash.

This happens because the final step in a plate setup forces you to calibrate the z height of the sonication horn, once this step is done the arm returns the sonication horn back home and the arm stays connected or at the very least in contact with the sonication horn. When calling sonicate_wells() right after, it seems as if the horn pushes and crashes into the horn.

Currently, there is a non-negligible delay between when an operation is issued from python and when the Duet Software Framework (DSF) executes it. The result is that simply polling the machine state until it stops returning the "idle" status doesn't work since the machine will continue to issue "idle" messages for a period of time until it starts processing the command.

A naive implementation would issue subsequent python commands while the machine was not yet finished executing its instructions. If those commands are directed at the machine, then everything is fine, and the machine will execute them serially. But if the python commands are intended to be executed by another peripheral device like a pipette or sonicator, then these devices will start early--before the machine has finished its command.

The current implementation only encounters this issue for machine-movement-related commands, so blocking until the machine state returns the desire position is a current workaround. Nevertheless, that requires some bookkeeping on the python side to track current and future position, something that DSF should really be doing.

The suggested way of fixing this issue in the general case is to use intercept mode, so that's the plan.