What is the purpose of the VIs in Labview\Targets and Labview\Resource?

[Daklu]

I am in the process of breaking down all the NI-supplied VIs our modular application depends on into individual packages that can be installed via opkg.  While looking through the list of dependencies, I've noticed there are several VIs that are used from places other than vi.lib, such as...

Labview\Resource\Framework\Providers\lveio

Labview\Resource\RVI\commonUtilities

Labview\Resource\RVI\CommunicationInterface

Labview\Resource\RVI\compliationResultUtilities

Labview\Targets\NI\FPGA

Labview\Targets\NI\RT\vi.lib

Q1:  My understanding has been that VIs placed in these directories provide functionality for the development environment and wouldn't be used by an application deployed to the target, but the evidence suggests I am wrong.  What functionality do these VIs provide?

Q2:  In the last directory there is a library named NI_Real-Time Target Support.lvlib.  Looking at the library file, it expects all the member VIs to be in <vi.lib>, not in Targets\NI\RT\vi.lib.  Am I correct in guessing this library is intended to be copied down to the target's vi.lib as-is and is NOT used in the dev environment?

[BradM]

Daklu,

I'm still not quite sure what the big-picture, end-goal is here. Why would you need to package up some of the VI hierarchy that's normally deployed when working with an RT target? If you're looking to install G through ipks, this is not a supported use-case and, depending on the end-goal use-case, may not work correctly.

From my time on the LVFPGA team, I can tell you that some of those folders include G that will be required anytime that you're interacting with a bitfile or talkikng with the RIO driver, so it will absolutely be required to run code that interacts with LVFPGA at runtime (desktop or RT target).

[DaveSnyder]

Brad,

We have a highly modular system that is currently deployed to hundreds of devices globally over cellular networks.  We have a small executable to bootstrap the system, but all our components are built as source distributions and loaded at runtime.

I need to package vi.lib (and other NI provided VIs) because our components depend on many of the same VIs.  If I include those depenedencies in multiple packages, uninstalling one package will remove that dependency, breaking the rest of the packages.  (opkg wasn't designed to handle the same file in multiple packages.)

Here are the options I see:

1. Break vi.lib into components, mapping out the dependencies, and figuring out how to build them into ipks.  This is the most desirable solution, as it adheres most closely to how packages are intended to function, minimizes bandwidth costs, and reduces deployment complexity.

2. Create a single package for all of vi.lib (that is used by any component.)  This is wasteful.  Any change in dependencies will require downloading the entire package again.  Lots of the bandwidth will be used downloading VIs that aren't used by that particular device.

3. Continue doing what we did with VxWorks and have each component include all the dependencies it needs to function.  Using our home-grown installer, duplicate dependencies are overwritten when new components are installed.  Nothing in vi.lib is ever uninstalled.  This is also wasteful, as lots of duplicate code is downloaded.  Furthermore, it also exposes us to the risk of having different versions of the same file in two different packages, meaning order of installation could affect device behavior.

"If you're looking to install G through ipks, this is not a supported use-case..."

This statement concerns me.  Other people I've talked to in NI have indicated opkg is the intended path for installing optional G components on the device.  Has this changed recently?  We have successfully run tests using opkg to install our components on the device.

"...depending on the end-goal use-case, may not work correctly."

Unfortunately, not working isn't an option for me. 

[BradM]

Thanks for the background.

I talked with someone who's a bit more familiar with how the LV RT host side cross compilation and deployment works, and it seems that building things as a source distribution (making sure to build all of the aspects of the "source distribution" files) may net what you want. I blame the fact that I deal mostly with the OS side of things

DaveSnyder wrote:

...

"If you're looking to install G through ipks, this is not a supported use-case..."

This statement concerns me.  Other people I've talked to in NI have indicated opkg is the intended path for installing optional G components on the device.  Has this changed recently?  We have successfully run tests using opkg to install our components on the device.

...

I'd be interested to know where you heard that, as the tools to build ipks are pretty much Linux-only as it stands, while RT development needs a Windows host since the RT plugin is Windows-only.

In theory, you should be able to build a source distribution, including all of the .libs, copy the resulting files to a linux machine and use the tools for building ipks (such as http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils) to build an .ipk file (or files, if you split them up).

As it should be clear at this point, this is an area that I'm less familiar with, so take the non-ipk bits with a grain of salt (I know ipks and opkg-utils pretty well)

[DaveSnyder]

I've talked to several people over the past year or so and can't remember who told me that.  It's possible I misunderstood what he meant.

"In theory, you should be able to build a source distribution, including all of the .libs, copy the resulting files to a linux machine and use the tools for building ipks (such as http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils) to build an .ipk file (or files, if you split them up)."

This is exactly what we do.  It works, though it is rather cumbersome.  I'm hoping to eventually automate the entire process through Jenkins.

Back to my immediate problem described in Q2 above, currently I can't do a source distribution build of the NI_Real-Time Target Support library because pulling it into a project creates all sorts of broken links.  I could copy the entire thing over to vi.lib and build from there, but I'd rather not do one-off exceptions if I don't have to.  Can you find some information on how this library is used, built, and deployed to the target?

[ASLindeman]

Daklu,

http://forums.ni.com/t5/LabVIEW/RT-Utility-VIs/td-p/418314 is directly related to your question.

From the looks of it, the "Targets" portion of the library was broken out at LV 8.x in order to allow for target-specific palettes. So the "Targets" VIs should show up in their current folder, as opposed to mis-linked to vi.lib as long as they are introduced into the project under an RT Target.

Best regards,

Adam