 |
Description  |
|
|
TECHNICAL FIELD
The present invention relates to automated material handling systems, and
more particularly to a control system for controlling the operation of a
storage/retrieval machine in such a material handling system.
BACKGROUND OF THE INVENTION
Automated material handling systems provide for the automatic stacking and
retrieving of material units to and from loading stations and storage bins
in a material storage environment. The automated system generally employs
a stacker vehicle or storage/retrieval (S/R) machine which shuttles loads
between specified locations in accordance with a control command input to
the system by an operator.
Each station or bin in the material handling system which the stacker
vehicle accesses is assigned an address in terms of its location with
respect to an aisle, bay, level, side or similar physical division of the
storage environment. An operator may accomplish a specific material
handling task by entering a command to the system informing it of the type
of task that is requested, e.g. loading a material unit on the stacker
vehicle at a loading station and stacking it in a prescribed bin, and
providing relevant addresses of station or bins involved in the operation.
The automation of the material handling system is accomplished through a
control unit which receives and interprets operator commands and processes
them into output signals that drive the stacker vehicle through the
appropriate steps necessary to accomplish the requested task. The stacker
vehicle control system requires logic capability that may either be in the
form of a hard-wired, special purpose logic unit or a general purpose,
programmable logic unit.
The use of a hard-wired, special purpose logic unit incurs a certain amount
of inflexibility in its application. More specifically, each such unit has
to be designed to meet or accommodate the particular operating parameters
of the storage environment in which it is employed. A change in either the
physical requirements of the material handling system or the type and
quantity of operator commands will necessitate a redesign of the special
purpose logic. The patent to Burch et al, U.S. Pat. No. 3,536,209, teaches
a special purpose logic unit of this sort, but, as noted, this form of
control unit is not well adapted to modifications for use in systems of
varying parameters.
The advent of the microprocessor has made a programmable, general purpose
logic unit the better choice for control system design where adaptability
to material handling environments of different operating parameters is a
consideration. The performance of the stacker vehicle control unit is
embodied in a control program; when changes are required to be made to the
control logic, they may be accomplished through modification of the
control program.
However, the use of a programmable, general purpose logic unit as an
element in a stacker vehicle control system is not without drawback. One
disadvantage is in the logistics of modifying the control program to adapt
to a new system environment. The basic control program is most often
written in a low level programming language, usually assembly language, by
a skilled programmer in order to generate the most efficient program code.
On the other hand, the person who is most familiar with the operating
parameters of a particular storage environment that necessitate
modifications to the basic control program is a systems engineer or
technician, who is not necessarily skilled as a programmer, at least not
at a lower language level.
One approach to a solution of this problem would be to define a high-level
user language and write a compiler to translate the user language code
into machine language form. However, accompanying this approach would be
the disadvantages of increased memory requirements and the need for an
operating system to implement the compiler. If the control system is to be
implemented with a microprocessor as the control logic unit, then these
specified disadvantages make this approach impracticable.
A second, alternative approach is to employ a general purpose emulator with
the microprocessor to allow the user to program in a high level,
user-oriented language. However, a general-purpose emulator has two
specific limitations. First, the user is programming in a general purpose
language that is not addressed to his specific practical needs, but rather
covers a generic class of programming needs. This impairs program
efficiency. Secondly, a general-purpose emulator requires a substantial
memory allocation, and the user may not be able to afford to dedicate the
amount of memory that the general-purpose emulator would require.
A third alternative is to program entirely in assembly language. The
manifest difficulty of interactive machine control programming at an
assembly level language makes this alternative impracticable. Moreover, an
assembly language control program is not given to easy modification to
adapt to varying operating parameters, e.g. a change in a functional
feature of the control program would require extensive rewriting. As such,
it provides a relatively inflexible approach in the context of the present
invention.
Accordingly, the problem addressed by the present invention relates to the
need to afford flexibility in the modification of the control program for
the programmable, general purpose logic unit when adapting it to a storage
environment of different operating parameters, so that it may preserve
efficiencies realized through lower level programming, and yet be readily
modified by system personnel not having extensive knowledge and ability in
a lower level programming language.
DISCLOSURE OF THE INVENTION
The present invention is a control system for controlling the operation of
a storage/retrieval machine in a material handling system. The control
system incorporates a programmable, general purpose logic unit which is
readily adapted to program modification to accommodate changes in
operating parameters of material handling system environments.
Broadly, the invention contemplates the general purpose logic unit of the
control system to operate under the control of a stored program. Execution
of the program will cause the logic unit to receive and interpret commands
from the system operator, process those commands through the
general-purpose logic unit, and output signals that drive the stacker
vehicle through the steps necessary to perform the commanded task.
An important feature of the present invention is in the use of a novel
programming and storage technique that affords flexibility in allowing
each user to modify the control program as needed to meet his specific
requirements. More precisely, the control program is logically divided
into two constituent parts, each of which is stored in a separate block of
memory. The first part may be regarded as a host control program that is
encoded in an efficient, low level programming language. The second part
may be regarded as a number of independently programmable application
routines that are encoded in a higher level programming language that can
be emulated by the lower level programming language of the host program.
In operation, the host program oversees certain basic responsibilities
such as receiving commands, checking them for validity and interpreting
them to determine what application routines are necessary for their
execution, and then calling the application routines of the second memory
block in appropriate order to carry out the commanded task.
By organizing the program in this manner, the host program can be written
once in the efficient, lower level language and left unchanged thereafter.
The application routines can be written to meet the requirements of a
specific material handling system in a convenient higher level programming
language and then emulated through the lower level programming language;
the emulatable relationship between the higher level and lower level
programming languages makes this possible. Thus the control program enjoys
greater flexibility, allowing a skilled programmer to make a one-time
encoding of the host program in an efficient, lower level language, and
allowing a system engineer or technician, who is more familiar with the
specific operating parameters of the material handling system environment,
to encode application routines in a higher level programming language that
is more easily understood by him, and which may be emulated by the lower
level programming language.
Moreover, this provides the additional practical benefit of allowing the
host program to be stored in a first, modular programmable
read-only-memory (PROM) chip and the application programs to be stored in
a second, modular PROM chip. In this manner, the application programs may
be modified for each different storage environment without affecting the
storage medium of the host program. This option facilitates the
adaptability of the control system to different storage environments.
A further feature of the invention is the inclusion of a diagnostic "trace
mode" routine in the host control program. The trace mode routine permits
an operator to identify problems in user program logic or locate
malfunctions in the control hardware. By use of the trace mode routine an
operator can trace through an execution of a user application program one
step at a time to provide a diagnosis of the execution of each user level
instruction. The execution status of each user level instruction is
displayed to the operator as well as the address of the next instruction
in line for execution. Where the user application program is comprised of
a plurality of independently programmed routines the trace mode feature
may be simultaneously applied to one or more of the routines.
The trace mode routine is particularly valuable for diagnostic purposes as
control over execution of the user application program generally resides
in the host control program, which causes the execution of the emulated
user application program to be normally transparent to the operator.
However, by including in the host control program the trace mode routine,
a diagnosis of the user application program can be made at the instruction
level, and at the routine level when the user program comprises a
plurality of routines.
A fuller appreciation of the present invention can be obtained by a reading
of the following detailed description which is to be considered in
conjunction with the drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an environmental view of an automated material handling system
illustrating an S/R machine of the type for which the control system of
the present invention is adapted;
FIG. 2 is a schematic overview of the S/R machine control system of the
present invention;
FIG. 3 is a generalized, block diagram representation of the on-board
processing logic illustrated in FIG. 2;
FIG. 3A is a more specific block diagram representation of the
read-only-memory portion of the processing logic of FIG. 3;
FIG. 4 is a schematic representation of the internal organization of the
control program logic that is used in association with the logic hardware
of FIG. 3;
FIG. 5 is a flowchart of the control program logic illustrating the manner
in which a user control program is emulated;
FIGS. 6A-D are flowcharts illustrating the specific tasks of operand
accessing and formatting in the emulation of a user program instruction;
FIG. 7A is an organizational chart illustrating how basic cycles or
routines in user instruction code may be selectively assembled to develop
specific programs that control an S/R machine through certain functional
operations, and
FIGS. 7B-CC are flowchart representations of each of the basic cycles or
routines appearing in the organizational chart of FIG. 7A.
BEST MODE FOR CARRYING OUT THE INVENTION
Introduction:
The invention to be hereinafter discussed relates to a control system for
an S/R machine in a material storage environment. An S/R machine,
sometimes referred to as a stacker vehicle, performs certain basic
material handling tasks, including the stacking, transporting and
retrieving of material units among material storage bins and loading
stations. The S/R machine control system of the present invention
incorporates a programmable logic unit that is programmable at two levels
to afford maximum user flexibility. The control system user can program
the control logic in a high level language that is related to specific
material handling operations, and which can be emulated by a host or
executive control program that is encoded in a lower level language to
achieve maximum program efficiency.
The detailed description of the S/R machine control system of the present
invention begins with a background discussion of a material storage
environment. The discussion then advances to an overview of the S/R
machine control system, and from there develops into a description of the
specific control logic hardware and software. As part of the discussion of
the control logic software, a procedural execution of a representative S/R
machine command is presented.
The Material Storage Environment:
FIG. 1 broadly illustrates a part of an automated material handling
environment pertinent to an understanding of the present invention. A
storage rack 10 is one of an ordered array of a number of identical
storage racks defining a bay along an aisle or similar physical
subdivision of a storage environment. Each rack is divided along its
vertical dimension into a plurality of bins 12. A bin 12 generally
represents the fundamental storage unit. Each bin is addressable in terms
of its level, bay, aisle, etc.
An S/R machine 14 is shown adjacent the storage rack 10 preparatory to
servicing a bin 12. The S/R machine 14 travels down an aisle defined by a
track 18. It comprises a rectangular frame structure having a vertical
dimension coextensive with the height of the storage rack 10. Material
units are loaded on a carriage 20 which travels along a vertical track 22
to service each of the bins 12 in the rack 10. The carriage 20 includes a
pair of shuttles 24 that extend laterally into the bin to stack and
retrieve material loads. The S/R machine 14, carriage 20 and shuttles 24
each have an associated motor drive generally illustrated by 26. The motor
drives 26 are under the control of an onboard contol unit 28 that is
responsive to operator commands, whether received locally or by remote
communication, to control the operation of the drive motors. The S/R
machine 14 is provided with a plurality of position sensors (not shows
herein in detail) that communicate information to the control unit 28 on
the relative position of the S/R machine 14, carriage 20 and shuttles 24.
Appendix A (pages A-1 through A-4) attached hereto is a listing of the
input and output signals to the control unit 28, including transducer
signals. Reference will hereinafter be made to signals appearing in
Appendix A as appropriate to describing the present invention.
Overview of the S/R Machine Control System:
FIG. 2 is a schematic representation of the control system of the present
invention in conjunction with an S/R machine 14. A remote communication
system 30 includes a display 34, preferably a CRT display, and a remote
keyboard 32 through which an operator may enter S/R machine commands. The
remote keyboard 32 is coupled to a first MODEM 36. The MODEM 36 transmits
information in serial-bit flow through line 38 to a communication bar 40.
The communication bar is laid along the aisle over which the S/R machine
travels. A transducer 42 mounted on the underside of the S/R machine 14 is
responsive to signals on the communication bar 40. Signals detected by the
transducer 42 are received by a second MODEM 44 for demodulation. The
remote commands are then communicated to the on-board processing logic 46,
which will hereinafter be described in greater detail.
Alternatively, the operator may communicate to the on-board processing
logic 46 through a local input device, such as a keyboard 48. A local
input device is most advantageous when troubleshooting S/R machine
malfunctions and for certain manually controlled operations.
The on-board processing logic 46 is coupled to a motor control unit 52. The
signals that appear on output lines 50a, b and c will respectively control
the operation of the vertical, longitudinal and lateral servo motors
associated with the S/R machine.
FIG. 3 more specifically illustrates the architecture of the on-board
processing logic 46. The architecture includes a central processing unit
54, which in the preferred embodiment is a microprocessor, specifically
Digital Equipment Corporation, Model PDP 11/03, LSI 11. The central
processing unit 54 has associated with it memory capability comprising a
programmable read-only memory (PROM) 56 and a read-write memory (RAM) 58.
FIG. 3A shows a more specific representation of the PROM 56 in the form of
two PROM chips 56a and b. The first PROM chip 56a stores a host control
program and the second PROM chip 56b stores a user application program.
The advantage of using separate PROM chips will become apparent in the
subsequent discussion of the host control and user application programs.
Operator input instructions, whether transmitted remotely or locally, are
received in serial-bit flow on line 62 by a universal asynchronous
receiver transmitter (UART) 60. The UART 60 is a specially designed LSI
circuit which performs serial-to-parallel data conversion and
transmission.
Signals from transducers mounted on the S/R machine are inputted through
lines 66 to a signal interface 64. The signal interface is under the
control of the central processing unit 54 and may be accessed as a port
whenever transducer signal information is required for the execution of a
program instruction. The plurality of transducer signals may be organized
into bytes that are selectively accessible to the central processor unit
54 through a multiplexer in the interface 64.
A peripheral interface adaptor (PIA) 68 provides output signals on lines 70
to the motor controls. The motor control signals may similarly be
organized into bytes that are selectively communicated to and from the
central processing unit 54.
Each of the components peripheral to the central processing unit 54 is
connected thereto through the CPU bus structure. More specifically, the
bus structure includes an address bus 76 nominally 16 bits; a data bus 74,
nominally 8 bits; and a control bus 72, nominally on the order of 10 or
more bits. The processing logic hardware is constructed in accordance with
the description in Microcomputer Handbook, 2d. Ed., Digital Equipment
Corporation, Maynard, Mass., 1977.
Organization of the Control Software:
FIG. 4 is a schematic representation of the internal organization of the
control software. As a preface to a detailed explanation of the control
software, an overview of the programming technique that is used in the
present invention will first be given.
The control software is written or coded at two levels; a lower, assembly
language level for executive program functions, and a higher, user level
for application program functions. It is contemplated that the lower level
programming will be done by a skilled programmer who is conversant in the
assembly language instruction set that accompanies the general purpose,
programmable unit used in the logic hardware. Moreover, it is contemplated
that the application programs will be written in a user language by a
systems engineer or technician who is familiar with the specific operating
parameters in the environment in which the S/R machine will operate. The
nexus between the high level, user language and the low level, assembly
language is in the capability of the low level language to emulate the
high level language. In this manner, the systems engineer can write
specific user programs in a language oriented to material handling
systems, and have those programs correctly emulated by a host or executive
program that is efficiently written in assembly language.
With reference to FIG. 4, the control software defines a number of
functional registers that are used for the intermittent storage of data
under program control. A pair of buffer registers 82 and 84 receive local
and remote operator commands, respectively. In the preferred form of the
invention, the commands are communicated by the operator via a keyboard in
ASCII code. The buffer registers 82 and 84 are coupled to a decoder 85.
The function of the decoder is to receive the ASCII-coded commands and
translate them into the code scheme associated with the assembly language
of the logic hardware.
Decoded operator commands are communicated from the decoder to a serial
array of command registers, including a work register 86, check register
88, buffer register 90 and execution register 92. Operator commands are
advanced through the serial array as they move toward execution. Before
giving an individual description of each register and its function, it is
beneficial to first identify the permissible operator commands and
describe their intended operation.
There are seven basic operator commands which are briefly described as
follows:
DEPOSIT: The DEPOSIT command causes the S/R machine to pick up a material
load at a loading station, transport it to a bin address and stack it
therein.
WITHDRAW: The WITHDRAW command causes the S/R machine to retrieve a
material load from a bin station, transport it to a loading station and
put it thereon.
GET: The GET command causes the S/R machine to go to a bin address and
retrieve a material load. The GET command is a half command in the sense
that no final destination is associated with it.
PUT: The PUT command causes the S/R machine to take a material load already
on the machine to a bin address and stack it therein. The PUT command is
similarly a half command in the sense that it defines no origin. The PUT
command may be used in conjunction with the GET command to accomplish
bin-to-bin material loading.
TRAVEL: The TRAVEL command causes the S/R machine to travel down the aisle
to a specific aisle position without regard to a stacking or retrieval
operation.
READDRESS: The READDRESS command causes the S/R machine to initiate
recovery from a programmably-recoverable error.
PURGE: The PURGE command causes a purging of the operator command currently
under execution and resets all program registers. The PURGE command will
stop motion of the S/R machine.
There are a number of ancillary commands which do not affect the operation
of the S/R machine, but merely provide the operator with information on
the status of the S/R machine. These commands will be discussed in
conjunction with the registers with which they are associated.
A work register 86 is a dedicated register where stacker commands and
addresses are retained while awaiting processing by the emulated (or
user-level) language. The work register 86 receives decoded commands
directly from the decoder 85.
In general, the command registers 88, 90, 92, 94, 96 and 98 are dedicated
registers under the control of the user program.
The check register 88 receives commands from the work register and holds
them for validation before execution. The check register is in the nature
of a buffer register which holds commands while awaiting authorization
from the operator for the command to be executed.
The buffer register 90 holds the validated commands that are awaiting
execution.
The execution register 92 holds the command currently under execution.
Each command is broken down into seven separate fields, each of which may
be independently accessed by the control program logic. There are seven
distinct fields, each of which is described as follows: STATUS: The status
of a command in a register is a single character, selected from a fixed
set of STATUS characters. COMMAND NUMBER: The machine commands are
internal number assignments to represent the specific type of command. For
example the DEPOSIT command is assigned 0, WITHDRAW 10, GET 20, PUT 30,
etc. STATION NUMBER: The station number field is a data identification of
the station involved in the command. AISLE NUMBER: The aisle number field
identifies the aisle in which the S/R machine operates. BAY: The bay field
is the identification of the bay involved in the command. LEVEL: The level
field is the data identification of the level in the bay involved in the
command. SHUTTLE STROKE: The shuttle stroke field identifies the specific
action which needs to be taken by the carriage shuttle to stack or
retrieve a material load. More specifically, the carriage may be divided
in two halves, each of which is serviced by a shuttle. The material load
on the carriage may be a single unit on either of the halves, or may be a
double unit on both of the halves. There are numerous permutations
involving one or both of the shuttles in a stacking or retrieving
operation. The exact shuttle operation required is specified by this
field.
A destination register 94 stores a current destination address of the S/R
machine. This is defined in terms of aisle, bay and level or station
depending upon whether the destination is a bin or station, respectively.
A completion register 96 stores the last command completed. This is
provided to allow program logic to look back one command and facilitates
communication of completed commands to the operator.
A location register 98 stores the current location of the S/R machine in
terms of its relative position with respect to aisle, bay and level.
Information stored in the location register is derived from position
sensors associated with the S/R machine.
A group of eight temporary registers 100 is provided for scratch pad
operations and used by the program logic to manipulate commands. A digital
input buffer register 102 contains an input byte which contains input
signal information. The input information is organized into bytes, and the
data byte contained in register 102 is selected from this organization of
bytes.
A digital output buffer register 104 contains an output byte. The output
information is similarly organized into bytes, and the output byte
contained in register 104 is selected from this organization of bytes.
A short status register 106 contains a string of characters representing
machine and control status. In response to an operator poll command (PP)
for information on the status of commands under execution or in the
command registers, this information is provided to the operator. The short
status register is divided into seven fields, each of which is briefly
described as follows: The first field contains information on the command
presently under execution, e.g. a DEPOSIT command. The second field
identifies the command in the buffer register awaiting execution. The
third field identifies the status of the command most recently sent by the
operator. The fourth field identifies the status of the machine by
indicating either normal operation or an error condition. The fifth field
indicates the mode of control, whether local or remote or otherwise. The
sixth field indicates the current physical contents of the carriage. The
seventh field indicates the mechanical state of the S/R machine.
A long status register 108 contains a string of characters representing a
more comprehensive description of the S/R machine status and command under
execution. A report response command (RR) will provide the operator with
this information. The long status register 108 contains twelve fields,
each of which is briefly described as follows. The first and second fields
identify the size of the loads on the carriage. The third, fourth and
fifth fields identify the load state of the carriage; particularly whether
it is carrying a single unit material load, double unit material load, or
variations thereof. The sixth field indicates the type of load seen in a
bin on a bin full error. The seventh field represents the mode of control,
whether local, remote, or otherwise. The eighth field contains information
relating to the mechanical condition of the S/R machine, indicating
whether it is in a normal or malfunction condition. The ninth, tenth and
eleventh fields respectively relate to the machine, carriage and shuttles.
More specifically, the fields indicate whether or not the associated servo
motors have nulled out or are driving. The twelfth field indicates whether
there is any external condition inhibiting the travel of the machine.
A transmit buffer 110, decoder 112 and transmitter 114 function in
cooperation with one another for the transmission of information from the
registers to devices external of the control logic environment.
All of the aforementioned registers may be created in a dedicated portion
of the RAM memory unit 58 of FIG. 3.
The balance of the software organization is broken down into functional
blocks of program instructions, except for certain other registers that
are closely associated with one or more blocks of program instructions.
Block 115 represents a distinct block of PROM memory where the user program
resides. The user program is written in a high level code and is
specifically directed to controlling the S/R machine.
Block 116 is a segment of program instructions in another block of PROM
containing the host or executive program. This block controls execution of
the various cycles or routines which make up a user program, i.e. it
effectively implements multitasking between user cycles. It controls the
sequence in which cycles are to be executed and then allocates emulator
execution time between cycles.
This block of instructions 116 is responsible for implementation of a
diagnostic feature of the emulator referred to as "trace mode," which will
be discussed in further detail in relation to FIG. 5. In short, trace mode
is a feature that may be selected by an operator through a keyboard
command or other input communication. By selecting trace mode, a flag is
set which permits the cycle to execute only a single user program
instruction, and display the results of that instruction execution along
with the address of the next instruction awaiting execution. The operator
may then step through the user program an instruction at a time by
successive keyboard commands; or, alternatively, may advance to the next
cycle or routine scheduled for execution. The trace mode option is
therefore provided to allow an operator to "trace" through the execution
of a user program to uncover errors in program logic or system hardware.
The next two blocks of instructions 117 and 118 are ancillary instructions
used to meet certain timing constraints related to hardware speed and
software processing time. They are briefly described as follows.
Block 117 is a segment of instructions in the host program which enables
the operator to specify a certain group of input signals, e.g. the
longitudinal or vertical address sensors, as high speed inputs requiring a
scanning rate greater than can be obtained by a user written cycle. The
speed requirement is derived from the speed of the S/R machine and the
size of the address sensor used. In practice, a scan control table is
defined in memory and the operator inserts an entry in the table for each
high speed input that is to be scanned. The scan control instruction block
117 will then automatically scan the specified inputs every clock tick
(i.e. sixty times per second based on line voltage) and save the data in
the defined strobe as one. The user tests for the presence of a one, and
then accesses the collected data by entry number in the scan control table
through user instruction commands.
Block 118 is a segment of program instructions in the host program which
has a function similar to that of block 117. In this case, however, the
concern is with the inability of the user cycles to process high speed
pulses derived from rotary shaft encoders on the S/R machine. The pulse
counter control instruction block 118 allows an operator to represent the
output of each rotary shaft encoder as an entry in a pulse counter table.
The pulse counter control instructions will then automatically process
encoder pulses by counting them and updating corresponding entries in the
pulse counter table. The user can then test and reset these table entries
by accessing the table through user language instructions.
Block 119 is a segment of program instructions in the host or executive
program, and has the function of accessing operands as a first step in the
process of emulating instructions encoded in the user language. The
program instruction segment represented by block 119 will hereinafter be
made more purposeful when taken in consideration with the following
description of FIGS. 5 and 6A-D.
Block 120 represents another segment of program instructions in the host or
executive program and has for its function the accessing and execution of
instructions in the user program segment represented by block 115. A
program counter 122 is associated with program segment 120 to facilitate
access to instructions in the user program.
Block 124 represents a segment of host or executive program instructions
that effect arithmetic and logical operations necessary for the emulation
of user program instructions.
Registers 126a, b, c and d are used for the accessing and formatting of
operands in the emulation of a user program instruction.
Block 128 stores information on the status of user routines or cycles that
form discrete parts of the user program. Information relating to the
program count and execution status of a cycle is stored in the RAM memory
block represented by block 128.
The Emulation Process:
FIG. 5 is a flowchart of the host control program which performs the
emulation of the user program. The user program is written in a user
language at a level above the host program. Appendix B (pages B-1 through
B-3) is a listing of the user language instruction set. The user language
instruction set comprises an extensive group of instructions that may be
used to construct user application programs in a domain specific language.
Appendix C (pages C-1 through C-18) is a description of each instruction
along with the operands associated with the instruction.
The user application programs are made up out of modular routines having a
hierarchal relationship to one another. FIG. 7A illustrates the user
program in terms of its organization in modular routines or cycles. An
inspection of FIG. 7A reveals that the basic operator commands, including
DEPOSIT, WITHDRAW, GET, PUT, TRAVEL and READDRESS are all executed through
a hierarchy of modular subroutines.
FIGS. 7B-CC are flowcharts of the user routines shown in FIG. 7A. Each of
the flowchart blocks contains an operation or decision paraphrasing the
user language instructions set forth in Appendices A and D. The following
is a brief description of each of the user cycles or routines of FIG. 7.
Cycle 0 as illustrated in FIGS. 7B-7E is a control cycle that controls
communication to and from the control system and validates the processing
of commands. The execution of Cycle 0 is a prerequisite to the execution
of all other cycles.
Its major responsibility is to check inputs from the keyboard and remote
position for their acceptability, and to respond back accordingly with
printed messages on the operator's screen or by sending messages over the
communications link back to the remote station. Cycle 0 also carries out a
number of minor functions which do not relate directly to operator input.
The following brief discussion of some minor functions is with reference
to the subcycle designation given in the drawings.
EB0A4. (FIG. 7B-1) The first task of Cycle 0 is to maintain a permissive
run pulse. This is a 1/2 second pulse which keeps a timing relay
energized. If execution of the host or user program halts due to program
or processor failure, the permissive run pulse will not be maintained
after 11/2 seconds. This will cause the timing relay to de-energize and
drop out all motor control circuits to bring the S/R machine to a safe
halt condition.
EB0A2. (FIG. 7B-1) This sub-cycle relates to a poll command which is issued
by the remote station when the S/R machine is under remote control. The
remote station successively polls (PP command) each S/R machine to
determine its operating condition. The response from the machine is a
Short Status report. When a poll command is received in the work register
the following activities take place: a 1/2 second timer is set to indicate
a poll command has been received; the Short Status report is sent over the
communications link; the work register is cleared of its poll command
(i.e., set to idle); and the cycle exits.
If the received command is not a poll command, it is then checked to see if
it is a Report Request (RR) command. A Report Request command is issued
only by a remote station. If in fact it is a Report Request command, the
following activities take place: the contents of the buffer, execution,
location, destination and long status registers are sequentially sent over
the communications links to the remote station; the work register is set
to idle; and the cycle exits.
EB-E. (FIG. 7B3) This sub-cycle performs a test to see if a next command is
a GO command. The GO command is sent over the communications link after a
DEPOSIT, WITHDRAW, PUT, GET, READDRESS, TRAVEL or PURGE command has passed
echo checking. If a GO command is received, it enables the S/R machine to
execute the command that is presently in the check register. The long
status register is set to Travel Allowed in the appropriate field
position, an Accepted message is displayed to the operator, and the cycle
exits.
EB0J. (FIG. 7G-2) This sub-cycle tests to see if the command presently in
the work register is a PURGE command. If so, the command is accepted and
the cycle exits.
EB0L. (FIG. 7-D1) This sub-cycle tests to see if the command presently in
the work register is a load move command. If so, it is tested for legality
by placing it into Temporary Register 7 and checking to see if it calls
for a legal station address. If illegal, the error flags in Temporary
Register 7 are set to 200 to signify an error in the station address. If
the station address is legal as a load or unload station, the station
address is decoded into a bay, level or shuttle stroke and the appropriate
tables of Temporary Register 7 are set accordingly.
The bin address is put into Temporary Register 10 and checked against a
table to determine if it represents an actual bin. If a match is made,
i.e. if the bin address is legal, the appropriate field in Temporary
Register 10 are set. A check is then made to insure that the shuttle
stroke for this station is legal. If illegal, a flat is set for later
reference. If no match is made when the bin address is checked against the
table of addresses, a cycle error flag in Temporary Register 10 is set to
indicate the same.
EB0O. (FIG. 7D-2) The function of this sub-cycle is to check to see if the
command presently in the work register is a READDRESS command and if the
execution register requires such a command. If not, the command is
rejected and the cycle exits.
EB0O1. (FIG. 7D-2) The function of this sub-cycle is to perform a series of
checks to see if a READDRESS command, if required, is legal. The READDRESS
command must not call for an aisle change. An aisle change will cause
check register status to be set to Forbidden Address status and an Illegal
Aisle Change address will be displayed to the operator. If the READDRESS
command is to remedy a station error and recites a legal address, the
command will be accepted and the cycle will await a GO command. On a size,
bin or carriage contents error, checks are made to insure that the
READRESS command contains the proper load/unload or bin address
destination to fit the load.
EBOV1. (FIG. 7E-2) The functions of this sub-cycle is to test for the
legality of a TRAVEL command. If a TRAVEL command is in the work register,
checks are made for the validity of bin address, station address and aisle
destination. The failure of any of these address parameters will cause a
flag and an appropriate field in the short status register to be set to
indicate an error and a corresponding error message will be displayed to
the operator. If the TRAVEL command passes the checks, the command is
accepted and the cycle exits awaiting a GO command.
EB0X. (FIG. 7E-2) This sub-cycle is concerned with a DEPOSIT, WITHDRAW, PUT
or GET command in the work register for an aisle change. If a check of | | |
