As we've seen previously, modularizing portions of a program and placing the required
logic into subroutines often results in a program which is both easier to read and understand.
In extreme cases, a programmer may even elect to modularize the total program. If this approach
is taken, then the resultant core or main program will often be nothing more then a list of calls
to subroutines where the details are dealt with. Very much like the Index for a book. The index
provides an overview from which the reader can readily discern where particular topics are
located, and then readily move to that location for further details.
In the case of the Elevator simulation, it isn't too hard to visualize how we might modularize
many, if not all the tasks that are going to be required. The tasks of closing and opening the door
are obvious candidates for modularization. Almost all programs require an initialization section,
and even tasks that require continual execution, such as catching a button press which denotes
a request for the elevator to arrive, can often be grouped into a subroutine, and then simply
called unconditionally on every scan. Add a module to track the elevator's motion, and
we should already have a fairly good topical outline for our program's Index.
Another factor which is somewhat unique to this exercise, is that we are going to need a fair
number of flags to keep track of what we are doing, and what must be done next. Fortunately, the
switch closures which denote a request to have the elevator arrive, will lead us to latching
the built-in lamp of the switch so as to visually confirm the request has been recognized. The
lamp for this switch should remain energized until the elevator car arrives, and hence that lamp
can serve the dual purpose of flagging that pending requests exists, it's floor, and indirectly the
required direction of travel. Employing I/O in this dual purpose manner should not be new, but utilizing
latch (L) and unlatch (U) instructions has until now been generally discouraged. You should be
well aware of the reasoning behind this by now, but there are situations where the latching
instructions are ideally suited to the task, and this happens to be one of them.
Exercise #1 -- Preparing Your Program's Index.
Open a new program, and enter the rungs shown below into the main or LAD2 section of this program.
Once this is accomplished, all further logic that you add to your program should be placed into
the appropriate subroutine which has been allocated for the particular task at hand.
You will note that a number of flags have already been pre-defined, and these are to be employed to
control the logic flow of your final program. Just to make life a little easier on your instructor, you
are asked to utilize unused bits in word B3:0 if and when any additional flags are required.
Exercise #2 -- Taking the Elevator to the Top.
In this exercise you will add all the appropriate logic to detect when the wall mounted
4th floor switch (I:1/11) is pressed. When this occurs, the elevator is to be put into motion
and proceed upwards until it arrives at the 4th floor where it will halt. This of course
assumes that the elevator starts out in it's default location at the first floor.
It's imperative that you accomplish this task while maintaining compatibility with the current
program structure. To this end, all 6 subroutines will be utilized, and therefore each must first be
programmed with the appropriate logic to accomplish this initial task.
U3, Initialization Subroutine:
Each time you test your program, you should first reset the simulation using the selection in the
simulations menu. This will ensure that elevator is back at the first floor and all the hardware
is in it's initial state. When you place your program into the run mode, U3 will be executed, and
it is here where you should ensure that all flags etc are in their correct initial state.
In particular, the "DoNext or Wait" flag should be latched true which will ensure that subroutine
U7 (Next Request or Wait) will be actively scanned at this time.
U4, Catch Floor Requests:
This subroutine is where the logic that will detect, and react to the closure of the 4th floor
wall switch should be placed. The lamp for this switch should be latched on, but this should only
occur if the elevator is not already at the 4th floor. In later exercises, additional logic will
be added for the other switches that can initiate a change in the elevator's location.
U5, Next Request or Wait:
This subroutine is where the decision to move the elevator will be made. The built-in lamps of
the wall mounted switches may be used as a flag to initiate a move of the elevator car. For now it
will only be necessary to monitor flag (lamp) O:2/11 and set the "Close and Go" flag in response.
This will in-turn invoke the "Close Door and Move" subroutine (U7) which will take care of
getting the elevator underway.
U6, Close Door and Move:
In this subroutine, locate the logic to close the door, and then energize the motor to get the
elevator underway. The desired direction is obvious in this case, but later you will most
certainly require flags to indicate which direction to proceed in. Before exiting this
subroutine make sure that both the "DoNext or Wait" and the "Close and Go" flags are
cleared (unlatched), and set the "Car is Moving" flag so that positioning of the car will be
U7, Track Car Movement:
Once the car is moving, this subroutine takes control, and is responsible for deciding where
to stop the car. In this exercise the direction and destination are fixed (up, 4th floor), so you
will only be required to determine when the car has reached the fourth floor. Once there, the
car's location should be flagged by updating the appropriate floor indicator lamps, and the
"Stop and Open" flag should be set (latched) which will in-turn invoke the "Stop and Open Door"
subroutine. The car's vertical position can be determined by reading the motor's shaft encoder
(I:5), and equating this reading to those you have gathered for the individual floors.
It may take a little trial and error to initially gather these values, but the task can be made
easier if you temporarily slow LogixPro's scan rate down somewhat.
U8, Stop and Open Door:
The first thing to do here is to stop the motor and reset (unlatch) the "Car is Moving" flag. You
should also extinguish the built-in lamp of the wall mounted request switch. The floor indicator
lamps above the door can be utilized to determine which lamp is to be extinguished. Lastly a small
2 second settling delay should be allowed for, followed by opening the door.
Once you have your program to the point where the elevator can be moved from it's initial location
to the 4th floor as outlined, you should then be ready to deal with returning it to the 1st floor.
Exercise #3 -- A Complete 2 Floor Elevator Control.
In this exercise, you are asked to add the required logic to implement a complete 2 floor elevator
control system. Floors 1 and 4 will be used for this purpose, and all switches and lamps associated
with these floors are to be made fully operational. All added logic should be placed into the
subroutine deemed appropriate for the particular task, and additional flags may be added as
When not actively moving, the elevator will be located at one of the 2 serviced floors,
sitting at rest with the elevator car door opened. When at rest, the only lamps illuminated will be the
appropriate floor indicator lamp located directly above the elevator door. Additionally, your program
should not respond to a switch press associated with the elevator's current location
On arrival at a floor, the built-in switch lamp for that floor should be extinguished, and
the appropriate floor indicator lamp above the door should be illuminated. The door should then be made
to open 2 seconds later. Additionally, the door must remain open for a minimum of 5 seconds before
being allowed to process another floor request. Floor requests occurring during this delay period should
not be ignored, but only delayed in processing.
While working on a solution for this exercise, keep in mind that you will soon have to extend this
control to all 4 floors. Flags to indicate in which direction the elevator is traveling will be
a must. Fortunately with just 2 floors, determining which direction to go is a trivial task, but one
that will become quite complex when additional floors are added.
Once you have assured that you can fully control the operation of this 2 floor elevator, you should
be well prepared to move onto the multi-floor exercise.
Exercise #4 -- Multi Floor Elevator Control.
Extending your program to accommodate multiple floors, would appear to be a relatively simple matter
of just adding the logic to deal with the additional switches and lamps. This must be done of course,
but a new issue arises in a multi-floor system which can prove to be quite a challenge to solve for.
With a 2 floor elevator, you really have only one choice when deciding in which direction the elevator
should move. In a multi-floor system however, you can be faced with 2 choices of travel whenever the
elevator is at an intermediate floor. In addition, you must also take into account whether the elevator is
at rest with no requests for service pending, or has stopped temporarily at the intermediate floor
while proceeding to a floor further beyond in that same direction.
In our multi floor system, the elevator should continue in it's initial direction of travel, stopping
at each intermediate floor which has a request pending for that particular direction, and continue in this
same direction until the farthest request for service is reached. At this point the direction of travel
should then be reversed if further requests are pending. Any requests associated with this new direction
of travel should then be serviced.
Once moving towards the farthest requested floor, the elevator should not stop at an intermediate floor
if the request at that floor is for the opposite direction; unless this is the farthest request. Otherwise
the floor should be bypassed and serviced when the elevator later approaches the floor from the opposite
direction of travel.
Keeping track of the direction of travel will be critical in this control scheme. It's therefore
suggested that you employ both "Going Up" and "Going Down" flags to help in the decision making process.
Only when there are no requests pending would the elevator be deemed to be at rest (Waiting), and both
direction flags would be set false (unlatched). The first new request detected can then be used
to determine the initial direction of travel, and the appropriate flag set (latched). Once a direction has
been flagged, then motion and servicing will continue until all pending requests are serviced. If required,
the direction may be changed, but not until all requests are serviced will both direction flags once again
The logic associated with determining the initial direction, change in direction, and achieving a
state of rest, ideally belongs in the "Next Request or Wait" subroutine. This logic will definitely
not be trivial to develop, and you are strongly advised to utilize whatever tools you have at your
disposal, including pen and paper to attain a suitable solution.
Best of Luck!