Elevator Circuit

Status
Not open for further replies.

Thread Starter

jegues

Joined Sep 13, 2010
733
Evening gents,

We've just recieved a group project in our digital logic course, and I'm trying to think of the best way to proceed so I thought why not post it on this forum and discuss some important things/details that I should consider when designing our system.

See figure attached for project details.

As a minimum our implementation will require the use of:

  • User input devices (buttons/keyboard);
  • Output displays - you may use the built in LEDs or may make use of external devices such as seven segment displays
  • Finite State Machine(s) to control the interaction of the parts;
Does anyone have any advice/ideas/tips/hints/suggestions for us?

Thanks again!
 

Attachments

Georacer

Joined Nov 25, 2009
5,182
A relay isn't something complicated. It amplifies the circuits potential power, much like a transistor when it operates on saturation.
Its key features are the voltage on which the secondary coil needs to be under, in order to close the switch it controls, the current the primary contact can handle and the voltage it can be put under.

If you want to use an FSM design, first come up with a working state diagram. A page of the AAC e-book concerning FSM's will be uploaded soon (I hope) so more to be heard from that part.
 

DonQ

Joined May 6, 2009
321
Relays are the ultimate logic gate. Contacts of different relays in series are AND gates, in parallel are OR gates. Normally closed contacts are like a NOT because they open when the coil is activated. The major difference is the currents used are generally much higher than integrated circuits. Logically, they are the same, just a current activated switch with (possibly) multiple channels.

What was that about being able to generate any logic equation with only one type of logic gate and the availability of a NOT...?

State machines? Look up "ladder logic". This is a graphical representation of relay logic, nowadays performed on PLCs, but originally (and still sometimes) performed on huge banks of actual clicking relays.
 

Georacer

Joined Nov 25, 2009
5,182
What was that about being able to generate any logic equation with only one type of logic gate and the availability of a NOT...?
On that post:
http://forum.allaboutcircuits.com/showthread.php?t=44279&highlight=NAND
along with icelated, we found that you can simulate AND, OR and NOT gates can be simulated with a NAND gate or a NOR gate. Therefore you can create any logic function either with only NOR gates or NAND gates.

Check it out. If we made a mistake please tell us so.
 

PRS

Joined Aug 24, 2008
989
The way I read your project specs, there is no real motor involved and hence no appreciable current. It sounds like this is a 5 volt and a 100 or 200 mA range logic project, and so no relays are required. Relays are for larger currents than semiconductors can provide. Rather than relays, and since this is a sequential logic circuit, you will be using logic gates and flip flops. Those buttons (for input) and LEDs (for output) are all low power devices. A simple low power 5 volt supply is enough for the whole project.

If this isn't a microprocessor project, which I understand to be the case, start by making a logic table for all of the conditions that can occur between three floors. An elevator climbing to level 2 usually will continue up to the 3rd floor, though 1 has been pushed on its way to 2. Think of things like that. This elevator has three states which correspond to the three floors. But the alternative paths between states requires logic. This is your challenge. You need to draw a 3-state diagram and, using it, imagine all of the possibilities that may come up and then, using common sense, determine the elevator's behavior and fill in the logic table. In the end, you'll be explaining your common sense decisions to your instructor.

Then, using the techniques of sequential logic you learned in class, develop a circuit to implement the control system on a breadboard. In a real application you would also need to vary the speed of the motor and detect (with sensors) the position of the elevator with respect to the doors. But I don't think your instructor is calling for such complications. At least I see none of that in the specs.

The outputs of your elevator controller, i.e. your control signals are a) direction, (1 for up, 0 for down, or vice versa); and b) on/off (1 for on, 0 for off or vise-versa -- your choice, but be consistent); also light1, light2 light3, all of which are either on or off (1 or 0).

The inputs are represented by the left side of your logic table. There are three buttons, but there are many more conditions dictated by logic. So add a 4th input and call it priority. This is 1 if the car should stop at the next station, 0 otherwise. Therefore make a 4 bit logic table on the left side and use the MSB for the priority bit:

0000
0001
0010,
.
.
.
1111

Remember that the next state of a sequential circuit is determined by both the input and the present state. That priority bit represents the present state and it is set logically according to your state diagram and common sense.

