1
\$\begingroup\$

I want to design a LIFT with the help of Finite state machine.

There are four floors. So I took them as 0, 1,2,3 and correspondingly the states. The 0,1,2,3 buttons are present inside the lift. If some one presses them accordingly it changes from one state(floor) to another.

But they are also UP, DOWN arrows present outside the lift on each floor. No DOWN arrow in 0th floor and no UP arrow in 3rd floor

I am not getting how to incorporate them into the design. With only four states 0,1,2,3 and say a person pressed the button 3 inside the lift from 1st floor, we are sending it state 3 directly. Now if in 2nd floor someone presses the UP arrow, the the lift should stop at the 2nd floor before going directly to 3rd floor, which I am missing.

May be taking UP, DOWN signals as asynchronous may help. But they are 6 such signals. So it is posing me into trouble.

Can some one help me. A state diagram helps me further.

\$\endgroup\$
3
\$\begingroup\$

You're confusing the floor destinations with the states. They are not the same.

For a lift, states would be:

  • Idle
  • Moving up
  • Moving down

The states would be changed by events such as:

  • Call button pressed
  • Floor button pressed
  • Arrived at target floor

The FSM doesn't care about what floor is what, only which floor it wants to get to when in a moving state.

Read more abut FSMs here: http://hacking.majenko.co.uk/finite-state-machine

\$\endgroup\$
5
  • \$\begingroup\$ But still I am not able to complete this. Can you please elaborate. \$\endgroup\$ – sai kiran grandhi Jul 12 '14 at 10:04
  • \$\begingroup\$ @saikirangrandhi To Majenko's answer you could add states such as "moving to 3", "moving to 1" etc Draw all valid states as circles (or rhomboids or whatever). From each state draw lines to other states which you can validly get to from the valid state. Label the lines with the conditions that cause the transition to occur. eg say you have states [1}, [3'] and [moving to 3]. From [1] draw a line to [moving to 3]. Label the line "button 3 pressed". From [moving to 3] draw a line to [3]. Label the line "arrived at 3". Do this for all valid conditions. ... \$\endgroup\$ – Russell McMahon Jul 12 '14 at 10:14
  • \$\begingroup\$ ... If you want to include motor directions they can be in the lines between states. eg on the line between [1] and [moving to 3] you can add the box {Start moving up}} and when you arrive at "arroved at 3" you can add {STOP MOTOR} in that line. There are other ways to identify what constitute states. The above works and others do 2. From this you should be able to get a workable scheme if you take the time to understand it. \$\endgroup\$ – Russell McMahon Jul 12 '14 at 10:18
  • \$\begingroup\$ @RussellMcMahon Very nice thoughts. But I was confused on a situation say I was moving from 1 to 3. Then the UP on 2 was pressed. I should take the request only when I have not crossed 2 whose information I don't have......... \$\endgroup\$ – sai kiran grandhi Jul 20 '14 at 10:43
  • \$\begingroup\$ @saikirangrandhi No need to be confused. Once you are in a state allow it to respond or not respond to a given button however you wish. If you are in [moving to 3] and button 2. is pressed you can make the response be anything you want. If there is no action associated with 2. it just ignores it. OR it could ring a bell and otherwise ignore it. And it COULD add 2. to the floors to visit list if still below 2, or put it in a "do next when going down" list. Or make a coffee or anything you like. \$\endgroup\$ – Russell McMahon Jul 21 '14 at 7:35
0
\$\begingroup\$

I would not represent each floor as a separate state. States are associated with a set of behavior which is different from the behavior of other states. Generally, a lift does not behave differently at floor 1 versus floor 2. So I don't think floors make good states.

I would start with three states: Idle, Loading, and Moving. The Idle state is when there are no destinations. The Loading state is while the passengers are loading or unloading. On entry to the Loading state the lift will open the doors. On exit from Loading, close the doors. The Moving state is while the lift is travelling to a destination. On entry/exit from the Moving state the lift starts/stops the motor.

The events that cause transitions between states include the floor buttons (inside the lift) and the call buttons (the up/down buttons) at each floor. Another event occurs when the moving lift reaches each floor. The floor number is data that is included with these events.

When the Idle state receives a button event it compares the floor number with the current floor. If the button event floor number is equal to the current floor then transition to the Loading state. If the button event floor number is different from the current floor then add the floor number to the destination list and transition to the Moving state.

When the Loading state receives a button event it compares the floor number with the current floor. If the button event floor number is different from the current floor then add the floor to the destination list and transition to the Moving state.

When the Moving state receives a button event it adds the floor to the destination list. When the Moving state receives the reached-floor event it updates the current floor and compares with the destination list. If the reached floor is a destination then remove the destination from the list and transition to the Loading state.

The tricky part will be managing the destination list. My first thought was that a linked-list data structure would be useful. Destinations could get prioritized and sorted as they are added to the list such that the first item in the list is the next destination. But that may be too complicated. A simpler idea may be to keep two separate arrays of destinations, one array for each direction. There is an element in the array for each floor. If the floor is a destination while traveling in a particular direction then the corresponding array element is true. The point is that there is more than one way to do it and I don't know what will work best. You're going to have to iterate on the design and the logic.

One of the nice things about this state machine design is that it easily extends to support any number of floors. In other words, you don't have to add new states and events when you add floors.

\$\endgroup\$
3
  • \$\begingroup\$ I think the design is complicated by adding the comparator and the circuit to manage the priority list. But I will try my best to implement it. \$\endgroup\$ – sai kiran grandhi Jul 14 '14 at 9:49
  • \$\begingroup\$ What is the difference that occurs between the UP and DOWN buttons. This important criterion is ignored \$\endgroup\$ – sai kiran grandhi Jul 14 '14 at 9:50
  • \$\begingroup\$ Whether the UP or DOWN call button was pressed will be an input into that tricky part of managing the destination list. If the elevator is travelling up from 1 to 3 when the DOWN button is pressed at 2, then floor 2 doesn't become an immediate destination because the elevator is travelling the opposite direction. Rather, floor 2 becomes a destination for when the elevator is moving back down. \$\endgroup\$ – kkrambo Jul 14 '14 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.