Back to Index

Preface

Problem

What is needed is a powerful, easy-to-use, inexpensive way to run experiments.

Solution Paradigm

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.

In order to optimize the two types of data recording, the Experiment Controller functions in two modes. Transparent data recording (for event logs) automatically and transparently takes care of virtually everything. Explicit data recording is for summary data primarily, but it could do event logs with a bit of planning. In this mode the experiment control program is responsible for keeping track of the behavior and is responsible for PRINTING it (in the desired format) to the network link. The network administration software transparently takes care of getting it to the right disk file with no action required by the researcher.

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.

Why a Network to do Experiment Control?

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.

Why a Network Based on this Experiment Controller?

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:

Design Goals:

  1. a low purchase price
  2. a simple package with no interfacing required
  3. versatility sufficient to support a wide variety of experimental apparatus and experimental designs
  4. an easy to learn and easy to use programming language
  5. high reliability
  6. a short mean time to repair and a low maintenance cost
  7. the ability to resist obsolescence
  8. the very best operating system environment and application tools
  9. transportability of control programs, database, and application software to other laboratories

The Solution Strategy Was To:

  1. develop a microprocessor-based Experiment Controller as a high- quality printed circuit board
  2. implement in firmware a specially written BASIC optimized for Experiment Control (ECBASIC)
  3. design the board to function as a peripheral processor on a network administered by whatever general-purpose computer the researcher wished to use

As A Result, The Experiment Controller Has The Following Assets:

  1. It's inexpensive. A complete, assembled and tested Experiment Controller costs about $600 - $700; less if you build it yourself.
  2. It's simple. One Experiment Controller does everything. It attaches directly to the Supervisor computer and the experimental apparatus with no additional interface required.
  3. It's integrated. One Supervisor computer is all that is necessary to control up to ten very complex experiments with 1 millisecond data collection.
  4. It's versatile. It's primarily for digital input and output. However, commercially-available daughter boards can be used to input or output analog signals. The Experiment Controller provides up to 8 inputs and 44 outputs, therefore experiments with three, 12-stimulus projectors can be controlled. The boards can be partially populated if only a few inputs or outputs are required. Additionally, the Experiment Controller can function as either a networkable controller or as a stand-alone computer.
  5. It's easy to implement research. ECBASIC is simple, easy to learn and easy to use. It's well known, many people can already program in BASIC, and many "how to" books are available. Additionally, we designed into our ECBASIC many high level process-control commands and detailed error messages. It may not be structured, but it is straightforward and is generally very easy to follow. This is especially true within the niche of ECBASIC, i.e., a control program for a single subject.
  6. It's reliable. We have experienced no in-house post start-up failures. Opto-isolated inputs and separate I/O and CPU power supplies have eliminated the source of occasional crashes that some labs experienced with our earlier system. An second problem we occasionally experienced with our previous system had been the result of our encouraging researchers to assemble it themselves in order to save money. Many labs built their own boards, unfortunately a few experienced intermittent failures which were generally found to be assembly problems. The current Experiment Controller is less complex, is solder masked to virtually eliminate "solder splashes," and is silk screened with the parts placement. As a result, assembly is far less demanding.
  7. It can be repaired quickly and has a low maintenance cost. Immediate maintenance entails replacing a malfunctioning board with a spare. Mean time to repair is therefore just a few minutes. Chip failures can usually be identified by swapping chips with those those from a working board. It's extremely unlikely that swapping chips would fail to identify the problem. As maintenance costs approach replacement cost, the board can be discarded; as a result, repair can never cost more than $600. Even total catastrophic meltdown becomes a relatively minor problem.
  8. It resists obsolescence. Often the pressure to upgrade a lab computer has been because of the availability of faster computers which provide better operating system utilities and application software; not because of the weakness of the process control component. Separating the experiment control subsystem from general computing allows the researcher to upgrade or change either one whenever it's appropriate without losing the other.
  9. The best operating system and application software is always available. The task of maintaining state of the art and optimal general-purpose software is left to commercial vendors who can provide the resources to develop and support it. The researcher may choose whatever hardware and software is appropriate at any point.
  10. Its programs are transportable because all boards are the same all control programs are the same.
  11. The Experiment Controller has on-board diagnostics. The memory is tested each time the board is powered up, and a firmware apparatus test mode can be enabled with a toggle switch. In this mode, each time an input occurs, the next consecutive output is turned on. An "off-line" test of the integrity of the Controller and experimental apparatus can be quickly performed each morning or before each session by activating each operandum and observing that each of the stimuli go on and off.

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.


OPTIONAL CONFIGURATIONS

  1. Supervisor Computer
    1. IBM PC compatible
    2. Macintosh
    3. Other personal computer
    4. VAX
    5. A dumb terminal rather than a computer

  2. Experiment Control CPU
    1. Experiment Controller
    2. An IBM PC itself by using an interface adaptor. If you have an IBM PC compatible and must minimize cost and can dedicate your PC to experiment control, then an adaptor board can be used to allow your PC to run ECBASIC and ECL and to drive our interface boards directly.

  3. Interface

Because all of these options are hard to visualize, a number of possibilities are illustrated in the following figures.

ASSUMPTIONS UNDERLYING THIS MANUAL

In order to simplify the presentation, the manual presumes that you will be using a:

USE OF THIS MANUAL

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.

THIS DOCUMENT IS ORGANIZED AS FOLLOWS:

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.

DISCLAIMER

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.

ACKNOWLEDGMENT

This project was supported by National Science Foundation grant DIR-8915226 to William L. Palya. The authors gratefully acknowledge the contributions of Elizabeth Palya.


Back to Index

Next Section



Contact: Don Walter

Date Last Reviewed : June 2, 2004