Connect with us

Finites State Machine (OT?)

Discussion in 'Electronic Basics' started by pdx, May 13, 2004.

Scroll to continue with content
  1. pdx

    pdx Guest

    Sorry if this is off topic but I have another question to help with the
    revision for my exam (it's tomorrow).

    Why would a finite state machine be an appropriate method of implementing
    the control logic of a drinks vending machine?
  2. A state machine is a model consisting of a number of states
    where events cause actions that can change the state. It can model
    almost anything.

    Subdivide the problem into static states and define the event that cause

  3. Andrew

    Andrew Guest

    So, very simplified, your drinks machine starts in a 'Waiting for Money
    event 'Money entered' causes a change to 'Waiting for selection state'
    event 'Pressing Coke' enters a 'Dispense Coke' state
    or event 'Pressing Fanta' enters a 'Dispense Fanta' state
    In either state 'Cup full' enters 'Waiting for Money' again
  4. pdx

    pdx Guest

    "The machine will accept the coins and eject a drinks can down the vending
    chute when the correct money is inserted and the machine is not empty."
    "The machine will reject the coins if the money is incorrect for any
    reason - wrong amount or foreign coins etc. - or if the machine is empty
    when the coins are inserted."

    Also provided are the outputs: KeepCoins, EjectCoins, EmptySignOn,
    and the inputs: MachineEmpty, AcceptCoins, RejectCoins

    For example - does that mean "AcceptCoins" would be a state? Or would the
    state be "Check coins", with "AcceptCoins" being an event?

    Also, why would the examiner provide AcceptCoins *and* RejectCoins since
    they should effectively always be the opposite of each other?
  5. Greg Lindahl

    Greg Lindahl Guest

    Please send us the address of your professor. We'll send him the
    answers directly, cutting out the middleman.

    -- greg
  6. pdx

    pdx Guest

    .... or maybe one of you could go into the exam I'm sitting tomorrow?

    I'll give you my student card and you've got approximately 14 hours to get
    over here and learn my signature.
  7. Not totally irrelevantly, we once had a machine that would deliver
    Bovril with whitener and sugar, due to a half-backed implementation
    of the state machine inside it. The person who created that beverage
    failed to get anyone to try it to see what it tasted like, so we
    shall remain forever in ignorance.

    But the error was a bit more subtle than the ones "pdx" is about to

    Nick Maclaren.
  8. I need to see the machine. What is an 'AcceptCoins' input? RejectCoins
    sounds as a button to terminate a purchase early. What is the KeepCoins
    output controlling? A lamp? A solenoid that dumps the inserted coins
    in the till? Too much guesswork here.
  9. pdx

    pdx Guest

    Four outputs:

    KeepCoins: Hi - holds open the mechanical gate that diverts the accepted
    coins, Lo - keeps gate closed
    EjectCoins: Hi - holds open the mechanical gate that divers the rejected
    coins, Lo - keeps the gate closed
    EmptySignOn: Hi - turns on the "Machine Empty" sign, Lo - turns off the
    "Machine Empty" sign
    EjectDrink: Hi - ejects a can down the vending chute, Lo - blocks the can
    from ejecting

    Three Inputs:

    MachineEmpty: Lo - whilst there are cans in the machine, Hi - when the
    machine is out of stock
    AcceptCoins: Hi - if the correct money has been inserted, Lo - otherwise. To
    allow time for coins (and soft drink cans) to clear their chutes there is a
    short delay before a Hi is reset to Lo.
    RejectCoins: Hi - if the incorrect money has been inserted, Lo - otherwise.
    To allow time for coins (and soft drink cans) to clear their chutes there is
    a short delay before a Hi is reset to Lo.

    This is all the information provided to me in the past exam question. Thanks
    for your help.
  10. Del  Cecchi

    Del Cecchi Guest

    Another trick question. These days it isn't an appropriate way. The
    appropriate way is with an embedded microprocessor. Finite state machines
    only made sense when microprocessors were too expensive.
  11. I always implemented finite state machines in software on microprocessors.
  12. No.

  13. About KeepCoins and that diverter... to where does it divert? To the
    cashbox? And that Ejectcoins diverter dumps collected coins to the reject
    bin, where the customer can take it out again? Again, I need to see the
    machine. And that would be my answer during an exam too ;)

    However, assuming my guesses are correct, it seems that it may work
    if you implement a statemachine with states like these:

    MachineIdle - turn off EjectDrink, turn off KeepCoins, turn off Ejectcoins.
    machine waits for 'AcceptCoins'. If signal present, it moves
    to NewPurchaseAttempt

    NewPurchaseAttempt - if MachineEmpty , turn on EmptySignOn and turn on
    and move to WaitOperator state.
    else turn on KeepCoins and EjectDrink, and move to MachineIdle

    WaitOperator - wait until signal 'MachineEmpty' goes false, turn off
    and move to MachineIdle state.

    I see no need/use for that input 'RejectCoins' without a better description
    or if I don't get to see the actual machine.
  14. A microprocessor *is* a finite state machine, no matter what software
    you load it with.
  15. pdx

    pdx Guest

    Unfortunately that's all the details provided.

    Thanks for your help - I wasn't sure whether I was to use some of the
    inputs/outputs provided as states or create my own states. Going by your
    answer I'd have to create my own.
  16. Guy Macon

    Guy Macon Guest

    Exactly so. You can then go deeper and fill in the details that
    the simplified view left out, such as replacing 'Dispense Coke'
    with 'drop cup' then 'turn on syrup' then 'turn on water' then
    'turn off... (etc.). Then you can go even deeper and replace
    'turn on syrup' with 'while if Syrup_Level > Minimum_level' then
    energize Syrup_Solenoid... (etc.)

    Oh My Goodness! I just invented FORTH!!! <grin>
  17. Steve

    Steve Guest

    Alan Turing, "On Computable Numbers with an application to the
    Entscheidungsproblem," 1936 ?

  18. Maybe, if no money is in, both are not active.
    The change of an input is an event. You have 8 input states, each can
    either stay unchanged or change to one of 7 different states. And 16
    output states. There are 96 different states with transitions. Fast
    coins can drop at surprising speeds - you'll need a fast
    microcontroller to get the short assertion of AcceptCoins . :)

    The same question for the outputs: why KeepCoins and EjectCoins, since
    you can either keep the money or give it back? What happens, when you
    do neither? And what, when you do both?
    Maybe, you can can handle both outputs with just 2 states - accept or
    reject - and reduce your state table to 8x8.

    Sh... Life'S not that simple. Back to the drawing table! Gimme better

    I'd assert KeepCoins all the time, except MachineEmpty or RejectCoins
    is asserted. And I'll only do EjectDrink, when (not MachineEmpty) and
    AcceptCoins is asserted. EmptySignOn will follow MachineEmpty, but
    what happens, when MachineEmpty deasserts? BSOD.
    IRQL_NOT_LESS_OR_EQUAL. There's no output for EmptySignOff, so it
    seems to be a DOO-(Drink Only Once)-type machine.

    Does this qualify as state machine?

    How comes that I do your homework?

  19. John Miller

    John Miller Guest

    pdx wrote to someone else:
    If you'll do a web search for "coin acceptor(s)" or "coin mechanism(s)" you
    may be able to find some documentation of fairly standard I/O that will
    give you some helpful clues.

    John Miller
    Retired developer of bottle/can vender (sic) contol systems
    Email address: domain,; username, jsm

    USENET would be a better laboratory is there were more labor and less
    -Elizabeth Haley
  20. Guy Macon

    Guy Macon Guest

    In addition, at the very low end there are chips that are dedicated
    state machines, there are times when a simple state machine can be
    implemented in an unused portion of existing programmable logic, and
    there are certain simple but time-critical functions that are suitable
    for dedicated high-speed state machines.

    The Finite State Machine is far from being obsolete.
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day