Can I run two almost identical LabVIEW programs in parallel?

[guangdew1]

I have a related question: I have a functional global used to send information between the two programs, it doesn't seem the functional global is working. How should I look into the issue?

[RavensFan]

That's because the functional global works within the context of the application instance.

Now that you are trying to separate your two programs, but yet you still want them to communicate somehow, you need to come up with a different method.  One way would be to use a network shared variable.  Another would be to use TCP/IP functions (one program opens, the other listens) to pass data back and forth.  I would use the shared variables as they are pretty easy to implement.  You just have to make sure your shared variable library is deployed whenever you open one program or the other.

[guangdew1]

Because the two programs need some shared resources, if one is using it, it needs to let the other one know and wait. I thought functinal global can send information between seperate running programs, looks it cannot in this case. I think I can save the information into a text file somewhere so both programs can access, do you think it's okay this way (the two programs are running on the same computer)? I don't know about the shared variable, I will look into it.

Thanks for the help,

[Mark_Yedinak]

A file can work but it is not the best choice. If you have a single shared resource one alternative is to write an application that handles this device. It can act as a TCP server which will accept commands from any client. It can process these in the order they arrived and therefore manage the resource. However, if you truly have a single resource then you may have no choice but to have your applications affected by the other. Only one application can access the device at one time. If the application can move on and do others things it can and the suggestion of the server would support that and allow the client to do other things. This may require that the client task has parallel tasks within it.

[RavensFan]

Using a text file to communicate between programs is kind of a hack.  I'd avoid it.  Use the shared variables.

Now I'm confused as to what you are really trying to do.  Originally you said you had to very similar programs that were trying to do the same thing, but when you ran one the other one "acted" like it was also running and you didn't want it to.  It sounded like you wanted similar, but separate programs.  Now with each post, you are saying you want the programs to interact more.  First it was just to pass data.  Now you say you want them to share resources.  What resources are being shared?

I think you should go back to square one and reexamine your architecture.  If you want them to be heavily related, then perhaps you should only have one program.  What is this program supposed to do?

[guangdew1]

Hi Mark Yedinak,

I have already had the program to test one unit. I thought I can easily test one more unit by running two programs in parallel with little modification to the program. I think I'll use the file option and try it further.

Thanks for the help,

[guangdew1]

The two programs are identical except they access different ports on the routing device, but there's also one shared port both program need to access. They need to avoid to use the shared port simultaneously, that's why they need to let each other know. Another thing is, if one selects one device to test, it needs to let the other program know which device it has selected, then the other program has to look for the other device to test. It's hard to explain, I hope I have made it clear.

The device under test is an audio device with network capability, audio distribution and control is through network.

I never used shared variable before, what should I pay attention to use it?

Thanks for the help,

[Mark_Yedinak]

I would probably use a single application that will spawn copies of the test itself. Each time it spawns the task (which is reentrant) it will pass the appropriate information for that device under test. The shared resource (your port in the case) will be supported using regular subVIs. Multiple calls to the same VI will automatically ensure only one access is occuring at a time. Using this approach with a dynamically called task you can easily support many devices. Your approach is very specific and only handles 2 devices. You then need to duplicate the code in order to add a third and so on. The above method allows the numbers of devices to be determined at runtime.

[guangdew1]

The hareware will not support testing more than two devices. I'm trying to do it in an easy way, to have two program running in parallel. If the two programs can share some information, then I can have them avoid conflict. If it will not work, I will have to expand the program to make it test two devices, it will be sure then.

[Mark_Yedinak]

You can write an application that can dymanically call your current application. This is a much better approach than simply making multiple copies. You will still need to develop some way to coordinate access to your shared resource. This will be necessary no matter what.

Also, it may be true that your current system only supports 2 devices but it is always a good idea to design in expandability from the start. Then when you get an update to your system that supports 4 or 8 or 20 devices you are all set. You've already designed for that and you won't have to make significant changes and may not require any changes at all.

Quick and dirty often works in the short term but more often than not it causes problems in the long run.