⟦47b9db676⟧

TextFile

;ali time 10 0 lines.4500
(netart=set 150
lookup netdiablo
if ok.yes
mode 15.yes
if 15.yes
(netartl=set 100
permanent netartl.17
netartd=set 100
permanent netartd.17
netartd=typeset machine.diablo proof.netartl
if ok.yes
c=copy message.no netartl
)
if 15.no
(
netart=typeset
if ok.yes
c=copy message.no netart
)
finis)
*pl 297,12,255,0,0*
*pn 0,0*
*lm0**lw 170* *ld16* *ps15*
*sj*
H. C. Ørsted Institute
Københavns Universitet
Universitetsparken 5
DK-2100 København Ø
Denmark
*qr*
*cd 1*
*rj*
*lm10*
The editor*nl*
Software*nl3**np 20*
Dear Dr. D. W. Barron
*rj*
*nl3**lm0*
*np 10*
Enclosed is a manuscript I would like to have considered for
publication in Software.
*np 10*
*nl6*
*lm100*
Sincerely
*nl4*
Anders Lindgård
*lm 0**ps15*
*rj*
*sj*
Submitted to Software
Version *cd1*
*nl2*
*nl*
*ct*
Hierarchical Multi-Level Computer Network for
---------------------------------------------
Laboratory Automation
---------------------
*ld16*
*0010**nl 1*
Anders Lindgård, Jørgen Oxenbøll and Ejvind Sørensen
H. C. Ørsted Institutet
Københavns Universitet
Universitetsparken 5
DK-2100 København Ø
Denmark
*rj*
*ld16**ns 1,6,Running title: Microcomputer network*
*rh 1,Microcomputer network*
*ns 1,3,Received:*
*ps0*
*ld8**ns 1,3,Abstract*
--------*ld16**np*
The design and implementation of a microcomputer network to support
laboratory automation is described and discussed. It is a multilevel
hierarchical starnetwork connected to a multiprogrammed computer
on which all programdevelopment is done. The system is capable of
supporting a large number of experimental setups. The microcomputers
are either used as 1. local microcomputers for experiment control
2. multiplexers for other microcomputers or 3. controllers for
peripherals known in the multiprogrammed computer.
*np*
The system combines the advan-
tages of a large multiprogrammed computer with those of a small
cheap dedicated computer close to the experiment.*np*
Characteroriented peripherals are connected to the multipro-
grammed computer only. This reduces the amount of system software to be
written for the network by an order of magnitude and eliminates the need for inter-
facing to existing small computer software.
The system software consist of three small programs (monitors)
providing a process concept and multibuffering of
data in the involved computers.
The monitor establishes a hierarchy of control
and they eliminate the need for any local load device for the
microcomputers as their monitors are in a read-only store.
*np*
The system developed is designed for control of experiments in
an environment where the experiments and the control strategies
change with time and where the datarefinement required is beyond
what can be done on the present generation of microcomputers.
*pn 5,0*
*ps 0*
*ld8**ns 1,3,Introduction*
------------*ld16**np*
The background for this project is the increasing need for
computer service to a large number of experiments at the H. C.
Ørsted Institute. Most experiments in physics and chemistry
there, are rather small but also very different in nature, so the
computer facility should be able to support very different needs.
The requirements from the experimentalists may be summarized as
follows:
*nl**lm20*
*mt 1, 1.* need for complex numerical datarefinement.*nl*
*mt 1, 2.*if local storage is provided, only moderate data transfer speed between experiment
and main computational facility is needed.*nl*
*mt 1, 3.* high degree of data security*nl*
*mt 1, 4.* experiments should be able to run for days*nl*
*mt 1, 5.* it must be cheap to add a new experiment to the system*nl*
*mt 1, 6.* short response time on a human time scale between
datacollection and final results*nl*
*mt 1, 7.* support of experiments at fairly large distances.*nl*
*mt 1, 8.* program development and modification must be easy*nl*
*lm0*
*nl2**np*
It is easy for a contemporary microcomputer system to fulfill
part of the experimentalists requirements, and it is easy for
a timeshared computer with an extensive set of peripherals
(lineprinter, magnetic tape units, disc file units, hardware
floating point) to fulfill what the microcomputer cannot do well.
So an obvious solution for us was to design a system where a simple
microcomputer is placed close to each experiment and
connected to a timeshared computer.
*nl**np*
The primary reason for choosing a solution with a many level
hierarchical computer system
was the requirement of being able to support
a cluster of experiments at a fair distance from the multi-
programmed computer.
*nl**np*
The design presented here is based on our experience with some
much less general microcomputer systems developed for the
RC4000 (Lindgård et al., 1977).
*ld8**ns 1,3,Computer systems*
----------------*ld16**nl**np*
Minicomputer systems have for a long time been used extensively
to control laboratory experiments. Often it has been the only
way of performing on-line control and data collection with
complex experiments. If a minicomputer system is used for
programdevelopment, debugging or just minor corrections to
the experiment control program it must have a fairly extensive
and expensive set of peripherals, usually costing much more
than the minicomputer itself. Still in most cases it is a tedious
job to develop programs and the system can by no means be said to
be cheap. It is a disadvantage in institutions with several
computerized experiments that stand-alone systems do not encourage
exchange of experience and programs. Often even the computers
are of several different kinds adding to desorganisation and
double work.*nl2*
Microcomputers are hardwarewise a good replacement for complex
specialized logic especially when local storage is required as
e.g. for multichannelanalyzers, as they are very cheap. They are
however very tedious to program. The short wordlenght, the primitive
instruction set makes debugging of assembly language programs
much more difficult than on most larger computers. This implies
that programsize should be kept small by using microcomputers only
for rather simple task as datacollection.
Some stand-alone systems have BASIC interpreters and some do
even have compilers for higher level languages. Often however
assembly language programming must be used for handling
process peripherals as this cannot be done within the language.
When using interpreters for datacollection it is a common problem that the data rate
is too fast for the slow interpretation of the code and
assembly language must be used.
*nl2*
A multiprogrammed computer with disc, lineprinter, good compilers,
editor etc. is very well suited for programdevelopment and for
controlling experiments which do not have responstime or syncroni-
sation requirements. A number of software techniques (Graae Sørensen and Lindgård, 1973)
are available
to make it possible to honor responsetime requirements on a multi-
programmed computer, but the more severe the responsetime requirements
are, the more inappropriate are constraints felt by other userpro-
grams. Dedicated monoprogrammed computers are much better suited
for handling responsetime requirements performing 'busy wait' until
the critical signal arrives. To make the busy wait situation tole-
rable the hardware must be cheap and here is where the microcom-
puters fit in. A symbiosis of a number of microprocessors with
a multiprogrammed computer retains the advantages of both systems.
*ps0*
*ld8**ns 1,3,Computer networks*
-----------------*ld16**nl**np*
Most computer networks (Kimbleton and Schneider, 1976) consist of
geographically separated individual computers connected through
slow serial lines. The earliest large scale
network is the ARPA net, which gives a possibility for communication
between large and smaller computers throughout USA (Roberts and
Wessler, 1970).*np*
A number of computer networks for experiment control
in physics and chemistry are described in "Computer networking and Chemistry"
(Lykos, 1975) and by Milett (Milett, 1976).
Most systems are hierarchical (Klopfenstein, 1973). At each experiment
there is a dedicated stand-alone minicomputer doing experiment control
only, while an experiment is in progress. The network has no control
over the computer. The computer has only a sparse set of
peripherals, and especially the lack of backing store makes
extensive programdevelopment and modification difficult.
The local minicomputer is connected to a more powerfull computer
through slow serial lines (typically less than 9600 baud). The
software for the different computers is very different and this
inhomogeneous structure reduces the usefulness of the system
considerably.
*nl**np*
*ld8**ns 1,3,Description of the implemented system*
-------------------------------------*ld16**nl**np*
The general layout of the network is shown in figure 1.
Each experiment using this network has a local microcomputer. The
microcomputers are all connected through the network to
a central microcomputer which is
of the same type as the local microcomputers.
A computer may be a multiplexer for up to 15 other
computers on the next lower level of the hierarchy. With
5 levels there is in practice no limit to
the number of computers which may be supported.
The central micro-
computer is connected to and controlled by the RC4000 computer.
A local microcomputer is a simple selfcontained system. It is primarily
used as replacement for multichannel analyzers, but also for complicated
experiments with extensive interaction between computer and experiment.
An example is an experiment for controlling oscillatory chemical reactions
(Graae Sørensen, 1979).
*ps0*
*ld8**ns 1,3,Local microcomputer hardware*
-----------------------------*ld16**nl1**np*
A local microcomputer is placed in a standard
19" chassis and a basic system is build af three
different modules: a central processor, a system input-output, and
a memory. Each module is placed on a seperate printcard
with dimemsions according to DIN (Europa standard card).

