The lab requesting this software invesitgates molecular physics using atomic force microscopy. The lab currently has a software package for controlling the atomic force microscopes and taking data, but this software package was written by non-developers over twenty years ago and is no longer a good solution.
The lab requests a new software package in order to be able to make the most out of their instruments. As the software has developed over the years, features have been added in order to more fully automate the experimental process. The current software supports semi-automatic data acquisition but adding features is a nightmare.
The entire focus of the program is to control a National Instruments data acquisition device, using current experimental state (positional coordinates, etc) to create forcing functions for the microscope. The current iteration of the software hard-codes the most common forcing modes. My intent is to create a software platform that can run any arbitrary forcing paradigm as long as it conforms to some interface, so that students can develop their own experimental functions and expand the program's versatility.
The software has strict usability requirements in order to be useful for the lab members:
- The software must be written in G (using LabVIEW) so that any lab member can edit it and so that the barrier to entry for doing so is limited
- The software must support all of the features of the current program
- The software must be suggestive enough that inexperienced developers know which parts to change or how to add new features
- Given experimental instrument state like positional coordinates, rate of forcing, etc, programatically determine a forcing curve and instruct the instrument to perform it
- Interpret the previous experimental run's acquired data in order to determine which of some set of forcing functions to apply
Program state will be held in global state variables with read and write protection/thread locking in order to ensure that only one functional block is running at any one time. Enough state will be held that any thread accessing the state variables will have enough information to decide what action to take or how to take it.
A runtime that supports self-contained blocks of code is desireable. Each self-contained block (run) will expose an input (or start) trigger and an output (or finish) trigger. On start, the block will request read/write access to the experimental state, when it recieves access it will use that state to determine which forcing function to apply, apply the function, record data, and give up the mutex, passing a reference to the state variables out of the finish trigger for the next block.
Blocks may be composed into larger functional groups as well, exposing the start trigger of the first block and the finish trigger of the last, in order to facilitate easier composition of functional segments.
This block structure will allow students to write new experimental modes by adding their business logic inside of blocks, stringing them together, and pushing that into the runtime.