03-06-2024 09:35 AM - edited 03-06-2024 10:21 AM
Hello everyone.
I have two identical Labview projects, one is practically a copy of the other, I have copied each vi with some small modifications but everything is relatively the same.
In both projects I use the same .lvlib which is in the location C:\Program Files (x86)\National Instruments\LabVIEW 2020\vi.lib\xxxxx\yyyy.lvlib. I drag this library directly into my project.
This is a Veristand Custom Device project but I think this is not relevant to my problem.
When I do the "built" of the configuration release of the project (all the built configuration is also identical in both projects) a library is created in National Instruments\NI VeriStand 2020\Custom Devices\(ProjName)|Windows\ called "ProjName Configuration" . When this file is created, when opening the system explorer initialization vi from this created configuration folder it has the arrow broken while in the project the arrow is not broken. In the original Project this does not happen, I can build and no arrow breaks. The reason for the broken arrow has to do with the library (it marks all the vis that I use from this library):
ROOT CAUSE: Dependency is broken.
When I enter the I saw that has the broken arrow it says the following: The library specified for this node cannot be found or cannot be loaded. Right-click the Call Library Function node and select Configure, then choose the correct library name or path.
This only happens in the new project but not in the original.
Does anyone know what I'm doing wrong???
Thank you so much!!
03-06-2024 09:49 AM - edited 03-06-2024 09:58 AM
The following is important to understand the problem:
In both projects, I right click and explore on the library, both take me to the same location (the one I already mentioned above), but if I open any vi of this library from both projects, 2 different vis open (I think I'd rather be the same).
When I open that same vi directly from the hard drive and not from the labview project, a third vi is not opened, but rather the vi from my original project is highlighted as if the copied project was pulling from somewhere else in memory, but in theory is the same..
03-06-2024 09:59 AM
It sounds like you are missing a DLL, or the path to it is wrong. Click on the broken run arrow and follow the error down until you reach a Call Library Function node. Then right click on that and open its configuration. You should find a path to the DLL it needs. Even if it's right there in the same folder you will probably need to specify the path. If that makes one of the errors disappear, you will have to do the same for all the CLFNs.
03-06-2024 10:00 AM - edited 03-06-2024 10:20 AM
I Think he following is important to understand the problem:
In both projects, I right click and explore on the library, both take me to the same location (the one I already mentioned above), but if I open any vi of this library from both projects, 2 different vis open.
When I open that same vi directly from the hard drive and not from the labview project, a third vi is not opened, but rather the vi from my original project is highlighted as if the copied project was pulling from somewhere else in memory, but in theory is the same..(I think I'd rather be the same)
03-06-2024 10:08 AM
But I would have to do that in the vis of the folder that is created when doing the build, what I want is for everything to turn out well when doing the build, and not correct the vis of that file that is created after doing the "build".
I don't understand why I have to modify these vis of the .lvlib library if they have always worked in the rest of the projects and not in this one.
03-06-2024 10:14 AM
Hmmm, I think you are right that this should just work. Honestly, I have never used any LVLIBs that contained VIs that called external code.
Hopefully someone with more experience with Call Library Function VIs will see this thread and suggest an answer...
03-06-2024 10:19 AM
No sir, the lvlib does not have vis that call external code, it has vis that are only used in this lvlib and I use the library in different projects, while in one project it does not give me problems, in this one it does. I don't know if it has to do with some type of library configuration in the project, but I see that everything is identical to the one that does work...
Thank you very much too!!
03-06-2024 12:49 PM
I was going by the error message in your first post. It says you are using some Call Library Function nodes. Those are yellow or orange VIs that allow you to call external code in LabVIEW.
Try to find one by clicking your broken arrow. That should open the error list.
Double-click the blue line that says: Call Library Function Node: No Library Specified and it should open a VI with that node:
Right-click and select Configure...
Make sure that the Library Name or Path is the same as the one in the project that is not giving you errors.
03-07-2024 01:48 AM
I was doing that, in that route everything is fine, but equally, what I need is that when doing a build everything turns out well, and not having to go to the project that has been built to change anything.
In the project from which I start to build there are no broken arrows, the arrow is broken in the project that is built. The original, the project on which I built, has everything right.
In other projects I use the same library, I do built and the arrow does not break, so I think the problem is not in the vis of the library but in the way of calling this library from the project from which I am doing built .
03-07-2024 04:24 AM
update:
In the original project, I do "find callers" on the library and a vi appears in the dependencies (read excel file.vi) and the library "system explorer.lvlib from veristand.
If I do the same in the vi that I replicated, it tells me "no items were found". In this project there is also the same vi "read excel file.vi". This saw, in the disk memory, it is in the same library folder that is giving me problems. The vi "read excel file.vi" is the same in both projects, in the same location, but in one case it appears as a library caller and in the other it does not....