VI Refererence behaviour

[mp_db_21]

Hi JÞB

I guess I still don't get it. When I change to "Start Asynchronous Call" I run into a problem of strict Type Definitions and the possibility of having different Sub Panels.

I created an example to show what I'm trying to do in my application. Closing the Sub Panels is really bad implemented in this example but it should show what I want to achieve and makes the example smaller. I added a disable structure at the point where the panel is started. It works ok with the "Run VI" version but it will rename all panels of the same kind. For the start asynchronous call I simply don't know how to do it.

Many thanks in advance!

[JÞB]

I'm posting with a mobile device so, I cannot open your vi to check what you are doing wrong.

Look into the shipping examples for the ACBR call and collect or fire and forget examples.   The ACBR does need a strict type vi ref to define the con pane and terminal datatype.  Additionally you do have to set the appropriate flags in the Open VI Reference call to prepare the vi for reenterent execution.  The examples show how this is done and the help for Open VI Reference explains the flag inputs.

So, once you have opened the Clone Instances of your vi you can simply wire the ref out to whatever Insert into Subpanel invoke node you want and the clones will run independently.  If you need the outputs wire the strict vi ref to the Start Asynchronous Call node and wire the Clone ref to a Collect Asynchronous Call.  More likely though you can use the Start Asynchronous Call node with a fire n forget.   Again, no LabVIEW Viewer here so inline snippets if you get stuck.

[mp_db_21]

Ok, it runs with the Asynchronous Call but still has the same issue, that all panels are renamed.

I did a PDF print of my example maybe this can be used on the mobile device to have a look. Snippets might not be enough to explain the situation.

[mp_db_21]

---

@JÞB wrote:

So, once you have opened the Clone Instances of your vi you can simply wire the ref out to whatever Insert into Subpanel invoke node you want and the clones will run independently.  If you need the outputs wire the strict vi ref to the Start Asynchronous Call node and wire the Clone ref to a Collect Asynchronous Call.  More likely though you can use the Start Asynchronous Call node with a fire n forget.   Again, no LabVIEW Viewer here so inline snippets if you get stuck.

---

I guess now I got it, so you mean adding an identical input node to all possible kind of panels and directly wire the output of Open Reference to it during Asynchronous Call to have it accessible in the panel?

This is what I did as a workaround but by using the Set Control Invoke node and Run VI. Of course your way is shorter.

[wiebe@CARYA]

---

@paul_cardinale wrote:

You don't need the numeric values to be the same.  Starting around LV 2008, NI made the comparisons smarter: When you wire two references to the "Equal?" or "Not Equal?" functions, it doesn't check whether the numeric values match, it checks whether the references refer to the same object.  Also, the "Search 1D Array" is smart: If it's an array of references, it searches for a reference to the matching object, regardless of the numeric value of references.

---

Sadly, as a key in a map or set, references fail...

Reference keys in maps\sets must be the same value to be unique, not just "Equal?".

I do think this is might be a bug, but inconvenient for sure.

[wiebe@CARYA]

---

@paul_cardinale wrote:

You don't need the numeric values to be the same.  Starting around LV 2008, NI made the comparisons smarter: When you wire two references to the "Equal?" or "Not Equal?" functions, it doesn't check whether the numeric values match, it checks whether the references refer to the same object.  Also, the "Search 1D Array" is smart: If it's an array of references, it searches for a reference to the matching object, regardless of the numeric value of references.

---

Also, I've seen at least one corner case where two references are the same, but Equal? returns FALSE.

I'd have to look it up, but IIRC Iterator terminals coming from a traversal and directly from the loop have the same reference (IIRC exact same number, but same UID for sure), but Equal? reports FALSE. Search 1D Array also doesn't find the ref...

This is just FYI, since you do a lot of scripting...

[rolfk]

---

wiebe@CARYA wrote:

---

I'd have to look it up, but IIRC Iterator terminals coming from a traversal and directly from the loop have the same reference (IIRC exact same number, but same UID for sure), but Equal? reports FALSE. Search 1D Array also doesn't find the ref...

---

Are you sure that was for still valid refnums? Because if they are not valid for some reason and LabVIEW checks for equality based on the object they reference to, you get the NaN comparison issue which states that NaN (NaRefnum in this case) is always unequal to whatever else you provide including any other NaRefnum).

[wiebe@CARYA]

---

@rolfk wrote:

---

wiebe@CARYA wrote:

---

I'd have to look it up, but IIRC Iterator terminals coming from a traversal and directly from the loop have the same reference (IIRC exact same number, but same UID for sure), but Equal? reports FALSE. Search 1D Array also doesn't find the ref...

---

Are you sure that was for still valid refnums? Because if they are not valid for some reason and LabVIEW checks for equality based on the object they reference to, you get the NaN comparison issue which states that NaN (NaRefnum in this case) is always unequal to whatever else you provide including any other NaRefnum).

---

Yes, same UID, but not equal:

The references are different, but they sure refer to the same object (same UID, same owner, same class name).

[JÞB]

---

wiebe@CARYA wrote:

---

@rolfk wrote:

---

wiebe@CARYA wrote:

---

I'd have to look it up, but IIRC Iterator terminals coming from a traversal and directly from the loop have the same reference (IIRC exact same number, but same UID for sure), but Equal? reports FALSE. Search 1D Array also doesn't find the ref...

---

Are you sure that was for still valid refnums? Because if they are not valid for some reason and LabVIEW checks for equality based on the object they reference to, you get the NaN comparison issue which states that NaN (NaRefnum in this case) is always unequal to whatever else you provide including any other NaRefnum).

---

Yes, same UID, but not equal:

The references are different, but they sure refer to the same object (same UID, same owner, same class name).

---

The counter terminal of a 0 iteration For loop is "unreachable" and that is probably NaRefnum.

[paul_cardinale]

---

wiebe@CARYA wrote:

---

@rolfk wrote:

---

wiebe@CARYA wrote:

---

I'd have to look it up, but IIRC Iterator terminals coming from a traversal and directly from the loop have the same reference (IIRC exact same number, but same UID for sure), but Equal? reports FALSE. Search 1D Array also doesn't find the ref...

---

Are you sure that was for still valid refnums? Because if they are not valid for some reason and LabVIEW checks for equality based on the object they reference to, you get the NaN comparison issue which states that NaN (NaRefnum in this case) is always unequal to whatever else you provide including any other NaRefnum).

---

Yes, same UID, but not equal:

The references are different, but they sure refer to the same object (same UID, same owner, same class name).

---

The reference comparison is working correctly.  There appears to be a problem with the UIDs.

The iteration terminal appears to be composed of at least 2 objects: There's an one object that shows an image of a square with an "i" in it, and another object which is the actual terminal that connects to a wire.