LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
mike-o-tronic

Simplify access to vi reference options

Status: New

I find it always a hassle to create an asynchronous call with the need of the "Open VI Reference" block. A strict static VI reference should be sufficient. Options should be either available in the properties via context menu, via property node or as input of the "Start Asynchronous Call Node".

 

I didn't go through the effort to create a property menu example, but here is an a graphic showing the help example and what I would wish for:

 

Call Options Example.png

12 Comments
AristosQueue
Proven Zealot

The problem you're trying to solve is good.

 

Your first proposed solution works (directly configuring the static VI ref):

Untitled.png

 

Setting the Options in a property is going to be weird -- no one is going to realize that what comes out of the node must be a different VI reference that has to be closed. It must be a different ref because it is configured differently for different calls, and if that ref wire has ever been forked upstream, you have a problem. If they're the same reference, then you have the problem shown in this picture:

Untitled.png

 

Your second version (setting flags on the CBR node itself) has a lot of problems -- I won't get into all the technical details here, but you wouldn't like the performance of that notation if you're making multiple calls to that CBR. The ref needs to know its setup ahead of time.

 

 

Here's another option that could work:

 

Direct wiring of the static VI ref to open a new ref.

Untitled.png

 

mike-o-tronic
Member

I like that little indicator on the static VI ref! That's what I'd consider the best solution.

 

But I refuse to accept the race condition excuse, just because if you wanted to prevent the programmer from creating race conditions, you'd have to come up with some really good ideas Smiley Very Happy

 

Same race, different reference:

Race Condition al a Carte.png

 

And to use one VI ref to open another VI ref is still unnecessarily complicated, don't you think?

wiebe@CARYA
Proven Zealot

>directly configuring the static VI ref

 

Sounds familiar... Even better if the Static Reference can do both...

mike-o-tronic
Member

The idea you linked is for a static clone reference, which personally I didn't have need for yet but I can see how it could be useful.

 

Nevertheless there was another idea mentioned in the clone ref idea which I must admit I duplicated. To my excuse the title is of that idea is "Allow Asynchronous Call By Reference with Strict, Static VI Reference" which is given.

AristosQueue
Proven Zealot

Any change to G that I can make that makes a race condition impossible or avoids introducing a new one is a valid excuse. There is no class of bugs that is more likely to escape testing, harder to debug, and more likely to destroy user confidence in an application. They are to be fought with every tool in our arsenal. There are languages that did away with references entirely in order to prevent those abuses, and if I thought I could impose that on G, I would, but reference-less languages are hard to grasp for many people, so I do what I can to minimize their danger.

wiebe@CARYA
Proven Zealot

>The idea you linked is for a static clone reference, which personally I didn't have need for yet but I can see how it could be useful.

 

I wasn't hinting at the duplicate (but great catch), because indeed the context is different.

 

I mentioned the link because it's a similar solution to a different problem. The root of both problems is that a SVR is useless if you want options. The same solution would work: give the SVR options.

 

crossrulz
Knight of NI

I would much prefer AristosQueue's last option: Direct wiring of the static VI ref to open a new ref.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
wiebe@CARYA
Proven Zealot

>I would much prefer AristosQueue's last option: Direct wiring of the static VI ref to open a new ref.

 

That seems to be the most in line with everything else in LabVIEW. And probably the easiest to implement. It would be an improvement.

mike-o-tronic
Member

So... what exactly is the difference between the SVR and the opened VR? I mean besides of that the VR can be opened with options.

 

I was wondering if it would be sloppy to not close the SVR. A google search found this:

LabVIEW closes this reference when the top-level VI is no longer in memory. However, if you use the Open VI Reference function with the Static VI Reference, you will want to ensure you close the reference that is passed out of the Open VI Reference function.
Which is from the actual search. The link to this information just results in an error:
 
Here it says:
When you open a reference to an application, project, VI, or other reference source, LabVIEW allocates memory to store that reference. 
 
My expectation would be that it is the same for a SVR. Just that it's opened as soon as the VI, that contains the SVR, is loaded. Is that correct?
wiebe@CARYA
Proven Zealot

>So... what exactly is the difference between the SVR and the opened VR? I mean besides of that the VR can be opened with options.

 

There's not really a difference. A SVR is a VR. The SVR is just a way to get a VR. OVR is another. OVR is explicit, so it needs a close. Closing the SVR seems redundant, I never close them. When using a SVR to call a OVR, the OVR reference needs to be closed.

 

>When you open a reference to an application, project, VI, or other reference source, LabVIEW allocates memory to store that reference. 

 

Uhh. Sure. It's data, so it needs memory for sure...

 

Not sure about the rest (it lingers a bit), but it's OT for this idea. It's your thread, so I'm OK with it.