Running two independant LV applications simultaneously

[Tournifreak]

I'm sure lots of other people have had similar questions to this, but I can't find anything specific in the forums...

I have a test system that runs two LV applications. One is written by me and runs as a .exe loader which then calls a main VI. The other application is written and maintained by someone else and runs as an exe.

It is possible that the two applications use VIs with the same name, or may do in future.

If I try to run the two applications uncompiled, I get all sorts of errors (probably because our VIs share the same name).  But so far, no issues running them compiled.

Will LV keep them separate because the applications they are part of are exe's? I want to be sure that I'm not going to get problems in the future. Can someone reassure me? (Or make any helpful suggestions?)

Thanks,
Jon.

[Abhinav T]

Hi Jon,

If you set the VI to be non-reentrant you will have issues with this. Setting your VI in this mode will create one instance of that VI that any application can call. If you set the VI in reentrant mode by going to File >> VI Properties >> Execution and make sure the reentrant execution check box is checked, your VIs will create two separate instances of each other.

[pincpanter · Accepted solution]

If you don't want to run both applications from the development environment, you are completely safe: the two executables don't interfere with each other (at least at the vi running level).
You don't need to change the reentrancy of your vi's - and changing this may even be a bad thing depending on how they work.

Message Edited by pincpanter on 07-12-2007 11:26 AM

[tst]

---

@Tournifreak wrote:

Will LV keep them separate because the applications they are part of are exe's?

---

Yes. Each application has its own memory space, so each application can have different VIs with the same name. You should have no problems doing this as long as you don't try to open both applications in LabVIEW itself at the same time.

By the way, a common way of getting around this is by using namespacing - each application (and module, potentially) gets a prefix or suffix, so that its VIs are guranteed to have unique name (for instance - app1_main.vi, app1_comm_Open.vi, app2_main.vi, etc.).

[Tournifreak]

---

@tst wrote:

---

@Tournifreak wrote:

Will LV keep them separate because the applications they are part of are exe's?

---

Yes. Each application has its own memory space, so each application can have different VIs with the same name. You should have no problems doing this as long as you don't try to open both applications in LabVIEW itself at the same time.

By the way, a common way of getting around this is by using namespacing - each application (and module, potentially) gets a prefix or suffix, so that its VIs are guranteed to have unique name (for instance - app1_main.vi, app1_comm_Open.vi, app2_main.vi, etc.).

---

Unique names do seem to be the way forward. But not the way back. i.e changing the names of hundreds of VIs at this stage fills me with terror!
Thanks!
Jon.

[tst]

---

@Tournifreak wrote:

changing the names of hundreds of VIs at this stage fills me with terror!

---

This can be automated (you can rename a hierarchy of VIs and maintain the connections), so it's mostly relatively easy when you have the right tool.

You could run into problems, however, if you're doing dynamic loading or refering to specific VI names.

[mikeporter]

You need to be careful about going too crazy with this renaming VIs thing. There is a good reason for each top level VI in each application to have a unique name, but be careful how far down into the code hierarchy you go. To begin with, the whole point of LV development is to create reusable pieces that will help you get started on the next application you have to write. Next, excessive renaming can create update problems. For example say you have multiple VIs that do the same thing but have different names. Now let's further suppose that something fundamental in the process changes that will effect all the VIs performing that function. To track the one change you have to locate and modify multiple VIs.

The only trick I can offer is the rather obvious point that names should tell you what the subVI does. Hence you should avoid simple names like "Open Port.vi" unless that subVI can open any port based on the the information that is passed to it. But if the subVI opens and configures a serial port for a particular kind of device, the name should reflect that. Something like, "Open and configure serial port for Initech 8000.vi".

Also make VI names readable. There is no advantage to cryptic C-like names like, "CnfgSerpInitek8k.vi".

There is no penalty for using long file names.

Mike...

[tst]

---

@mikeporter wrote:

For example say you have multiple VIs that do the same thing but have different names.

---

Well, you shouldn't have that. If the VIs do the same thing, there should be a single utility VI called by all programs and it should be placed in the user.lib folder.