Showing results for 
Search instead for 
Did you mean: 

indicator doesn't light up

Go to solution



B: We wait for the signal to be acquired.


C. We collect data from channel 1


D. We collect data from channel 3 and turn of the trigger ready indicator.


The problem is the 50 ms Wait in frame A. Without that wait, the trigger ready light doesn't turn on.

0 Kudos
Message 1 of 11

Would it have been that hard to at least post an image (better is the VI)? My guess is a race condition.

0 Kudos
Message 2 of 11

Half of my message was lost. This is LabVIEW 2010 SP1.


Someones home but the light isn't on.


In frame A, we ready the scope for data acquisition and turn on the "Trigger Ready" light (boolean).

In frame B, we wait for the signal to be acquired.

In frame C, we download the data from channel 1.

In frame D, we download the data from channel 3 and turn off the data acquisiton light.


The problem is in frame A. Without that 50ms wait, the Trigger Ready boolean never turned on. If this is indeed a race condition, then are you saying that the frames are superfluous?

0 Kudos
Message 3 of 11

How long is the indicator on with the 50ms delay?  Have you timed how fast it takes the code to run?  If the code executes quickly enough, it is possible that you simply cannot see the flash occur as it is turned on and off too quickly.

0 Kudos
Message 4 of 11

And yes, a sequence structure is almost always superfluous. For that matter, I'm not sure the In Place structure is doing you any good either.

0 Kudos
Message 5 of 11

Hey oyester,

I agree with what Dennis and Matthew have said that without the wait the code is probably being executed too fast for you to notice the change in indicator value.  How long are you expecting your data aquisition from the scope to take? Longer than 50ms?  The in place element structure does seem to be superfluous in this situation. Your sequence structure in this case also seems mostly superfluous.  The errors wires between your blocks will ensure dataflow for your code.  The one place you may want it is to make sure the delay occurs after the light is turned on.  Please post back if you have any additional questions. 

Kevin Fort
Principal Software Engineer
0 Kudos
Message 6 of 11

No. Step B takes several seconds to run. It is waiting for a technician to perform an experiment that that will send a signal to the scope. Once the signal gets to the scope, the trigger event happens and the program moves on. The light is supposed to indicate on the computer that the scope is waiting. This snippet is inside of JK's state machine and the in-place is there because the attached cluster is very big. I put in the sequence structure because I thought that the boolean would be set in frame A and not unset until frame D. 

0 Kudos
Message 7 of 11

Have you tried viewing the data flow with highlight execution, probe tool?  Are you getting any errors?  Use an error cluster indicator at the end of the chain if are not already.

Reese, (former CLAD, future CLD)

Some people call me the Space Cowboy!
Some call me the gangster of love.
Some people call me MoReese!
...I'm right here baby, right here, right here, right here at home
0 Kudos
Message 8 of 11

Are there any other local variables for the indicator anywhere else in your program? (Right click/Find/Locals Variables)


Do you see the LED blink at all? Does the code work but just not turn on the LED?


Here is something dumb. Right click the LED indicator and select Find/Terminal and see if it goes to the terminal your frame A. It is possible to have two controls or indicators with the same name. Something that should cause a broken run arrow but would break a lot of code. It is possible that you are writing to a different indicator that is hidden.

LabVIEW 2012

0 Kudos
Message 9 of 11
Accepted by topic author oyester

It could be a compiler issue.  The way you have it written, moving the update of the indicator to outside of the sequence structure would mimic the same behavior you have now.  You can also make a new frame between A and B where you update the indicator, which is technically more correct because the trigger is not ready until have the config.  It should probably be in frame B, but you may see the same issue.


You could also try swapping the local and terminal to see if it makes any difference.  But 50ms is such a non-noticable thing, it's probably not worth the trouble.


I forgot which LV version it was (probably LV 7 or 7.1), a colleauge asked me to look at some code that wasn't working.  A for loop wasn't putting out the expected value.  I dumped a 1ms delay in the loop and the loop functioned properly.  Sometimes, the compiler does some wierd things.

0 Kudos
Message 10 of 11