The second strong belief underpinning MIDAS philosophy is that somebody must be able to configure and modify conveniently both hardware and software of every automation system. It is most efficient that this person be the experimenter himself (noting the exception of very large systems) provided that he can do so conveniently without having to learn disciplines such as assembly language computer programming or digital electronics, which are most probably unrelated to his specialty.

We do not wish to imply that MIDAS can or should be applied to all situations -- it provides no advantage to very large, very small or very fast experiments. MIDAS was designed to apply to situations requiring moderate capabilities, where less than state-of-the-art performance is acceptable, but where cost, setup time and versatility are of great importance.

In short, MIDAS is meant to be a convenient do-it-yourself automation tool for the experimental scientist. In this respect MIDAS follows in the tradition established by the creators of OMNITAB* that perhaps the best way to help a large number of people with a large need is to make it very easy for them to help themselves.

1.1 Purpose of this Document

First of

This report is intended to accomplish three purposes. all, it serves to provide an intorduction to the overall philosophy and functional characteristics of the MIDAS concept. By reading only Sections 1 through 4, an interested person may learn enough about the salient features of MIDAS and how MIDAS is applied to determine whether or not the MIDAS approach would be preferable to some other digital interface standard, such as CAMAC, in the light of his particular requirements and capabilities. Second, this report serves to document and specify the architecture, organization and electrical and mechanical standards of the MIDAS system, thus placing these standards and design concepts in the public domain. We have intentionally attempted to avoid unnecessary overspecification which would tend to lock the design of MIDAS components to a particular detail design or logic family. Third, the report is intended to provide sufficient detailed information to allow anyone skilled in the techniques of digital logic design to design and construct modules and controllers which will operate in MIDAS systems together with components designed by others. The information necessary to ensure this compatibility is found in the latter half of the document Sections 5 through 9 including the Tables and Appendix.

*NBS Handbook 101, "OMNITAB, A Computer Program for Statistical and
Numerical Analysis", J. Hilsenrath, G. G. Ziegler, C. G. Messina,
P. J. Walsh and R. J. Herbold.

2.

Basic Features and Terminology* of the MIDAS System

(a) MIDAS is a user-oriented digital interface system for
laboratory data acquisition and experiment control,
based on a building-block or "modular" construction.
It is composed of a number of unit functional "modules"
which may be plugged into "slots" in a standard "crate'
which provides power and interconnections between
modules to create more powerful and complex equipment
assemblies. Each module is in itself a complete inde-
pendent functional unit, and when plugged into the
crate is able to communicate bidirectionally with other
modules plugged into the same crate or other intercon-
nected crates. A crate, and a number of such inter-
communicating modules together with a "program source"
for issuing "commands" to the modules and possibly a
"recording device" for recording data and results form
a complete "system".

(b) MIDAS is physically and mechanically based on CAMAC
hardware and dimensions [1]1. MIDAS and CAMAC hard-
ware and crates are physically interchangeable but are
not necessarily electrically compatible, due to dif-
ferences in operating philosophy.

(c) Individual modules make connection to a standard CAMAC
'dataway" through 86-way connectors mounted at the rear
of the crate. The dataway provides common bussing of
digital data, commands, control signals and power to
the modules.

(a) MIDAS is a "programmable" system. A module will become
"active" or perform a function in response to a command
present on the dataway. A logical sequence of commands
forms a "program". All commands and data are trans-
ferred between modules in standard 7-bit parallel
USASCII code format [2]. A module may issue commands
to or receive data from any other module, or any device
external to the system which communicates in USASCII
code.

(e) The rightmost two slots in the crate are unique and are
occupied by the "System Controller". The System

*In the interest of clarity, MIDAS terminology is enclosed in quotation marks when first introduced.

1Figures in brackets indicate the literature references at the end of this paper.

