Broken vi packed project library (lvlibp)

[anony-mouse]

I have a labview library with no reported errors.  I compile this library into an lvlibp and 2 VIs have broken arrows with no errors listed.  I can open the packed project library and recompile the code and the arrow goes away but since I can't save back into the lvlibp then the next time I close and open labview I have to do the same recompile.  I tried recompiling and then rebuilding with no success.  The broken VIs are the LVOOP where the parent and ancestor classes are both lvlibps as well if that helps any.  Any ideas?

I have attached the project, code and packed project in question.  It is the I-7063.lvclass: Digital read.vi and I-7063.lvclass: Digital write.vi that are broken.

[Tortu]

Greetings anony-mouse

I took a look at your code and reproduced the issue on my end. At this time, I’m trying to find an explanation of your issue. I will keep you posted, and please let us know of any breakthrough that you have.

Regards.

[Tortu · Accepted solution]

Greetings anony-mouse

I apologize for not getting back to you sooner. I have been trying to find the root of the problem, but it has continued to elude me. However, one thing that I have noticed is that every time I load your project, it gives me warnings related to dependency paths. I ignored them at first but when I tried fixing them I realize that some elements expect the libraries to be in one path and other elements expect the same library at another path. It is possible that the compiled project packed library is getting confused and this may be related to the problem. After all, the description of the LV Class Default Value VI states:

"Returns the class data for the class whose path you wire to the path input. If the class is not in memory, LabVIEW attempts to load it from disk..."

The important part to note is the second sentence.  The first thing this VI will do is to look at the LabVIEW class name that is in the path.  If that class is already in memory then it will load the one in memory.  This is both a speed benefit as we don't have to read from disk but it is also a language benefit.  This prevents us from loading two classes of the same name into the same application. This behavior may explain why your packed project library is failing.

Try to clean up the references in your project and compiling the packed project library again, and tell us if that solve the problem. Have a nice day.

[anony-mouse]

That does seems to have fixed the issue.  Thanks!