# the dreaded elevator program

B
Thread Starter

#### Brandon

I (college student), and my group inherited an elevator project that is supposed to operate between 3 floors. We stripped it down and have reassembled it. We have wired a 24vdc motor so that it can be ran forward and reverse. We also have wired a couple pots in series with the motor to control and adjust the speed both up and down. We have also counterbalanced the elevator, and hard wired a solenoid to disengage the brake while the elevator is moving. Limit switches are hard wired into the plc from each floor. Up to this point the project works good,as we can adjust to the proper speed and it is mechanically sound.
Now we are at the programing stage, and have tried with limited success to get the elevator to correctly respond to the call buttons on each floor. The paramaters, as far as the function of the elevator, are: it needs to be able to respond in an efficient manner to multiple call button inputs and logically deliver passengers to their destinations
I have programmed a couple of different ways and am not sure if I am going about it in the right way.
I am somewhat familiar with subroutines and think that this may be the best way to get the elevator to proceed to a specific floor in a specific manner. However if a fifo stack could be adjusted after data has been entered, this might work as well. I have also considered using AND, OR, or other instructions.
I do not need or want anybody to email a sample elevator program, but if any body can give me a few suggestions, I would appreciate it, thanks.

R

#### Ralph Kitts

Using the FIFO approach is do-able. I would use two FIFOs (one for call buttons, and one for the buttons in the elevator). Use them to load (FFL) the FIFOs, and when moving, compare the first values in each (non-zero) and go to the closest floor. If you are on floor 2, however, you must remember where you came from, so that you don't just cycle between floor 2 and 1, for instance. In other words, toggle you destination for that circumstance. (Remember to unload the FIFOs (FFU) as you arrive at a floor.) You could use yet another FIFO for remembering the order each of the six buttons were pressed, but for three floors, I don't think you'd need it. Good luck.

B

#### Brandon

Thanks for replying Ralph. I think I may use the Fifo instructions and some compare instructions thanks.
Brandon

J

#### Joe Jansen/ENGR/HQ/KEMET/US

AGH! Overkill!

Rather than using subroutines for each floor call, etc, just keep track, using an internal bit, which direction you are going. After each stop, check the direction bit. Then check if there are any 'passengers' who want to go that direction (floor buttons in the car) or any call buttons that need to be serviced in that direction. If yes, then continue in that
direction. If no, reverse your direction bit, and loop back to the check. When there is no activity the process will maintain a tight loop of
reversing and checking, with no motion initiated.

As you pass the middle floor, only stop to answer a call button if the call direction matches the motion direction, or if a internal passenger wants to get off. Make sure that if the internal passenger stops it as it is coming down from the 3rd floor, you do not cancel the 'up' call button, because the directions do not match. This would also apply if you had more than
three floors, for all the middle floors.

This should be able to be done in straight ladder logic, no special functions or subroutines needed.

HTH

--Joe Jansen

J

#### Jiri Baum

Hello Brandon,
> The paramaters, as far as the function of the elevator, are: it needs to
> be able to respond in an efficient manner to multiple call button inputs
> and logically deliver passengers to their destinations

The standard solution is the "elevator algorithm", I believe. Rather than always servicing the nearest call, which will result in the middle floors being serviced better than the top and ground, the elevator has a direction
flag. When this flag is up'', the elevator services the next higher floor. When there isn't any request above, the flag is switched to
down'', and the next lower floor is serviced, until there aren't any requests below. Then it switches back to up''.

For this to work properly, you need separate "up" and "down" call buttons on all the floors. (Think it through, because there are actually two kinds
of requests - going up' and going down'.)

For low-usage elevators, it's simpler to have just one call button on each floor, which grabs the elevator for that person. If the elevator is already in use, the call is ignored (I suppose it could be queued in a FIFO, but I've never seen that done).

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
tlhIngan Hol jatlhlaHchugh ghollI' Hov leng ngoDHommey'e' not yISuD
Never bet on Star Trek trivia if your opponent speaks Klingon. --Kung Foole

G

#### Greg Goodman

Consider the elevator as having stateful operation. Its states are going up, going down, or sitting idle. ("going up" and "going down" are
logical states, not physical ones. it may be physically stopped while logically going up, as when it drops off a passenger at one floor while
headed to drop off another passenger on a higher floor.)

