LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Are these Asynchronous VIs considered as open reference?


@Kevin_Price wrote:

I don't know if it contributes to your problem, but my first advice is not to rely on "Abort VI" calls.  Make yourself a cleaner, more controlled shutdown mechanism.

 

Use of "Abort VI" can leave the async vi's in a weird state.  It seems plausible to me that when you use it on async clones, those clones may not get cleaned up properly, and you don't know it because the next launch creates a distinct instance of it that works.

 

-Kevin P


The why I like to explain it is that using the abort VI is liking stopping your car by slamming into a wall. Yes, it will stop the car but there are many undesirable effects of doing it that way.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 11 of 12
(157 Views)

@Foreshadow20 wrote:

Basic info that can be skipped:

I have an application (test sequencer) that uses 2 types of reference and I seem to have a memory leak. Yes You DO!

 

I wonder if the Main application is still considering as open reference when the windows are closed through user manipulation or VIs being self-closed.

 

First Asynchronous Type: Debugging windows

2 types:

Running VI: A complete VI with JKI State machine
Static Front Panel with indicators

 

Second Asynchronous Type: Multiple Clones

Async Reference 2.png

 

Thanks


Bothe examples Use the Run vi method poorly.  The Caller will keep the vi ref open until it goes idle.  If you changed the Auto-Dispose of Ref to TRUE the ref would close when the clone goes idle  Closing it in the callee is a no-op because the owner of the ref is the caller.

 

Better, Stop using run.vi method and use the ACBR that is exactly what it is there for


"Should be" isn't "Is" -Jay
0 Kudos
Message 12 of 12
(147 Views)