So you need to think like this: If the car is at 1 and both 2 and 3 buttons are pushed, make the car go to 2, turning off light 1 and stop there and turn on light 2 (I'd add a timer circuit in order to show this, otherwise events will happen too fast to see them occur), then the car goes up to 3 and stops. This means light 2 goes off and light 3 goes on. Remember direction = 1 in both cases, but there are five changes in the on/off control from 0 to 1 from 0 to 1 to 0.

Good luck and have fun!

I just re-read the specs. Another output is to show the direction the car is traveling. You actually don't need another output for this. Just use the up/down control line mentioned above. It would control the motor direction if the motor was actually present. To implement this directional signal on your breadboard just use two opposing LEDs, one red, the other green, and designate one as up the other as down.

Just as an aside: You are making a dedicated computer. It just does one thing: It controls a three floor elevator. But larger logic systems, such as microprocessors and micro-controllers are based on the same logic that you are developing. In this case, each instruction represents a hardware implementation, be it a Do While Loop or a Go To instruction. So you see, this project is leading you to somewhere big. If you pursue this think Intel or Microchip Corporations, and the like.
 
Last edited:

Thread Starter

jegues

Joined Sep 13, 2010
733
The way I read your project specs, there is no real motor involved and hence no appreciable current. It sounds like this is a 5 volt and a 100 or 200 mA range logic project, and so no relays are required. Relays are for larger currents than semiconductors can provide. Rather than relays, and since this is a sequential logic circuit, you will be using logic gates and flip flops. Those buttons (for input) and LEDs (for output) are all low power devices. A simple low power 5 volt supply is enough for the whole project.

If this isn't a microprocessor project, which I understand to be the case, start by making a logic table for all of the conditions that can occur between three floors. An elevator climbing to level 2 usually will continue up to the 3rd floor, though 1 has been pushed on its way to 2. Think of things like that. This elevator has three states which correspond to the three floors. But the alternative paths between states requires logic. This is your challenge. You need to draw a 3-state diagram and, using it, imagine all of the possibilities that may come up and then, using common sense, determine the elevator's behavior and fill in the logic table. In the end, you'll be explaining your common sense decisions to your instructor.

Then, using the techniques of sequential logic you learned in class, develop a circuit to implement the control system on a breadboard. In a real application you would also need to vary the speed of the motor and detect (with sensors) the position of the elevator with respect to the doors. But I don't think your instructor is calling for such complications. At least I see none of that in the specs.

The outputs of your elevator controller, i.e. your control signals are a) direction, (1 for up, 0 for down, or vice versa); and b) on/off (1 for on, 0 for off or vise-versa -- your choice, but be consistent); also light1, light2 light3, all of which are either on or off (1 or 0).

The inputs are represented by the left side of your logic table. There are three buttons, but there are many more conditions dictated by logic. So add a 4th input and call it priority. This is 1 if the car should stop at the next station, 0 otherwise. Therefore make a 4 bit logic table on the left side and use the MSB for the priority bit:

0000
0001
0010,
.
.
.
1111

Remember that the next state of a sequential circuit is determined by both the input and the present state. That priority bit represents the present state and it is set logically according to your state diagram and common sense.

