What is needed is a powerful, easy-to-use, inexpensive way to run experiments.
Our solution is paradigmatically different from the approach most researchers are familiar with. Like any paradigm, once you are familiar with it, your intuitions will serve you well. Unfortunately, until you are familiar with it your intuitions may lead to confusion. This section is an attempt to assist you in establishing the right mind set. Clarifying these issues will make easier the reading of the manual and use of the Experiment Controller.
1. Distributed Processing
Our system relegates experiment control to peripheral processors located in each experimental apparatus. In this sense, each apparatus becomes a "smart," totally self-contained apparatus and only needs to be told the procedures to carry out. Because the processing task is distributed, our system can integrate fifteen complex, independent experiments each of which provides 1 ms resolution for program control and data collection. We also provide software which runs in the supervisor computer (most likely, the computer on your desk or the computer in the running room) whose task it is to communicate with, coordinate, and administer the various Experiment Controllers. This utility coordinates the various activities, much as a president's secretary can be directed to assign specific tasks to various vice presidents and receive their reports. The researcher need only tell the network administration program in the supervisor computer which apparatus is to get which experiment control program and the names of the resulting data file.
Figure 1 illustrates the difference between a time-sharing solution and a distributed-network solution.
The following figure illustrates how the hardware, software, and researcher articulate. While most of the components are probably not yet comprehensible, this and the other figures in this section will be useful to refer back to when the words in the subsequent sections are insufficient to make things clear. For now, attend only to the fact that a researcher can communicate to a particular Experiment Controller through a network administration program.
2. Dedicated CPU
Our system uses a separate computer for each experimental station. CPU chips are very inexpensive, especially when compared to the software and hardware necessary to split a CPU between experiments.
3. Single Wire Network
A single wire (4 conductors) plugged into the Supervisor is used to communicate to all the Experiment Controllers. Each Experiment Controller has its own address, much as a party line telephone. The many wires between the control equipment and the experimental apparatus are less than a foot long. Wires and connectors are the major source of unreliability and are therefore minimized.
4. Algorithmic Control Language
An algorithmic language (which specifies a series of actions and program flow) is used to carry out the research rather than a state notation language (which specifies states and the rules for transition). In particular, we chose the syntax of BASIC for the primary experiment control language because it is extremely easy to learn and is already widely known.
Unfortunately, there is much confusion concerning the ease of doing real-time experiments with BASIC. This is for two reasons. 1. In the early days of computer-controlled experimentation, researchers used Dartmouth BASIC for real-time control. They found it difficult. This was because it was slow and it had no reasonable instructions for real-time control, not because of its syntax. 2. BASIC is not a very reasonable language for a professional career programmer to use to do general data-manipulation programming, when compared to C or PASCAL, especially when the programs get very large.
ECBASIC is not intended for large programs nor data manipulation, nor professional programmers who can spend a year or so learning to program. Additionally, it has instructions specifically designed for experimental control, and it is very fast (it is "compiled," i.e., pre-tokenized).
5. Event Log Recording
We chose to explicitly provide for the recording of event logs. With an event log, an appropriate analysis can be carried out after the fact. Events can be selected and tallied by sequentially "searching" through the data file for their code, much the same way as a word processor searches through a text file for the occurrence of a particular word. In point of fact, traditional data selection and summarization code written into traditional experiment control programs do this same thing in real time with the unfortunate result that there is no possibility of going back and changing what was done.
By enabling data selection and analysis after the experiment, no information is lost. If the original analysis is inappropriate, or if re-analysis in light of recent understandings is appropriate or even if simple "playing with the data" is desired, the complete data record can be re-analyzed. Other researchers could analyze your data for their effect. An additional benefit of this approach is that it allows the researcher to write an experiment control program without being concerned with data collection. We chose to make the collection and storage of complete or partial event logs very easy (more precisely stated as: data collection implemented transparently without explicit actions by the experiment control program). Any class of events (stimulus change or response) can be automatically coded, temporally tagged and transparently stored on a disk file on the Supervisor computer without requiring any explicit action by the experiment control program.
Traditional data selection and summarization is also available with our Experiment Controller. With this type of data recording, the researcher estimates where the effect will "show up" and selects and typically accumulates those data across a session (e.g., total pecks in FI link, or cumulated latency to first peck in FR link. ECBASIC allows approximately 25,000 counters and or timers. The only action the experiment control program must take is to PRINT the data in the desired format. The network administration software takes care of getting it from the Experiment Controller to the appropriate disk file.
Figure 3 illustrates the way complete event recording instantiates the behavior. Each event is logged. The figure illustrates a segment of a disk file resulting from the stimulus onset (event or "genus" 1) of a house light (type or "species" 21) at 363083 milliseconds. A key peck (genus 3) occurred on key 2 (species 2) at 365397 milliseconds. A key peck (3) then occurred on key 1 (1) at 366002, etc. Subsequently, any summary data can be extracted from the event record. The figure also illustrates simple summary data in the left portion.
6. Replaceable/Disposable Control Equipment
We designed the Experiment Controller so that if something goes wrong with a board it can be replaced with a spare within a few minutes by a person with only modest technical skills. Additionally, the board is designed to be inexpensive enough to be disposable if it cannot be easily repaired.
As a computer is used to carry out more of the activities in a laboratory, the demands placed on the functionality of that system increase. The more the computer does, the easier it is to envision additional tasks for it to do. Users quickly come to want fast response times and user-friendly software, while at the same time requiring that the system perform screen editing, database management, data analysis, and scientific visualization. All of these uses are resource intensive and require a relatively sophisticated computer.
On the other hand, the lab computer is typically also responsible for the control of experiments. This task is very simple and requires few resources. Unfortunately, as the lab computer evolves toward greater functionality, justifying its use as an Experiment Controller becomes increasingly difficult. Each cycle that the computer uses to perform the simple task of arranging the contingencies of an experiment diminishes its ability to provide expensive resources to researchers.
As a result of these divergent niches, it appears reasonable to consider the use of two computers: a computer optimized for running experiments, which is relatively simple and inexpensive, with few resources; and a machine optimized for general-purpose use, with many resources and which provides a high degree of functionality. Fortunately, the two distinct machines can be transparently integrated into a single system that fulfills both needs while at the same time being both user-friendly and economical.
A network can be formed in which a general-purpose computer such as an IBM PC, Macintosh, or VAX passes experiment-control tasks down to inexpensive peripheral processors and provides for the orderly and transparent collection and storage of the obtained data. In this type of system, experiment control is relegated to an inexpensive machine while a computer with many resources provides for general services such as word processing, laboratory information management, and analysis. A network of simple Experiment Controllers imposes negligible overhead on the Supervisor general-purpose machine while at the same time providing large-machine support for running experiments. An additional advantage of such a network is that the main computer can be upgraded or changed without a substantial loss of software investment.
Many computer-based experiment control systems are arrived at with what appears to be the most inescapable of deductive logic but yet don't catch on. Time will demonstrate whether my own glasses were (or are) any more tint free, but at present the rationale and solution appears reasonable. Currently, there are more than 100 of the older versions of our Experiment Controllers in service and users' group discussions have been scheduled at several professional meetings. The current high performance Experiment Controllers are substantially improved by explicitly targeting reported difficulties.
Initially, I tried to conceptualize an ideal lab computer. It became apparent that the following assets were critical:
The Solution Strategy Was To:
As A Result, The Experiment Controller Has The Following Assets:
The solution strategy avoided the major difficulty in developing a behavioral control system. Writing and debugging a timesharing operating system is a lot of work, and requires meticulous attention to detail if it is not to "go off into the woods" every so often for "unknown" reasons. Additionally, there is a great deal of overhead in trying to implement several processes on the same CPU. Timesharing several experiments or experiment control and general purpose computing dramatically slows down the response time to any one. Worst case delays between a response and a consequence can be sizable in timesharing systems and can have a substantial impact. Unfortunately they are rarely documented. We felt that a multiprocessor solution was the obvious choice in that individual controllers were so inexpensive. The arguments against the use of timesharing computers for lab control are as applicable today as they were when computers first arrived in the lab. The only change has been that our dedicated lab computers have imperceptibly evolved into large timesharing computers. The 16 megabyte 32-bit timesharing computers with 300 megabytes of disk storage is now on our desk rather than across campus.
Our solution strategy also avoided the major stumbling block restricting other labs from benefiting from a lab developed system. In the past, implementing someone else's computer-controlled laboratory system had been difficult. Many systems were not developed by formally trained, professional engineers. As a result, those systems occasionally experienced more unforeseen problems than is desirable in a research program. Published experiment control systems often evolved over several years, while potential users were required to buy into the whole package in one budget year. The system was often idiosyncratic, with some of the components or the computer itself sub optimal, obsolete, or largely undocumented local constructions. Getting most of a control system was usually not enough. Either the identical hardware was necessary or the services of an in-house guru were required.
We feel that our new Experiment Controller has been designed to avoid all of these pitfalls by being an inexpensive, completely self-contained, solder masked and silk screened printed circuit board computer with on-board experiment control software support in firmware. Additionally, we will provide the boards assembled and tested for labs without technical expertise. The only obligatory task facing the researcher is to plug the Experiment Controller into some existing computer, and attach it to the experimental apparatus, and write the desired control program.
Because all of these options are hard to visualize, a number of possibilities are illustrated in the following figures.
5. Data Collection
In order to simplify the presentation, the manual presumes that you will be using a:
The intention of this manual is to present the details necessary to use all of the capabilities of the Experiment Controller. It is important to keep in mind, especially if you are a beginner, that the vast majority of researchers will need to use only a few instructions and the simplest hardware to accomplish all they need. Do not allow the detail of the manual to mask the simplicity of this system. It is unlikely that you will ever need any optional, advanced facilities. The manual must cover everything anyone would ever want. Instructions which could be skipped over on the first reading are noted "intermediate, advanced or guru." A useful strategy to get started is to just skim over this manual reading about how things work in general, and when necessary, about the simplest instructions. When you are comfortable with the system or if you need a specific instruction to do something special reread the language reference manual. Personally, I recommend that you skim through the manual every so often in case there is a much easier way to do something. Sometimes the value of a specific instruction is not apparent until you have a specific need.
It is very difficult to write a single manual to cover all conceivable possibilities for all conceivable users. Please bear with this manual. In one place or another, it will occasionally bore you, will occasionally be written in jargon, will occasionally fail to explain details you need when you need them, and will occasionally cover many details that are irrelevant to anything you will ever want to do. I recommend that you skim through attending to the headings and getting the gist of the sections. Read whenever it seems helpful, and go back through the manual several times. Make a point to eventually know what all the instructions do and to read the appropriate manual section if something seems hard to do.
If You Need More
If additional instructions or changes are desired let us know and we will try to do what we can. Reasonable changes in either the hardware or software might be considered. Extensively commented sources are available for any of this software. It was written by Don Walter specifically for the Experiment Controller and is in the public domain for non-commercial use.
Unit 1 is the Preface. It develops the "mind set" appropriate for easy use of a distributed network to do experiment control.
Unit 2 is the ECBASIC Language Reference Manual. It provides format information, how to use the various commands, error messages, and programming examples.
Unit 3 provides information concerning ECBASIC Networking with Explicit Data Collection. It presents the information necessary to establish a network of ECBASIC Experiment Controllers as peripheral processors on a general purpose machine when only explicit (summary) data recording is used.
Unit 4 provides information concerning the use of ECBASIC with an IBM PC Adaptor Board. It presents the differences between typical ECBASIC and EBAS.
Unit 5 presents information on the hardware itself: how to attach the experimental apparatus to the Experiment Controller, hardware options and how to select them, and information pertinent to building or debugging a board.
Neither the authors nor Jacksonville State University shall be libel in any way for any direct, indirect, incidental, consequential, or specific damages of any kind or from any cause whatsoever arising out of or in any way connected with the use or performance of this software or hardware. Neither Jacksonville State University nor the authors will guarantee this software nor guarantee to support it.
This project was supported by National Science Foundation grant DIR-8915226 to William L. Palya. The authors gratefully acknowledge the contributions of Elizabeth Palya.
Date Last Reviewed : June 2, 2004