VI Interface type

[deceased]

Hi All,

I have a minor annoyance with an asynchronous call by reference. The code I am calling has a type def enum on the connector pane. If I modify this enum in any way the code breaks unless I set the VI reference to strict.

I have a property node that is getting the VI path which now says "VI INTERFACE TYPE 2" and increments with each change I make.

I no longer want or need the old interface type but have no idea how to remove it.

Anyone have any ideas?

Thanks!

[Bob_Schor]

A VI (+ the TypeDef) attachment would make things a lot clearer.  I'm not 100% certain I know what you mean by "asynchronous call by reference" -- if you mean "Start Asynchronous Call", then I thought that the VI reference had to be a Strict Type Reference ...  I'm pretty sure that the reason for this is that (a) if you changed the Enum definition on the called sub-VI, then you need to use the same Enum definition in the calling VI (or else the wires won't connect), and (b) when you use Start Asynchronous Call, the Connector Pane and its type definitions comes from the VI Reference, so it needs to carry all of the Type information for its connector pane.

Bob Schor

[deceased]

Thanks for the reply Bob, unfortunately I cannot share the code in this case, but I have taken a screenshot of the section in question.

Indeed you are correct that I mean "Start Asynchronous Call".

The VI being called has a queue reference for it to return data and also a cluster of event registrations, so the Async code can be controlled.

One of the event registrations has the typedef enum as its event data type. This way, if I need to add more commands, I can just update the typedef and a case structure inside the event structure.

The problem is, every time I update the enum with a new command, the property node increments the "VI Interface type".

If I disconnect the strict VI ref, I can browse the VI interface types (for the old unneeded VI interfaces, which incidentally all appear identical in terms of connector pane). These other interface types are now obsolete, since the new one supercedes them, but I have no way to remove them.

Its a strange one, but fear it will grow out of control if I continue as is.

[Hooovahh]

Bob is still correct that if you type def the cluster (in the queue) then when that cluster is updated, the interface to the VI will be updated, and so will your strict type constant.

However I think what you are doing is a big no-no in LabVIEW.  Are you registering for events, and then placing that event registration refnum into a queue?  In almost all circumstances you should not branch the registration refnum and share it with any place other than a single event structure.  The VI analyzer even has a test to find this.  If so I would consider redesigning your system.

[deceased]

Sorry Hoovah, its not clear from the image. One of the inputs to the async code is a queue ref, so it can spew data back to me.

The other input is a cluster of event refs which the async code registers for.

The code works fine, but each time I add a new command to the enum the VI interface count increases.

[Hooovahh]

Is the cluster a typed cluster?  Is the enum a type def?  Is the data in the queue a cluster?  Is that cluster typed?  Basically every cluster and every enum should be a type def (also a VI analyzer test for this).  If this is fixed it will likely take care of your problem because updating any data type, will update it everywhere it is used including the connector pane layout, and strict VI constant.

[deceased]

---

@Hooovahh wrote:

Is the cluster a typed cluster?  Is the enum a type def?  Is the data in the queue a cluster?  Is that cluster typed?  Basically every cluster and every enum should be a type def (also a VI analyzer test for this).  If this is fixed it will likely take care of your problem because updating any data type, will update it everywhere it is used including the connector pane layout, and strict VI constant.

---

Cluster of event refs is a Typedef

Enum is a Typedef

Queue data is a typedef'd cluster.

Its not really an issue, as long as I dont run out of numbers for the VI interface type, but that property node is an eyesore and I have no idea how to get rid of the old "VI interface types" that are no longer part of this project.