Finites State Machine (OT?)

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?

 

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
actions.

Rene

 

So, very simplified, your drinks machine starts in a 'Waiting for Money
state'
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

 

"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,
EjectDrink.
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?

 

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

-- greg

 

.... 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.

 

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
make.


Regards,
Nick Maclaren.

 

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.

 

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.

 

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.

 

I always implemented finite state machines in software on microprocessors.

 

No.

-Peter

 

About KeepCoins and that diverter... to where does it divert? To the
internal
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
EjectCoins
and move to WaitOperator state.
else turn on KeepCoins and EjectDrink, and move to MachineIdle
state.

WaitOperator - wait until signal 'MachineEmpty' goes false, turn off
EmptySignOn
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.

 

A microprocessor *is* a finite state machine, no matter what software
you load it with.

 

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.

 

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>

 

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

Steve

 

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
specifications!

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?

Andreas

 

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, n4vu.com; username, jsm

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

 

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.