Controller performs in-crate housekeeping functions; decoding system commands and slot "addresses", activating slot positions and generating timing and control signals. In addition, the System Controller serves as an interface between MIDAS modules and external recording devices and program sources, performing serialparallel and parallel-serial conversions where necessary. (f) MIDAS is intended to be used extensively without requirement for an external computer as a "stand-alone" data acquisition and control system. In its simplest configuration, a low-cost teletypewriter ("TTY") serves as both program source and recording device. The TTY keyboard and paper tape reader are used to issue commands to the system, while data is recorded permanently on the teleprinter and paper tape punch. Hence, the Basic System Controller interfaces directly with a 20 ma current-loop TTY operating serially in the full-duplex mode. Similarly, it will interface directly to a CRT terminal, or when computer control is desired, will interface to minicomputers and telephone couplers (timeshared computers) which are TTY-compatible.

(g) There is no inherent limitation to the operating speed of the MIDAS system other than the limitation imposed by backplane transmission characteristics. The modules will operate at the speed of the program source, which may range from 10 characters (commands) per second for the slowest serial teletypewriters up to data rates approaching one megahertz for bit-parallel commands issued by a minicomputer. Recorded data must naturally be transferred at the operating rate of the recording device. It is the function of the System Controller to synchronize transfer of data and commands between the MIDAS modules and an external program source or recording device.

(h) MIDAS is not intended to compete with or supplant CAMAC; rather, it was developed to fill a void existing between NIM and CAMAC not serviced by either concept. for digital data acquisition and control situations of moderate complexity, where cost, flexibility and ease of programming are paramount, and where computer control is only an option. It is intended to be used as a general-purpose laboratory instrument to perform many and varied tasks during its lifetime.

3. Operating Configurations and Upgradability

Although MIDAS has been optimized for self-contained "stand-alone" applications where computer control is not required, the system may be upgraded through a series of easy transitions to more complex closedloop operation under control of a local or remote computer. In most cases the transition involves only plugging in an appropriate cable, and at most, a different module. Several examples of possible operating configuration follow:

3.1 Stand-alone System

Teletypewriter Control

The simplest MIDAS configuration consists of only a crate with necessary modules connected through a Basic System Controller to an unmodified teletypewriter through the standard serial data current-loop connection, with the teletypewriter wired for 20 ma full-duplex operation (fig. 2). This mode of operation employs the teletypewriter keyboard, paper tape reader and answer-back drum for programming the system, and the teletypewriter printer and tape punch are used for recording the data in a format controlled by the program. Operating rate of the system is, of course, limited and determined by the rate of the teletypewriter, generally 10-30 characters (commands) per second. This rate is sufficient for a surprising number of experimental situations, especially those involving appreciable settling times such as are encountered in photometry or calorimetry, or involving very precise measurements which normally require a period of the order of one second to digitize the analog signal.

The program command sequence is punched into paper tape from the keyboard with the teletypewriter in the LOCAL mode. The program tape is then loaded into the tape reader and, if the program is repetitive, may be formed into a continuous loop. Control may be transferred from the main program in the tape reader to a subprogram coded into the answerback drum, or the program may halt and request input from the keyboard, but it is a requirement of this simplest configuration that the program must be sequential.

3.2 Stand-alone System

Programming Module Control with Teletypewriter Output

The second level of sophistication reached by a stand-alone system eliminates the teletypewriter tape reader and answer-back drum as the program source, employing instead a special "Programming Module" to store the program and issue commands to the system (fig. 3). The teletypewriter is now used solely for entering manual commands and recording the output data during an experiment. This greatly eases wear on electromechanical components of the teletypewriter and frees the system from the limitation of running at teletypewriter speeds, except when output is required. The Programming Module is loaded by entering a command sequence from the teletypewriter keyboard or reader. This program is stored in a small memory and may be run by transferring control to the Programming Module by keyboard or tape command. The program stored in the memory of the Programming Module need not be entirely sequential, but may consist of a main program and a number of subprograms which may be accessed by a "jump" command. Some closed-loop operation may be incorporated into the program, such as conditional jumps to subroutines dependent on the state of input lines from the experiment. This form of operation simulates closely a computer-controlled system except for the lack of computational capability.