LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV2020 Project has errors after clone with GIT

Dear community and LabVIEW development team,

I have been using LabVIEW in combination with GIT for many years. Nevertheless, I often find that a project with no errors on one PC has errors on another PC.

 

It has just happened to me again. I push a project from my office PC to a GITLAB repository and clone it to a lab PC. I have checked the commit hashes for superproject and submodules, everything is identical.
Nevertheless, two errors are displayed on the Lab PC:

Firstly, a file is faulty, because the standard express VI "Display Message to User" is not found.

 

Secondly, in the case of a class, it is claimed that an interface VI has not been overwritten. However, the VI  is present in the class.

 

On both PC LV2020 + SP1 Academic Edition is installed. IMAQdx packages differ (20.6 in office, 21 in lab), but are not used in current project.

 

Can someone explain to me how this behaviour comes about?

 

 

 

 

0 Kudos
Message 1 of 10
(1,704 Views)

Did you tell GIT to treat .lvprojects and .lvclass files as binary files?

 

If you didn't GIT will at some point merge those files.

 

I'd post some links, but apparently Khoros cleared my favorites.

0 Kudos
Message 2 of 10
(1,664 Views)

I have had issues like this before it is usually cased by a .lvproj bad path. 

 

1) The path in the .lvproject does not match the path on your computer so it cant find things. 

2) The project can link to the wrong .vi on your computer if the .vi gets moved and you don't realize it, the .vi will stay in your project but not be tracked by git and cause errors on other computers 

 

 

I have found that letting the project manager handle the .vi locations helps quite a bit. I used to not use .lvlib at all, and that was a dark time.  Now I always use .lvlib nested in classes nested in .lvlib. I always create new .vi in the class .lvlib so it sticks it in the class .lvlib directory . It helps keep things more portable. 

 

I also like to merge .lvproject and .lvclass using git. They are xml files so you can see when and if paths are changing. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 3 of 10
(1,628 Views)

@Jay14159265 wrote:

I also like to merge .lvproject and .lvclass using git. They are xml files so you can see when and if paths are changing. 


Well, good luck with that.

 

If you don't merge you can still see paths changing (e.g. in Diff). But your files won't be corrupted.

 

The GIT merge doesn't know anything about the contents of those XML files. For example, if you add and delete VIs from a class in different branches, the class file will be merged regardless the actual VIs that are in the class.

 

I know a lot of people got burned by GIT merging .lvclass and .lvproj files. So I do mean it when I wish you good luck with it, but I don't recommend it.

0 Kudos
Message 4 of 10
(1,613 Views)

Ah yes, let me elaborate on that, I do a manual merge using vs code not an auto merge, I agree that git has no idea what a .lvproj file is, hell git has no idea what an .xml file is. I merged .lvproj and .xml files enough times to understand how to do it successfully (manually). I work with a group of jr devs that sometimes do not follow best practices and I can always catch them misbehaving when I merge the .lvproj file back into master. Any way, your mileage may vary. 

 

Besides if you have never fixed a corrupt .lvproj file, now is as good a time as any to learn : ) 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 5 of 10
(1,600 Views)

@Jay14159265 wrote:

Ah yes, let me elaborate on that, I do a manual merge using vs code not an auto merge, I agree that git has no idea what a .lvproj file is, hell git has no idea what an .xml file is. I merged .lvproj and .xml files enough times to understand how to do it successfully (manually). I work with a group of jr devs that sometimes do not follow best practices and I can always catch them misbehaving when I merge the .lvproj file back into master. Any way, your mileage may vary. 

 

Besides if you have never fixed a corrupt .lvproj file, now is as good a time as any to learn : ) 


In my experience, fixing a corrupt lvproj file isn't the hardest thing.  The hardest thing is deciding which entries you should keep.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 6 of 10
(1,592 Views)

Just found my bookmarks. They where not deleted, just so well hidden it's almost less work to find the posts with google...

 

LabVIEW and git - NI Community

LabVIEW and git - NI Community

 

Two posts, with the same name.

Message 7 of 10
(1,579 Views)

wiebe@CARYA wrote:

Did you tell GIT to treat .lvprojects and .lvclass files as binary files?

 

If you didn't GIT will at some point merge those files.

 

I'd post some links, but apparently Khoros cleared my favorites.


Hello everyone, thank you for lively discussion and apologies for my long silence due to Christmas holiday.

 

@wiebe@CARYA:  No, I haven't. I was even not aware of this possibility. I'm excited to see if this fixes the problems.

 

@Jay14159265: my project is based on Actor framework. So each class is in its own .lvlib.
The absolute path to the project has changed. Maybe a problem is that the submodules are in the same directory level as the calling application.

And it sounds like I occasionally need to look into .lvproj and .lvlib files...

0 Kudos
Message 8 of 10
(1,557 Views)

Yesterday I finally had some time to investigate the issue. I could solve it, but am a bit baffled... Now step by step:

I created a .gitattributes file for project and submodule:

 

*.lvproj binary

*.lvlib binary

*.lvclass binary

 

Commit -> Push to repo -> Chekout to lab PC. The same error occurs that an interface method is not overwritten 🤔

Then I copied the project from Office PC to Lab PC manually to a separate folder. No errors are reported in this case.  I compared the lvlib, lvclass and lvproj files in with Notpad++. Notepad++ did not show any differences. After that, I used WinMerge (a really nice tool!) to compare whole folder structure. The only difference WinMerge showed me was that in text files the line endings were in Unix style on the lab PC, but in Windows style on the office PC... Actually this should not be, because GIT is configured with

 

git config --global core.autocrlf true

 

so that on commit the line endings should be in Unix style and on checkout in Windows style. I then left in the problem project folder the .git folder and manually copied the LV project from office PC. GIT showed changes in the lvlib and lvclass files. So far so good.  Then I have run a revert just for fun and expected that, the error should appear again. However, it did not! I am pretty surprised...

 

The realization is: LabVIEW gets confused with different line endings.

 

How the behaviour from the GIT side comes about is unclear to me. Especially since it should treat the files as binary.

0 Kudos
Message 9 of 10
(1,494 Views)

Over here it says:

 

You almost always want autocrlf=input unless you really know what you are doing.

 

I never touched this option. But I absolutely do not know what I'm doing (when it comes to autocrlf)...

0 Kudos
Message 10 of 10
(1,473 Views)