*nl**np*
The central processorcard contains a M6800 microprocessor with an
eight input interrupt controller, clock, address
decoding and the necessary buffers to drive the bus.
There are also 8k of PROM memory to store the monitor,
and 2k of RAM memory for the monitor variables and
descriptions.
*nl2*
The system input-output card contains a timer,
which is used as a system clock, and three asyncronous
controllers for communication with the host computer.
The three communication lines are
high-speed (50 kbaud) full duplex serial lines
with current-loop connections.
One is dedicated to commands from the computer higher
in the hierarchy (the master) and one for requests from the other (the
slave) and the third for block transfers between the two computers.
This separation makes the software interface much simpler at a rather
small cost in extra hardware, as modems are not required within the
institute.
*np*
A memory card contains 32 kbyte of RAM constructed
of 16 k dynamic RAM chips, and is equipped with
parity generation and control. In the microcomputer
chassis, there is room for two memory cards,
so that the full memory capacity of the M6800 can be
utilized.
*nl2*
To avoid heating problems (there is no blower installed),
there is only room for 8 slots in the standard chassis.
As the basic system occupies 4 slots, it is
possible to have 4 user defined print cards. Each
card is build with a 96 pole connecter, and the system
bus uses 64 of these. Motorola's standard microcontroller
chips are used for interfacing, and their use are
supported by predefined address decoding by hardware,
and there are monitorfunctons to control interrupt
and datatransmission. To the standard controller chips
are connected user defined functions e.g. analog to
digital converters.
*nl2*
The prototype microcomputer was developed in 1977, and
there is now (feb. 1981) connected 12 local
microcomputers to the system. Only in one of these
cases, the userdefined electronics could not fit
into the standard chassis, so an extension chasssis
was used.
*nl2*
*ld8**ns 1,3,The System Software*
-------------------*ld16**np*
The system software attempts to make the network trans-
parent to the programmer. In the RC4000 computer the local micro-
computer user program is simulated as a process much like another computational
process (internal process) (Brinch Hansen, 1970,1973). In the
local microcomputer the RC4000 is simulated as a process as well,
and we have attempted as far as possible to keep the same conventions
in both ends.*nl**np*
The system provides only a set of tools for control and communication
but it does not enforce any strategy for user programs in the
two computers (Brinch Hansen, 1970).
*nl**np*
When using the system there will at run time exist the following
programs.*nl*
*lm12*
*nl*
*mt 1, 1.* Local microcomputer user program

