Sanity Check

[rune vedde]

It is good to see that there are people out there that have the same problem and that I am not the only one that is loosing my mind.

In my computer the vi’s is living there own lives and I have no control of witch vi is loading at witch time.(sometimes it looks like it)

Then LV8 was released and I was told that now the problem is solved with the new Project explorer. That seems to be true but when you build an application the vi settings of private and global does not follow to the application and everything is like before.

I have an lv application that dynamically loads another Lv application depending on witch instrument. Both applications are built exe files. An if those two applications have a sub vi with same name the first sub vi that is loaded will be used by both applications.

That means that it is possible to change function of a compiled application???????

And that is really scary!!!!!!!!!!!

Please correct me if I have got this wrong, nothing will make me happier.

Rune

[tst]

I don't have 8, so I can't tell for sure, but the way I understand it, the project environment and multiple instances is only for the development environment (which makes sense).

---

@rune vedde wrote:
I have an lv application that dynamically loads another Lv application depending on witch instrument. Both applications are built exe files. An if those two applications have a sub vi with same name the first sub vi that is loaded will be used by both applications.

---

I'm not sure how you're calling them dynamically if they're exe files - an exe file is an executable even if it has VIs in it and there is no need to call those VIs dynamically. Basically, every exe you run should have its own memory space and there shouldn't be any conflict. If you only have a single memory space, use different names for VIs which perform different operations.

[rune vedde]

This problem exist in both LV8 and Lv7. My task was to build and qualify a program that runs a test on a transducer. This test program must not change behaviour after qualification.

Then I have a main program that run different test depending on what type of transducer I want to test. The main program passes values to the test program and reads the result from the test.

I first thought that when I build an exe file I was sure that sub vi’s inside the exe file that was used, not vi’s in memory. But when I use the dynamically load a vi from a exe file it seems that it is the same as loading it from a llb or directly from disk. Then to me, it seems somewhat pointless to build exe’s.

 

[tst]

I still don't understand what you're doing.

It doesn't matter where the VI is - if there is a VI of that name already open in your current application instance, LV will take the one in memory and not the one you're trying to load. Once again, if you are running 2 different executables built by LV, each should have its own memory space and you should be able to load different VIs with the same name into each of the executables (unless you're doing something like calling Open Application Reference, thereby tying the 2 executables together).

If this didn't help you, I suggest you post a small example showing what you mean.

[rune vedde]

In the beginning I taught that when I used the call by reference node and calling a vi inside an executable, I open and run that executable. But it seems that lv is reading the vi inside the executable, loading and run this in the same way if it is in a llb.   

Is there any other way to do this??  

Attached is part of my block diagram showing that I load an vi inside transducer1_test.exe

Passing the comports and status. When the test is finish I got the result in the test result array.

This is a small part of an bigger application.

 

[tst]

---

@rune vedde wrote:

In the beginning I taught that when I used the call by reference node and calling a vi inside an executable, I open and run that executable. But it seems that lv is reading the vi inside the executable, loading and run this in the same way if it is in a llb.   

Is there any other way to do this??  

---

At the risk of sounding like an idiot, I will quote myself - "It doesn't matter where the VI is - if there is a VI of that name already open in your current application instance, LV will take the one in memory and not the one you're trying to load". An exe is basically an llb, so that's exactly what LV does - it loads the VI from the exe into the current instance's memory space. If you are running the executable, it should have its own memory space.

Why are you calling the VI from inside the exe? Why are you using a constant path at all? Why not use different names for VIs which do different tasks? Why are you using a CBR node instead of directly calling the VI? Using CBR nodes is usually a sign of a plug-in architecture, where you don't know the names of the VIs in advance, only their connector pane pattern - often, selecting such a plug-in is done by reading which Vis are found in a certain directory and treating them as plug-ins. I'm still not sure why you're doing this as you are, which makes it harder to help. My strongest advice would be to use different names.

[rune vedde]

Tst wrote:

"It doesn't matter where the VI is - if there is a VI of that name already open in your current application instance, LV will take the one in memory and not the one you're trying to load". An exe is basically an llb,

Actually I was told different by Ni support a couple of years ago. But I have experience that you are right.

I am not using a constant path, I read the path from a database that has record of test program corresponding to product connected. So every product has its own test program.

The idea is when a new product is introduced I just make a test program end update the database and then the test program works inside the main program without any changes.

My main program and test program have some common tasks like communicate with the product. So if I modify one of them and forget to rename the sub vi, it will change behaviour when run together or I accidentally name a sub vi with same name. Main Program has ca300 subs and the test program has ca50.

So I have realized that I have to be very careful when naming sub vi’s, but what can I do to be 110 % safe that there will be no mix of sub vi’s??

Is there other ways to do my application?

[tst]

I don't know how 8 does it, but as far as I understood the abilty to do this in 8 is only through using different instances for each project, meaning that you can't have 2 VIs with the same name open in the same project at the same time (at least that's what I understood, but I don't have a running version of 8).

Anyway, as I said, if you have VIs which will have different functionality and you don't want to have cross linkage problems, I think you have to give them different names, and I doubt that even 8 will help you there. Often, the way to do this is by using a prefix or suffix naming convention (let's say all the VIs for the main program will have "main_" as a prefix, and each of the subVIs can have its own prefix or you can have a common one for all of them. You can have a look at the OpenG VIs to see examples of this.

[rune vedde]

Thanks for yor reply and your time on this matter tst.

I hope Ni will fix this problem somtime in the future, untill then i will follow yor suggestion on naming vi's.

Rune