Error at opening VI reference in Packed Project Library

[Jens_Moehring]

Hello together,

we are experiencing a weird problem regarding dynamic vi calls in a packed project library in LabView 2014 and 2015. The packed library is used as a plugin in our application. When we open a dynamic vi reference to call a method of the plugin we experience two different behaviors:

• When we open the frontpanel of dynamic called vi programmatically all reference open methods succeed.
• When the frontpanel is closed we get alternating:
  1. A successful vi reference open operation
  2. Error Code 7 from "open vi reference" (Internally in the error message error code 56 from the packed project library is mentioned)

This alternating error behavior is highly stable and not timing dependent. It can be repeadted endlessly. Each call opens the reference, executes and close the reference. We checked our reference closing procedures and all references are close properly after using.

I checked the forums for similar problems but did not find anything. Did anyone experience something simillar? Unfortunately, as the problem occurs in a very large application, it will not be easy to break down the issue to a simple example.

Thanks

Jens

[Norbert_B]

Jens,

how does your Open VI Reference look like? What are the options you wired up? Is it a static path, relative path or VI name you wire up for the VI?

Error 7 means: File not found. This could indicate some issues with relative <-> static path conversion.

Speaking for your first bullet: The open front panel makes sure that the VI is always in memory (as long as the panel is open OR a valid reference to the VI is still used).

My guess is that the application unloads the VI and you try to get the reference by VI name only....

Norbert

[Jens_Moehring]

Thanks for the suggestions regarding my post. I tried to create a minimal example of the calling system, just opening and closing the reference without any execution of methods. Here we can observe the described behaviour by requesting the vi reference in a loop.

 

We checked the possible problems of relative paths, but we used only absolute paths like in the example above. Depedingung if the case is using the FP.Open function we get two different results:

Just opening the VI by hand yields the same results.

Jens

[Sam_Sharp]

Could this be related to something I seem to have in the back of my mind that certain VI Server calls and/or reference closes are actually asynchronous so it takes another loop of the for loop for everything to actually close to be opened again - what happens if you put a 100ms wait in the for loop?

[Norbert_B]

Jens,

what bothers me is that the error seems to occur on the iteration '0' if the "Open Front Panel" option is false.

Question: The false case of the case structure simply connects the wires (error, reference) without further content?

It seems that the calling VI is NOT part of the lvlibp. Is that correct?

Can you also check for the file path output of the Get Exported File Path VI is it is correct at any iteration?

thanks,
Norbert

[Jens_Moehring]

Thanks a lot for the helpfull suggestions.

I think we finally figured out the issue we were facing. It seemes we messed up the labview project during the built of the packed library dependencies. I think the main reason for our issue was that we copied packed libraries with dependencies to each other to different relative paths after building them. This resulted in some automatic relinking to new paths while loading the main project. It seems like this resulted in some name conflicts. I think this leaded finally to the issue with the dynamic call.

We resolved the issue by carefully rebuilding the libraries step by steo from an earlier version from our repository. All builds were directly pointing to their final relative paths inside the application. This removed the relinking issues at project loading. After this we did not have the dynamic call issue any more.

Best regards

Jens

[Jens_Moehring]

Unfortunately I was too quick with my positive review of the problem. After recheck we found it still present. I boiled it down a minimum example. From my point of view this example reveals a bug in the LabView (2015) environment.

When I just call a “get reference” for a member function of a class inside a packed library, everything is OK. But when I independently get the class standard values by the “Get LV Class default value.vi” without doing anything with it, the get reference operation fails every second time with the failure mode described above (error code 7).

The “get reference” call to exactly the same function does never fail if I move it out of its class but keep it still inside the packed library.

To review the behavior, have a look at the following images. Furthermore, I will attach a minimum example project.

[Jens_Moehring]

Just to add a few more bits to the issue I have described:

- Adding delays at various points does not alter the behaviour.

- I checked the status of the vis in memory described in the last paragraph of http://www.ni.com/tutorial/14393/en/ - "Asynchronous Behavior of the Close Reference Function" by using the property "Get all Vis in Memory". The dynamically opened vi is not in memory any more after closing the reference in all cases.

Maybe someone hast still an idea what I can furthermore check.

Thanks a lot

Jens

[Cepera]

I have a similar experience using packed libraries: every other call to a VI in one of my packed libraries fails with the following message:

Error 7: Open VI Reference in EmbedTest.vi->_Tester.vi->_SolidusTestExec.vi<APPEND>
An error occurred loading VI 'ICal Visual Inspection.lvlibp:_Panel.vi'.
LabVIEW load error code 56: Could not find VI in the packed library. You might get this error if you load a VI in a packed library with the same name but different path than the pack

VI Path: <b>C:\Solidus\Test Exec\Tests\ICal Visual Inspection.lvlibp\_Panel.vi</b>

Interestingly, even though Open VI Reference returns an error, the VI is loaded into memory. Because of the error, a reference to it (after an unsucessfull Call By Reference) fails to close, so it stays in memory. Next time I call Open VI Reference to the same path, the VI is alreay in memory, and everything goes well, so after its Call By Reference, the reference is closed correctly, the VI unloads, and now the next attempt to open its reference fails. Thus the call succeeds every other time

A few more notes: (a) I do not use classes. (b) I use this approach with at least one more similar packed library, and it works every time.

I suspect that something got cross-linked in the packed library, but I cannot see it in its project. It probably happened because I created it from another "template" library and then moved its VI's into it. I'll try to recreate it from scratch and I'll ost the result.

[Cepera]

It looks like I was able to fix the problem:

1. I copied all VI's that were part of the library to a separate folder and deleted the project and the lvlib file. With all projects closed, I opened each VI; they all opened with an error that they could not find the library file. I disconnected each VI from the library (File | Disconnect) and updated subVI's and controls, so that evenually each VI had no errors.

2. I created a project and a library in it and added all VI's to this new library. After that, I created a packed library distribution in this new project and built it. At this point, everything worked: my main application had no trouble calling the packed library every time.

The takeaway for me is this: keep your template VI's outside of a library in a separate folder (e.g. Template). When you want to create a library, COPY them to a new folder structure, then create a project and a library and add them to your new library from that new folder structure. Don't try to create a new project and library from existing projects/libraries.