*nl*
*mt 1, 2.* Local microcomputer monitor simulating the RC4000,
simulating local peripherals and controlling the local user program

*nl*
*mt 1, 3.* A multiplexer program in the central microcomputer
handling up to 8 simultaneus messages between the RC4000
and each local microcomputer

*nl*
*mt 1, 4.* Multiplexer program in the local microcomputers acting
as nodes in the network.

*nl*
*mt 1, 5.* RC4000 processes simulating the local microcomputers
and some system processes

*nl*
*mt 1, 6.* RC4000 user program acting as an operating system for the local microcomputer
user program
*nl**lm0*
*ps0*

*ld8**ns 1,3,RC4000 processes*
----------------*ld16**nl**np*
In the RC4000 computer the network is represented as a set of peripheral
processes as part of the RC4000 monitor (Brinch Hansen, 1970, 1973),
see figure 2.
Closest to the hardware there is a blocktransfer process named "dma", a process
for handling messages to the central microcomputer named "trm" and a process
for handling answers to messages named "rec". Theese processes handles
normally only messages from the process
named "central", exept when debugging the hardware
or the system software for the central microcomputer. In the latter
case they are handled directly from priviledged RC4000 internal processes.
For each local microcomputer there exist a process. For a normal
experiment microcomputer this is the process the RC4000 user program
communicates with. The multiplexer microcomputers can only be accessed
by priviledged processes and this is only used for initialization.
Local peripherals to a local microcomputer may be represented in
the RC4000 as proceses. Only block input/output are accepted
for these processes.
*nl**np*
Messages to the local microcomputers:
*lm20*
*nl2*
*mt 1, 1.* autoload
*nl*
*mt 1, 2.* sense
*nl*
*mt 1, 3.* start user
*nl*
*mt 1, 4.*stop user
*nl*
*mt 1, 5.*input block
*nl*
*mt 1, 6.*output block
*nl**np**lm0*
An autoload message initializes a microcomputer. All pending
messages in the network are released. The user program is put
into the stopped state, but otherwise nothing is done to the user
program.
*nl**np*
The sense message gives a statusword for the userprogram.
*nl**np*
start user program and stop user program will start and stop the
user program respectively. stop user followed by start user
do not change the value of the program counter.
*nl**np*
block input or block output transfers one datablock
of 768 bytes. The transfer may be to absolute addresses in the
local microcomputer or the micrcomputer user program may
supply the addres for the transfer.
*nl**np*
The RC4000 user program may be regarded as an operating system
for the local microcomputer user program. It is normally initiated
from a typewriter terminal placed in the same room as the local
microcomputer, but this is not a requirement. It acts as a loader
for the local microcomputer user program and receives the collected
data which then are stored in a file. It may automatically be re-
started after system breakdown in the RC4000 using the automatic
upstart facilities in one of the operating systems
(Lindgård, 1979).
*ld8**ns 1,3,Local microcomputers*
--------------------*ld16**np*
The primary reasons for introducing the local microcomputers is
that they radically improve data security and that they give a
much better timeresponse to external signals than a multipro-
grammed computer.*nl2*

