Manual Revision 1.2 (26 December 1993)
Our Experiment Controller is designed to function as a remote peripheral processor in a network. The Experiment Controller is an interface between a Supervisor computer such as a PC, Macintosh or VAX and an experimental apparatus such as a pigeon chamber. Currently, fifteen Experiment Controllers may be added as peripheral processors on a single serial port of a Supervisor general-purpose machine. Multiple experiments that are extremely complex and absolutely time critical can be simultaneously conducted from a relatively simple general purpose computer.
The serial interface on the Experiment Controller is designed to appear as a modem or a dumb terminal to the Supervisor computer. As a result a simple RS-422 interface is all that is necessary to communicate to a network of Experiment Controllers. (RS-422 is standard on a Macintosh; the normal PC serial interface is RS-232 and therefore requires an RS-232 to RS-422 converter. Alternatively, an RS-422 serial interface board can be installed in the PC.)
The Experiment Controller serial interface allows multiple controllers to be attached to the same RS-422 line. This is possible because each Controller monitors the activity on the network line and if its access code, or "address," is seen, then that Controller answers, otherwise it does not interact on the line, just as if it were not connected to the line at all. This arrangement uses a select command which allows the researcher to address each particular Experiment Controller so that it will "pick up." This arrangement also uses a deselect command to get an Experiment Controller to "disconnect."
In order to simplify networking our Experiment Controllers on your general purpose computer, a network administration program is normally used on your Supervisor computer to automatically pass commands and files to the remote Experiment Controllers and read data from the Experiment Controllers onto the specified disk files of your Supervisor computer. The next sections of this chapter present the network administration software that we support. Alternatively, any number of the readily available software utilities for modem communication, RS-232/RS-422 networking, or character handling can be used to manage the Experiment Controllers.
The network administration software is designed to make the day-to-day running of experiments easy. When an experiment is to be run, it prompts the researcher for (among other things) the experiment, the apparatus, and the file name for the resulting data. It then automatically loads the experiment control program into the apparatus, starts it running, collects the resulting data, and stores the data on the disk file. Currently, fifteen different experiments can be run asynchronously.
The type of data collection you choose has a major impact on the number of experiments you can run simultaneously and the spare functionality of your Supervisor computer.
If you are doing explicit data collection and are (a) collecting only summary data from the Experiment Controllers (e.g., summating responses etc. into counters and timers); or (b) collecting complete event logs which result in less than 8K characters of data; and will use the network link only at the end of each experiment, then the only limitation on the number of simultaneous experiments which can be run is governed by the length of time it takes to upload the data and download the next experiment control program for each Experiment Controller and the acceptable delay before getting back to the first Experiment Controller. Our estimate is that it takes about one second to upload twenty-five "counters" and twenty-five "timers" from each Experiment Controller at 9600 baud. If you are satisfied with only summary data at the end of the session and need more than fifteen Experiment Controllers on your network, contact us. With a minor modification, 256 controllers could be on the same network.
If you are explicitly collecting data from your experiments only at the end of the sessions, then you can do anything you wish with the Supervisor computer while running the experiments. The Supervisor computer is not used to run the experiments and collect the data. If, while the experiments are running you wish to use the Supervisor computer for any other task, and (a) you are using RBAS on a PC, the network administration software can be terminated (see FREEZE and RESTORE in the RBAS section) or, (b) you are using ExpRun on a Macintosh, you can simply use Multi-finder to start a second task while ExpRun is still running.
The experiments are run as independent tasks in peripheral processors, therefore, in either case the experiments are unaffected. An advantage of the network concept is that virtually 100% of the resources of the Supervisor computer are available for other uses while experiments are running. When the network administration software is started again it can carry out its data collection functions and no experimental data will have been lost. The data format in the explicit mode is ASCII.
On the other hand, if you choose transparent (event log) recording then the number of experiments which can be run simultaneously is a function of the mean worst case sustained (greater than 5 minutes) data rates of the experiments, and the baud rate of the network link. The issue is that the Supervisor computer must sequentially poll each Experiment Controller and transfer the current data in each Controller to the Supervisor computer disk. (Note that it does this transparently.) The slower the baud rate of the network link and the faster the incoming data rates, the fewer the Experiment Controllers can be handled with no possibility of a data overflow in the worst case. Our estimate is that nine experiments constantly generating ten events per second can be handled at 9600 baud. The data format in the transparent mode is binary.
Hybrid data collection is supported for those researchers who wish to transmit explicitly collected data or other information to the supervisor while the experiments are running or wish to use explicit data collection rather than transparent event log data collection, but who wish to collect complete event logs anyhow (i.e., the hard way). This data collection procedure is the explicit data collection mode but data is transmitted during the experiment. This procedure will work but could cause a problem if some planning is not done.
then you will be constrained by the following:
These constraints are because ECBASIC has an 8K character buffer for characters to be sent upline to the Supervisor. As long as there are less than 8K characters to send, it has no impact on the experiment control program. (It is sent transparently by the communication software in either explicit or transparent data collection mode.) But, when full, the experiment control program stops until the buffer unfills.
For example, if an experiment has a 30 second timeout every 5 minutes during which the experiment is effectively off and you wish to upload only about fifty 6-digit counters, then data could be uploaded during the experiment to the Supervisor computer with virtually no risk of worst-case problems, even if you had a great many Experiment Controllers on the same network and a very low baud rate. However, if the longest "dead time" available were only a few seconds and you were attempting to upload a sustained data rate of more than 90 characters per second from ten Experiment Controllers across a very low baud rate network link, then a worst-case overrun is likely.
Because the controllers contain a relatively large communication buffer and the network is automatically uploading data often and at a relatively high rate, the data rate generated by an experiment in a burst can be relatively high. The baud rate and the number of active experiments constrain the window during which any one experiment can generate 8,000 characters of data (i.e., events times number of characters used to code it). If the 8K buffer fills, then ECBASIC waits for permission to use the network (it "hangs") until the buffer unfills. The faster the baud rate the fewer the characters per event, and the fewer the active experiments the longer the permissible burst window duration. We roughly estimate nine experiments, 9600 baud, 14 characters per event, at a mean 6 pecks per second in any 90-second window as being one combination of conditions which are a limiting case.
If you will be using a hybrid data collection scheme, it is a relatively simple matter to write experiment simulators (programs which generate data at a rate and pattern similar to the expected research) and simultaneously run the desired number. A simple rule of thumb is to double your best estimate of the expected data rate or provide data transmission windows half of your best estimates in order to assure that no worst-case overflow will occur. Note that all boards are configured in this mode (i.e., explicit) when shipped. See the Configuration sectionfor further details.
Before you can use your controller in a network you must provide power to your board; hook-up the communication line; and configure your board with respect to its unit number, communication mode, data collection mode, and baud rate.
RBAS (Rev. 1.24)
RBAS is a program which runs on IBM PC or PC-compatible machines running MS-DOS. RBAS administers and coordinates all the communication between the Supervisor computer and the Experiment Controllers, much as a good executive secretary handles the details of carrying-out the wishes of a president. RBAS is intended for use in situations where explicit summary data recording is done and the data are collected at the end of a session. In that situation also, data communication issues will not affect experiment control. RBAS will function in hybrid data collection situations (i.e., explicit data collection and data sent upline during the experiment), but the researcher should carefully think through worst-case situations and the consequences of a controller waiting to send data when it should be controlling the experiment. Note that you first must set up your hardware as indicated in the Hardware section.
Under normal conditions, RBAS is invoked by typing the following:
or RBAS can be invoked with two optional parameters, port number and baud rate. In that case, RBAS is invoked by typing the following:
Port number is set to either 1, (when the Experiment Controllers are connected to COM1), or 2 (when the Controllers are connected to COM2). Baud (the transmission speed) is set to match the baud rate at which the Controllers have been set (see board configuration procedure). RBAS defaults to COM1 at 9600 baud if no arguments are provided. For any other setting, both calling parameters must be provided. The arguments are not separated by commas and no brackets are used.
Example:
If any illegal calling parameters are specified, the following message will be printed:
For an IBM PC or an IBM PC/XT, communication to the Experiment Controllers should be at 4800 baud. An XT will communicate at 9600 baud, but there may be occasional errors. If you experience errors in uploading or downloading information, the PC may be having trouble keeping up. Set the Controller and the RBAS calling parameter to a slower baud rate.
When RBAS starts, it prompts the researcher with the word:
Below are the responses recognized by RBAS. All are single character commands.
A "Control-Break" will abort any of these routines. RBAS will then return to the Command prompt.
Start
If you wish to START an experiment when at the command prompt, enter:
RBAS will then prompt the researcher with:
An experimental apparatus number (1 through 15) is then entered, for example:
If the apparatus number entered is one that is already running, RBAS will print the following message:
Assuming no error at "Apparatus Number," RBAS then prompts for the name of the ECBASIC experiment control program which implements the experimental procedures for the current session in that apparatus.
After the prompt, the name of the file is entered, followed by a carriage return.
Our convention for experiment control programs happens to be, for example E35L.XXX (experiment 35, phase L (i.e., 12)). However, any convention can be used. The file need not be in the default directory. If it is in some other subdirectory, the appropriate subdirectory names along with the file name in normal MS-DOS format is entered. If the file specified is not found, RBAS will respond with:
Assuming no error at "Program Name", RBAS prompts for the name of the file in which that day's data for that experimental apparatus are to be stored.
The name of the data file followed by a carriage return is then entered.
Our convention for data file names happens to be for example, 345035.L14 (bird 345, experiment 35, phase L, session 14). Again, this file can be created in any subdirectory by using normal MS-DOS format. When the file name is entered, RBAS will check to see if the data file already exists. If it does, RBAS will respond with
Enter your response as either "Y" or "N," for example:
If the response is "Y," RBAS overwrites the file (e.g., experiment started and then aborted because of some error, and you do not care about the data). If the response is "N," RBAS will reprompt for a new data file name (e.g., experiment started and temporarily stopped for some reason, like a power failure, and you want to continue the session, and you want to save both parts of the data).
If the specified file cannot be created, RBAS will print the message,
and will reprompt for the data file name.
Before RBAS starts an experimental session, it creates and opens the specified data file, sends the program to the specified Controller, and then tries to start it. If there are no problems, RBAS will return with the command prompt. However, if the Experiment Controller does not respond properly RBAS prints the message.
If this error occurs, the apparatus is probably turned off, in apparatus test mode, or disconnected. Correct the fault, reset the Controller and try again.
RBAS is constantly polling. It links with each Experiment Controller each (number of active controllers times 1.2 seconds). If there are any pending PRINT statements, then RBAS uploads the strings and transparently appends them to the designated disk file for that controller. Specifically, RBAS gives each controller, in turn, 1 second to "talk" and appropriately stores the information it receives.
Because ECBASIC must wait for permission to upload data, it is typical programming practice to put all "PRINT" statements at the end of the program after the experiment is over, if you do not specifically wish to collect data while the experiment is running. In point of fact, the Experiment Controller has a large buffer and RBAS can service Controllers relatively quickly. It is likely that PRINT statements can send data almost whenever you wish. However, worst case possibilities must be considered. The Controller halts at PRINT statements if its buffer has filled until the buffer unfills.
If a PRINT "*DONE*" statement follows the data at the end of an experiment, then RBAS will react to that item in the data stream by signifying that that experiment has completed by printing on the screen.
Loading Daily Parameters
RBAS also allows adjustment data to be loaded with a control program. In this case, the data is appended to the control program file following an *DATA*. Care should be taken to match the carriage returns in the data with the format requested by the input statement. Note that the data for
would appear as
while the data for:
would appear as:
Kill
The KILL command is used to immediately terminate an experiment. If you wish to KILL an experiment when at the command prompt, enter:
Again, RBAS prompts for a specific experimental apparatus number.
The program for the specified Experiment Controller will be halted, all the outputs in the apparatus will be turned off, and the data file will be closed. RBAS then returns with the Command prompt.
Display
The DISPLAY command provides the status of the currently running experiments. If you wish to display the current status of the experiments when at the command prompt, enter:
RBAS lists all active experiments in the following manner:
If all experiments have finished, RBAS will print the following message:
This message also occurs if RBAS has just been RESTARTED. RBAS will initially assume that no Experiment Controllers are running.
Display Status
You may display status information about any of the experiments which are running with the DISPLAY command.
In order to display a status message, insert a PRINT "*STATUS*" in the output buffer. For example,
The status message consists of any characters following the "*STATUS*" up to the next carriage return. If the status message does not fit on the line it will be truncated.
Run time error messages are also displayed in the display report when requested. If an error occurs while running a program ECBASIC prints the error with a leading "*ERROR*". RBAS copies the remainder of the line to the status buffer and displays it in the display report when requested. Note that after an error the unit will continue to display as active (since no "*DONE*" was seen), so you will need to KILL the unit to clear its active state.
Reinstating RBAS
There may be times you want experiments to continue to run but you would like to quit out of RBAS or even turn off your machine. If RBAS is exited while experiments are running, all open data files are closed. The Controllers, nevertheless, continue running and collecting data as if nothing had changed. When the controller is ready to upload, it will wait for the go-ahead signal from RBAS as always. If RBAS is not running the controllers will stay at that state indefinitely with no data loss. RBAS provides several options:
Freeze
The FREEZE command saves the status of the network as a disk file. It saves the Experiment Controllers which had been active, and the names of the appropriate data files for each. If you wish to freeze the status of the network when at the command prompt, enter
The status will be saved as a disk file called RBAS.DAT. if you frequently experience problems which require that you restart RBAS, you may wish to FREEZE immediately after starting your experiments in case anything goes wrong.
If you wish to reinstate RBAS from MS-DOS, type:
The /r switch reinstates RBAS with the network status as it was when the last FREEZE was executed. RBAS will consider those Experiment Controllers which had been active still active, will re-open the disk files which had been open, and will append the data from the previously specified Controllers to the previously specified disk files. Care should be taken not to do an RBAS/r when you had intended to "start fresh" or if you froze some other configuration than the one that you wish reinstated.
Restart
If you were running experiments and your Supervisor computer crashed requiring you to reset or reboot, you can restart RBAS where it left off. RBAS is restarted by invoking RBAS and when at the command prompt, enter:
The restart procedure is quite similar to the start-up procedure. RBAS prompts with
The number of an apparatus (1 through 15) that was running before RBAS was exited is then entered, for example:
Next, RBAS prompts for the data file name
If the file name specified
already exists (which it will if you are restarting), RBAS will prompt with:
The new data will overwrite the old data file if your response is
The new data will be appended to the old data file if your response is
This is typically the appropriate response.
RBAS will reprompt you for a new file name. If your response is
If the file specified cannot be created the message:
will be printed and RBAS will reprompt for the data file name.
When set up RBAS will then return to the command prompt and begin collecting data.
Connect
The Connect command allows you to establish a dedicated link directly to a particular Experiment Controller. The PC then acts as nothing more than a keyboard and a CRT screen on the Experiment Controller. If you wish to connect to the Experiment Controller when at the command prompt, enter:
In this mode no network communication is necessary because in effect there is only one computer. The system will act exactly as any computer running BASIC. If you type LIST, the program will be listed onto your monitor. This mode is very useful in debugging ECBASIC programs. For example, if you type "TURNON 4", light number 4 will go on. If you type PRINT A the value of variable A will be printed onto your screen. It is important to note however that RBAS cannot function as a network administration controller for other experiments while in the direct connect mode and you do not have any of your IBM PC resources such as an editor or a disk. (This configuration is exactly the same as having a terminal connected directly to a single controller in stand-alone mode, see stand-alone mode section.
RBAS prompts for the number of the apparatus to which you wish to connect.
You respond by entering the controller number (1 through 15), for example:
RBAS prints the following:
When the "OK" prompt appears, the direct link has been established. "OK" is the ECBASIC prompt sent from the Experiment Controller itself. The Experiment Controller is the computer you are "on" and it is an independently functioning computer waiting for input from the keyboard. At this point ECBASIC commands can be sent directly to the controller and the responses will print directly to the screen or will directly activate output on the Experimental apparatus (e.g., typing "TURNON 4" will turn on output 4). See the System Commands or the Immediate Mode section of the unit on the ECBASIC language. To break the link, type Control-Break. This returns to the command mode.
Quit
The Quit command exits RBAS and returns to MS-DOS. If you wish to quit from RBAS and return to MS-DOS when at the command prompt, enter:
When RBAS is exited, the experiments continue to run undisturbed. However. the data generated by those experiments will not be automatically stored on the disk when the experiments complete. RBAS must be restarted to obtain that functionality. When RBAS is exited all open files are closed. To re-open the files for data collection, RBAS must be reinstituted through the Restart command or the RBAS/r command.
MS-DOS requires that you specify how many files you wish to have "open" at the same time. maintaining open files uses system resources and therefore it is not appropriate to provide for an excessively large number of files. The parameter is maintained in a file on your root directory on the drive to which you boot and is labeled CONFIG.SYS. The number of file control blocks (FCBs) should be set to:
This specifies that 16 files can be open at one time and that their are 8 that MS-DOS cannot close automatically. The number of open files that MS-DOS can access should be set to:
This specifies that there can be 20 open files that system calls can access.
If you do not have a CONFIG.SYS file or if all of this MS-DOS stuff is confusing, contact your MS-DOS guru or technician who will set up your CONFIG.SYS for you. It is a characteristic of MS-DOS and is therefore common to all IBM and IBM clones. Note that some older DOS versions or subsets of DOS may not accept FCBS=16,8.
ExpRun (Rev. 0.91 Beta)
ExpRun is a program which runs on Apple Macintosh computers. ExpRun administers all the communication between the Supervisor computer and the Experiment Controllers, much as a good executive secretary handles the details of carrying-out the wishes of a president. ExpRun is intended for use in situations where explicit summary data recording is done and the data are collected at the end of a session. In that situation, data communication issues can not affect experiment control. ExpRun will also function in hybrid data collection situations (i.e., explicit data collection and data sent upline during the experiment). However, the researcher should carefully think through worst-case situations and the consequences of a controller waiting to send data when it should be controlling the experiment. Note that you first must set up your hardware as indicated in the Hardware section.
B. First you must set the communication options.
1. Select the port
The options can be viewed by clicking (and holding) on the down arrow in the PORT box. Choose the desired port by releasing the button over your choice.
2. Select the baud rate
Decide what baud rate you would like. Keep in mind that the higher the baud rate, the more difficult it will be for the Macintosh to keep up. The slower the baud rate, the more time consuming the data transfer. A good start is to select 9600 baud. If you encounter any problems, slow it down. If it works fine and you want faster data transmission, speed it up.
See Hardware section on baud rate and confirm that it is set to your desired baud rate.
Position the cursor over your baud rate choice and release.
3. Select the desired type of data collection
Decide whether you want to use explicit data recording or transparent data recording. (See Networking section on data collection types.) Set the dip switch on the Experiment Controller accordingly. (See Hardware section on how to configure the board for your desired data collection type.)
If you will be doing explicit (summary) recording with the general intent of uploading the data at the end of the experiment. ExpRun will give each Experiment Controller permission to use the network link for 1 second in turn each (number of Experiment Controllers times 1.2) seconds. ExpRun will store the data for each experiment in ASCII format into the specified data files. This data can then be imported directly into whichever database or analysis program you want.
(2) Select transparent (event log) recording/binary
When you have completed setting the communication options, click OK to implement your choice.
Start
If you wish to load an experiment control program into an apparatus and start it
a. Enter the address of the desired apparatus
When you have entered the address of the desired apparatus, click on the
OK button. To cancel the START function click the CANCEL button.
b. Select the experiment control program you want
Our convention for naming experiment control programs happens to be: E, experiment number, phase letter, group number.XXX. For example, E35L.XXX (experiment 35, Phase L). Additionally, we maintain current experiment control programs in the EXPERIMENTS folder. However, any convention can be used. The file need not be in any particular directory. Use the normal Macintosh procedures to get to the file you want.
c. Enter the name of the data file into which the results of that experiment are to be put.
Our convention for data file names happens to be bird number, experiment, phase and session, for example, 345035.L14 (bird 345, experiment 35, phase L, session 14). This kind of scheme makes it easier for automated batch analysis programs. Again, this file can be created in any subdirectory by using normal Macintosh procedures. The name of the data file followed by a return is then entered.
When the file name is entered, ExpRun will check to see if the data file already exists. If it does, ExpRun will respond with a question box:
Click yes or no
If the response is "Y", ExpRun overwrites the file (e.g., the experiment started and then aborted because of some error, and you do not care about the data). If the response is "N" (e.g., experiment started and temporarily stopped for some reason, like a power failure, and you want to continue the session, and you want to save both parts of the data). ExpRun will reprompt for a new data file name.
If the specified file cannot be created, ExpRun will display the error box:
and will cancel the start command.
Before ExpRun starts an experimental session, it creates and opens the specified data file, sends the program to the specified Controller, and then tries to start it. If there are no problems, ExpRun will return with the command prompt.
Once the experiments are running, ExpRun intermittently polls each one. If there are any pending PRINT statements, then ExpRun uploads the strings and transparently appends them to the designated disk file for that controller. Specifically, ExpRun gives each controller, in turn, 1 second to "talk" and appropriately stores the information it receives.
If you do not specifically wish to collect data while the experiment is running, typical programming practice is to put all "PRINT" statements at the end of the program after the experiment itself is over. This is because if the data buffer on the Experiment Controller is full, ECBASIC must wait for permission to upload data. In point of fact, it is likely that PRINT statements can send data whenever you wish, especially at higher baud rates. It takes very little real time to transmit large amounts of data at 56K baud and an 8K buffer is very large. However, worst case possibilities must be considered. The Controller halts at print statements if its buffer has filled until the buffer unfills.
If a PRINT "*DONE*" statement follows the data at the end of an experiment then ExpRun will react to that item in the data stream by closing the data file for the experiment and setting the apparatus status to IDLE. If no other units are active ExpRun will display an "All Units Done" alert and activate the system warning sound (i.e., beeps you).
Loading Daily Parameters
ExpRun also allows adjustment data to be loaded with a control program. In this case, the data is appended to the control program file following an *DATA*. Care should be taken to match the carriage returns in the data with the format requested by the input statement. Note that the data for
would appear as
while the data for:
would appear as:
Kill
If you wish to KILL a running experiment control program The KILL command is used to immediately terminate the experiment. The program for the specified Controller will be halted, all the outputs in the apparatus will be turned off, and the data file will be closed.
Pull down ACTION
Display Status
If you wish to display the status of the experiments which are running the DISPLAY STATUS menu entry causes a status window to be displayed.
Pull down ACTION
ExpRun lists all active experiments in the following manner:
Entries for Idle units are displayed in "gray" format. For active units it is possible to display a status message by inserting a "*STATUS*" in the output.
The status message consists of any characters following the "*STATUS*" up to the next carriage return. If the status message does not fit in the Status Window it will be truncated.
Run time error messages are also displayed in the status window. If an error occurs while running a program ECBASIC prints the error with a leading "*ERROR*". ExpRun copies the remainder of the line to the status buffer and displays it in the status window. After an error the unit will continue to display as active (since no "*DONE*" was seen), so you will need to KILL the unit to clear the active state.
You may position the display box where ever you wish.
When you no longer wish to have the DISPLAY window open, close it in the standard Macintosh fashion or select DISPLAY STATUS again to toggle the window off.
Connect
If you wish to connect directly to a particular Experiment Controller
The Connect command allows you to establish a dedicated link directly to a particular Experiment Controller. The Macintosh then acts as nothing more than a keyboard and a CRT screen on the Experiment Controller. In this mode no network administration is necessary because in effect there is only one computer. The system will act exactly as any computer running BASIC. If you type LIST, the program will be listed onto your screen. This mode is very useful in debugging ECBASIC programs. For example, if you type "TURNON 4", light number 4 will go on. If you type PRINT A the value of variable A will be printed onto your screen. It is important to note however that ExpRun cannot do network administration for other experiments while in the direct connect mode and you do not have any of your Macintosh resources such as an editor or a disk. (This configuration is exactly the same as having a terminal connected directly to a single controller in stand-alone mode (see stand-alone mode section.))
When the text window appears, the direct link has been established. The Experiment Controller is the computer you are "on" and it is an independently functioning computer waiting for input from the keyboard. (An "OK" is the ECBASIC prompt sent from the Experiment Controller.)
If you wish to disconnect, simply click the close box on the window.
On older Macintosh machines (i.e., 512K or Mac Plus) the keyboard does not have a control key making a Control-C (interrupt) difficult to perform. On these machines use Option-C or ENTER to generate a control-C. Some International keyboards may need to be an Option-X.
Quit
If you wish to QUIT,
The Quit command exits ExpRun and returns to Finder. If experiments are running pending data may be lost. Note that if you wish to do something else with your Mac, simply start the new task with system seven.
Pulldown ACTION
(This section has not been verified)
Experiment Controllers can be used with Apple IIe and IIc computers as Supervisors by using any of a number of modem communication programs. ProTERM can be made to work. The limitations of the ProTERM software constrains the "user-friendliness" of this administrative software.
This section documents the actual characters which cause the Experiment Controllers to "pick up" or "hang up" from the network line. This section also provides examples of network administration and communication for the advanced user. With this information you can develop your own network administration software or configure any communication package to your needs.
SELECT COMMAND
To select a particular Experiment Controller send an ASCII SOH (Control-A or 01 hex); followed by the unit number (ASCII 0 - 9 and A - F) (30 -39 hex and 41 -46 hex); followed by an ASCII capital S (53 hex). This transmission will "wake-up" the specified Controller #1 or will get Controller #1 to "pick up" its connection to the network "party line." Note that this message is only 3 characters. The unit number of the Experiment Controller is set by the unit number mode select switch on the Experiment Controller itself (see the Hardware section of the document). The format of the select command is as follows:
where - <> are not used - they are for showing that only
- S0H is 01 hex
- unit is the number or letter (0-9, A-F) which specifies the unit number as specified in the unit number dip switch
- S is 53 hex
Example:
^A1S
where - ^A is used to represent the Control-A character
DESELECT COMMAND
To deselect or place a particular Experiment Controller off-line send an ASCII DC3 (ASCII Control-S or 13 hex). Note that this is only a single character. This transmission will get whatever apparatus is selected to "hang-up." This command can be used to throttle the transmission coming up the line when the Supervisor computer is getting swamped such as when a disk access is necessary. Only one Experiment Controller can be selected at a time so a unit number is not necessary. The format of the DESELECT command is as follows:
where - <> are not used - they are for showing that only a
- DC3 is 13 hex
Example:
^S
where - ^S is used to represent Control-S
TYPICAL PROTOCOL
The networking protocol is very straightforward and is essentially the same as typing on a terminal to a stand-alone system with some very slight differences.
The following are exact character by character replicas (excluding the "any program" indicator) of the file necessary to send various programs to an Experiment Controller. ^ signifies a control character as ^A = Control-A. <CR> signifies carriage return. <LF> signifies line feed. Blank spaces represent the character "space." Line feeds have been added to the example for clarity (most systems insert line feeds following carriage returns anyway). Note that the controller sends a line feed following every transmitted carriage return. These can be ignored by the Supervisor computer or used as error checks during program loading. Additionally, note that when sending ECBASIC, line numbers should be in increasing order otherwise the controller will spend time shifting the program around while you are trying to downline load a program.
Downline loading an ECBASIC program.
Main to Controller Controller to Main ^A1S<CR> OK<CR><LF> ^C<CR> OK<CR><LF> NEW<CR> OK<CR><LF>
10 REM This shows the format for network communication<CR> ------------ 11 REM When it is only an ECBASIC program<CR> P 20 DIM A(5)<CR> R 30 FOR I=1 TO 5<CR> A O 40 A(I)=I<CR> N G 50 NEXT I<CR> Y R 60 FOR I=1 TO 5<CR> A 70 PRINT A(I)<CR> M 80 NEXT I<CR> 90 END<CR> ------------- OFFRUN<CR>
This message will select Experiment Controller 1 (^A1S), terminate any running program (^C), clear the program buffer (NEW), downline load the program, and start the program running and deselect the Controller (OFFRUN). The response to the initial ^A1S depends on what the Experiment Controller is doing. If it is running a program, it will not respond. If it's waiting to output, it will begin sending its output. If it's just waiting, then the response will be as shown. After executing the lines 10-60 when it encounters the PRINT statement the Controller will "hang," waiting for "permission" to output. Whenever the main computer again issues
Your software on the Supervisor computer, or network administration software can then read this input exactly as if it were being typed in from a terminal. The ECBASIC program will continue printing until it completes the program or it is sent a ^S which will halt output until a further ^A1S is sent. In this way, the program on the Supervisor computer can halt input while it is writing to a disk or "catching up" so that the input from the Experiment Controller will not swamp the Supervisor computer. After all data is obtained send a ^S to deselect the Experiment Controller. The Experiment Controller will not execute a PRINT statement if it is deselected. It will execute all PRINT statements when it is selected.