LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI will not execute from caller VI

Hello,

 

I've encountered an issue for which I can't seem to find a solution. I have a VI which builds debug commands based on a bunch of selectors. I had it working for a long time, but I recently added the option to build varying commands for communicating with multiple DUTs at once. Some commands for example require writing a string unique to each DUT, which ultimately requires a for loop. The loop should iterate for N cycles where N is the number of COM ports listed in the port array, and the unique strings are indexed on each iteration of the loop.

 

The VI executes just fine on its own (from its front panel), but when I call the VI from my higher level VI it seems to be bypassed without executing at all.

 

Essentially, when I probe the inputs of the problematic VI there is only the "not executed" message in the probe watch window. I then watch my main test interface (This would be the highest level VI in the structure) proceed to the next stage of the test, where I acquire data from a DAQ. At that point I can't proceed, because all of the setup I needed to be configured prior to testing was just skipped for no explicable reason.

 

Snapshot of my probe watch window from both perspectives. COM8 goes in... then nothing. I don't even see the front panel execute like it normally would. I tried recompiling the VI to no avail. 

 

abenevides_0-1656717853916.png

abenevides_1-1656717939192.png

 

 

0 Kudos
Message 1 of 9
(1,074 Views)

Interestingly, placing a breakpoint inside the problem VI "fixes" the issue. Of course I can't keep the breakpoint in there, and removing it allowed the problem to return.

0 Kudos
Message 2 of 9
(1,070 Views)

Additionally, if I place a breakpoint on the Sub-VIs icon it also functions as expected after clicking the continue button. It's like the breakpoint is reminding the VI that this Sub-VI exists... Really scratching my head here.

0 Kudos
Message 3 of 9
(1,056 Views)
You might have set the execution options to prealicate clones.

"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 9
(1,053 Views)

Check the vi properties for execution before head scratching removes hair.


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 9
(1,051 Views)

So I believe I am getting to the heart of the issue. It seems to be a timing issue.

 

Originally, I had a wait timer with a zero wired to it on the consumer loop which contained the "problem" sub-vi.

 

I increased the wait period to 100ms and it now works like a charm. Interesting that I didn't have this issue before. I typically wire all of my loops up with a 0 timer and don't encounter any weird problems.

 

I really don't want to keep a 100ms delay every time I execute this loop. Test time is critical in my application and arbitrarily adding delays is something that drives me crazy. I want to just run the software as fast as possible without burning the CPU.

0 Kudos
Message 6 of 9
(1,049 Views)

I will give it a try. thank you for the suggestion.

0 Kudos
Message 7 of 9
(1,048 Views)

Both VIs are set to non-reentrant.

0 Kudos
Message 8 of 9
(1,047 Views)

should attach the code instead of the screenshot, it is one vi/zip instead of 2 jpgs

 

may be a flow problem, if you have tested having a breakpoint can solve the problem, it hints that that section need some flow control. but without the code, cannot really give any useful comments

CY (expired CLAD)
0 Kudos
Message 9 of 9
(1,042 Views)