From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with subVI input data not updating

I have one program(state machine) which is calling a bunch of subVIs but the problem is input to the subVIs data are not updated (front panels of subVIs are not opened). Unit testing for all subVIs are ok and when I run the main VI with all subVIs opening front panel, they seems to be fine. Actually, some subVIs are working fine without opening front panel but some are not. I need to compile all those into one exe program.

Please help me.
0 Kudos
Message 1 of 9
(2,980 Views)
Your description is a bit confusing.


m_min wrote:
... but the problem is input to the subVIs data are not updated (front panels of subVIs are not opened).
Updating a front panel is not the same as opening a front panel of a subVI. Do the subVIs return the correct data or are you just worried about the values on their front panel.
If the subVI does not open it's front panel, it does not need to update the controls, because that would just be a waste of resources..


m_min wrote:
Unit testing for all subVIs are ok and when I run the main VI with all subVIs opening front panel, they seems to be fine. Actually, some subVIs are working fine without opening front panel but some are not.
Could you be a bit more specific on what you mean by "OK" and "fine". These are not well defined debugging terms.


m_min wrote:
I need to compile all those into one exe program.

In what way is this related to the above problems? VIs are always compiled. Do you mean you want to built them into an executable? Do you have the application builder?
 
 
How are the subVIs configured, e.g. the windows appearance settings? How is the subVI node setup? What are the execution settings (for example subVIs set to subroutine priority will not update their front panel). What do the subVIs do? What is the difference between the ones that are fine an those that are not?. Is anything set to reentrant?
 
I think it would really help if you could attach some of your code, e.g. a simplified example that still shows the problem. Tell us how to run it and what to look out for. What do you expect and what do you observe instead?
 
What is your LabVIEW version?
0 Kudos
Message 2 of 9
(2,971 Views)
Dear

Sorry about the confusion...

I have to open the subVIs in order to work with main VI. If I do not open the subVIs, they don't get the "input values" which are transferred from main VI and in this case, they don't return the correct output and program kind of stuck.

Some VIs doesn't have that problem.
0 Kudos
Message 3 of 9
(2,966 Views)
My LabVIEW version is 8.2.1. I have developer version so i think i can build exe file.

All the VIs are normal priority with no re-entrant VIs involved. SubVIs' windows appearance configs are normal(default) and their priorities are normal. SubVI nodes are setup with Input/output terminals. SubVIs which works fine are doing various functions i.e. polling data (using serial port) from loggers and some support functions. The problematic subVIs do the text processing, i.e. extract the downloaded raw text report into meaningful data arrays. What i mean by unit testing ok is that if i enter the input manually, that subVI is working fine.

If I open those problematic subVIs and run the main VI. They works fine. So i thought it has something to do with opening the subVIs or not.
0 Kudos
Message 4 of 9
(2,964 Views)
I cannot create the problematic situation in test vi as the actual main VI is kinda complicated to get the input values for subVI.

I have tst upper one level main VI for that subVI and thy work fine so i guess the problem is in transportation of variables or so ..
0 Kudos
Message 5 of 9
(2,955 Views)
I kinda of sorted this problem.

All I have to do is ... go to that problematic VI properties => windows appearance => Custom => and check these 3 checkboxes...  (1) Show front panel when called (2) Close afterwards if originally closed (3) show front panel when loaded ....

i think setting transparency to 100% would make the vi invisible if you don't want the user to see that vi.

gosh.. i spent 2 days on that....
                                                                                    
0 Kudos
Message 6 of 9
(2,932 Views)
Do you use VI Server to start the VI's?

In that case, the executable builder removes the front panels by default. So
you'll have to edit the executable settings, so each dynamically called VI's
front panel isn't removed. You can also do this by setting the VI property
open when called, but this property doesn't open the front panel if the VI
is started dynamically.

Regards,

Wiebe.




0 Kudos
Message 7 of 9
(2,930 Views)
That is just silly.


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


m_min wrote:
All I have to do is ... go to that problematic VI properties => windows appearance => Custom => and check these 3 checkboxes...  (1) Show front panel when called (2) Close afterwards if originally closed (3) show front panel when loaded ....

If the front panel visibility changes the output of a subVI, something is terribly wrong and we better try to find the cause instead of  doing weird workarounds such as fullt transparet panels or maving the panel coordinates to offscreen.
 
Could it be that you have some of the inputs miswired?
 
If you don't want to post the VIs here, submit them to somebody at NI or e-mail them to me privately. (use my forum name at gmail dot com).
0 Kudos
Message 9 of 9
(2,905 Views)