LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

string indicator not updating until program stops running

Solved!
Go to solution

Hello,

I have a little problem here.

Why is the string not updating until the correct guess is found? I keep on guessing and pressing the ok button, however whenever I press the ok button, the string doesn't update saying it's too low or too high, and only shows correct guess when the program stops.

please find attached the VI.

 

Here's the problem statement:

 

Write a LabVIEW program that will randomly generate an integer in the range 1 to 10, and guides you in correctly guessing the integer. When the VI is running, the user will type his/her guessed integer into the Guess control and then click on the OK Button labeled Enter Guess. The program should display a feedback about the guess (e.g. too low, too high, correct) in the Message indicator.
The program keeps running until the user guesses the number.

0 Kudos
Message 1 of 9
(2,746 Views)
Solution
Accepted by topic author daniel1313

Hi Daniel

 

As you have no timing function of any sort your loop is running as fast as possible. This means that when you press ok it does correctly write your message to the string indicator but it is immediately overwritten by the main false case.

 

I suggest using the Highlight Execution feature, shown below, to better understand what is going on in your code.

Niatross_0-1582385506464.png

You can keep your current code structure but instead of writing a empty string constant to the indicator either retain the previous value in a shift register or only write to the indicator in your main true case. If you do this I suggest you put a wait function in your loop to prevent maxing out your CPU.

 

A better method would be to use an event structure to register when the ok button has been pressed

 

Message 2 of 9
(2,735 Views)
Solution
Accepted by topic author daniel1313

I'd also suggest using an Event Structure for this (responding to a button click).

Place the string calculation inside the Event Structure and the indicator outside.

 

If you use Select nodes (you'd need two) you can remove all case structures.


GCentral
Message 3 of 9
(2,729 Views)

I realised that from previous answers, however I shouldn't use structures that we didn't covered yet. 

Thank you.

0 Kudos
Message 4 of 9
(2,704 Views)

Thank you. I will avoid using however the event structure.

0 Kudos
Message 5 of 9
(2,702 Views)
Solution
Accepted by topic author daniel1313

@daniel1313 wrote:

I realised that from previous answers, however I shouldn't use structures that we didn't covered yet. 

Thank you.


Fair enough. I will note you could at least remove the nested structures if you subtract the target value from the guess, and then wire the result to the selector in the case structure.

By using case selector values "..-1", "0" and "1.." you'll be able to handle the 3 cases and output a suitable string value (and boolean for the termination condition).

 

You'll still need to handle the case where you don't click "OK" or "Guess" or whatever though - use a Shift Register, or place the indicator inside a second (outer) Case Structure as was originally suggested.


GCentral
Message 6 of 9
(2,696 Views)

@cbutcher wrote:
By using case selector values "..-1", "0" and "1.." you'll be able to handle the 3 cases and output a suitable string value.

Or do a +1 on the result and use it to index into an array of strings. No case structure needed. 😉

Message 7 of 9
(2,639 Views)

I ended up using shift registers, and it worked. I might try modifying the nested case structures or replace them with one major case structure with case selector values, however I submitted the file with these nested structures. Is it a major problem in that case? 

0 Kudos
Message 8 of 9
(2,610 Views)

@daniel1313 wrote:

I ended up using shift registers, and it worked. I might try modifying the nested case structures or replace them with one major case structure with case selector values, however I submitted the file with these nested structures. Is it a major problem in that case? 


If it works, it probably isn't a major problem in general 🙂

 

The suggestions we made are largely to reduce the amount of "hidden" code (because you can't see all of a Case Structure at once, only one of the cases) or to reduce the number of operations.

In some cases it can be easier to follow code if there are fewer operations, but you should be careful to avoid "clever" code that is less easy to understand - this might be frustrating for others reading your code (or you, in 6 months time when you come back to read it and have forgotten why you did something "clever"). Whether or not indexing an array of strings based on the difference between a guess and a target value, +1, is "too clever" is up to you (and perhaps any colleagues who might read it). I thought it was clever in a good way, but YMMV.

 

In general, altenbach's suggestions on the forum are often also efficient in terms of memory usage or CPU requirements, although in this case probably you'll never have a problem with either.


GCentral
0 Kudos
Message 9 of 9
(2,601 Views)