We have designed the system such that a datacollection may
continue independant of whether the central microcomputer or the
RC4000 are running, which is invaluable as the RC4000 is a machine
used for hardware and software experiments. Interrupt driven data-
collection from the experiment is expected to be the normal way
of working. We do not consider it important to be able to do this
with the highest obtainable speed, as it is not very expensive to
replace interrupt driven datacollection with a DMA-channel.
For continous datacollection a speed with one 8-bit data word
every few milliseconds transferred from the experiment to the
backing store of the RC4000 is our design goal. This
is an improvement of two orders of magnitude for interrupt driven
datacollection using a time sharing swopping operating system in
the multiprogrammed computer.*nl2*
*ld8**ns 1,2,Local monitor*
*ld16*
*nl**np*
The monitor for the Motorola M6800 microcomputer is written in assembly
language and resides in EPROM.
The monitorprogram contain a subset of the monitorprocedures from
the RC4000 monitor.
The monitor is a processmonitor and is divided in four internal and
three external processes at system startup.
An internal process is defined:
Execution of one or more interuptable programs in a given store area. The
internal process is identified by a unique name.
An external process is an input/output program identified by a unique name.
Internal processes can refer to it by name without knowing the address of
the device used.
For each process the monitor maintains a processdescription, which contain the
kind,name and current state.
Two of the internal processes is free for use by the user and the remaining two
are a part of the monitor and performs message interpretation
and exchange of data between RC4000 and the local microcomputer.
The internal processes is scheduled using a very simple strategy:
"Scan array of internal processes and start the first, which is made
ready to run".
An external process is not scheduled in the sense that it is given
a certain amount of runtime; it is purely interruptdriven and
is initialized when an internal process sends a
message to it.
The three external processes that exist at system startup, are used for
exchange of systemmessages and blocktransfers between the RC4000 and
the local microcomputer.
If a user want to use a peripheral he must first create an external process,
which acts as a softwareinterface between the peripheral and the
userprocess. The monitorprocedure "CREATE EXTERNAL PROCESS" creates a
processdescription, enters the name in the monitor's nametable, and connects
the physical device to the processdescription using a devicetable.
In PASCAL notation the physical/logical link would look like:
*sj*
FUNCTION GET_DESCRIPTION(poll_address:integer):integer;

TYPE
tdevice = RECORD
address_physical_device : INTEGER;
address_external_process: INTEGER;
END;

