Automatic running of MED-PC species: any
Maintainer Michael Davison Current version 0.1
Original Author Michael Davison, Doug Elliffe Date last modified unknown
License BSD MED-PC version 4
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.
No references given. Click to e-mail a reference to the maintainer.
Code
How to use this code Download the code Download an example macro Download the profile
 

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 s uccessively – 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 2 GROUP 0 PROGRAM EXPT2 FILENAME BOX 1 BIRD21.0 LOAD BOX 2 SUBJ 4 EXPT 2 GROUP 0 PROGRAM EXPT2 FILENAME BOX 2 BIRD24.0 LOAD BOX 3 SUBJ 2 EXPT 2 GROUP 0 PROGRAM EXPT2 FILENAME BOX 3 BIRD22.0 LOAD BOX 4 SUBJ 5 EXPT 2 GROUP 0 PROGRAM EXPT2 FILENAME BOX 4 BIRD25.0 LOAD BOX 5 SUBJ 3 EXPT 2 GROUP 0 PROGRAM EXPT2 FILENAME BOX 5 BIRD23.0 LOAD BOX 6 SUBJ 6 EXPT 2 GROUP 0 PROGRAM EXPT2 FILENAME BOX 6 BIRD26.0 EXIT_WHEN_DONE ON START BOXES 1 2 3 4 5 6

(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 2.0 RESOLUTION 10 NUMBOXES 6 TIMERADD 768 LONG_NAME 0 ENDTIME 1 DRIVE C:\birds\data\ 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 783 0 0 1 1 INPUT 1 2 783 0 0 2 1 INPUT 1 3 783 0 0 4 1 INPUT 1 4 783 0 0 8 1 INPUT 2 1 783 0 0 16 1 INPUT 2 2 783 0 0 32 1 INPUT 2 3 783 0 0 64 1 INPUT 2 4 783 0 0 128 1 INPUT 3 1 784 0 0 1 1 INPUT 3 2 784 0 0 2 1 INPUT 3 3 784 0 0 4 1 INPUT 3 4 784 0 0 8 1 INPUT 4 1 784 0 0 16 1 INPUT 4 2 784 0 0 32 1 INPUT 4 3 784 0 0 64 1 INPUT 4 4 784 0 0 128 1 INPUT 5 1 785 0 0 1 1 INPUT 5 2 785 0 0 2 1 INPUT 5 3 785 0 0 4 1 INPUT 5 4 785 0 0 8 1 INPUT 6 1 785 0 0 16 1 INPUT 6 2 785 0 0 32 1 INPUT 6 3 785 0 0 64 1 INPUT 6 4 785 0 0 128 1 MAXOUT 1 8 OUTPUT 1 1 792 1 6 1 1 OUTPUT 1 2 792 1 6 2 1 OUTPUT 1 3 792 1 6 4 1 OUTPUT 1 4 792 1 6 8 1 OUTPUT 1 5 792 1 6 16 1 OUTPUT 1 6 792 1 6 32 1 OUTPUT 1 7 792 1 6 64 1 OUTPUT 1 8 792 1 6 128 1 MAXOUT 2 8 OUTPUT 2 1 792 1 7 1 1 OUTPUT 2 2 792 1 7 2 1 OUTPUT 2 3 792 1 7 4 1 OUTPUT 2 4 792 1 7 8 1 OUTPUT 2 5 792 1 7 16 1 OUTPUT 2 6 792 1 7 32 1 OUTPUT 2 7 792 1 7 64 1 OUTPUT 2 8 792 1 7 128 1 MAXOUT 3 8 OUTPUT 3 1 792 1 8 1 1 OUTPUT 3 2 792 1 8 2 1 OUTPUT 3 3 792 1 8 4 1 OUTPUT 3 4 792 1 8 8 1 OUTPUT 3 5 792 1 8 16 1 OUTPUT 3 6 792 1 8 32 1 OUTPUT 3 7 792 1 8 64 1 OUTPUT 3 8 792 1 8 128 1 MAXOUT 4 8 OUTPUT 4 1 792 1 9 1 1 OUTPUT 4 2 792 1 9 2 1 OUTPUT 4 3 792 1 9 4 1 OUTPUT 4 4 792 1 9 8 1 OUTPUT 4 5 792 1 9 16 1 OUTPUT 4 6 792 1 9 32 1 OUTPUT 4 7 792 1 9 64 1 OUTPUT 4 8 792 1 9 128 1 MAXOUT 5 8 OUTPUT 5 1 792 1 10 1 1 OUTPUT 5 2 792 1 10 2 1 OUTPUT 5 3 792 1 10 4 1 OUTPUT 5 4 792 1 10 8 1 OUTPUT 5 5 792 1 10 16 1 OUTPUT 5 6 792 1 10 32 1 OUTPUT 5 7 792 1 10 64 1 OUTPUT 5 8 792 1 10 128 1 MAXOUT 6 8 OUTPUT 6 1 792 1 11 1 1 OUTPUT 6 2 792 1 11 2 1 OUTPUT 6 3 792 1 11 4 1 OUTPUT 6 4 792 1 11 8 1 OUTPUT 6 5 792 1 11 16 1 OUTPUT 6 6 792 1 11 32 1 OUTPUT 6 7 792 1 11 64 1 OUTPUT 6 8 792 1 11 128 1 INPORT 0 783 0 1 INPORT 0 784 0 1 INPORT 0 785 0 1 OUTPORT 1 792 6 1 OUTPORT 1 792 7 1 OUTPORT 1 792 8 1 OUTPORT 1 792 9 1 OUTPORT 1 792 10 1 OUTPORT 1 792 11 1 TESTPORT 783 -1 1 TESTPORT 0 0 2 TESTPORT 0 0 3 TESTPORT 0 0 4 INPORTMIN 783 INPORTMAX 785 OUTPORTMIN 792 OUTPORTMAX 792 INRACKMIN 1 OUTRACKMIN 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.

Related programs Other versions
No training programs submitted/required

No older versions available
No experimental versions available