Updating 1 indicator in different states

[TheAlPaca]

Hey all,

I am doing a little exercise that is supposed to simulate the workings of a senseo coffee machine (very minimalisticly).
Everything is running in a state machine and the problem I am having is with updating the Thermometer.

I wanted to make it update in real time using steps of 2 degrees instead of just having to wait without feedback untill it shoots from 0 to 100. This also means that I had to place the Thermometer inside a while loop in my state machine. I need to call the thermometer in two different states, one state to make one cup of coffee and one state to make two cups.
But since I am calling the Thermometer inside the state it always creates a separate indicator in every state.

What I want to achieve is have both states express their temperatures on the same thermometer since they can't be active at the same time anyway.

Has anyone got a clue to how to achieve this? I can't seem to figure it out 😕

Thanks in Advance,

Michiel

[crossrulz]

Need to update a single indicator in two different states of your state machine?  Sounds like a perfect place for a local variable. *now ducking for cover*

[Dennis_Knutson]

Or move the indicator outside of the loop and use a shift register.

[TheAlPaca]

Thanks! I did not work with variables before and this perfectly solved my problem, very usefull!

[Jacobson-ni]

---

@crossrulz wrote:

Need to update a single indicator in two different states of your state machine?  Sounds like a perfect place for a local variable. *now ducking for cover*

---

LabVIEW Police, did somebody mention using local variables in this thread?

On a more serious note, If you are just doing this as an exercise I would recommend also trying to do this with shift registers as Dennis suggested. Understanding how to do this type of task with shift registers will be very useful if you start developing larger applications.

[TheAlPaca]

Whats so bad about using Local variables then? Seems to work just fine for me!
Giving shift registers a look now.

[Jacobson-ni]

Alpaca,

For the most part, overusing local variables can slow performance and cause race conditions.  As your applications get larger the performance loss becomes more noticable and race conditions become more likely. You can get some more detailed information in link below.

http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/using_local_and_global/

Local variables get a bad rap on the forums (I had to give Crossrulz a hard time when he posts *now ducking for cover*), they definitely have their uses but I tend to side with the LabVIEW Style Guide by saying "Use Sparingly" for the above reasons.

[TheAlPaca]

Ah yeah that makes sense, thanks for the insight!

I'm trying to figure out a way to make this work with Shift Registers in the same way as it worked with local variables but I am experiencing the same problem as before. My values aren't updating in real time. When executing in highlighted mode I noticed that the while loop is not passing any data to the outside untill it has finished running.

I have found some stuff about producer/consumer loops to do this but this looks kind of complicated, is there any easier way to pull the value after each iteration?

Thanks.

[Dennis_Knutson]

You don't place the indicator outside the while loop. It is outside the case structure that is your state machine.

[crossrulz]

---

TheAlPaca wrote:

I have found some stuff about producer/consumer loops to do this but this looks kind of complicated, is there any easier way to pull the value after each iteration?

---

Your terminal needs to be INSIDE of your state machine loop (but outside of the case structure).  And then each case needs to do something with the value.  A large number of them will just pass the value through.  The two states that actually do something with the value can just update it.

Style guide wise, yes you should be using the shift register.  But in reality: you have no chance of a race condition since you are only updating an indicator and only in two states that cannot be ran at the same time.  This, in my honest opinion, is an acceptable place to use a local variable.  Though, I'm still a little upset about losing that point on my CLD (yes, I did exactly what I am suggesting and I lost a point on my CLD simply because local variables are "against style rules").  Now, if you have a large number of states updating that indicator, then I would go with the shift register (the locals would be causing a lot of unnecessary data copies).