awbirdsall / acbar-control Goto Github PK

particle ejection would be easier if push buttons available to increment/decrement flow (e.g., by 1 or 10 sccm), like push buttons for trap voltage controls.

After collecting data for long periods of time, ACBAR Control begins to lag. The problem could likely be solved if, after saving variable data to a file, it were cleared in the MATLAB workspace. Then, new data would be collected in the variable, and would be appended to the file in the next save, instead of overwriting the existing file data. Hopefully this could lower RAM usage and improve program speed.

Also, the data should be saved in a different file format (e.g., CSV).

Helpful to set DC voltage to 0 with single click. Add button to do this.

When adding new functionality to the window interface it's helpful to have a button to rebuild the windows (maybe other than main?) without having to do the whole close, cleanup, and restart rigamarole. To do this properly:

• pause the timers while it's happening
  • only restart at the end if they were running to begin with
• delete the instrument connections
  • easiest way: delete(instrfind), but this seems to lead to an error in which fastTimerFcn then thinks main.MKS946_comm (and maybe others) still exists once things are up and running again
  • optional: reconnect after rebuild
• reset the image acquisition (imaqreset)
  • optional: reconnect after rebuild

Maybe this sort of code could also be used for a cleaner Quit function?

Inherited code stores AC amplitude and frequency state as the strings displayed in the microscope window. This makes code dealing with the AC signal needlessly complex (lookup string, convert string to float with correct format specifier, manipulate float, convert float back to string with correct format specifier), making the code hard to maintain or update.

Steps to address this:

• Create new global variables to store AC amplitude and frequency state.
• Add these variables to list of variables not cleared by flush_data().
• Write functions set_ac_amp() and set_ac_freq() that are structured like set_dc(): (1) communicate with function generator to update actual AC value, (2) update global variable, (3) update display string.
• Replace existing AC amplitude/frequency code with calls to new functions.

it would be convenient to have a way, in software, to eject a particle from the EDB by setting the AC amplitude to 0 and then returning it to its existing value after a user-defined amount of time.

requires:

• "particle eject" button
• text box to define ejection time (in seconds)
• callback function for button that defines old_ac_amp = main.amp_ac_trap, calls set_ac_amp(0), waits for the ejection time, and then calls set_ac_amp(old_ac_amp)

If you press the "Inject" button directly after sending a different serial command to the Arduino (e.g., change DC voltage with DAC, or droplet Burst), the feedback text prints the message corresponding to the other serial command (e.g., "First 4 dac bits") rather than "Inject". This must be because the serial buffer is accumulating a set of responses from the Arduino, and the "inject" button feedback text uses an earlier message that hasn't been cleared from the buffer.

Need to improve handling of serial buffer: shouldn't be building up like this. In doing this keep in mind single Matlab function calls (or even single serial messages sent to Arduino) can result in multiple responses from the Arduino.

Inherited matlab code uses numerical indices to refer to graphics objects. This is both opaque (e.g., figuring out what flocalhandles(3).Children(3).Children(1) means!) and brittle to changes to the user interface, since the numerical index of an object in a window can change when other objects are added or removed.

I've made a few one-off changes (see toggle_window_visibility(), and hold_button_handle and fringe_button_handle in update_cameras()), but this should be fixed in a unified way throughout the code.

To address this:

• (459c315) Add a Tag property to each uicontrol object (see https://www.mathworks.com/help/matlab/ref/matlab.ui.control.uicontrol-properties.html#d119e1189874).
• (66a5316) Write a generic lookup function that returns the handle for a uicontrol object, given a Tag and maybe a parent object/window (see findobj(): https://www.mathworks.com/help/matlab/ref/findobj.html). The function should deal appropriately with a failed lookup.
• Replace all index-based handle references with tag-based lookups.

As written, SCRAM_COMMS() is broken. It deletes some serial connections and updates a few UI elements, but not everything it needs to. Should be able to look at the ...comms()-type functions as reference for what gets turned on/off when the various serial connections are started/ended.

Currently if Matlab code queries Arduino for RH/T measurements (serial command 'r', within update_arduino()) and the query times out before receiving a response, the entire program loop crashes. This seems to be because update_arduino() tries to append to temp.UPSIdata with a vector missing data, leading to a size mismatch error.

This is an issue because update_arduino() is called regularly when the running program may be unattended.

To resolve, should more gracefully handle a timeout: if Arduino times out, display message reporting timeout and move on.

main.microscope_image is never recorded if the fringe pattern is not being collected.

This is because fasttimerFcn only records microscope_image to main every 20th fringe pattern added to fringe_compressed. So, no fringe patterns = no recording of microscope images.

Make it possible to record microscope_image even if fringe pattern tracking is not happening:

• update logic so microscope_image commands aren't nested within fringe_compressed criteria, but microscope_image still records with appropriate frequency (currently every ~200 s, or every 20th savelogic, or every 2000th run of fasttimerFcn)
• add toggle so appending to microscope_image can be turned on or off. (UI checkbox?)
• record separate timestamps for microscope and fringe images (currently both use image_timestamp)

Current droplet injection commands are hard-coded in Arduino injection code ("s" = single droplet, "1" = 20 droplet burst, "5" = 250 droplet burst). Would like there to be an option for a user-configured command. Free parameters should be:

• total number of droplets
• delay time between each droplet in burst

This requires thinking about a good convention for sending this information to the Arduino over the serial connection. Right now everything is a single character command except for the DAC DC setpoint.

Ideally there would also be a command to cancel a droplet injection in progress.