How to transfer a cRIO project to another developers computer?

[AD56]

I have a cRIO project that with all of my created files saved in a single root directory that is sourced controlled. When my coworker cloned down the project LabVIEW could not find the project libraries, resources, or "Targets" files. It was expecting for files to be in paths that aren't even mapped that way on my PC. The things I have attempted are:

1) create a source distribution. When I attempt to create a source distribution for the the crio project files (all of the "My computer" files are fine on my coworkers PC) the destination path is defaulted to "/home/lvuser/natinst/bin" which seems like a linux path. I tried to change the path to "C:\Backup_Test" but I get this error:

"The build is missing one or more source files or items the source files reference on disk." and If I click Yes I get "Command requires GPIB Controller to be Controller-In-Charge."

2) Copy files down manually. I tried to copy my vi.lib, Resources folder, and Targets folder to the source control and get my coworker to pull down those files to his program (x86) folder. This resulted in missing files at the location of "C:\Program Files (x86)\National Instruments\LabVIEW 2019\Targets". The files that labview was looking her in Targets aren't even on in my Targets. We manually copied the files that it was looking for to Targets anyways and... the RT vi was broken completely. Broken controls. blocking error. tons of errors.

How can I get this working! I've attempted to source control the entire project and that works great for the vi's that we made... but it's all the LabVIEW back end libraries/classes or whatever it's looking for that's the breaking project. Any suggestions?

[GerdW]

Hi AD,

what about using SCC to transfer VIs (and other stuff) between several developer computers?

[AD56]

Gard, I have the project files and it's subvi's/controls/etc source controlled already. With your suggestion I would need to source control my whole National instruments/LabVIEW 2019 directory which would mean the developer would have to replace his National instruments/LabVIEW 2019 directory with the source controlled directory. I can do this but since he and I have the same labview version, and the same libraries and the same source controlled project I was hoping that we wouldn't need to have the SAME labview directory.

Edit: I changed would to wouldn't*

[GerdW]

Hi AD,

why do you think you need to place vi.lib into SCC?

All you need to put into SCC is your "cRIO project"!

Me and collegue do several cRIO RT/FPGA projects and we share our project folders just by SCC! (We use the exactly same LabVIEW installation of modules and toolkits…)

[Jacobson-ni]

Hard to tell without knowing what files aren't being found on the second computer but I would suspect it is missing some Toolkit/Driver/Package. If you can show us what dependencies aren't being found we might be able to help point to any missing installs but I would start with making sure LabVIEW, Real-Time Module, FPGA Module, and cRIO device drivers are all installed.

[cbutcher]

I think Matt Jacobson has already suggested the main point (probably missing a LabVIEW component/package for cRIO or RIO Support or LabVIEW RT/LabVIEW FPGA or similar) but some further comments on your original post:

---

@AD56 wrote:

The destination path is defaulted to "/home/lvuser/natinst/bin" which seems like a linux path

---

This is the default installation location for the RT executable for Linux RT. Perhaps the source distribution targets the cRIO device, and is intended for copying there (e.g. if you had a large number of cRIOs and wanted to place the same code on all of them)?

---

@AD56 wrote:

2) Copy files down manually. I tried to copy my vi.lib, Resources folder, and Targets folder to the source control and get my coworker to pull down those files to his program (x86) folder. This resulted in missing files at the location of "C:\Program Files (x86)\National Instruments\LabVIEW 2019\Targets". The files that labview was looking her in Targets aren't even on in my Targets. We manually copied the files that it was looking for to Targets anyways and... the RT vi was broken completely. Broken controls. blocking error. tons of errors.

How can I get this working! I've attempted to source control the entire project and that works great for the vi's that we made... but it's all the LabVIEW back end libraries/classes or whatever it's looking for that's the breaking project. Any suggestions?

---

You definitely don't need to do this. Like GerdW, I also have cRIO+FPGA code that happily lives in Git SCC and doesn't cause me problems (at least beyond the typical minor frustrations with Git and LabVIEW).

[AD56]

The missing files were Modbus files, a 3rd party package that was already downloaded, and a bunch of folders under vi.lib like Utilities etc.

I finally got it working but I don't know why I needed to do this process. If someone could shed some light on why I had to do it this way please let me know.

I on my co-workers computer we had to pull the project from SCC and connect the the cRIO that I have been using. We mapped, manually, everything that we could (note that labview was looking at the right locations for a lot of the files but had "Targets" in the middle of the path which was incorrect. I assume targets really meant cRIO). The project was still broken, we saved, closed, and then opened the project and the RT main application and mapped one vi from each of the missing package/libraries. We then saved, closed, and opened the project again and then we mapped everything again including paths that we already mapped. At this point the window application and the real-time application were not broken anymore. We saved, closed, opened, and it was able to find all the files again. Keep in mind that all the files that we had to map/link to were all under Program (86)/national instruments/labview 2019! labview found all the files under the SCC repo easy enough.

Now my coworker can pull from git with no issues. Why in the world did we have to go through such a manual process! This is something that labivew should, and normally can, handle just fine!

[cbutcher]

vi.lib has a special type of link, so I'm surprised it didn't correctly find the files. I've only seen this type of issue when you don't have the files (so the project loses them) then they appear somewhere else (perhaps before installing, or after you download the sources from a separate repository, etc). If they get linked incorrectly, and the project is saved, then you'll have to manually relink them to vi.lib after installing them.

Hard resetting your project file once you had everything correctly installed might have helped you, but I don't know...

I guess if you have it working, you don't intend to re-break things just to find out!

[Jacobson-ni]

From my understanding, having targets in the vi.lib path isn't necessarily incorrect. Different targets can have their own vi.lib (like FPGA and RT) so any VIs that live in that scope should first try to search that target vi.lib but should then default to the normal vi.lib if it can't find the specific dependency. I don't know why it wasn't defaulting to the normal vi.lib after failing to find it in the targets folder.