Conditional Disable Missing VI

[FlamingYawn]

I have a VI I would like to use in both "My Computer" and "RT" targets in my project.  When used on the RT target, I want this VI to call "RT Debug String.vi", which is only available on the RT palette.  I have placed the call to "RT Debug String.vi" in a conditional disable structure set to RT as the targe type.  When I open the VI on "My Computer" target, the relative path base switches from the RT target and LabVIEW can no longer find "RT Debug String.vi".  I get a dialog asking me to "Find the VI Named 'NI_Real-Time Target Support.lvlib:RT Debug String.vi'".  I can point the dialog to the VI under "..\LabVIEW 2012\Targets\NI\RT\vi.lib\rtutility.llb\" but then it wants me to save changes to "NI_Real-Time Target Support.lvlib".  I can save the changes, but then when I close and open the VI again, it can't find "RT Debug String.vi" and I get the same dialogs.  What's the right way to do this?

[mikeporter]

Well, it sounds like you are doing it the right way. Are any of the files involved write protected by any chance?

What happens if you don't find the "missing" VI?

Mike...

[codeman]

You can call the "RT Debug String.vi" from a "Call By Reference" node.  Setup the node to "Load and retain on first call".  That should avoid the issue.

[FlamingYawn]

Hey Mike,

Thanks for your input.

None of the files are write protected.

If I choose to ignore the missing VI, the parent isn't broken, I just get the icon with the question mark for "RT Debug String.vi" in the RT case of the coditional disable.

The problem is that I don't want to get the search dialog each time I open a VI that depends on this shared VI.  I'd like to turn it into a reuse VI that works on both targets, but don't want this baggage.

Robert

[FlamingYawn]

That's a great workaround to call by reference.  I'll probably end up doing that, but would love to hear NI weigh in on the right way to do this.  It almost seems like a bug to me.

[mikeporter]

I would say that it is absolutely a bug. I have done exactly what you are trying to do in the past and it worked great.

Mike...

[codeman]

There does seem to be a behavior difference there.  LV 2011 doesn't prompt the user when there is a missing subvi in a disabled subdiagram; 2012 does.  You might want to hit up NI e-mail support.  NI Applications engineers tend not to check threads that have already been answered.

[dan_u]

I have exactly the same issue, and I'd also love to get rid of the search dialog. It's the same with "RT Get CPU Loads.vi" and "RT Get Memory Usage.vi". At least the compiled version does not show the load dialog 

---

@codeman wrote:

There does seem to be a behavior difference there.  LV 2011 doesn't prompt the user when there is a missing subvi in a disabled subdiagram; 2012 does.  You might want to hit up NI e-mail support.  NI Applications engineers tend not to check threads that have already been answered.

---

This is correct for diagram disable structures, but not for conditional compile structures.

I'm also using "RT Get CPU Loads.vi", the output of which is a typedef. If I put a typedef indicator on the FP I get the load error even if I use the diagram disable structure (since I can't disable a FP element). At least this is easy to fix by just disconnecting the indicator from the typedef.

@Robert: did you try using the call by reference approach?

[PatJamSim]

Hello all,

There was a recent service request regarding this issue that another engineer handled.  When attempting to verify whether this behavior should be considering a bug that needs correction, it was determined that it is actually expected behavior.  The conditional disable is a run-time disable, and therefore does not prevent the RT VI from being loaded into memory when the VI itself is opened.  Here is what that engineer had to say:

"When the VI is opened, there's no check to see where each function is on the block diagram; LabVIEW simply tries to load everything into memory. 

If you were working with a VI that was only used in a Windows environment but for some reason contained RT VIs, you could theoretically direct the VI to the rtutility.lib and the dependency would remain intact. Your issues are arising because the VI is being saved both under Windows and your RT Target. When the VI is saved under the RT Target, the VI reconfigures itself to run in the Real-Time environment, thereby dropping the explicit dependency to the rtutilities library. When you then open the VI again under My Computer, you must reconfigure the VI for a Windows environment and specify the dependency again. 

As you mentioned in your post, ignoring the missing VI will allow you to skip the dialog and will simply populate the block diagram with the missing VI question mark. The Call By Reference Suggestion is another way to make things more convenient if you absolutely need to keep moving the VI back and forth between environments."

You can either ignore the messages as being irrelevant, handle the message each time, or use call by reference to avoid it entirely.  Hopefully this information is useful to all of you, and I agree this behavior is less than ideal.