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: 

Allow Asynchronous Call By Reference with Strict, Static VI Reference

The static VI Reference has the ability to be made strict. A strict and static VI reference shows the icon of the target VI (static part) and a small red star (strict part). This allows a strict, static VI reference to be wired directly into a CBR node.

StrictStaticVIRef.png

However, the new async CBR feature does not work with strict, static VI references because it also requires option 0x80 or 0x100 to be wired into the Open VI Reference.

 

There should be a way to specify an async call inside a strict, static VI reference. That way, an async call can be made by way of a reference returned by a strict, static VI ref and not just with an Open VI Ref.

12 Comments
Proven Zealot

Users need to specify "call and collect" or "call and forget" mode, so this idea would include new popup options on the static VI reference to set one of these two properties so that the ACBR node knows what to do when called.

Member

Also don't forget about the 0x40 option, the refnum needs to set to either allow serial or paralell calls if multiple ACBR nodes are made in succession.

Member

Maybe the implementation should allow the user to set any open options flags on the strict VI reference. Some options might be useful in completely different use cases.

 

For example, non-strict static VI reference to reentrant VI with option 0x8 specified to allow a reentrant instance to be called by way of a Run VI method.

Member

Perhaps with a polymorphic selector?

Proven Zealot

Conceptionally I do not like to intermix functionality. So the polymorphic selector or anything similar on the CBR or ACBR node feels like the wrong thing to me, as that function should not be concerned about the opening of a new reference and the possible options of that. Also it poses an extra problem for cases where it can't just use the passed in static refnum but instead needs to create a new one to open it with the right options. That refnum needs to be deallocated too! You could always deallocate it after a call, or only if the output refnum isn't wired, but that still makes the actual refnum handling a lot more complex and possibly performance costly.

 

If anything at all, such an option should be placed on the Static Refnum icon. This icon is already responsible for providing a working refnum so it could also include a method to define the options on that refnum. The CBR and ACBR should not be concerned about creating the right refnum at all.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Member

 

Knight of NI Knight of NI
Knight of NI

Another alternative would be to place this in a subVI's Call Setup dialog. Today, if you right click a subVI and select that, you get the option to control when it loads and unloads and then the subVI call is automatically wrapped in a CBR node. If we add it, it could use the same mechanism and it will allow us to make an async VI call.

 

Pros:

 

  1. Cleaner code (only a single element on the diagram).
  2. Maintains an existing idiom.

Cons:

  1. Only handles the use case of a single static VI.
  2. Hides the details of the call inside the dialog (unless NI adds some indications to the CBR node).

___________________
Try to take over the world!
Proven Zealot

Tst: I assume you're not interested in the Call&Wait case but only the Fire&Forget?

Knight of NI Knight of NI
Knight of NI

> I assume you're not interested in the Call&Wait case but only the Fire&Forget?

 

Correct. In the case of the single static VI, the call and wait case is handled using a standard subVI call, so we don't need to add anything to get that option.


___________________
Try to take over the world!
Knight of NI Knight of NI
Knight of NI

P.S. I said my suggestion only covers the use case of a single VI (which is what's shown in the original image), but that's not actually true.

 

In the case of multiple VIs, the original suggestion would basically have a case structure around the static reference to select the VI. In my suggestion, the same case structure could be around the CBR node itself.

It's true that the first code is slightly simpler, because it avoids duplicating the config for the CBR node, but there's no real difference.


___________________
Try to take over the world!