VAR
dev : integer;
devtable : ARRAY(.0..maxdevice.) OF tdevice;
BEGIN
dev:=0;
WHILE devtable(.dev.).address_physical_dev<>poll_address DO
poll_address:=poll_address+next;
GET_DESCRIPTION:=devtable(.dev.).address_external_process;
END;
*nl**np**rj*
The following is a short description of the systemresident processes.*nl**np*
*lm 20*
*mt 1,COMM :*
This is an external process, which handles messages from
RC4000. Its action is to receive six bytes from the central
microcumputer, pack them into a messagebuffer fetched from
messagepool and send the message to the internal process INPR.*nl**np*
*mt 1,REQ :*
An external process, which send answers to the RC4000.*nl**np*
*mt 1,DATA :*
This process handles blocktransfer between RC4000 and the local
microcomputer.*nl**np*
*mt 1,INPR :*
This process decodes the messages received from the COMMprocess
and takes action according to the kind of message. The identi-
fication of the message is compared with the identification of the
microcomputer. If they are equal it is a command to the monitor
and may be one of the controlfunctions such as autoload, start
and stop.*nl**np*
Is the identification different, the message is treated like
a message to a receiver in next lower level and is send
to the USER process.*nl**np*
*mt 1,RCRD :*
This is the process which handles all blocktransfers
from/to the central microcomputer.*nl**np*
*mt 1,USER :*
This process allways start execution in location 0, where
the userprogram should be placed using the loadprogram
in RC4000.*nl**np*
In order to protect the microcomputer form running wild
the monitor places the monitorcall "PASSIVATE" in this location
in case that no program has been loaded and the useer has sent
startmessage.*nl**np*
*mt 1,DUMM :*
This process allways executes a "PASSIVATE", which sets the passive
bit in the process statusword. This however do not restrict the
user to only to use the USERprocess. By mean of the monitorprocedure
"GETADDRESS" the address of the process may be fetched and the local
instruction counter can be replaced by a userdefined value.*nl**np*
Thus the DUMM process can be forced to start execution anywhere in
the avaible memory.*nl**np*
*lm0*
*nl**np*
The communication takes place sending
messages to these processes and waiting for answers
using monitor procedures. From the
RC4000 messages may be send to the user process and they are handled
by the user program calling monitor procedures wait-message, send-answer. Waiting on
any event is taken care of by a wait event procedure. All these
procedures are as close to their RC4000 equivalents (Brinch Hansen,
1970 and 1973) as possible in order to simplify concepts and software. A message
to another process will contain an operation describing the proce-
dure to be used by the called process, some parameters and a
time-out specification. The time-out specification is necessi-
tated as we are forced to regard the process peripherals as highly un-
reliable. The internal clock is used by the called process to keep
track of whether the external signal comes before time out occurs,
and thus provides a check on the peripheral equipment.
Peripheral processes will in general accept messages requesting
a block of data to be input or output, thus freeing the user
program for handling the devices on a primitive level.
*nl2*

*ld8**ns 1,3,The central microcomputer.*
--------------------------*ld16**nl**np*
The hardware for the central microcomputer differs from the local microcomputers by the interface to the RC4000 only. Simple communication between
the RC4000 and the central microcomputer uses two sets of dual 24 bit regis-
ters and interrupts, see figure 1. Block transfers takes place directly between the
stores of the two computers.
The RC4000 can reset, stop and start
the central microcomputer thus having complete control over the microcompu-
ter. The only private peripherals for the central microcomputer are 15
triples of receiver/transmittes used for communication with the
local microcomputers on the next level.
*nl**np*
The multiplexer program is a program which runs in the userprocess
in the central microcomputer. The monitor is the same a for the
local microcomputers except for the handling of dataflow between RC4000
and the multiplexer. See hardware description above.*nl**np*
The multiplexer program handles up to 8 messages to
each local microcomputer from RC4000.
Theese message are used for input of data blocks, output of
datablocks and for control. One is reserved for handling autoload messages, else
the system would be able to deadlock itself.

