From Bcontrol
Revision as of 04:48, 25 December 2011 by CarlosBrody (talk | contribs)

Runrats, A dispatcher frontend

Runrats is a simplified GUI to streamline and manage the process of running a rig and large numbers of rats. Runrats reads a MySQL-based schedule of rat IDs, rig IDs, and timeslots, and uses that to offer the person running the rig a simplified GUI to start up a protocol and run the appropriate rat.

For the technician or researcher running a rat:

In a lab, Runrats would generally be started by a startup script when launching MATLAB. It can be run by typing


at the matlab command line. Runrats will read the directory structure in the Main_Data_Directory settings preference (or if this is not set, it will assume that your settings are in ../SoloData/Settings) and populate a list of experimenters. The technician or researcher running rats then follows the simple steps:

  1. Pick an experimenter
  2. Pick a rat
  3. Press LOAD
  4. When ready, press RUN
  5. When the experiment is over, press END
  6. All done for this rat, go to step 1 for the next rat..

For the researcher writing a protocol that will be under the control of Runrats:

When the technician clicks LOAD, an ExperimenterName/RatName combination will already have been selected. Runrats will then take the following steps:

  1. Run cvs update on the Settings directory for the ExperimenterName/Ratname combination, thus downloading the latest settings files from the cvs server.
  2. Find the latest settings file with a date not in the future.
  3. Use the name of that file to determine the protocol to start up. See Protocol Settings for a description of settings filenames and how the protocol is encoded in them.
  4. Before opening the protocol, runs the Manual Test, which forces the technician to test lights, sounds, pokes, and water delivery.
  5. After the Manual Test is concluded, open the chosen protocol.
  6. Once the protocol is open, load the settings file.
  7. Enable the RUN button, and wait for the technician to click RUN.
Choice of settings file sxample: suppose that for rat Carlos/C181 there are settings files 'settings_@Classical_Carlos_C181_111015a.mat', and 'settings_@DelayedOrientation_Carlos_C181_111016a.mat'. Then, for rat Carlos/C181, on the 15-Oct-2011, the @Classical protocol will be started, and the settings file ending in 15a.mat will be loaded for it before the protocol starts running. The next day, on the 16-Oct-2011, the @DelayedOrientation protocol will be started, and the settings file ending in 16a.mat will be loaded for it before the protocol starts running.

When the technician clicks END, Runrats will then take the following steps:

  1. Runrats calls dispatcher with a 'Stop' action -- as a protocol writer, you don't need to worry about this, it simply means that the state machine is halted.
  2. Runrats calls the protocol with an 'end_session' action.
  3. Runrats saves the session data. It assumes that all protocols have an @saveload plugin. It uses that to save the data from the session. More specifically, Runrats calls the @saveload/SavingSection with action='savedata' and 'interactive'=0.
  4. Runrats calls the protocol with a 'pre_saving_settings' action.
  5. Runrats saves the settings for the next day by calling @saveload/SavingSection with action='savesettings' and 'interactive'=0
  6. Runrats asks dispatcher to close the protocol

Inside your protocol, within 'end_session' you might typically do things like compile summary statistics for today, etc. While within 'pre_saving_settings' you might typically do things like changes to the settings based on what you want the rat to do tomorrow.

If you take a rat out of the training schedule you can add a file called ex_runrats to the rat directory. This will keep the dropdown list of rats from getting too busy by excluding that rat from the list.