ABAPI Examples 2013.zip

[Daklu]

Darren wrote:

As for acquiring all the project item references, have you tried using this VI (also discussed in the hidden gems presentation):

I gave it a try but it didn't work.  It uses the same technique I do and suffers from the same problem--it will only return items in the dependency section of the project window.  If the project doesn't know about the dependencies it can't return them.

I vaguely remember hearing something about Labview only loading dependencies to a certain depth in order to reduce loading times.  If that is accurate, is there an easy way to override the behavior?

(Hmm... I guess the next thing to try is getting vi refs for all the dependencies to force those lower level items to load.)

[Darren]

Daklu wrote:

(Hmm... I guess the next thing to try is getting vi refs for all the dependencies to force those lower level items to load.)

                   

I assumed you were already doing that by wiring a FALSE into the "Exclude Dependencies?" input of Open References To All Libraries And VIs In Project.vi.

[Daklu]

I did wire a FALSE to that terminal, but as near as I can tell just adds the items that are already in the dependency section to the list of project items returned.

What I meant was, for every project item I get from the dependency section, use the VI Reference property node to force Labview to load it.  If Labview only loads dependencies n layers deep, then loading the dependencies should cause those deeper dependencies to get loaded.

[Darren]

Daklu wrote:

                       

I vaguely remember hearing something about Labview only loading dependencies to a certain depth in order to reduce loading times.  If that is accurate, is there an easy way to override the behavior?

                   

I have never seen or heard of this behavior. If it's true, and it's the cause of the problems you're seeing, I have no idea how to override it.

[Daklu]

Darren wrote:

I have never seen or heard of this behavior. If it's true, and it's the cause of the problems you're seeing, I have no idea how to override it.

                   

I don't know if that explanation is exactly true, but it sure behaves as if it is true.

I call the VIReference property node on my top level vi and move all the project items out of the dependencies section and into my project.  Then I go through and call the VIReference property node on all the items that were in dependencies, and the dependencies section fills up with new items.  I had to iterate through the process 3 times to get all the vis being used.

[Darren]

About the only thing I can think of that might cause this behavior is code/conditional disable nodes and subVIs set up for dynamic calls. SubVIs in disabled code and subVIs set to 'load and retain'/'reload for each call' may conditionally appear in Dependencies depending on whether or not their calling VIs are in some particular state.

[AristosQueue (NI)]

LabVIEW's project lists all the dependencies to as deep as they go. There's no pruning done. I don't know what you're seeing, but that isn't it. Neither of the Project Item properties (Path or VIReference) that you mentioned have any effect on the dependencies list, unless loading is causing a search for missing references and it is finding them.

[Daklu]

AristosQueue wrote:

Neither of the Project Item properties (Path or VIReference) that you mentioned have any effect on the dependencies list...

                   

All evidence suggests otherwise.  Here are easy repro steps:  (Do these via scripting, not manually)

1. Create and show a new project
2. Add an sbRIO-9626 target
3. Add a top level vi to the sbRIO target
4. Confirm the file is in the project and the dependencies section is empty
5. Invoke the VIReference property node on the top level vi.  Wait while Labview finds dependencies.
6. Confirm the dependencies section is now populated.

This is repeatable for me every time.  The only two ways I've been able to get a vis dependencies is by using the GetVIDependencies method (which has other issues I've described) or calling the VIReference node and extracting them from the dependencies section of the project.

Daniel Smith and Burt Snover have copies of the state of my build script as of yesterday morning if you want to look at it.  I'm also working on getting permission to send the code we are trying to compile... getting this automated build working has turned out to be much more difficult than expected.

AristosQueue wrote:

...unless loading is causing a search for missing references and it is finding them.

                   

I assume when adding a file to the project via scripting the project doesn't know the file is a vi, so it doesn't bother loading it and the dependencies aren't populated.  If the VIReference node does cause the vi to load, as it appears, that would explain why the dependencies are populated after calling it.

[AristosQueue (NI)]

Oh. You're adding it via scripting.

No, in that case, we just turn off population of the Dependencies entirely. You have to manually tell the project to regenerate the Dependencies. Use this method:

If we rebuilt the dependencies after every file you added, it would be tremendously slow to add a block of VIs, especially if those VIs have overlapping dependnecies. So adding by scripting never refreshes the dependency list.

[Daklu]

Thank you very much Stephen, that is *exactly* what I needed.  Creating the build project used to be a 45 minute process... now it takes about 5 minutes.

I still have to iterate through refreshing dependencies and adding them to the project 3-4 times before refreshing doesn't add any more dependencies to the project.  Granted, after the first pass of gathering dependencies most of the remaining dependencies look like pretty obscure low level things from NI.

These are shots of the dependencies that were collected on the second and third passes.  It's pretty clear at some point LV decides to quit populating the dependency folder.  I don't object to that behavior--I just need to understand what those cutoff points are.