The term input is used for data to the
RC4000 and output for data from the RC4000. Due to
some restrictions in the RC4000 monitor it has been necessary
to let only the RC4000 user program send messages.
This does not limit the possibilities for interaction
between the user programs in the two computers, but it
does make conversations more elaborate.
The multiplexer program is organized
as a number of processes each describing a local microcomputer and a
central logic handling the incoming messages and answers.
The blocktransfers is handled using a
multibuffer technique to smoothe datatransfers to the RC4000. At
present there are three buffers of 780 bytes - 12 bytes for header
and 768 bytes datasegment - for each microcomputer.
Multibuffering of input is necessary to speed up the transfer of data
to the RC4000 backing store as this has to go through the user
process in the RC4000 and the user process is subject to swopping.
Times between swop out and swop in does only rarely and at very
high loads exceed 30 sec giving a minimal data rate of 75 bytes/sec.
In practice by measuring over several days the
limit is 2000 bytes/sec.*nl**np*
One of the main difficulties in the system is to avoid
that the local microcomputer destroys the communication channels
if the program in the local microcomputer runs wild. Due to
the lack of memoryprotection both the monitorstore
and
the userstore may be overwritten, thus bringing the
microcomputer in an undefined state.*nl**np*
In order to avoid breakdown of the central microcomputer
all transfers are preceeded by a sense operation, which cleans
the channels and tries to get in contact with the local microcomputer
If this fails all messages are rejected and an answer send to
RC4000 indicating the failure. If the sense operation is
performed succesfully the local microcomputer is in a well
defined state or migth be brought in this state using an autoloadmessage.
One of the advantages by using a hierarchical network is that it is
possible for a computer at a higher level to disable the communication
channels and avoid being constantly interrupted
due to programming errors. The channels are only opened when
exchange of information takes place. This is possible as
no transfers are initiated by a process lower in the hierarchy.
*ld8**ns 1,3,Using the system.*
-----------------*ld16**np*
The user of the system is supplied with two model programs,
one ALGOL program for the RC4000 and an assembly language program
for the local microcomputer. From these two programs
the user is expected to develop the specific programs
for the experiment. The model programs handles a
standard task of reading data from a device
and transfering buffers to a
file in the RC4000 system.*nl2*
The local microcomputer model program.*nl2*
This program is organized as a set of coroutines having a single
waiting point (wait event). One coroutine takes care of the data-
collection proper. This part is usually different from applica-
tion to application.
A coroutine receives messages
from the RC4000 and interpretes the content, which may be a stop
datacollection message or a request for transmission of a speci-
fied buffer. As a convention all buffers contain an identification
number, number of words in this buffer and a status word.*nl2*
The ALGOL model program*nl2*
The ALGOL model program handles both datatransfers and control
of the local microcomputer user program.
In the arguments in the call the user specifies 1. the name of the
microcomputer, 2. the file holding the microcomputer assembled pro-
gram 3. the datafile for results and 4. restart condition. The program
checks rather detailed that arguments are sensible e.g. that the
file of the assembled program does contain a program for this type
of local microcomputer, Normally the program then proceeds by reading
the local microcomputer program from the file
into the local microcomputer
and starts it. If the restart condition is true no loading takes
place but the program in the local microcomputer is checked. The
program now has to handle two parallel activities: 1. to transfer
datablocks from the micro and store these in the file specified
and 2. to receive commands from the terminal and interprete and
execute these.
Transfer of datablocks is performed using a multibuffer technique
and the program is prepared to handle retransmission when faulty
blocks occur.
*nl**np*
For maximum safety, the data result file contain the idenfication-
number of the latest block stored. When restarted the program will
request the local program to retransmit all buffers with this
identificationnumber and higher, previously sent.*nl2*
At any time the user may from the terminal issue a command to the
ALGOL program. At present the command may be 'stop'
datacollection or 'where'. 'Where' will give the number of buffers
collected.*nl2*
Data safety.*nl2*
This issue is of primary concern to the users who really do not accept
other failures than those due to their own equipment. For this reason
we have in the software implemented fairly elaborate safety precau-
tions.*nl2*
In the local micro no datapoint is destroyed before the whole available
store is filled up with data. As most of the computers has data storage
enough for a complete experiment the multibuffer strategy will try
to ensure that there during the experiment is both a copy on the RC4000
disc of most of the data and a copy in the local microcomputer.
The RC4000 datafile will the next morning automatically be dumped on to
a magnetic tape.*nl**np*
The restart facility can be used in an automatic upstart of the data-
collection program by one of the operating systems
(Lindgård, 1979). This operating system will as part of the start
up sequence after a system failure start a number of programs.*nl**np*
The program for the central microcomputer is as standard loaded
by the RC4000 monitor during its initialization. This has only the
effect on the local microcomputer that any pending datatransfers are
delayed until a request is issued from the user ALGOL program to
start again.*nl**np*
Noise on the communication lines between the local microcomputer and
the central microcomputer is a problem as faulty transmissions do
occur now and then. Our remedy is to use full duplex transmission and to
have the sender to retransmit a few times.
For severe transmission errors the ALGOL program must determine what to do.
*nl**np*
The local microcomputer is equipped with a clock and this is used
for 'time-out' on all datatransfers. This ensures that
any coroutine or process will not wait for ever in any waiting point
due to hardware errors in the peripherals.*nl2*
*ld8**ns 1,3,Discussion*
----------*ld16**np*
The network approach taken in this work offers several advantages
compared to other networks for laboratory automation
(Lennon, 1975; Ashenhurst, 1975; Arden and Berenbaum, 1975)
The local microcomputers really has the minimal configuration to per-
form the datacollection and control task, as the only peripherals
besides the simple communication channels are the process control
peripherals.
A drawback in our approach is that the multiprogrammed computer
must be running in order to use the terminals, but as this computer
very rarely fails this is of minor importance.*nl2*
In the minicomputer networks where the local minicomputers are stand
alone systems (Ashenhurst, 1975) most of the program development is
done on the local computers using a slow teletype. The program-
ming is usually done in BASIC extended with assembly language coded
procedures for the specific aplication. The larger computer in the
system provide backing store facilities and may offer assembly of
assembly language programs with listing of programs. Usually several
types of computers are connected in the network making the software
inhomogenous with e.g. different editors and compilers on the different levels.
*nl2*
In our approach to computer networks we have eliminated many of the
problems of the traditional laboratory automation networks. Connec-
ting character oriented peripherals to the central computer only,
makes it possible to have only one level of character oriented soft-
ware, which is much easier to maintain than a two level system
with possibly different computer types. In this system the only pro-
gram parts which will differ when a local central processor is replaced
by another completely different type is the short application
program and the local monitor. On the central computer the only
software change is to generate a new table describing the instruction
set to our general table-driven assembler (Bang, 1974).
The hierarchy of strict
control as implemented by the local monitor in non-volatile stores
reduces upstart problems, program loading and it creates a simple
block oriented communication scheme, which is simple to use.*nl2*
The most important disadvantage of the present system is the requirement that
application programs for the local microcomputers has to be written
in assembly language, allthough the local monitor has a very extensive set of
procedures to support the user programs. They are usually very short.
In our next microcomputer project
this will be remedied. We
are currently developing PASCAL compilers.
Theese are
based on the sequential and
concurrent PASCAL compilers developed by Brinch Hansen (Brinch Hansen
1975, 1976).*nl**np*
Another disadvantage with the Motorola 6800 processor presently
used is that there is no way of protecting the monitor datastructures
nor is it possible to prevent a user program from effectively
setting the computer in a state so that
the RC4000 computer cannot autoload it or perform any other
control function, i.e. by setting the stackpointer
to zero. Only a power-up interrupt will then set the coputer
in a welldefined state and restart the monitor.
*nl**np*
Using a network of slavemicrocomputers for control and datacollection
rather than the larger multiprogrammed computer directly has a number
of advantages for a large class of experiments.
Experiments which have simple data input requests in the range
from approximately 1 ms to approximately 1 sec for long periodes of time are hard to
handle in a general way on a multiprogrammed computer (lindgård et al
1976, Lindgård et al, 1977). In this timerange the microcomputer
completely solves the timing problems as we have demonstrated
continous datacollection with 5 msec per point where the data ends
safely on the backing store of the larger computer.
*nl**np*
Another advantage
of the local microcomputers is the ease of introducing new devices
for a specific experiment. On the RC4000 computer the introduction
of a new directly controlled device requires a new table called a processdescription for
each new device introduced.
This is a part of the monitor
which then must be reassembled and reloaded. This is a tedious task
and requires that all user activities are stopped during reload.
In the microcomputers only the application pro-
gram and possibly, but rarely, the local monitor must be changed.
Theese changes requires only a stop for the specific local micro-
computer.*nl**np*
Giving each user a microcomputer has also a social impact in
the computing environment. When we used the multiprogrammed
computer for direct experiment control, any breakdown of
the computer was considered intolerable by the users and
many errors in the users own equipment
were attributed to be computer faults allthough they
were not. There was also much reluctance against
computerizing experiments. With the local microcomputers
area experimentalists changed attitude and
became quite enthusiastic for cumputerizing experiments.
Now they further regards errors in their local microcomputer
in the same relaxed way as other equipment errors. And
if an RC4000 breakdown occurs (which is a rare event)
the number of complaints are indeed low.
*nl**np*
A system like the one described can only
be developed if the number of potential users at a site
is resonably high. It does require, we believe,
that there is a computer department with resources
to develop hardware and software.
*ld8**ns 1,3,Acknowledgement*
---------------*ld16**np*
The enlightning and valuable discussions with Dr. P. Graae Sørensen
and Dr. R. Moss
during the years has had a great impact on the project.
*rj*
*ps0*
*ld8**ns 1,2,References*
----------*nl2*
*ld16*
*sj*

