LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW: VI called by Invoke Node does not fulfill all loop iterations

Solved!
Go to solution

Hello,

 

I'm working on a Labview project, where I have a "main VI" calling a "SubVI" by using the Invoke Node function. 

(I isolated the problem to make it easier. See ziped code below.)

The mainVI calls the SubVI which is a loop with 5 iterations. To see if all iterations were done I am writing to a txt file.

 

All is working how it should work if I have opened the Front Panel of the sub VI that I am going to call. 

But if I don’t open it and delete the created txt file, my subVI is leaving its loop mostly at the first iteration and doesn’t leave the loop where it should. If I repeat it often enough it happens also sometimes that all iterations are fulfilled. If I don’t delete the txt between the executions and only close the front panel of my subVI, it mostly fulfills all iterations if it had already worked before.

And I don’t know why it is executing in different ways...

 

Thanks for any help 🙂

 

(I am using LabVIEW 2014 with Windows 7)

0 Kudos
Message 1 of 10
(2,574 Views)

Seems to work fine here. (After adjusting the paths to the new hierarchy).

Since the number of iterations is known before the loop starts, why is it not a FOR loop?

0 Kudos
Message 2 of 10
(2,563 Views)

At first thank you for your fast answer!

Did you deleted the txt file for the calling with the closed front panel? Because then I only get the first iteration...

And what do you mean by adjusting the path to the new hiewarchy?

 

Of cause you can also use a FOR loop. But I isolated this case from a more complex VI where I need a while loop.

0 Kudos
Message 3 of 10
(2,560 Views)

@annikas wrote:

 

And what do you mean by adjusting the path to the new hiewarchy?

 


You do a lot of path manipulations (strip/build) to form the subVI path, while currently all VIs are in the same folder.

0 Kudos
Message 4 of 10
(2,556 Views)

@annikas wrote:

Did you deleted the txt file for the calling with the closed front panel? Because then I only get the first iteration...

 


OK, just tried again over 10 times with the subVI closed and the output file deleted every time. Always get all lines. (This is LabVIEW 2018, sorry cannot test in your native version)

 

Have you tried a forced recompile (ctrl+shift+run arrow button)

0 Kudos
Message 5 of 10
(2,528 Views)

OK, I was able to reproduce it after all. It does not seem to happen if you don't close the reference after the invoke node, so maybe you are pulling the carpet out from underneath it. Since both things occur in parallel, the outcome is not predictable and it might succeed sometimes.

 

Note that if the front panel is open, it behaves differently (point #2 below).

 

Details here:

When you create a refnum to a VI, LabVIEW loads the VI into memory. The VI stays in memory until you close the refnum and until the VI meets the following conditions:

  • There are no other open references to the referenced VI.
  • The front panel of the VI is not open.
  • The VI is not a subVI of another VI in memory.
  • The VI is not a member of an open project library.
0 Kudos
Message 6 of 10
(2,526 Views)
Solution
Accepted by annikas

 


@altenbach wrote:

OK, I was able to reproduce it after all. It does not seem to happen if you don't close the reference after the invoke node, so maybe you are pulling the carpet out from underneath it.

 

In fact that is exactly what is happening.  Closing the reference in the caller aborts the sub.vi in most cases.

 

Capture.pngit is much safer to use an Async Call By Ref than the invoke node.

 

Note: Any Property node in the sub.vi referencing "This VI" prevents the sub.vi from aborting because it also has a reference to itself.

 

Essentially, The only excuse to use Close Ref to the Sub.vi with F autodispose and F Wait for vi completion is if the caller see some type of error and error handling determines that the sub.vi should abort on that error (usually occurring in some other parallel process)

 

 

NOTE: That is sloppy error handling. a controled shutdown method is prefered buy, LabVIEW does allow the Abort VI Method so this implicit abort is syntactically valid and documented behavior.  In Other Words "Don't Do That!"



"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 10
(2,508 Views)

I think that is the answer.

I rebuilt the programm with an asynchronous call and it is working 🙂

Thank you very much!

 

But I still dont understand why the "SubVI" was only aborted in the most cases and not in all cases.

0 Kudos
Message 8 of 10
(2,482 Views)

@annikas wrote: 

But I still dont understand why the "SubVI" was only aborted in the most cases and not in all cases.


Firstly, as from the source I quoted, it will not do it if the front panel is open.

Secondly, we have a race condition where the subVI is started and then aborted a randomly short time later. It depends on the exact code scheduling how many iterations the subVI will be able to do before it dies, and this is not predictable.

0 Kudos
Message 9 of 10
(2,476 Views)

@annikas wrote:

I think that is the answer.

I rebuilt the programm with an asynchronous call and it is working 🙂

Thank you very much!

 

But I still dont understand why the "SubVI" was only aborted in the most cases and not in all cases.


It is one of those very nasty things that LabVIEW programmers rarely need to think about.  Any reference (property node) that needs the FP in memory... (Yup, Hit the help file repeatedly) would prevent the "abortion" of the sub.vi.

 

Most Cases.  "Can Abort the sub VI"  not "Will abort..."  subtle, normally you don't want to go there


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 10
(2,468 Views)