I have a VI that I have run in Windows for a long time with no problem. A portion of the code makes a call to Get Exported File Path, and the PPL path input is wired to of course a path constant that points to my PPL location.
I am now running this same VI in Linux. Each time it gets to that node, I get an error: "<path_to_lvlibp>/view_support_lib.lvlibp is not a readable library" and it errors out.
In this same VI, I reference a custom control and another VI, both located at basically the same path as the lvlibp (I say that to say, I don't think the issue is for instance a space in the path, because then those things would fail as well).
More broadly speaking, to try and debug this problem I placed a path constant down and then tried to browse to my lvlibp. I can get all the way to the lvlibp, and experience tells me that when I select the lvlibp itself in Windows, it then opens up and wants me to pick a VI from inside the lvlibp. But in Linux, when I select the lvlibp itself, the same error window pops up that I mentioned previously where it just says its not a readable library.
To make thing easy, I went and opened up the file permissions on the lvlibp to 777, but it made no difference. I can select the 'problem' lvlibp when running LabVIEW in Windows with no problem. So in summary, there's a problem only when I try to browse to that lvlibp from within Linux...any suggestions on what I can check?
Thanks in advance
Is this a packed library you created yourself? Packed libraries are compiled for specific targets, so you won't be able to use them cross-platform, if you have the source code for the packed library then you can recompile for use on Linux.
yes it is...you make a very valid point, it seems like that is the issue...now I'm wondering if I can even do what I need to.
Short background - I use VI scripting to parse through a directory and create several VIs from the text files in said directory. I then have a separate executable VI that I use to 'view' those output files. The exe is basically a window, and into that window I load one of the other VIs I mentioned that gets created automatically that lets me look at a part of our chip dynamically over Ethernet.
To keep this as portable as possible, I use an lvlibp and my VI script creates and wires together nodes from within the lvlibp. As I mentioned before, this all works great in Windows...I run my top-level VI, and out comes all these VIs dynamically created from the text files.
The issue I was trying to solve is that I need this to happen automatically each time our chip is built. This means running it in Linux since that's where all our other tools reside. I wrote a script that basically opens LabVIEW and passes in the params, i.e. does what I did manually in Windows...but as I mentioned previously, fails when it tries to place the nodes from the lvlibp.
So it sounds like a solution would be to rebuild the lvlibp for Linux. So I have 2 questions:
1. ultimately, the final executable will always be run in Windows...so does this mean that if I fix this problem for now by targeting Linux, that then the issue will be that the "viewer" EXE won't run in Windows (because each time it opens one of the dynamically generated VIs, that dynamically generated VI will have an lvlibp call in it that was targeted to Linux)
2. how do I target Linux? I don't see that option in the build properties, so is it a matter of, whenever you build the lvlibp, it simply targets the host OS?
Thanks for your suggestions.
maybe a simpler question is in order - ultimately all I need to solve is that I want the Linux version of LabVIEW to place a VI from within an lvlibp that targets Windows...I don't need Linux to run said VI, just to place it down (as I mentioned before, all of these VIs will ultimately only run in Windows, I am just using Linux as a build environment since that's where the other tools reside and we don't currently have a Windows server).
I can understand the LabVIEW would throw an error saying, sorry, can't place down this node because I can't open the lib its in...but is there a way to force that since I know I won't be running this thing in Linux?
Is this something that you might be able to use an LLB for instead of an lvlibp? It would still keep your code portable as you package the VIs you need into a single file, but get around the "needing to be compiled" bit.
Here's a simple scripting example where I add a VI from an LLB (LV2017). The VI path uses the LLB name as a directory (maths.llb\add.vi), even though it's a single file on disk.
Reports of the demise of the llb seem to be premature. 😄
Thank you for the suggestion...I understand what you are suggesting but so far am having trouble implementing it. I added all my 'support' VIs to a single LLB, which I built and then placed in the same directory as my output executable...but when I run the exe it can't find the subVIs it needs (i.e. the ones in the llb).
I must be doing something wrong but right now I'm not sure what...any llb creation examples you can point me to? Thanks,..
To provide more detail...I took note of all the files I had in my lvlibp (under the assumption they are the same ones I'd want in an llb). I moved all of them out of the lvlibp into a new folder I called support. I then added a new build spec called support_llb, and followed these instructions to build said llb.
I then opened one of the 'dynamic' VIs that I intend to view with the executable, and changed it's block diagram to call the subVI inside the llb as opposed to the one inside the lvlibp.
I build the exe and the llb, moved both of them to the same local directory (so that the llb and exe are located in the same dir), then ran the exe. It loads the view of the dynamic VI, but never finishes loading it such that I can interact with it (my trial and error w/ the lvlibp leads me to believe this is because it can't find the subVI located within the llb, it exhibited the exact same behavior when it couldn't find the subVIs inside the lvlibp).
Here's some pictures that show my issue as I suspected...I hacked up some code so that I could remote debug. Recall as stated in my previous post I built the llb, then I commented out the offending code to force it to load so I could see what's going on. Notice the big question mark in the box on the left, and the error in the window when I hover over it.
But here's the part I don't understand...it says it can't find it there, but the llb manager clearly shows it's there...notice the paths match and IP_wrapper is clearly there. I'm perplexed....