How to use a VI to find the node count of a VI in C++.

[ChrisWoodard]

I have created a VI that finds how many nodes a VI has. You pass in the file path as a string, and it counts the nodes. This works great in dev; however, when I build it into a dll and run it in my C++ program it gives an error because the compiled code is not saved with the source code (It can't make a vi reference). This can be solved by unchecking the property in the VI I am trying to dynamically call to not save the compiled code; however, This is going to be checking the node count for hundreds of VIs in separate projects and I don't want to have to change that setting everywhere. Am I missing something, or is there a better way to do this?

Essentially I want to find the node count of a VI without altering the VI using the VI's path. 

[billko]

oops you already count the nodes.

[ChrisWoodard]

Yea, my issue is just that when I run this in my C++ program I get an error when trying to create a VI ref, because the VI is not apart of the project. Essentially I'm asking if there is a way to analyze a VI to find the node count programmatically when the VI was not built in the dll.

[avogadro5]

I don't think you can traverse the BD at all in RTE

Your calls to Traverse for GObjects.vi are very likely returning error 1043 "LabVIEW: (Hex 0x413) The property or method is not supported in this version of LabVIEW." You should wire the error clusters through so you don't have strange problems you can't diagnose. have fewer strange problems you can't diagnose.

[ChrisWoodard]

Ah ok, I was getting my error before then when trying to create a VI reference. Just so, I understand correctly the RTE is what VI's run on when built correct? Which would explain why it works in LabVIEW but not when it's a dll.

[ChrisWoodard]

I normally receive this error 59 from the Open VI Ref.

If I fix that by making the VI I am trying to open save the compile code with the source file (Which I don't want to do) I get this error from the TRef Traverse VI. If this VI won't work I do not mind writing my own recursive VI to count nodes. I just need to be able to pull a VI reference to do that.

[avogadro5 · Accepted solution]

---

@ChrisWoodard wrote:

Ah ok, I was getting my error before then when trying to create a VI reference. Just so, I understand correctly the RTE is what VI's run on when built correct? Which would explain why it works in LabVIEW but not when it's a dll.

---

Yes. I'm not an expert but generally what happens is when the caller loads the DLL you built, first the DLL loads the runtime engine and then the runtime engine loads the actual VI you're trying to run. Traverse for GObjects.vi will only work on block diagrams in the development environment, meaning when called by LabVIEW.exe. As a rule, RTE cannot view or interact with the BD in any way.

Depending on what you're doing, you have some options besides the DLL. If you do have access to LabVIEW development you can use VI server over TCP/IP to connect to LabVIEW and run VIs in the development context: this is how VI package manager works. LabVIEWCLI also uses VI server to provide a CLI for LabVIEW development.

If you do not have access to LabVIEW development where this tool is running, pylabview can extract a bunch of info about the block diagram without requiring LabVIEW.

[ChrisWoodard]

OK, that sounds like what I'm looking for thanks a lot. I will look into it.

[ChrisWoodard]

This worked great. When researching this I also found XActive, which seemed to be a bit more simpler. Therefore, I set it up using XActive. This requires that the bittness of the C++ and LabVIEW match, so watch out for that. Also, it requires whatever is running the C++ code also has LabVIEW installed

[avogadro5]

Fair warning, I have used the ActiveX API in C# (here) and find it buggy especially with multiple LabVIEW versions installed. It also seems to stop working related to suspending the PC. NI has pretty much abandoned it because Microsoft has deprecated the whole framework.

There are distinct advantages though, for instance it will launch LabVIEW for you if it isn't running when you go to connect, and the API is extremely lightweight and loads in milliseconds vs seconds for loading the runtime engine to perform VI server ops for you.

I would like to see NI create a lightweight .NET replacement API but don't see it happening soon.