My lvlib paths/URLs are obviously absolute

[flintstone]

Hi,

 

I have the problem that the projects that I and a colleague developed cannot be built by our automatic build system, there are VIs missing which are part of an lvlib which we created. I managed to reproduce the problem by checking out to the same path as the automatic build does and there the lvlib does not find it's VIs either. Looking into the lvlib file with a text editor I saw paths (or URLs as they are called there) that equal our development environment. For trying I changed them in the text editor to the location where the build shall happen and, voilà, the lvlib would find it's VIs again.

 

So these URLs are for sure absolute paths which are used to find the VIs. But from what I've read I understood that the lvlib (at least outside of vi.lib and user.lib) stores relative paths, so either I didn't get the point or something goes wrong there or it's a LV bug.

 

Whatever it is but I really need to get this working so one option is to change the paths for the time being to relative paths. I tried with the format "./<subfolder>/<VI name>" but the dot is then replaced by the library name (which is, of course, not a valid directory). Does anybody know how to enter there a valid relative path?

 

Thanks and cheers,

flintstone

 

[flintstone]

Hi,

 

I know checked vs an earlier revision of the projects that would work with automatic build (again in the text editor) and there are relative paths used for the VIs of the lib. So at least I know now how to fix it for the release which is due now.

 

But since I'm 150% sure that neither I nor my colleague decided to make these paths absolute (and I also do not find the corresponding setting in the GUI) I assume it must have been done automagically by LV. And I have to say, this is not acceptable. I cannot check manually the paths before handing this over for automatic build.

 

Maybe someone can identify possible errors we did or give a hint how to force LV to use relative paths everywhere and anytime (apart from the "standard libraries" of course).

 

Cheers,

flintstone

[Ton Plomp]

Very strange, have you moved VIs around without using the Project explorer?

 

I have not seen this issue.

 

Ton

[flintstone]

With SVN diffs I could find the revision where the change from relative to absolute paths happened. My colleague did this commit after having fixed another very strange problem where cluster elements were resorted and we did not know how this happened.

 

This all gives me an extremely bad feeling, my fear is that the cluster resorting and the relative/absolute path problems are only symptoms of some underlying problem and we cannot trust the code as it is now because we only saw the effects that would actually break something but if e.g. cluster resorting has happened with values that have the same type then the error will only be found by misbehavior of the actual device or code inspection. Both is not desired .

 

Cheers,

flintstone

[JackDunaway]

... Looking into the lvlib file with a text editor...

 

Can you post a sanitized version of the LVLIB XML?

[flintstone]

Yes, you can find a before-after comparison below. I took out all Item sections but one and replaced folder names there with dlevel1 ... dlevel6 up to the directory where the lvlib file is located.

 

Thanks and cheers,

flinstone

 

XML START

 

BEFORE:

