vi.lib VIs missing from RTE

[John Lokanis]

I have run across a strange issue. I have some code that calls FP driver VIs (from vi.lib). These VIs are loaded dynamically by an EXE (plug-in architecture). I build the library of these VIs for distribution using OpenG (target: llb). I also exclude the vi.lib VIs since these should be included in the RTE. This has worked fine for all my code up until I starting using the FP VIs. (FP Open.vi, FP Read.vi, FP Write.vi, FP Close.vi).

It seems like these VIs are missing from the RTE vi.lib. Very weird.

Does anyone know how to have the OpenG builder include just some of the VIs from vi.lib that a particular VI has dependencies on? I don't want to include everything from vi.lib in my LLB distribution or it will be huge.

thanks for any ideas.

-John

[asbo]

I don't know that you could make an exception like that, but an unfortunate but functional solution would be to copy the VIs you use out of vi.lib and keep them in your source directory so they're included like your other code.

[John Lokanis]

Yes. That does solve the issue, but it adds 600k to the size of my library...

[Neville D]

Might have something to do with the fact that FieldPoint modules have very little memory and slow processors, so the RTE on FP might be very different than the normal LV-RT install on a PXI for example.

Are you building it under a FieldPoint target in the Project?

N.

[John Lokanis]

I use the 1804 FP unit that does not have a controller. So, the RTE I am referring to is the one for a Windows machine.

[LAVA 1.0 Content]

QUOTE (jlokanis @ Jun 9 2009, 08:52 PM)

Does anyone know how to have the OpenG builder include just some of the VIs from vi.lib that a particular VI has dependencies on? I don't want to include everything from vi.lib in my LLB distribution or it will be huge.

thanks for any ideas.

-John

So you know which VIs are troublesome (from trial and error), what you could do is build an additional library with just these VIs placed inside a container VI (similar to an 'old' tree VI), and load this container VI into memory of your RTE, I am not sure if this will work since it might require a recompile of the library VIs.

Another option is to exclude the vi.lib but have a call-back VI loaded with OpenG builder that includes the troublesome VIs into your distro.

My advice is to open up the builder sourcecode and see which specific call-back VI you need.

Ton

[Chris Davis]

QUOTE (jlokanis @ Jun 9 2009, 01:52 PM)

FP Open.vi, FP Read.vi, FP Write.vi, FP Close.vi

You might want to make sure you have included the DLL that these VIs call (FPLVMgr.dll) where it can be found by the VIs. When you bundle as an LLB using OpenG Builder, it doesn't know that it needs to include the DLL for use in an executable. If you are getting an error 1003 when you try to run the llb code, you may just be missing the DLLs.

[John Lokanis]

Yes, that was a problem at first because the DLL was in the 'data' support folder of the EXE. Once I moved it into the same folder as the LLB, the error 1003 went away.

So, now I have bundled all the vi.lib VIs into my LLB, got the DLL in the right place, made an iak file of all the cFP units in the whole factory and tweaked the:

C:\Program Files\National Instruments\Shared\FieldPoint\LabVIEW\fpconfig.ini

file so it has an alias that points to my iak file, I can finally run code that uses the IO Point input to the FP VIs using a string derrived from a script file! I have achieved data driven cFP nirvana! WooHoo! Now I can deploy and only need to update the iak if the IPs change or we add new hardware! And it is 10x faster than the old method (using LOGOS calls via DataSocket).

I must say, however, what a PITA this was. And completely undocumented by NI.