LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application locking up at Call by Reference

We are seeing our application lock up occasionally at a VI Server Call By Reference node. The VI acts like it is waiting for subVI called to execute, but the subVI acts like it never got the message to execute. We've seen this at a number of VIs that call subVIs by reference. In some cases we are using strickly typed VI references, and in other cases we are not. We've seen the code lock up in both. Has anyone else seen this type of behavior?

We are running LabVIEW 7.0, Windows XP, and TestStand 3.0.

Also, I noticed that in a couple of places, the reference isn't explicitly closed. Since these VIs are only a small part of the application, not called very often, would that cause much of a problem (memory or otherwise)?

0 Kudos
Message 1 of 4
(2,681 Views)
It sounds like your reference is pointing to something else than you think it is pointing to.  Generally speaking, not closing references is not good.  Whether it will lead to problems is most likely a matter of probability.  Could it be that the reference is actually being closed before you issue the correct command?

Fix the code first (make sure that references are closed when they're no longer used and make sure references aren't closed when they are still in use).

References are great for uncovering tiny errors in code.  Hunt them down and show no mercy!  Or just debug, that'll work too.

Seriously, I recommend you trace where the references are coming from and make sure they're being closed at the right time.

Important is also the difference between (what I understand as) "static" references (right-clicking a control and selecting -create reference) and those created dynamically (such as in lauching a VI via VI server).  All Dynamic references should be closed when finished.

If you could post a picture of the block diagram (Jpg is good, BMP is bad) maybe someone can offer some more precise help.

Hope this helps

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 4
(2,671 Views)

I think the problem may be an interaction with TestStand, possibly a conflict with different threads.  One question that I can't find the answer to is:  what execution system do VIs run in when they are called by reference?  For example, if TopLevelVI.vi calls SubVI.vi by reference, if TopLevelVI.vi is set to "other2" and SubVI.vi si set to "same as caller", does SubVI.vi run in the "other2" execution system, or does it run in the default "standard" execution system?

Tom

0 Kudos
Message 3 of 4
(2,662 Views)

Hi Tom,

That is a very interesting question!  I had to check around a bit to find someone who knew this, but it seems that calling a VI by reference doesn't prevent it from using the execution system of its caller.  Therefore, in the example you specified, the subVI would run in the "other2" execution system.

Best Regards,
Megan B.
National Instruments

0 Kudos
Message 4 of 4
(2,642 Views)