01-05-2015 07:30 PM
Yeah I have it inside the While of the Statemachine and outside the Case of said Statemachine, sorry if I was unclear.
Added a picture for clarification.
01-05-2015 08:58 PM
Several things:
1) You're coding in multiple directions. Break that habit. It makes your code harder to read and you'll regret it when trying to debug later. Inputs to a loop come from the left. Outputs go to the right.
2) If you're using a while loop inside of a state, you probably want to re-think your state machine. You're locking yourself into that while loop and consequently the state. If you use logic to leave the loop, you can use that same boolean with a select to output the same state so your handling loop knows to increase the temp further if there aren't any other inputs that hsould override the behavior.
3) A shift register is read like any other output to a while loop. It will be updated within the loop on each iteration, but it won't be read externally until the loop finishes. That's why you're not seeing it update. When they said shift register, they meant the while loop encompassing the entire state machine rather than a loop within a state.
4) You COULD use the local variable here. But, doing so empowers you to use a poor state machine architecture. In addition to the reasons Jacobson listed, this is another reason you want to avoid it. Just because you CAN hammer a screw in doesn't mean you SHOULD hammer a screw in. You're using the option because you can rather than because you should. You should fix your architecture to something that matches the idea of a state machine better. What do you do if the user hits a stop button midway through the temp increasing? Do you want the machine to stop immediately or to continue working towards that?
01-06-2015 05:50 AM
Thanks for all the feedback!
@natasftw wrote:
If you use logic to leave the loop, you can use that same boolean with a select to output the same state so your handling loop knows to increase the temp further if there aren't any other inputs that hsould override the behavior.
I don't really get what you exactly mean or how I should implement it. I mean, wouldn't using logic to leave the loop mean that I have to break it (stop it from running)?
Considering to just leave this be for the moment until I have a broader understanding of Labview since it seems so much more complicated to implement this correctly as I thought and I am spending quite some time on this.
01-06-2015 05:53 AM
@natasftw wrote:
2) If you're using a while loop inside of a state, you probably want to re-think your state machine. You're locking yourself into that while loop and consequently the state. If you use logic to leave the loop, you can use that same boolean with a select to output the same state so your handling loop knows to increase the temp further if there aren't any other inputs that hsould override the behavior.
Agree completely. This will also force you to use a shift register on the outer loop to keep track of the temperature. I would actually use two different states here: increment and check if done. So the check if done state will call the increment state if you haven't reached your limit yet, otherwise it will move on to the next thing. It might be a good idea to allow of checking for user events in that sequence as well. You could also hold in a shift register how much it is to go up. This way you can use these two states unchanged no matter how much you need the temperature to go up.
01-06-2015 05:56 AM
TheAlPaca wrote:Considering to just leave this be for the moment until I have a broader understanding of Labview since it seems so much more complicated to implement this correctly as I thought and I am spending quite some time on this.
When it comes to state machines, the very first thing you should do is create a state diagram. Visio tends to work well for doing this. But this diagram will help you so much when you try to actually implement it.
01-06-2015 06:04 AM
@crossrulz wrote:
Agree completely. This will also force you to use a shift register on the outer loop to keep track of the temperature. I would actually use two different states here: increment and check if done. So the check if done state will call the increment state if you haven't reached your limit yet, otherwise it will move on to the next thing. It might be a good idea to allow of checking for user events in that sequence as well. You could also hold in a shift register how much it is to go up. This way you can use these two states unchanged no matter how much you need the temperature to go up.
Ah I think I get it now, I'll give this a go and will report back.
Sorry for being such a hand full.
01-06-2015 07:24 AM
@TheAlPaca wrote:
Sorry for being such a hand full.
You think you are being a hard full? Trust me, you are far from the worst person we have helped (or at least tried to help) on here. Just keep asking questions. Things will sink in eventually.
01-06-2015 07:32 AM
Solved it! I really don't get why I made it so hard for myself, this way is so much simpler.
Did not even need the extra state to check for the thermometer's completion.
Picture in attachment for clarification.
Thanks for all the patience everyone! Learned alot, bunch of heroes you are! 🙂
01-06-2015 08:08 AM
@TheAlPaca wrote:
Sorry for being such a hand full.
Having a desire to learn is rarely a handful. The handfuls are the folks that come here expecting their code to be written for them and then complain when it isn't. You're more of an ideal poster.
I noticed on the most recent picture your temperature wire goes under the case structure so you can't see it being wired to the output tunnel. This is another habit that will drive you crazy later during debugging. When debugging, it's always easier to see exactly where each wire is going. When your code is working, it's purely cosmetic. When the code isn't working, it's a nightmare. For your benefit later, you'll want to avoid those nightmares 😃
01-06-2015 08:15 AM
Ah yeah I see what you mean, fixed!
Thanks for the heads up!