So you need to think like this: If the car is at 1 and both 2 and 3 buttons are pushed, make the car go to 2, turning off light 1 and stop there and turn on light 2 (I'd add a timer circuit in order to show this, otherwise events will happen too fast to see them occur), then the car goes up to 3 and stops. This means light 2 goes off and light 3 goes on. Remember direction = 1 in both cases, but there are five changes in the on/off control from 0 to 1 from 0 to 1 to 0.

Good luck and have fun!

I just re-read the specs. Another output is to show the direction the car is traveling. You actually don't need another output for this. Just use the up/down control line mentioned above. It would control the motor direction if the motor was actually present. To implement this directional signal on your breadboard just use two opposing LEDs, one red, the other green, and designate one as up the other as down.

Just as an aside: You are making a dedicated computer. It just does one thing: It controls a three floor elevator. But larger logic systems, such as microprocessors and micro-controllers are based on the same logic that you are developing. In this case, each instruction represents a hardware implementation, be it a Do While Loop or a Go To instruction. So you see, this project is leading you to somewhere big. If you pursue this think Intel or Microchip Corporations, and the like.
Thank you for the excellent reply. What you've interpreted from the project is exactly what the instructors are expecting from us.

I'm going to read over your post a few more times, try a few things out and I'll see what I can come up with. I'll edit this post with my results.

Thanks again!

EDIT: Here's a truth table I came up with from what you had recommended. (See figure attached)

I'm a little confused as to what should be on the right side of my table. Also, should each light (1,2,3) have its own column in the table?

Is the idea to split the logic of the elevator into 2 parts, one part that is simply sequential logic (i.e. doesn't depend on the state of the elevator), and another part which DOES depends on the given state of the elevator?

Your post has got me thinking alot, but I still don't have any solid sort of structure down, ideas and variables are still floating around.

Any suggestions?
 

Attachments

Last edited:

Georacer

Joined Nov 25, 2009
5,182
Is the idea to split the logic of the elevator into 2 parts, one part that is simply sequential logic (i.e. doesn't depend on the state of the elevator), and another part which DOES depends on the given state of the elevator?
Just a small correction here, in sequential logic, the output is dependent of the current state.

If this was an actual build, things would be easier, in the logic part. But we 'll find a way.

It is important to set up correctly the inputs, the states and the outputs of the system.

Your inputs are the "call" pushbuttons outside the elevator and the "floor" keypad inside the elevator.

Your states are the 3 floors.

Your ouputs are the on/off signal and the direction signal.

To build the initial FSM system, the inputs and the states are enough. If I were you I would make a truth table with columns as sush:

2 columns for the state variable (2 bits to encode the floors)
3 bits for the "call" buttons (3 floors by 2 directions)
3 columns for the "floor" keypad (you can select all 3 floors if needed, that's why there are 3 bits, much like the "call" buttons)

This results in 256 rows. Now this are a lot of cases, but with this approach of the problem I don't see another way to describe the system completely. Even if the elevator can "target" only one floor at a time, you would still have many cases.
Now, this is duable. Just very impractical in my opinion.

I think a modular solution would be easier for the mind (save you the 8 variable Karnaugh) and a more satisfying challenge.
 

Thread Starter

jegues

Joined Sep 13, 2010
733
Just a small correction here, in sequential logic, the output is dependent of the current state.

If this was an actual build, things would be easier, in the logic part. But we 'll find a way.

It is important to set up correctly the inputs, the states and the outputs of the system.

Your inputs are the "call" pushbuttons outside the elevator and the "floor" keypad inside the elevator.

Your states are the 3 floors.

Your ouputs are the on/off signal and the direction signal.

To build the initial FSM system, the inputs and the states are enough. If I were you I would make a truth table with columns as sush:

2 columns for the state variable (2 bits to encode the floors)
3 bits for the "call" buttons (3 floors by 2 directions)
3 columns for the "floor" keypad (you can select all 3 floors if needed, that's why there are 3 bits, much like the "call" buttons)

This results in 256 rows. Now this are a lot of cases, but with this approach of the problem I don't see another way to describe the system completely. Even if the elevator can "target" only one floor at a time, you would still have many cases.
Now, this is duable. Just very impractical in my opinion.

I think a modular solution would be easier for the mind (save you the 8 variable Karnaugh) and a more satisfying challenge.

What do you mean by a modular solution, Georacer?
 

PRS

Joined Aug 24, 2008
989
Hi Georacer! You made some points that have me thinking I've forgotten something. I have to review my old textbook because now I'm not real clear on a few things.
 

PRS

Joined Aug 24, 2008
989
I can't tell you what Georacer means by modular solution, but he said a few things that make me think I have to review my old textbook. I'll look into it and get back with you. This problem intrigues me.
 

Georacer

Joined Nov 25, 2009
5,182
It seems rather old and cheap when digital electronics classes try to test student by making them build with gates, circuits so complex that are nowadays constructed with a simple microprocessor.

This is one case. An FSM as we saw is out of the question. No need to torture yourself over A0 sized truth tables. What we need here is to break the problem to smaller ones that are solved independently and employ a little wit.

What I meant by modular solution is to construct stand-alone circuits that will take inputs and perform a specific job. Their outputs will be handled by other modules in a way that won't overcomplicate things.

First lets realise that if we want each floor to communicate to the elevator the direction the passenger wants to travel, we need to take a 3 bit inormation from each floor (no call, down, up). Mutliplied by n (3 in our case) floors (I don't want to lose the ability to expand the system) that makes a lot of input. We need to take that number down too.

Instead of processing this information right away and try to produce a result at once, we could let the info rest in a memory block (FF, counter) until we need it. Lets make a reference table out of IC's instead of investing time encoding all the possible states our circuit could have.

Here's what I have in mind. Pay attention as I haven't worked out the details:

1. One Up/Down Counter with Enable control will represent the elevator position and 1 bit (in an FF?) will represent its direction.
2. Registers for each floor will store whether the caller wants to go Up, Down and the actual Call for the elevator on that floor. 3 bits for each floor, 9 in total. But we won't be examining them simultaneously so don't fret!
3. A comparator will say if the destination of the elevator is above, below or on the same floor as the cabin.

I imagine the operation like this:

The elevator counter will wait inert with its Enable signal deactivated. When a floor call is pressed, we will store it, but will only pass it to the comparator if it mathes with the elevator direction. The comparator will detect whether its upwards or downwards relatively to the cabin and the elevator will move towards that direction. When the cabin reaches a destination, it will deactivate momentarily, the floor call will be erased and the procedure will start anew.

It's still very basic but I feel it's on the right direction. I estimate the circuit at about 10-20 IC's. It still needs a lot of work; it's not a trivial exercise. I 'll come up tomorrow with more details.
 

PRS

Joined Aug 24, 2008
989
Your approach may work, but that's not what jegues learned in class; that is, if things haven't changed much since I went to school. If he used your approach and succeeded in meeting the requirements for the elevator, he would probably not get an A or even a B. I know this because I did it with the result that it only made the instructor angry since I didn't use the approach taught in class. By the way, I got a C on that project. I think jegues wants an A.

After I finished school, when I actually had some time on my hands, I went back over sequential logic and cleared up the things that had gotten past me. I'd like to help jegues and his friends from making the same mistake I did. :)
 
Last edited:

Georacer

Joined Nov 25, 2009
5,182
You might be right, but I can't think of any viable way to implement an FSM in this contraption.

You know what the most frustrating thing is? That you bust your @@$ to cover all possible combinations of things that can go wrong, end up with a huge build (which most of the times is buggy), and the professor tells you at the end that he thinks what he asked was very simple, had you done a dozen assumptions. Unreal assumption like, there won't be two elevator calls at the same time.
This is what has happened to me.
 

PRS

Joined Aug 24, 2008
989
You might be right, but I can't think of any viable way to implement an FSM in this contraption.

You know what the most frustrating thing is? That you bust your @@$ to cover all possible combinations of things that can go wrong, end up with a huge build (which most of the times is buggy), and the professor tells you at the end that he thinks what he asked was very simple, had you done a dozen assumptions. Unreal assumption like, there won't be two elevator calls at the same time.
This is what has happened to me.
That's interesting. I see I wasn't alone in doing that, LOL! ;)
 

PRS

Joined Aug 24, 2008
989
I just uploaded a partial state diagram and a partial truth table to get you on your way, or to at least help you think about the problem. Notice the LED for the first floor only comes on when the inputs are 0000 and 0001. Similarly, the 2nd floor LED is on only when 0100 and 0101, etc. Add three output columns for the LED's.

Note I combined the info about location and push-button status and created a 4 column input table and labeled the circles in the state diagram according to the table. Notice the MSB, as I drew it, is input line A. A and B together represent the car's present state, i.e. it's position. Lines C and D are the button pushed and help determine the next state. Line U/D' is up and down. Attach two opposing LEDs to this line and you fulfill the directional signal requirement. The output labeled ON/OFF' refers to the motor.

When you fill in the truth table make use of Don't Care conditions. An example of this is the initial state where the motor is off. In this case the direction doesn't matter. Use of Don't Cares help simplify your Karnaugh Map and hence the physical implementation. You should make a Karnaugh Map for each output.

When you get a genuine understanding of the diagram, fill out the truth table and finish both the diagram and the truth table at the same time. But before actually doing the Karnaugh Maps and creating a hardware design, take your state diagram and truth table to your teacher and ask if you're on the right track.

I hoped this helps! ;)

By the way, note that the buttons inside the car and outside the car are the same, so just OR each pair together.

An hour after thinking further on the subject, I don't think this approach get's it done. There are further complications. Please let me know if you've found the right approach? Perhaps Racer's idea is the way to go, after all. I can't find a satisfactory way of determining whether the car should stop at the second floor or just keep going. Maybe a 5th input? In that case the Karnaugh maps will be hard to do.

You do indeed need more input information to make the elevator work in the traditional sense. Your inputs are two lines like A and B above to indicate the state, and then 3 lines to indicate which button has been pushed, one for each button. This makes 5 inputs so far. But you need one more. This is for the case when, say, the car is coming down from 3 toward 2 and both 1 and 3 have been pressed. Now what do you do -- service 1 or 3? The protocol for elevators seems to be that the elevator will keep heading in the direction it is going -- whether up or down -- and keep servicing calls in that direction until it has reached the end of the line, and only then will it change direction. So another input is direction. This makes 6. And this calls for complicated Karnaugh Maps. Good luck!
 

Attachments

Last edited:

Thread Starter

jegues

Joined Sep 13, 2010
733
I just uploaded a partial state diagram and a partial truth table to get you on your way, or to at least help you think about the problem. Notice the LED for the first floor only comes on when the inputs are 0000 and 0001. Similarly, the 2nd floor LED is on only when 0100 and 0101, etc. Add three output columns for the LED's.

Note I combined the info about location and push-button status and created a 4 column input table and labeled the circles in the state diagram according to the table. Notice the MSB, as I drew it, is input line A. A and B together represent the car's present state, i.e. it's position. Lines C and D are the button pushed and help determine the next state. Line U/D' is up and down. Attach two opposing LEDs to this line and you fulfill the directional signal requirement. The output labeled ON/OFF' refers to the motor.

When you fill in the truth table make use of Don't Care conditions. An example of this is the initial state where the motor is off. In this case the direction doesn't matter. Use of Don't Cares help simplify your Karnaugh Map and hence the physical implementation. You should make a Karnaugh Map for each output.

When you get a genuine understanding of the diagram, fill out the truth table and finish both the diagram and the truth table at the same time. But before actually doing the Karnaugh Maps and creating a hardware design, take your state diagram and truth table to your teacher and ask if you're on the right track.

I hoped this helps! ;)

By the way, note that the buttons inside the car and outside the car are the same, so just OR each pair together.

An hour after thinking further on the subject, I don't think this approach get's it done. There are further complications. Please let me know if you've found the right approach? Perhaps Racer's idea is the way to go, after all. I can't find a satisfactory way of determining whether the car should stop at the second floor or just keep going. Maybe a 5th input? In that case the Karnaugh maps will be hard to do.

You do indeed need more input information to make the elevator work in the traditional sense. Your inputs are two lines like A and B above to indicate the state, and then 3 lines to indicate which button has been pushed, one for each button. This makes 5 inputs so far. But you need one more. This is for the case when, say, the car is coming down from 3 toward 2 and both 1 and 3 have been pressed. Now what do you do -- service 1 or 3? The protocol for elevators seems to be that the elevator will keep heading in the direction it is going -- whether up or down -- and keep servicing calls in that direction until it has reached the end of the line, and only then will it change direction. So another input is direction. This makes 6. And this calls for complicated Karnaugh Maps. Good luck!
Thank you for all your help (You and Georacer and Others), but even after all this, the project itself looks like a giant mess.

I honestly have no clue how I'm actually going to implement something like this. If I just had to do one part of the elevator (like lighting up leds for the floor that it's on) then I might be able to do it.

But something of this size and complexity is overwhelming, and I still don't even really understand how to start.

Is there anything specific I should ask my professor that would greatly simplify the problem, or atleast make it more managable?
 

Georacer

Joined Nov 25, 2009
5,182
PRS had a point there: Ask your professor if you can do the task without an FSM. If not, ask for a hint; nothing wrong with being modest. Refer to the ways that the inputs and outputs could be grouped in independant processes, and stress the fact that you are not sure a 6 input FSM (with the 64 row truth table) is the solution the professor expects from you.

I don't know how tight the competition is at your class, but you could ask some of your coleagues too for hints.
 

PRS

Joined Aug 24, 2008
989
Thank you for all your help (You and Georacer and Others), but even after all this, the project itself looks like a giant mess.

I honestly have no clue how I'm actually going to implement something like this. If I just had to do one part of the elevator (like lighting up leds for the floor that it's on) then I might be able to do it.

But something of this size and complexity is overwhelming, and I still don't even really understand how to start.

Is there anything specific I should ask my professor that would greatly simplify the problem, or atleast make it more managable?
I keep helping as far as I am able, but yesterday I found out my copier doesn't work and that means I have no scanner. Also my computer will not do a software reboot. I'm going to do a total re-installation of Vista to see if that fixes it. Not having a computer, even for a day, makes me feel like a duck out of water. So I'll keep thinking out the elevator problem. I'm intrigued by it. If you don't hear from me again it's because I've ruined my computer. See ya! ;)
 
Status
Not open for further replies.
Top