It is the Experiment Engine's task to run experiment jobs submitted to it through iLab. When the web services thread receives an experiment job via the Submit web service method, the experiment request in the form of an Experiment Specification is queued at the Lab Server's database. When the Experiment Engine is running, it periodically queries the database every five seconds to check for incoming experiment requests from users.
If the Lab Server's experiment queue contains any pending experiments, an experiment request is selected from the queue in a First-In First-Out basis after ordering the jobs in descending order of priority. Each time an experiment request is selected to be run at the Experiment Engine, it is labeled as 'IN PROGRESS' in the Lab Server's database.
The list of experimental routines or instructions to be executed at the experiment hardware for this experiment job is then loaded at the Experiment Engine. These instructions for running the experiment are obtained by parsing the Experiment Routine for the current lab, whose location is stored on the Lab Server's database. The Experiment Routine can reside on any world-readable web address (e.g. in the 6.302 Athena locker), which makes it easy to maintain and mody on the fly by 6.302 course staff and WebLab administrators. Furthermore, it is now possible to easily switch from one experiment to another (e.g. when changing from one lab assignment to the next) by creating more than one Experiment Routine files and simply updating the current lab pointer at the Lab Server's database.
Once this set of experimental instructions has been parsed and loaded into memory at the Experiment Engine, it is then personalized to run the user's particular experiment request. The user's particular run of the experiment consists of the previously loaded list of experimental instructions, along with a number of experimental parameters whose values have been set to those provided by the user in the Experiment Specification. This personalization of the experiment instructions takes place by first parsing the Experiment Specification received when the job was submitted, and then completing the experimental instructions with these user-specified parameters and their values.
Upon parsing and completing the experimental instructions with the user-provided Experiment Specification, the Experiment Engine is ready to execute the experiment request on the hardware.
Running an experiment consists of the following steps which are executed sequentially at the Experiment Engine:
1). Resetting the hardware: this step resets the hardware session by pausing any current measurements and resetting the signal analyzer when necessary.
2). Initializing the experiment: sets the measurement type and mode on the signal analyzer. The measurement type can be one of frequency response or time response. The measurement mode is one of linear response, log response, or swept sine.
3). Preparing the measurement: in this step, the measurement options for the experiment are set in the order in which they were specified in the Experiment Routine. The experiment options are divided into three main types:
- Gain: this option sets the gains on the LabJack DAQ board. The Experiment Engine communicates with the LabJack by means of a dynamic link library called through a wrapper class.
- Source: used to set the source level at the signal analyzer.
- Frequency: sets the start and stop frequency, as well as the sweep rate for the measurement on the signal analyzer.
4). Running the measurement: in the final step, the measurement is started at the signal analyzer. While the measurement takes place, the Experiment Engine continually polls the analyzer at one second intervals to check whether the experiment has been completed. Once the measurement is finished, the experiment results are dumped from the signal analyzer to the Experiment Engine over the GPIB connection.