LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Beginner question re: case structures

Solved!
Go to solution

Uuhhhhh yeah I don't know I put that select function in there. It obvipusly wasn't doing anything. Thanks for the heads up!

Any tips on how to start integrating the simple code I have into a state machine?

 

Thanks,

 

George

0 Kudos
Message 21 of 37
(1,588 Views)

Ok, so after a fresh look at things, I think I am getting closer. I have tried the case structures once again. I am at the point where I have no broken wires, but the VI is still not functioning as I expect it would.

 

It doesn't seem to be going to the "Waiting" state after taking the money, and vending the soda.

 

I know I have something wired up wrong, but don't know what.

 

Thanks as always,

 

George

0 Kudos
Message 22 of 37
(1,563 Views)

You need to attach the type definition. Also try to avoid overlapping wires because it can leat to errors that are hard to detect.

 

  • Obviously, you need to remain in the take money state until there is enough money.
  • Similarly, you need to stay in the dispense state until an item has been dispensed.
  • you don't need the select node in the "give change" state, the change will be zero if the entered amount is correct.
  • the "select soda" led belongs outside the case structure.
  • Implement the power off state that returns change in any is left before shutting down.
  • It never stays more than 100ms in the waiting state because it will alway continue to the take money state. Isn't that what you want? (taking money until there is enough and waiting seems to be the same thing, more or less.)
  • etc. ...
0 Kudos
Message 23 of 37
(1,555 Views)

Hi altenbach,

 

Thanks again for taking the time to help me. Sorry for forgetting to attch the type def. I will attach it here.

 

Yes staying in the money state, and then the dispense state (which to me could almost be the same state?) untill the proper amount is added is important. One of the criteria was that the user should have the option to put in more than enough money, and then receive change. That being the case, wouldn't I still need the code to calculate & dispense the change?

 

What is the difference if the select soda LED stays in or out of the case structure? Is it causing something I don't want while remaining inside?

 

The power off state is another thing that I'm not even quite sure I'd need. Can I just leave the button in all of the other states, and not create a seperate state for it? I'm thinking that in real life, someone buying a soda wouldn't shut the machine off.

 

I want the machine to go back to the take money state, after the vend & change return state. What I really want as a result is that you can't make another selection before putting more money in (which means that when switching states, the $$ entered would be reset by the state change), and also the change returned should be reset to zero at the same time.

 

I hope I am making sense with all of this. I feel like I am close, but the last bits seem the hardest for me to grasp.

 

Again, thank you very much for your time.

 

George

 

0 Kudos
Message 24 of 37
(1,542 Views)

@gsrokmix wrote:

wouldn't I still need the code to calculate & dispense the change?


Yes, but the amount is automatically zero of the amount is correct. Only the subtraction is important, the select node is no needed.

 


gsrokmix wrote: 

What is the difference if the select soda LED stays in or out of the case structure? Is it causing something I don't want while remaining inside? 


If you stay in the add money state until there is enough money, the LED will only ever see a TRUE. If it is outside, it will reset to FALSE later once the condition is no longer met.

 


@gsrokmix wrote:

 

 

The power off state is another thing that I'm not even quite sure I'd need. Can I just leave the button in all of the other states, and not create a seperate state for it? I'm thinking that in real life, someone buying a soda wouldn't shut the machine off.

 

I want the machine to go back to the take money state, after the vend & change return state. What I really want as a result is that you can't make another selection before putting more money in (which means that when switching states, the $$ entered would be reset by the state change), and also the change returned should be reset to zero at the same time.


The money should only reset to zero after a bottle is dispensed and change is returned.

 

You need a power off state for cleanup. For example if there is money left (e.g. if not enough money has ever been entered), that should be returned when shutting off.

 

0 Kudos
Message 25 of 37
(1,534 Views)

Hi George,

I’m going to go against the crowd here, so feel free to ignore this post.

I believe that using an Event Structure will make this application more flexible and user friendly.
Don’t get me wrong, traditional State Machines are great, I use them all the time, but not to solve every problem.

Looking at your latest code:

What happens if the user realizes after inserting his money, that he only has $1.45? Can he get his money back? (He could if you added a check case on the stop button, but that starts to get ugly. Plus how does that relate to the real world – do you have to unplug the machine to get your money?)

What if I want to buy 2 cokes? I put in two dollars, get 1 coke, the machine spits out 50 cents, and then I have to put that back in and add another dollar. Wouldn’t it be better/more realistic if I could put in 3 dollars and just get my 2 cokes?

My point is that you can get locked into “states”. The Event Structure allows us to program the way the real world operates.

My suggestion:

- Use an Event Structure (They really aren’t that difficult – think of them as fancy cases)
- A shift register keeps track of the money deposited (at any time)
- Enable the buy buttons when there is enough money – disable when there is not enough
- Have a Return/Change button to get your change at any time

In the attached example, I put your “money” code in an Event Structure.
The only extra things added are: Initializing the Money, a Stop button, and comments.
You could add two Event cases and the associated logic and be about done.

steve

 

----------------------------------------------------------------------------------------------------------------
Founding (and only) member of AUITA - the Anti UI Thread Association.
----------------------------------------------------------------------------------------------------------------
0 Kudos
Message 26 of 37
(1,501 Views)

Hi altenbach,

 

Thanks for your responses. I will se if I can make your suggestiions work.

 

George

0 Kudos
Message 27 of 37
(1,477 Views)

Hi Steve,

 

Thanks for taking the time to repsond, and upload some code. I will take a look at what you've done, and your suggestions, and see if I can make sense out of them.

 

Thanks again,

 

George

0 Kudos
Message 28 of 37
(1,476 Views)

@stevem181 wrote:

I’m going to go against the crowd here, so feel free to ignore this post.


I don't think anyone discouraged the use of an event structure, we just did not want to overload the beginner programmer with additional concepts. 😄

0 Kudos
Message 29 of 37
(1,459 Views)

@altenbach wrote:

@stevem181 wrote:

I’m going to go against the crowd here, so feel free to ignore this post.


I don't think anyone discouraged the use of an event structure, we just did not want to overload the beginner programmer with additional concepts. 😄


Actually I kind of did as I can't say I have ever found a real use for event structures. I have tried them out hear and there, but I guess they just never clicked with me.

 

To me they brake the dataflow paradigm so I tend to tell new programmers to avoid them

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 30 of 37
(1,446 Views)