Automatic running of MED-PC controlled experiments1
Michael Davison
University of Auckland, New Zealand.
We run our experiments automatically in a time-shifted environment in which the room
lights go on at 12 midnight and off at 4 pm. Thus, each pigeon has its own intelligence
panel consisting of 3-4 keys, a magazine, and colored lights behind the keys. We have
developed an automatic running procedure over a number of years – initially using only a
small amount of MPC I/O and using decoders on each interface that, when sent a code,
turned that interface on, and the other 5 parallel connected interfaces off. We have now
moved to separate I/O for each intelligence panel, and I’ll discuss the new system only.
Each experiment has 6 pigeons and panels, and we run these simultaneously. I’ll take the
example of the machine that runs Experiments 2, 4, 5 and 10 (one more to be added).
The I/O for this set consists of 15 DIG-716B cards set to the appropriate memory
locations. Each of the 716Bs (which have 8 inputs and 16 outputs) controls two pigeon
panels, so each one has 4 inputs and 8 outputs (we wired the connections ourselves, but I
am sure that MED Associates could easily provide appropriate connection leads). Thus,
the first 3 716s run the 6 birds in Experiment 2. The 5 experiments are run successively –
Pigeons 21-26, then Pigeons 41-46, and so on. We use MED-PC 4, build 46.
Because you can’t (apparently) set up 36 boxes in MED-PC configuration (I’d be happy
to be shown to be wrong!), we have to use special procedures to load the appropriate
configuration (.dta) files for each successive experiment, using the /INSTALL=
command line addition when loading MED-PC. There is a bug in the interpretation of
this in Build 46 (and probably in previous builds) that fails properly to interpret
commands of the form
/INSTALL=”C:\MED-PC IV\filename.dta”
and this command will only work in this way
/INSTALL=filename.dta
and for this to work, you have to have moved to the MED-PC IV directory before starting
MED-PC.
This fragment is how we do this for Experiment 2 in a batch file:
cd c:\med-pc IV
start/wait MEDPC_IV.exe /I /INSTALL=MPC2INST2.dta
the cd command moves the focus to the MED-PC IV directory so that MPC2INST2.dta
can be found without drive and directory information.
Start/wait starts MED-PC and waits until the software has completed running before
moving on to the next line in Batch (without this, batch files will do all the commands on
all lines without waiting). Thus, the exit on completion in MED-PC has to be set up for
all MPC running programs.
/I forces MED-PC to use the interface – sometimes, we have found, it can fail to find it
when it is there.
The Batch file that runs all of the experiments (Starter.bat) is:
del c:\birds\data\*.0
cd c:\med-pc IV
start/wait MEDPC_IV.exe "c:\MED-PC IV\macro\macEXPT2.mac" /I
/INSTALL=MPC2INST2.dta
start/wait MEDPC_IV.exe "c:\MED-PC IV\macro\macEXPT4.mac" /I
/INSTALL=MPC2INST4.dta
start/wait MEDPC_IV.exe "c:\MED-PC IV\macro\macEXPT5.mac" /I
/INSTALL=MPC2INST5.dta
start/wait MEDPC_IV.exe "c:\MED-PC IV\macro\macEXPT10.mac" /I
/INSTALL=MPC2INST10.dta
start/wait c:\birds\expt5\b5anal.exe
start/wait c:\birds\expt5\Crender5.exe
start/wait c:\birds\expt2\cb2anal.exe
start/wait c:\birds\expt2\Cmove2.exe
start/wait c:\birds\expt4\cb4anal.exe
start/wait c:\birds\expt4\Crender4.exe
start/wait c:\birds\expt10\cb10anal.exe
start/wait c:\birds\expt10\convert.exe
(without the carriage returns on the starting MED-PC lines)
In this way, the (current) 4 experiments are run successively, and then a series of
PowerBASIC executables are run that do things like simple analyses, and moving,
backing up, and truncating data files made by MED-PC( because we use large arrays that
are never completely filled).
For exch experiment, an appropriate macro is set up – for example, for Experiment 2, we
have:
LOAD BOX 1 SUBJ 1 EXPT
FILENAME BOX 1 BIRD21.0
LOAD BOX 2 SUBJ 4 EXPT
FILENAME BOX 2 BIRD24.0
LOAD BOX 3 SUBJ 2 EXPT
FILENAME BOX 3 BIRD22.0
LOAD BOX 4 SUBJ 5 EXPT
FILENAME BOX 4 BIRD25.0
LOAD BOX 5 SUBJ 3 EXPT
FILENAME BOX 5 BIRD23.0
LOAD BOX 6 SUBJ 6 EXPT
FILENAME BOX 6 BIRD26.0
EXIT_WHEN_DONE ON
START BOXES 1 2 3 4 5 6
2 GROUP 0 PROGRAM EXPT2
2 GROUP 0 PROGRAM EXPT2
2 GROUP 0 PROGRAM EXPT2
2 GROUP 0 PROGRAM EXPT2
2 GROUP 0 PROGRAM EXPT2
2 GROUP 0 PROGRAM EXPT2
(again without the carriage returns). Similar macros are written for the other
experiments.
The odd order is because the first 716B runs Pigeons 21 and 24, just because of the
physical way we have the cages in the lab – it’s easier to run the partial DB 25 connection
between 21 and 24 than between 21 and 22.
An example of a .dta file may be useful – this one Experiment 4, which is run from the
3rd to the 5th 716Bs:
MPC INSTALLATION
RESOLUTION 10
NUMBOXES 6
TIMERADD 768
LONG_NAME 0
ENDTIME 1
DRIVE
FLOPPY 0
BACKUPS 0
AUTODUMP 0
NAMEFORMAT C
PRINTTYPE 4
NAMECHAR !
BKUPFREQ 10
IRQ 3
RMAX 1 4
RMAX 2 4
RMAX 3 4
RMAX 4 4
RMAX 5 4
RMAX 6 4
INPUT 1 1
INPUT 1 2
INPUT 1 3
INPUT 1 4
INPUT 2 1
INPUT 2 2
INPUT 2 3
INPUT 2 4
INPUT 3 1
INPUT 3 2
INPUT 3 3
INPUT 3 4
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
MAXOUT
OUTPUT
4
4
4
4
5
5
5
5
6
6
6
6
1
1
1
2
3
4
1
2
3
4
1
2
3
4
8
1
2.0
C:\birds\data\
783
783
783
783
783
783
783
783
784
784
784
784
0
0
0
0
0
0
0
0
0
0
0
0
0
1 1
0
2 1
0
4 1
0
8 1
0 16 1
0 32 1
0 64 1
0 128 1
0
1 1
0
2 1
0
4 1
0
8 1
784
784
784
784
785
785
785
785
785
785
785
785
0
0
0
0
0
0
0
0
0
0
0
0
0 16 1
0 32 1
0 64 1
0 128 1
0
1 1
0
2 1
0
4 1
0
8 1
0 16 1
0 32 1
0 64 1
0 128 1
792 1
6
1 1
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
MAXOUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
MAXOUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
MAXOUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
MAXOUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
MAXOUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
OUTPUT
INPORT
INPORT
INPORT
OUTPORT
OUTPORT
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
4
4
4
4
4
4
4
4
4
5
5
5
5
5
5
5
5
5
6
6
6
6
6
6
6
6
6
0
0
0
1
1
2
3
4
5
6
7
8
8
1
2
3
4
5
6
7
8
8
1
2
3
4
5
6
7
8
8
1
2
3
4
5
6
7
8
8
1
2
3
4
5
6
7
8
8
1
2
3
4
5
6
7
8
783
784
785
792
792
792
792
792
792
792
792
792
1
1
1
1
1
1
1
6
2
6
4
6
8
6 16
6 32
6 64
6 128
1
1
1
1
1
1
1
792
792
792
792
792
792
792
792
1
1
1
1
1
1
1
1
7
1
7
2
7
4
7
8
7 16
7 32
7 64
7 128
1
1
1
1
1
1
1
1
792
792
792
792
792
792
792
792
1
1
1
1
1
1
1
1
8
1
8
2
8
4
8
8
8 16
8 32
8 64
8 128
1
1
1
1
1
1
1
1
792
792
792
792
792
792
792
792
1
1
1
1
1
1
1
1
9
1
9
2
9
4
9
8
9 16
9 32
9 64
9 128
1
1
1
1
1
1
1
1
792
792
792
792
792
792
792
792
1
1
1
1
1
1
1
1
10
1
10
2
10
4
10
8
10 16
10 32
10 64
10 128
1
1
1
1
1
1
1
1
792
792
792
792
792
792
792
792
0
0
0
6
7
1
1
1
1
1
1
1
1
1
1
1
1
1
11
1
11
2
11
4
11
8
11 16
11 32
11 64
11 128
1
1
1
1
1
1
1
1
OUTPORT
OUTPORT
OUTPORT
OUTPORT
TESTPORT
TESTPORT
TESTPORT
TESTPORT
INPORTMIN
INPORTMAX
OUTPORTMIN
OUTPORTMAX
INRACKMIN
OUTRACKMIN
1 792
8
1 792
9
1 792 10
1 792 11
783 -1 1
0
0 2
0
0 3
0
0 4
783
785
792
792
1
1
1
1
1
1
Notice the input memory locations starting at 783 (the first 716 is at 780), and the
memory locations and offsets for the outputs.
So, how do we get the STARTER.BAT above to start at the right time? We use the MS
task scheduler (we use Win2000) to run this file at an appropriate time. This is not ideal,
but seems to be all that is available (other schedulers, like AT, have the same problems
below). The problem seems to be this: Our machines are connected to our network, and
we have to have automatic updates from MS turned on. Even though we set this to
“advise us when new updates can be downloaded”, even this process seems sometimes to
kill the task scheduler – requiring the password again to be supplied before it will start
the batch file again. This doesn’t happen when we are not connected to the network.
Thus, about once every month or two, the experiments are not started and we lose a set of
data. But this seems a small price to pay – the benefits of this system of running are (1),
it’s accurate every time; (2), no one has to mess around actually running the pigeons; (3),
the pigeons get handled less (just weighed once a day); (4), the data are available to us
when we come to work in the morning; and (5), with the machines connected to the
network, we use another task scheduler set up to back up all our data and running files
each day to the network (using Xcopy). The drawback is the cost of all the MED
interfacing, but we try to use this efficiently.
If any reader can see better ways of doing this, please post to this website.
1
With thanks to Tom Tatham who has given us critical help on a number of occasions,
and Doug Elliffe who is the co-developer of the above procedures.