Finites State Machine (OT?)

P

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?
 
pdx wrote:

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?
Click to expand...
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
--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
 
Rene Tschaggelar wrote:
pdx wrote:

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
Click to expand...
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
 
"Rene Tschaggelar" <none@none.net> wrote in message
news:40a3cb19$0$705$5402220f@news.sunrise.ch...
pdx wrote:

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.
Click to expand...
"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?
 
In article <2ghvjqF3429bU1@uni-berlin.de>, pdx <pdx@spamtrap.com> wrote:

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?
Click to expand...
Please send us the address of your professor. We'll send him the
answers directly, cutting out the middleman.

-- greg
 
"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:40a3ce15$1@news.meer.net...
In article <2ghvjqF3429bU1@uni-berlin.de>, pdx <pdx@spamtrap.com> wrote:

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?

Please send us the address of your professor. We'll send him the
answers directly, cutting out the middleman.
Click to expand...
.... 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.
 
In article <40a3ce15$1@news.meer.net>, Greg Lindahl <lindahl@pbm.com> wrote:
In article <2ghvjqF3429bU1@uni-berlin.de>, pdx <pdx@spamtrap.com> wrote:

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?

Please send us the address of your professor. We'll send him the
answers directly, cutting out the middleman.
Click to expand...
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.
 
"pdx" <pdx@spamtrap.com> schreef in bericht
news:2gi0toF30judU1@uni-berlin.de...
"Rene Tschaggelar" <none@none.net> wrote in message
news:40a3cb19$0$705$5402220f@news.sunrise.ch...
pdx wrote:

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.

"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?
Click to expand...
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.

--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)
 
"Frank Bemelman" <f.bemelmanx@planet.invalid.nl> wrote in message
news:40a3da02$0$194$c3e8da3@news.astraweb.com...
"pdx" <pdx@spamtrap.com> schreef in bericht
news:2gi0toF30judU1@uni-berlin.de...
"Rene Tschaggelar" <none@none.net> wrote in message
news:40a3cb19$0$705$5402220f@news.sunrise.ch...
pdx wrote:

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.

"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?

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.
Click to expand...
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.
 
"pdx" <pdx@spamtrap.com> wrote in message
news:2ghvjqF3429bU1@uni-berlin.de...
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?


Another trick question. These days it isn't an appropriate way. The
Click to expand...
appropriate way is with an embedded microprocessor. Finite state machines
only made sense when microprocessors were too expensive.
 
"Del Cecchi" <cecchinospam@us.ibm.com> wrote in message
news:2gi5u4F359r3U1@uni-berlin.de...
"pdx" <pdx@spamtrap.com> wrote in message
news:2ghvjqF3429bU1@uni-berlin.de...
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?


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.
Click to expand...
I always implemented finite state machines in software on microprocessors.
 
On Thu, 13 May 2004, pdx wrote:

Also, why would the examiner provide AcceptCoins *and* RejectCoins since
they should effectively always be the opposite of each other?
Click to expand...
No.

-Peter
 
"pdx" <pdx@spamtrap.com> schreef in bericht
news:2gi5l5F36627U1@uni-berlin.de...
"Frank Bemelman" <f.bemelmanx@planet.invalid.nl> wrote in message
news:40a3da02$0$194$c3e8da3@news.astraweb.com...
"pdx" <pdx@spamtrap.com> schreef in bericht
news:2gi0toF30judU1@uni-berlin.de...
"Rene Tschaggelar" <none@none.net> wrote in message
news:40a3cb19$0$705$5402220f@news.sunrise.ch...
pdx wrote:

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.

"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?

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.
Click to expand...
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.


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)
 
"Richard Henry" <rphenry@home.com> schreef in bericht
news:yqRoc.29065$fE.19074@fed1read02...
"Del Cecchi" <cecchinospam@us.ibm.com> wrote in message
news:2gi5u4F359r3U1@uni-berlin.de...

"pdx" <pdx@spamtrap.com> wrote in message
news:2ghvjqF3429bU1@uni-berlin.de...
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?


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.
Click to expand...
A microprocessor *is* a finite state machine, no matter what software
you load it with.


--
Thanks, Frank.
(remove 'x' and 'invalid' when replying by email)
 
"Frank Bemelman" <f.bemelmanx@planet.invalid.nl> wrote in message
news:40a3eac3$0$201$c3e8da3@news.astraweb.com...
"pdx" <pdx@spamtrap.com> schreef in bericht
news:2gi5l5F36627U1@uni-berlin.de...
"Frank Bemelman" <f.bemelmanx@planet.invalid.nl> wrote in message
news:40a3da02$0$194$c3e8da3@news.astraweb.com...
"pdx" <pdx@spamtrap.com> schreef in bericht
news:2gi0toF30judU1@uni-berlin.de...
"Rene Tschaggelar" <none@none.net> wrote in message
news:40a3cb19$0$705$5402220f@news.sunrise.ch...
pdx wrote:

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.

"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?

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.

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 ;)
Click to expand...
LOL.

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.
Click to expand...
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.
 
Andrew <ajhuk@hotmail.com> says...

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
Click to expand...
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>


--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
have an "impossible" engineering project that only someone like
Doc Brown can solve? My resume is at http://www.guymacon.com/
 
Frank Bemelman wrote:

A microprocessor *is* a finite state machine, no matter what software
you load it with.
Click to expand...
Alan Turing, "On Computable Numbers with an application to the
Entscheidungsproblem," 1936 ?

Steve
 
"pdx" <pdx@spamtrap.com> wrote:

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 "C" being an event?

Also, why would the examiner provide AcceptCoins *and* RejectCoins since
they should effectively always be the opposite of each other?
Click to expand...
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
--
"It's not the things you don't know what gets you into trouble.
"It's the things you do know that just ain't so."
-- Will Rogers
 
pdx wrote to someone else:
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.
Click to expand...
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
 
Richard Henry <rphenry@home.com> says...
"Del Cecchi" <cecchinospam@us.ibm.com> wrote...

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.
Click to expand...
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.


--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
have an "impossible" engineering project that only someone like
Doc Brown can solve? My resume is at http://www.guymacon.com/
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top