10-12-2017 05:06 PM
@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.
10-12-2017 05:27 PM - edited 10-12-2017 05:31 PM
@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
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