Quick Tip: Asynchronously launching VIs the right way

If you’re like me, you probably call VIs asynchronously all the time.  Like me, you’ve probably also been doing it wrong for years.  If you’re doing it like this…

Capture

…stop doing that.  For some reason (which I assume is a bug deep in the guts of LabVIEW) when you use a strictly typed VI reference to call VIs asynchronously like this, LabVIEW fails to release the VI reference…sometimes.  It’s a terrible bug because 99% of the time it works just fine, but every once in a while all of your libraries will stay locked after your code is done executing and you’ll be scratching your head trying to figure out why.  Instead, do it like this:

Capture2

Removing the strictly typed VI reference fixes the issue and LabVIEW always releases references correctly.  Interestingly, the Actor Framework made this exact mistake up until a recent version which removed the strictly typed VI reference, as shown here.  I suspect this is the reason why I’ve had many Actor Framework based projects inexplicably refuse to unlock libraries in the past.  A comment in the Actor Framework code suggests that the strictly typed VI reference was removed for an RT bug, but I’m certain the bug occurs on Windows as well.  Also, the Actor Framework still uses strictly typed VI references for “Time-Delayed Send Message.vi”, which is (anecdotally) where I’ve seen this issue show up most often.  Maybe there’s a good reason why the time delayed send message VI was left this way, but I don’t know what that reason might be.  If Stephen Mercer or anyone else can explain this (and happen to be reading this blog post) please comment below!

 

4 thoughts on “Quick Tip: Asynchronously launching VIs the right way

  1. Interesting. I’ll modify my calls that way as I do occasionally have locked classes.

    BTW, you shouldn’t be using 0xC0 if you are only using the ref once. Just use 0x80, as the 0x40 flag creates a pool of clones.

    Like

  2. Interesting. I’ll modify my calls that way as I do occasionally have locked classes.

    BTW, you shouldn’t be using 0xC0 if you are only using the ref once. Just use 0x80, as the 0x40 flag creates a pool of clones.

    Like

  3. Pingback: An Asynchronous Multi-client TCP Server in LabVIEW | LabVIEW Coder

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s