10-24-2016 02:08 PM
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
10-24-2016 03:49 PM - edited 10-24-2016 03:49 PM
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
10-24-2016 04:03 PM - edited 10-24-2016 04:08 PM
You need to attach the type definition. Also try to avoid overlapping wires because it can leat to errors that are hard to detect.
10-24-2016 04:41 PM
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
10-24-2016 05:04 PM
@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.
10-25-2016 08:30 AM
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
10-25-2016 01:37 PM
Hi altenbach,
Thanks for your responses. I will se if I can make your suggestiions work.
George
10-25-2016 01:39 PM
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
10-25-2016 03:21 PM
@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. 😄
10-25-2016 04:44 PM - edited 10-25-2016 04:45 PM
@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