Labview SubVI's LED communication with the main VI problem

[argonst]

I am relatively new with labview and I am coming across a problem when using Subvi's and a main VI. The problem that I am having is whenever any LED on my Subvi program is supposed to turn on or go high the LED that is connected to it in the main VI doesn't respond. I am just doing a simple VI and a subvi communication where in the main VI is a normal LED connected to another normal LED in the Subvi. Does anyone know why the main VI LED doesn't respond and if so what would I have to do to fix this problem?
Thanks,
Jason

[Ali84]

Have you checked that the terminal in the SubVi connector is correct? That is, make sure your output is the LED that whose signal you want to send to the main VI (the terminal should be green and thick lined). Maybe if you send the programa and subprogram.

Also, you may want to check that you LED in ther subvi is indeed turning on at the momento you want it to.

Cheers.

[argonst]

Ali84 I am certain that the data being sent out of the connector is an output and I do know that the LED in the SubVI turns on. That was one of the first things that I checked. A thing that I forgot to mention is the testing is done inside a case statement, so the LED high or low is being sent out of a case statement in the SubVI. The main VI is in a while loop receiving the information. I do notice that if the switch is still on and not controlled that the LED will turn on in the Main VI. The problem lies when i want it to be timed or a quick turn on and off switch.

[Marc_A]

I suspect this is a simple dataflow problem where you're trying to change values in a subvi and have them affect the main vi while the sub vi is still running. However, I can't be sure without seeing the code. Could you post the 2 vis?

[Dennis_Knutson]

You have the main LED indicator outside the case statement? If so, what is in the other case? If it's nothing and if you've selected 'Use Default' on the exit tunnel of the case statement, your indicator will go false immediately when you change cases. The default value when exiting a case statement is false. One simple fix might be to simply move the indicator inside the case statement. You could also post the main and subVI to see what is actually being done.

[argonst]

Dennis,
I tried what you mentioned and that didn't work. I must not be doing something right or understand how this all works. I have attached the files. They are just example VI's of what I want to do. The LED inside the case is what I am aiming to turn high on the main VI when the Subvi does.

[argonst]

Sorry about that I forgot to save one of the files. Here is the actual zip file.

[Dennis_Knutson]

Since there is code in the false case, you should have left the indicator outside the case statement. I moved it to where it should be an corrected the connector pane. Convention says that outputs should use the right side of the connector pane. The VI and subVI work as expected. Setting Boolean 4 to True and running the VI returns a True after a 5 second delay. Setting Boolean 4 to False returns a False immediately.

[argonst]

Dennis,
Thanks for the reply and that did work. I did make a mistake and I am glad that you noticed it. The LED is supposed to be in the case statement, but there isn't supposed to be any false statement information. I guess I forgot that I changed a few things around and left it there. Would there still be a solution if the false statement info was deleted and the LED was put back in the case?

[Dennis_Knutson]

There's always a solution.

I don't have a good understanding of what you are ultimately trying to do. The subVI you wrote as an example is a bit 'silly' and if you have a blank false case, I'm not sure I understand the reasoning to have a case statement at all. You could probably accomplish what you want by having a case statement in the main VI and just calling the subVI when the front panel control goes true. With your existing code, the subVI is being constantly called no matter what the state of the front panel control is. That's just wasting cpu cycles.