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 controlled.

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 required.

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 become false.

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!
..........