vi conflict between 2 projects running simultaneously

[wwjacobd]

Hello,

I am pretty new to using LV and have essentially been placed in a position where I need self teach LV.  The issue at hand right now is that we have 3 separate physical boxes that perform a few actions that are controlled by 1 labview program per box. When just one box is running the program runs as it should logging how many times a lever is pressed and how many times a pellet is dropped from each successful lever press.  Now here comes the issue, when a 2nd program is opened up and both are running at the same time, the program prompts that the pathing of the .vi's changes from the folder it originated in say "box 2" and changes to the pathing of "box 1".  This ends up with lever presses or pellets dropped being recorded in the 2nd program creating this weird cross data collection scenario.

Is there a solution so that this conflict between .vi's can be delineated so that the programs aren't trying to use the same exact path for a vi and will in fact keep their own directory?

(this is probably not worded the right way, I am brand new and unsure of how to actually describe the problem)

[Yamaeda]

---

@wwjacobd wrote:

Hello,

I am pretty new to using LV and have essentially been placed in a position where I need self teach LV.  The issue at hand right now is that we have 3 separate physical boxes that perform a few actions that are controlled by 1 labview program per box. When just one box is running the program runs as it should logging how many times a lever is pressed and how many times a pellet is dropped from each successful lever press.  Now here comes the issue, when a 2nd program is opened up and both are running at the same time, the program prompts that the pathing of the .vi's changes from the folder it originated in say "box 2" and changes to the pathing of "box 1".  This ends up with lever presses or pellets dropped being recorded in the 2nd program creating this weird cross data collection scenario.

Is there a solution so that this conflict between .vi's can be delineated so that the programs aren't trying to use the same exact path for a vi and will in fact keep their own directory?

(this is probably not worded the right way, I am brand new and unsure of how to actually describe the problem)

---

Compile them into an .exe. Are they 2 copies of the same program? If so you need to change an ini-setting for the .exe to allow multiple instances.

[crossrulz]

If you are running from the LabVIEW editor, then you need to make sure you open up two "programs" in different projects.  The project will set the application instance and prevent the cross-linking that you are describing.

[RTSLVU]

Well the first thing that comes to mind is instead of trying to run multiple instances of the exact same program, write one program that can handle any one, any two, or all three "boxes".

[wwjacobd]

As far as I can tell, they are the same .vi.  The only reason there are multiple instances of it running are to change COM ports to point to different boxes to control via a drop down menu in the .vi

[wwjacobd]

well the way these are saved on the system here...its a ton of .vi's.  Rookie question,  is there an associated project for every .vi?  Or can .vi's be generated independent of a project?  I'm under the impression the project folder houses the vi's inside of it and is the working directory for the vi's included.  Is this how LV works or am i fundamentally misunderstanding the directory structure? 

Secondly,  if these are just standalone .vi's not made in a project, is there a way to just take this program and create a project for it and throw it into the project folder to isolate it from the crossing data i originally described?

[Yamaeda]

---

@wwjacobd wrote:

is there an associated project for every .vi? 

Or can .vi's be generated independent of a project? 

I'm under the impression the project folder houses the vi's inside of it and is the working directory for the vi's included.  Is this how LV works or am i fundamentally misunderstanding the directory structure? 

Secondly,  if these are just standalone .vi's not made in a project, is there a way to just take this program and create a project for it and throw it into the project folder to isolate it from the crossing data i originally described?

---

1. That would be a very strange design choice. 🙂

2. Yes

3. Correct, that's the idea of a project

4. You can easily create a project and add the VIs to organize and handle your project, but it won't isolate in this case.

I'd still recommend building an .Exe and running 2 copies of that, they are quite isolated.

Ofc you might need some touch up to make it into a decent program. E.g. if you now select a com port and then press Run it won't work in an exe as it autoruns, so you'll need to fix such behaviours first.

[wwjacobd · Accepted solution]

All,

After becoming more familiar with the software and how to effectively describe the issue I was having accurately, what I didn't know about the LV software and what I found to be the solution are:

1.  There is a fundamental difference between Ctrl + C/Ctrl + V a VI with its subVI's in bulk, and File -> Save -> Save unopened copy.

2.  The solution to this problem was to go into the directory that was original, we'll call it version A and then save the subVI's from that directory that were being called, as a an unopened copy into the directory of version B(new version) and then just overwrite the subVI's.  That alleviated the directory pathing issues being identical for both and causing the problem.

Furthermore, I recognize how this would be a non issue moving forward if I just use projects and drag the VI's I want to use into the project instead of having to restructure a VI every time I want to cannibalize it for pieces.  Thanks to everyone for pointing me in the right direction.