OpenVI Reference and All.AllVIs synchronization delay

[Jim Kring]

I'll bet a dollar that someone from NI says that this is not a bug, but it's really bugging me, nonetheless...

When you open a reference to a VI by path, which was not previously in memory, there is a small time delay between when the Open VI Reference funtion returns (returning a valid VI reference) and when the VI appears in the App.AllVIs array, which supposedly contains the list of all VIs in memory. To me, this seems like a bug -- I have a reference to a VI in memory and it's not in the list of all VIs in memory. In my opinion, the Open VI Reference function should update the list of AllVIs before it returns to its caller. :2cents:

Download File:post-17-1205274083.vi

[Aristos Queue]

It's not a bug.

No, I don't actually believe that. But I felt I should say it so that you could win your bet. I like supporting open source software efforts.

[Jim Kring]

QUOTE (Aristos Queue @ Mar 12 2008, 07:32 AM)

It's not a bug.

No, I don't actually believe that. But I felt I should say it so that you could win your bet. I like supporting open source software efforts.

Thanks for your support The reason that I was worried that this would be considered a "feature" is that the "Close VI Reference" function does not wait until a VI is unloaded from memory before it returns (See this old info-labview thread: http://sthmac.magnet.fsu.edu/cgi-bin/ILVsearch/search.pl?Match=1&Realm=ILV2003&Terms=%22Bug+-+Close+VI+Reference+and+App.AllVIs%22' target="_blank">Bug - Close VI Reference and App.AllVIs) -- that's why we created the OpenG "Wait on VIs Unloaded from Memory" function. It seems ironic that 5 years later I realize that the inverse problem is occurring in "Open VI Reference" and the workaround is to create a "Wait on VIs Unloaded into Memory" function.

[update: CAR# 96951]

[Anders Björk]

I agree it seems reasonable.

[TG]

QUOTE (Jim Kring @ Mar 11 2008, 11:22 PM)

[status: CAR# 96951]

I'll bet a dollar that someone from NI says that this is not a bug, but it's really bugging me, nonetheless...

That workaround looks familiar to me.

(keep looping until you get what you were expecting)

[Christina Rogers]

Duplicating my response to Jim's comment on my blog directing me to this thread:

Jim, I see that you've already submitted a bug report (thank you!) for the problem with the "All VIs in Memory" property. I hereby officially confirm that this behavior is a bug. The referenced VI is fully loaded into memory when the Open VI Reference completes execution, but the All VIs in Memory property is filtering it out of its list incorrectly. I looked up the CAR and the developers investigating the problem have found a workaround: "Place an empty sequence structure immediately after the open vi reference." I apologize for the inconvenience, and hope this helps!

PS CAR# 96951 was marked as a duplicate of CAR# 49855.

[Jim Kring]

QUOTE (Christina Rogers @ Mar 16 2008, 06:50 PM)

Duplicating my response to Jim's comment on my blog directing me to this thread:

Jim, I see that you've already submitted a bug report (thank you!) for the problem with the "All VIs in Memory" property. I hereby officially confirm that this behavior is a bug. The referenced VI is fully loaded into memory when the Open VI Reference completes execution, but the All VIs in Memory property is filtering it out of its list incorrectly. I looked up the CAR and the developers investigating the problem have found a workaround: "Place an empty sequence structure immediately after the open vi reference." I apologize for the inconvenience, and hope this helps!

PS CAR# 96951 was marked as a duplicate of CAR# 49855.

Thanks for confirming and for the work-around. I've updated the CAR# in my original post.

[Rolf Kalbermatter]

QUOTE (Christina Rogers @ Mar 16 2008, 08:50 PM)

Jim, I see that you've already submitted a bug report (thank you!) for the problem with the "All VIs in Memory" property. I hereby officially confirm that this behavior is a bug. The referenced VI is fully loaded into memory when the Open VI Reference completes execution, but the All VIs in Memory property is filtering it out of its list incorrectly. I looked up the CAR and the developers investigating the problem have found a workaround: "Place an empty sequence structure immediately after the open vi reference." I apologize for the inconvenience, and hope this helps!

Now that is a fancy workaround! And I was always thinking that sequence structures had no other runtime influence than enforcing execution order. In this case they obviously do more since they logically wouldn't do more than what the error cluster is already doing.

Rolf Kalbermatter

[Aristos Queue]

QUOTE (rolfk @ Apr 25 2008, 12:36 AM)

Now that is a fancy workaround! And I was always thinking that sequence structures had no other runtime influence than enforcing execution order. In this case they obviously do more since they logically wouldn't do more than what the error cluster is already doing.

All structure nodes provide an opportunity for threads to yield. That bit of yield is all that is necessary to give the Open VI a chance to finish registering the new VI.

[Rolf Kalbermatter]

QUOTE (Aristos Queue @ Apr 25 2008, 01:13 AM)

All structure nodes provide an opportunity for threads to yield. That bit of yield is all that is necessary to give the Open VI a chance to finish registering the new VI.

I take it with structure nodes you mean (Stacked) Sequence Structure Nodes and maybe Case Structures, but not loops? I thought of them as Structure Nodes too until now but this is probably not the classification the LabVIEW team is using.

And in that respect the notion that a sequence structure does not cause any significant runtime delay ever certainly has to be reconsidered too. If there are asynchronous threads like this (or any other VI server proxy threads) waiting they will be serviced and delay the execution of the sequenced code. Until now I was rather assuming that this would only happen at specific asynchronous nodes such as Wait (until multiple ms) etc.

Rolf Kalbermatter

[bpreis]

QUOTE (Aristos Queue @ Apr 25 2008, 01:13 AM)

All structure nodes provide an opportunity for threads to yield. That bit of yield is all that is necessary to give the Open VI a chance to finish registering the new VI.

I believe the wait functions (Wait Until Next ms Multiple and Wait ms) wired to zero are another, slightly more intuitive way, to do this. It had a few practical uses in LV RT.