It’s imperative that you accomplish this task while maintaining compatibility with the current program structure.

This of course assumes that the elevator starts out in it’s default location at the first floor. 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. In this exercise you will add all the appropriate logic to detect when the wall mounted 4th floor switch (I:1/11) is pressed. …Įxercise #2 – Taking the Elevator to the Top. 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.

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. 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. Open a new program, and enter the rungs shown below into the main or LAD2 section of this program. …Įxercise #1 – Preparing Your Program’s Index. 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. 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. 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. 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. Add a module to track the elevator’s motion, and we should already have a fairly good topical outline for our program’s Index.Īnother 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. The tasks of closing and opening the door are obvious candidates for modularization.Īlmost 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.

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.

Logix pro door simulator exercise 3