Jump to content

OpenVI Reference and All.AllVIs synchronization delay


Recommended Posts

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:

post-17-1205274070.png?width=400

Download File:post-17-1205274083.vi

Link to comment

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) ;)

Link to comment

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.

Link to comment

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.

Link to comment
  • 1 month later...

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

Link to comment
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.
Link to comment

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

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.