Difference between revisions of "Runrats"

From Bcontrol
(For the technician or researcher running a rat:)
(For the technician or researcher running a rat:)
Line 12: Line 12:
 
# When ready, press RUN
 
# When ready, press RUN
 
# When the experiment is over, press END
 
# When the experiment is over, press END
# Goto step 1.
+
# 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:===
 
===For the researcher writing a protocol that will be under the control of Runrats:===

Revision as of 04:35, 25 December 2011

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

runrats('init')

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,

Runrats will use the name of that file to determine which protocol to start up for that rat, and will then load the corresponding settings file. (Note that Runrats will run cvs update on the Settings directory for the ExperimenterName/Ratname combination (thus downloading the latest settings files that have been uploaded to the cvs server), before searching for the latest file with a date not in the future.)

Example: 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.


  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.