From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unexplained "function conflict"

LV2013 SP1,  Win 7

 

The basic question is... why is this wire broken, and what can I do to fix it?

 

See this JING: < http://www.screencast.com/t/U3h0MMGe >

 

I have a record, called an ADDON CONTROLLER RECORD.

 

The record contains a reference to a VI called an ADDON.

 

It also contains a reference to a VI called an ADDON CONTROLLER.

 

The ADDON vi has one terminal, which is an ADDON CONTROLLER RECORD.

 

My intent here is to open up a copy of the ADDON, and store the reference in the record, which seems to go OK.

 

I also want to open a copy of the ADDON CONTROLLER, and store the reference in the record, but that results in a broken wire.

 

The JING shows that, even if I create a new control for the VI RefNum, and paste it into the TypeDef, it still complains of a "function conflict".

 

Since I just created the refnum type, how can there be a conflict?

 

I suspect it has something to do with recursion: the VI has a terminal with a cluster, the cluster has a VI RefNum, the RefNum describes a VI with a terminal, the terminal has a cluster, the cluster has a VI Refnum, the RefNum describes a VI with a cluster, etc., etc., etc,

 

You can see that the help window is screwed up, showing several levels of this.

 

But how does that result in a "function conflict"?

 

Can I resolve this, or do I have to keep the Controller RefNums separately?

 

What are the rules?

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 2
(2,520 Views)

CoastalMaineBird wrote:

 

Can I resolve this, or do I have to keep the Controller RefNums separately?

 

What are the rules?


I wouldn't worry so much about the rules (I would have expected LV to either freeze or disallow it in the first place) and just avoid recursive data types. If this is the data type you need, keep the VI reference in a non-strict format and cast it to the strict type when you need it. I haven't tried this specifically, but a quick test indicates that you can't use To More Specific Class or Type Cast, but Variant to Data seems to work.


___________________
Try to take over the world!
0 Kudos
Message 2 of 2
(2,490 Views)