The events that matter are somebody presses a call button, somebody presses a destination button, and the elevator approaches the next
floor. We don't need to remember what order buttons got pushed in. An idle elevator moves in the first direction that somebody asks it to, and
a moving elevator keeps moving in the same direction as long as there are uncompleted tasks in that same direction.

The elevator keeps a 3-state value indicating its current task. It's either going up, or it's going down, or it's sitting idle.

The elevator can keep a data structure of three bits that characterizes the current state of each floor. It's either a passenger's destination,
or it's not. It's either waiting for an up elevator, or it's not. And it's either waiting for a down elevator, or it's not.

Any time a button gets pressed, the state of the appropriate floor is updated, and the elevator is informed of the fact. If the elevator is
idle, it starts moving toward that floor and sets its own state accordingly (moving up or moving down).

As a moving elevator approaches each floor, it decides whether it needs to stop at that floor or not. An up elevator will only stop at a floor
if it is a current destination or is waiting for an up elevator. Similarly, a down elevator only stops at a floor if it is a destination
or is waiting for a down elevator. ("Approaching a floor" is a slightly more complex determination if you've got a multi-speed elevator. When
you start moving, you have to decide if the next known stop is far enough away to justify high-speed, and you have to know how far away
from a stop you need to start slowing. If you're moving fast and a new destination crops up ahead of you when you're too close to slow and stop
in time, then it doesn't count as "ahead of you". In principle, the elevator can have one of five states: "going up fast", "going up slow",
"going down fast", "going down slow", and "going nowhere".)

When the elevator stops at a floor (and opens the door and waits a bit and closes the door), it has to decide what to do next. As long as
there are unmet demands for service in the same direction it's been moving, it keeps moving in that direction. When it finally stops and
finds no uncompleted tasks in the same direction, then it may start serving demands in the opposite direction or, if there are no outstanding demands, sit idle. Here's a tricky part; the elevator reaches the last known destination in its current direction of movement, then stops, opens and closes the door... and has to wait a bit before deciding what to do next. Just in case a new passenger got on an picks a destination in the same direction it's been moving.

Note that, for a moving elevator, the only event that matters is that it approaches a floor, because the only action it's willing to take is to
stop when it gets where it's going. A button-press can affect what it does when it approaches the next floor, but the event that precipitates
action is the approach. A button press *is* a meaningful event for an idle elevator though, since it is the only event that causes an idle
elevator to change state.

The reason we don't have to remember which buttons got pressed in which order is that, even with our simple strategy, there's no chance of
keeping a potential passenger waiting indefinitely. The elevator shaft is of finite length, so the worst-case wait for passenger who just missed the elevator is a complete round trip of the elevator with a stop at every floor, or 2x(N-1) stops in an N-story building.

Hope this helps some.

Greg Goodman
Chiron Consulting

E

#### Eric Nelson

Yes, dreaded! This "elevator project" has been discussed to death over at www.plcs.net (and possibly here as well). Search the archives at PLCS.net (and be sure to read the "New Here" section). If you decide to post this question over there, be sure to don your flameproof suit, as this subject has become quite a sore point at that board ;o)

- Eric Nelson
[email protected]
Controls/Software
Packaging Associates Automation Inc. [email protected]
Rockaway, NJ, USA

M

#### Mark Ray

Hello
It sounds like you are on the right track by making it as effietient as possible. I have not written programs for elevators but I have waited for them many times. I really like the elevators that have a display that shows the progress of the elevator. If the elevator is stuck on a floor I know I have to use the stairs or I know what floor I need to go to to get the elevator. Have you considered setting up the elevator conditions as a boolean expression and reducing it to its lowest logic. Or have you considered using a matrix to establish the many possible conditions and then write the logic to match. Just an idea.
Cheers
Mark Ray

B

#### bazh

I am wanting to know if anyone has a ladder diagram solution to the elevator example given with the LADSIM program and also if anyone could suggest a suitable PLC for an elevator that travels between 2 floors and can respond to obstructions in the doorway and alarms etc. Thanks in advance.

V

#### Vic Ellescas

Mitsubishi PLC is your best bet for this type of application. Easy configuration, extreme reliability, and company longevity. Mitsubishi
have also have have an elevator program to suite your need. See "www.ibit.com":www.ibit.com for more info. Regards, Vic Ellescas

Similar threads