Arden B. W. and Berenbaum A. D. 1975
Proc. 5th symposium Operating System Principles,
Austin, Texas 114-115

Ashenhurst R. L. 1975
Computer Networking and Chemistry,
Ed. P. Lykos, ACS Symposium Series _«bs»1_«bs»9 108-117

Bang J. 1974
Rapport 74/15, Datalogisk Institut,
Københavns Universitet

Brinch Hansen P. 1970
Comm. ACM _«bs»1_«bs»3 238-250

Brinch Hansen P. 1973
Operating System Principles
Prentice Hall, Englewood Cliffs, New Jersey

Brinch Hansen P. 1975
IEEE Trans. Soft. Eng. SE-_«bs»1 199-215

Brinch Hansen P. 1976
Software Pract. & Exper. _«bs»6 141-206

Graae Sørensen P. and Lindgård A. 1973
Computers in Chemical Research and Education
Ed. D. Hadzi, Elsevier, Amsterdam 5/39-58

Graae Sørensen P. 1979
Ann. New York Acad. Sci. _«bs»3_«bs»1_«bs»6 667

Kimbleton S. R. and Schneider G. M. 1975
Comput. Surv. _«bs»7 129-173

Klopfenstein C.E., Heap A. R., Koskinen J.,
and Spencer R. B. 1973
Computers in Chemical Research and Education,
Ed. D. Hadzi, Elsevier, Amsterdam 1/171-188