-------------------------------------------------------------------------------------------------------------------
<?xml version='1.0' encoding='UTF-8'?>
<Library LVVersion="10008000">
 <Property Name="NI.Lib.Icon" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!(]!!!*Q(C=>7R=2MR%!81N=?"5X<A91P<!FNA#^M#5Y6M96NA"R[WM#WQ"<9A0ZYR'E?G!WPM1$AN>@S(!ZZQG&0%VLZ'@)H8:_X<^P(^7@8H4Y;"`NX;8JZPUX@@MJXC]C.3I6K5S(F/^DHTE)R`ZS%@?]J;XP/5N<XH*3VSEJ?]Z#F0?=J4HP+5<Y=]Z#%0/>+9@%QU"BU$D-YI-4[':XC':XB]D?%:HO%:HO(2*9:H?):H?)<(<4%]QT-]QT-]BNIEMRVSHO%R@$20]T20]T30+;.Z'K".VA:OAW"%O^B/GK>ZGM>J.%`T.%`T.)`,U4T.UTT.UTROW6;F.]XDE0-9*IKH?)KH?)L(U&%]R6-]R6-]JIPC+:[#+"/7Q2'CX&1[F#`&5TR_2@%54`%54`'YN$WBWF<GI8E==JE3:E3:E-51E4`)E4`)EDW%D?:)H?:)H?5Q6S:-]S:-A;6,42RIMX:A[J3"Z`'S*<?HV*MENS.C<>Z9GT,7:IOVC7*NDFA00><$D0719CV_L%7.N6CR&C(7(R=,(1M4;Z*9.T][RNXH46X62:X632X61?X6H(L8_ZYP^`D>LP&^8K.S_53Z`-Z4K>4()`(/"Q/M>`P9@<P<U'PDH?8AA`XUMPTP_EXOF`[8`Q<IT0]?OYVOA(5/(_Z!!!!!!</Property>
 <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
 <Item Name="Timing" Type="Folder">
   <Item Name="TIME_msecTimerTimeout.vi" Type="VI" URL="../Timing/TIME_msecTimerTimeout.vi"/>
 </Item>
</Library>
-------------------------------------------------------------------------------------------------------------------



AFTER:

-------------------------------------------------------------------------------------------------------------------
<?xml version='1.0' encoding='UTF-8'?>
<Library LVVersion="10008000">
 <Property Name="NI.Lib.Icon" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!(]!!!*Q(C=>7R=2MR%!81N=?"5X<A91P<!FNA#^M#5Y6M96NA"R[WM#WQ"<9A0ZYR'E?G!WPM1$AN>@S(!ZZQG&0%VLZ'@)H8:_X<^P(^7@8H4Y;"`NX;8JZPUX@@MJXC]C.3I6K5S(F/^DHTE)R`ZS%@?]J;XP/5N<XH*3VSEJ?]Z#F0?=J4HP+5<Y=]Z#%0/>+9@%QU"BU$D-YI-4[':XC':XB]D?%:HO%:HO(2*9:H?):H?)<(<4%]QT-]QT-]BNIEMRVSHO%R@$20]T20]T30+;.Z'K".VA:OAW"%O^B/GK>ZGM>J.%`T.%`T.)`,U4T.UTT.UTROW6;F.]XDE0-9*IKH?)KH?)L(U&%]R6-]R6-]JIPC+:[#+"/7Q2'CX&1[F#`&5TR_2@%54`%54`'YN$WBWF<GI8E==JE3:E3:E-51E4`)E4`)EDW%D?:)H?:)H?5Q6S:-]S:-A;6,42RIMX:A[J3"Z`'S*<?HV*MENS.C<>Z9GT,7:IOVC7*NDFA00><$D0719CV_L%7.N6CR&C(7(R=,(1M4;Z*9.T][RNXH46X62:X632X61?X6H(L8_ZYP^`D>LP&^8K.S_53Z`-Z4K>4()`(/"Q/M>`P9@<P<U'PDH?8AA`XUMPTP_EXOF`[8`Q<IT0]?OYVOA(5/(_Z!!!!!!</Property>
 <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
 <Item Name="Timing" Type="Folder">
   <Item Name="TIME_msecTimerTimeout.vi" Type="VI" URL="/dlevel1/dlevel2/dlevel3/dlevel4/dlevel5/dlevel6/Timing/TIME_msecTimerTimeout.vi"/>
 </Item>
</Library>
-------------------------------------------------------------------------------------------------------------------

[JackDunaway]

The only thing that jumps out is it looks like you're using LV2010 -- hopefully this issue would not bite you in later versions. Otherwise, it feels like a bug.

[flintstone]

Thanks for having a look, unfortunately I cannot switch to newer versions due to the project policy.

[Dan DeFriese]

I've never seen the lvlib resort to absolute paths, but if it is modified while in the LabVIEW directories (vi.lib, instr.lib, user.lib, etc...) it may get saved with symbolic paths instead of relative paths. As in this example from my instr.lib folder:

 

 

<Item Name="Aardvark Convert Error.vi" Type="VI" URL="/<instrlib>/aardvark/aardvaru.llb/Aardvark Convert Error.vi"/>
<Item Name="Aardvark GPIO Set.vi" Type="VI" URL="/<instrlib>/aardvark/aardvark.llb/Aardvark GPIO Set.vi"/>
<Item Name="Aardvark GPIO Direction.vi" Type="VI" URL="/<instrlib>/aardvark/aardvark.llb/Aardvark GPIO Direction.vi"/>
 

Could your source have been in these LabVIEW directories?

 

~Dan

[flintstone]

The paths in the lvlib file are not Windows path format so I guess they are symbolic, too. My colleague is already on Easter holidays so I'll have to wait until next week. I doubt he did exactly this but maybe he did something similar so thanks for the hint.

[Rolf Kalbermatter]

The paths in the lvlib file are not Windows path format so I guess they are symbolic, too. My colleague is already on Easter holidays so I'll have to wait until next week. I doubt he did exactly this but maybe he did something similar so thanks for the hint.

 

LabVIEW uses URL format for its XML based paths which happens to be always Unix style. Symbolic paths are rather something like "<instrlib>/aardvark/aardvark.llb/Aardvark GPIO Set.vi", however the HTML expansion does make that a little less obvious in Dan's post.

 

To my knowledge LabVIEW only should use absolute paths as reference if they happen to refer to a different volume. On real Unix systems this is of course not an issue as there you have one unique filesystem root, but I have a hunch your colleague may have accessed the VIs through a mounted drive letter. I could see that causing possible problems if the VI library was loaded through a different drive letter than the actual VI. Shouldn't usually be possible but its not entirely impossible. The actual path in the XML file may not show to be different because the path handling that determines if paths are on the same volume works likely on a different level and when the paths are finally converted to the URL style format they are most likely normalized, which means reducing the path to its minimal form and that could resolve drive aliases.

[flintstone]

We had a change of the VM infrastructure we are working on recently and also switched the drive where the project is located so this would match the information in your post. I will test this.

 

Thanks!

[Aristos Queue]

Rolf has the right answer... there is no relative path from one drive to another drive, so the path that gets stored is an absolute path.

[flintstone]

I'm still investigating and as I said I'll have to ask my colleague but we never changed the relative positions of the lvlib and its VIs. We changed the drive to which we check the whole project out, so I do not see a reason to use an absolute path there.

[Rolf Kalbermatter]

I'm still investigating and as I said I'll have to ask my colleague but we never changed the relative positions of the lvlib and its VIs. We changed the drive to which we check the whole project out, so I do not see a reason to use an absolute path there.

 

Well there might be some sort of bug in LabVIEW here, but it seems that LabVIEW for some reasons was made to believe at that point that the lvlib and the according VIs would not come from the same volume (drive). That is AFAIK the only reason for LabVIEW to use absolute paths when referring from one resource file to another one it would depend on.

 

When loading that lvlib, your collegue probably got a warning to the fact that VIs where loaded from a different path than where they were expected (maybe he had them still in memory loaded from the old path). This dialogue is however IMHO rather unhelpful in many cases, as it does not always give a good overview as to why this warning was created and offers even less possibilities to fix it.

[flintstone]

Since I cannot reproduce it with the few attempts I tried I'll have to wait.

 

For the dialog: Yes, I know it, I also find it confusing but this should not be the problem.

[jives]

I am the ominous colleague who checked in the revision that "broke" our VIs

 

A while ago we were forced to switch our checkout directory to a network drive. The actual switch went smoothly, and we did not see any of these path issues until later.

 

I have only one copy of our code, and this copy is always located on the network drive on my VM. I never open code that is located somewhere else if I have another project open at the same time. However, I definitley had the VI in question loaded into memory, because I had another project open at the same time, and this project uses the same lvlib.

 

I did get a dialogue that a VI was loaded from a different location, but this was a different VI (the NI-Motion find_buffer.vi). This VI is actually a part of <instrlib> as far as I know as well as located in our SVN as a local copy (because we had LV installations where this VI was located in a different path in <instrlib>).

 

I'd say we have a combination of all of the possible causes mentioned above - just not for the VI in question (TIME_msecTimerTimeout.vi).

Is it possible that other VIs inside an lvlib get affected LV changes a path from relative to absolute?

[flintstone]

So since we don't have any further input on this it will seemingly be unresolved.

 

This really gives me a great feeling about building a big and expensive system with this software ...

[Jordan Kuehn]

So since we don't have any further input on this it will seemingly be unresolved.

 

This really gives me a great feeling about building a big and expensive system with this software ...

 

While there are many NI staff that visit these forums, it is not guaranteed to get you a definitive answer on any question.  There are many users who are extremely knowledgeable about labview here, but if the answer is out there someone may have missed this thread or is just too busy.  Before getting upset about not getting this resolved I'd suggest contacting NI directly (this is a user community, not NI).  If you've got a good relationship with your sales guy or anyone at the HQ you may be able to bypass the AE department and get in contact with someone in R&D that can answer this directly.  Be sure to mention this thread.

[Rolf Kalbermatter]

So since we don't have any further input on this it will seemingly be unresolved.

 

This really gives me a great feeling about building a big and expensive system with this software ...

 

I would have to echo Jordan's comments. NI isn't perfect but certainly one of the better suppliers in software land. And as software developer yourself you should know that fixing a bug without a reproducible error procedure is very hard and often impossible. So far all that is mentioned in this thread are symptoms and possible reasons of what could have been a contributing factor to what you saw happening. Without more info about how to produce this error it most likely will be almost impossible to come up with a fix.

[flintstone]

As you saw I tried to reproduce the problem but I didn't manage. I'm with you that this is the kind of bugs that are almost impossible to find and fix. So even worse, I have a programming environment that most probably contains a bug that can destroy my projects. With a dozen different software projects and hundreds of VIs created by us as well as > 1000 VIs created by an external partner we cannot manage to do manual checks.

 

And, sorry to say, I dispute that NI is one of the better suppliers. I've worked in other environments and had not even half the number of problems. If I were the software manager in our project I would eat the bitter pill rather now than later and throw out all the LV code to replace it with C/C++ . This is an environment which is very stable and where long term support is provided.

[Jordan Kuehn]

Have you called NI?  Have you tried to resolve this problem with them?  If not, why are you complaining about NI not having a fix for your problem?  That's like me going to change my oil and complaining about how my car manufacturer has some strange problem with the shifter.  A problem that no one else can reproduce.  I don't think that NI is perfect, but you are being unreasonable.  If I were NI I'd tell you to go change your code to C++.  Your disposition would certainly turn me off from being an 'external partner' that would provide you >1000 VIs. 

[Rolf Kalbermatter]

As you saw I tried to reproduce the problem but I didn't manage. I'm with you that this is the kind of bugs that are almost impossible to find and fix. So even worse, I have a programming environment that most probably contains a bug that can destroy my projects. With a dozen different software projects and hundreds of VIs created by us as well as > 1000 VIs created by an external partner we cannot manage to do manual checks.

 

And, sorry to say, I dispute that NI is one of the better suppliers. I've worked in other environments and had not even half the number of problems. If I were the software manager in our project I would eat the bitter pill rather now than later and throw out all the LV code to replace it with C/C++ . This is an environment which is very stable and where long term support is provided.

 

You are unreasonable and you know that. Moving to C++ to make sure to not run into problems or bugs sounds like a plan, but a bad one. Which C compiler do you plan to use, GCC, Visual C, Intel CC, Borland C, Watcom C? They all are great but none of them is bug free and when you have managed a few more complex C++ projects you will know that, as you are sure to run into some code constructs that do not always get compiled right by some of them. Nothing that can't be worked around but still.

 

And that is just the compiler. Lets not talk about the IDE's that have all their obnoxious behaviors and bugs too. So the question at the end of the day that remains is what are the people at your company more familiar with and how much code can be produced and how bug free can you and your colleagues make your own code. Changing programming languages because of an (acquired) antipathy is a sure way for disaster.

[flintstone]

The problem with resorted cluster elements returned, this time in the way that I feared most, compilation is not broken so the system was built and deployed but is not usable now. Since there seems to be a problem somewhere in one of our base classes (not the library which showed the absolute/relative path problem) which has not yet gone away we can surely now go to ask NI for help.

 

Yes, I'm frustrated and maybe a bit too harsh sometimes. But I really had a number of problems which cost me a lot of time due so small programming bugs in NI software, see e.g. here http://lavag.org/topic/16218-lv-fpga-master-typedef-not-found-issue/ . And my decision to throw it out right away before more code is developed for this does not only come from my antipathy but also from the fact that we are building a machine which is supposed to run for 30 years and already within 3 years we had problems which required us to change and/or the LV software environment. The lack of a long-term support version in which small issues like this FPGA thing are fixed is imo a no-go for a serious long-term software project.

 

Compare this to other development environments where people keep the build environment together with the code to make sure that they can still fix issues years later. Compare this to the C/C++ world where 20 year old code (if done properly) will still work.

 

My grief is not only that a basic construct like a cluster is making so many problems, it's also that I don't see how we can build a durable solution. Something which I put there and then it just works.

[Jordan Kuehn]

Thousands of people use LabVIEW and NI products every day to great success.  I've made many systems that work day in and day out without failure.  Otherwise I'd be getting constant calls from our customers.  I don't know why you aren't succeeding, but I'm not certain you are pointing your fingers in the right direction.  You mention you have some code developed in house and some code developed by a 3rd party.  What made you bring in this party and are you certain everything has been integrated well?  I'd start with looking at the quality of their work.  Finally, if you are convinced it is an NI issue I am confused why you come here to complain about them not taking care of it.  Their support can take a while to filter up to R&D if you have a legitimate bug, but you will get there or will have your problem fixed.  If no one can reproduce it though, it is very difficult to not look back and ask what is happening with your system.