LabVIEW Bug: "Dynamic IUse Node has no referenced vi..." and vi refuses to compile

[Thomas_robertson]

We've run smack into a nasty LabVIEW bug.  I've created a support request but I'm wondering if someone here has thoughts.  

I have an object "Voltmeter.lvclass" in my code. If I drop an instance of it onto a vi "Flatten Voltmeter.vi" then check in my code, then force sync all my code from SCC such that LabVIEW has to recompile my entire code base, I get errors "Report this problem to National Instruments Tech Support. Dynamic IUse Node has no referenced VI to call...".  Once my source code is open some dynamic dispatch vi's which are in a totally different part of my heirarchy have the error that the VI failed to compile.  I can use CTRL-click on the broken run arrow to recompile it and then all is fine, but, if I check in the recompiled vi to SCC, then force sync all code from SCC the problem persists.

This is critical to us because our automatic builder deletes our source code and force syncs to head daily, so we are now getting build failures.

I am aware of this thread, but, obviously the solution is not a solution in my case:

https://forums.ni.com/t5/LabVIEW/dynamic-IUse-Node-has-no-referenced-VI-to-call/m-p/1002944#M448015

[thuyanhl]

Hi,

I believe that you can look into this option: https://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/separate_compiled_code/

This will allow you to only compile the VI you are currently working on and commit it without affecting other VIs in your project or hierarchy.

This way, you won't have to commit the other VIs that seem to be broken. 

Is this what you are looking for?

[Taylorh140]

I just ran into the same "Dynamic IUse Node has no referenced vi" problem. Its easy enough to hit Ctrl+(run arrow) but it still wont build with app builder. Did you find a solution?

[Taylorh140]

I found that if i run a mass compile with the project closed it happens in quite a few places. but all of the broken items are inside a lvlib file.  The mass compile status ends pointing to seemly random places in the code. When I remove the dynamic dispatch calls from those VIs the error seems to jump to new locations.

#### Starting Mass Compile: Tue, Jun 20, 2017 12:16:26 PM
Directory: "C:\ICECorp_PBMS_DT"

Compiler Error: Dynamic IUse Node has no referenced VI to call. Node = 0x0000020E in C:\ICECorp_PBMS_DT\SVN_OTIS\iTestStand OO Objects\BoundsExpression\Base\InterpertExpression.vi
Compiler Error: Dynamic IUse Node has no referenced VI to call. Node = 0x000005AE in C:\ICECorp_PBMS_DT\SVN_OTIS\iTestStand OO Objects\ScalarExpression\Base\InterpertExpression.vi
Compiler Error: Dynamic IUse Node has no referenced VI to call. Node = 0x00000095 in C:\ICECorp_PBMS_DT\SVN_OTIS\iTestStand OO Objects\ChannelManager\Base\ExecuteStep.vi
Compiler Error: Dynamic IUse Node has no referenced VI to call. Node = 0x000001DF in C:\ICECorp_PBMS_DT\SVN_OTIS\iTestStand OO Objects\DataRecorder\RecordData.vi
Compiler Error: Dynamic IUse Node has no referenced VI to call. Node = 0x000001D2 in C:\ICECorp_PBMS_DT\SVN_OTIS\iTestStand OO Objects\ChannelValueInitializer\AssertInitialValues.vi

RecordData.vi actually has no dynamic dispatch calls. it still has the error though.

[Taylorh140]

I think I found a solution ... but i don't like it. If i remove my code from the lvlib and put it right into my project everything works no issues.

[_carl]

I just encountered the same issue.

I was able to solve this by a combination of:

- Renaming the VI.

- Clearing compiled object cache (under Tools -> Advanced)

- Restarting LabVIEW

Renaming seemed to be essential, not sure if the other two were.  After renaming (and having it compile) I was able to rename it back to its original name.

[billko]

---

@_carl wrote:

I just encountered the same issue.

I was able to solve this by a combination of:

- Renaming the VI.

- Clearing compiled object cache (under Tools -> Advanced)

- Restarting LabVIEW

Renaming seemed to be essential, not sure if the other two were.  After renaming (and having it compile) I was able to rename it back to its original name.

---

I'd say there is a fair probability that both actions were necessary, and in that order.  Maybe renaming it forced the cache to update?