Lennon W. J. 1975
Computer Networking and Chemistry
Ed. P. Lykos ACS Symposium Series _«bs»1_«bs»9 67-84

Lindgård A., Moss R. and Oxenbøll J. 1976
Comp. & Chem. _«bs»1 7-11

Lindgård A., Graae Sørensen P. and Oxenbøll J. 1977
J. Phys. E Scientific Instrumentation _«bs»1_«bs»0 264-270

Lindgård A. 1979
Software Pract. & Exper. _«bs»9 xxx

Lykos P. 1975
Computer Networking and Chemistry
ACS Symposium Series _«bs»1_«bs»9

Millet E. J. 1976
J. Phys. E _«bs»9 794-802

Roberts L. G. and Wessler B. D. 1970
Proc. AFIPS _«bs»3_«bs»6 543-549
*ps0*
Figure Captions.
*nl2*
*ct*Figure 1.*rj**nl2**np*
Sketch of the M6800 laboratory automation network. All terminals
are primarily connected to the RC4000 computer, which is the
master of the network. A central M6800 microcomputer
communicates with the RC4000 through two sets of 24-bit
registers and an RC4000 controlled DMA-channel. Up to 15
microcomputers may be connected and they may be either
multiplexers (MUX) or experiment controllers (local) or
device controllers (not shown).
*nl2**ct*Figure 2.*rj**nl2**np*
Process layout in the RC4000. The figure shows the processes
for the network and the communication paths between theese.
Closest to the hardware is a process controlling the DMA-channel
"dma", a process for sending messages to the central "trm" and
a process for receiveing messages from the central "rec". Messages
are exchanged through the communication registers. The rest of
the process network mirrors the physical computer network.
"per1" and "per2" are local M6800 peripherals known in the RC4000
and physically connected to "mux2".
*nl2**ct*Figure 3.*rj**nl2**np*
Sketch of the local microcomputer hardware. The process controller may
be a number of serial transmitters/receivers, parallel input/output
units, programmable timers, DMA controllers etc.
*nl2**ct*Figure 4.**rj**nl2**np*
Sketch of the hardware and software elements involved in the communication
between an RC4000 user program and an M6800 user program.
*ef*
▶EOF◀

DataMuseum.dk

RC4000/8000/9000

⟦47b9db676⟧ TextFile

Derivation

TextFile