steady wrote:
My feeling is NI doesn't elaborate some basic important concepts thoroughly: like "Application Instance" and "VI Server". Let us take the above instance: I build A.EXE and B.EXE, and want them both to communicate with C.EXE. So are there 3 "Application Instances" of A, B, and C, or there is only 1 "Application Instance", i.e. LabView itself?
There's an explanation of application instances here. In your case, A.exe, B.exe, and C.exe will all be separate application instances. In the development environment, if they are all part of the same project, then they are in the same application instance. If they are each independent projects, then they are separate instances. To use VI server over TCP (which is what you want to do), each instance needs to be on a different port. This shouldn't be a problem because the only instance that actually needs VI server in your situation is C. A and B will only be clients, so they do not need VI server to be enabled.
steady wrote:
I care above question, because I found in many articles it pointed out "Run-time Engine" and "Development System" can't share same port. Otherwise there will be error.
http://digital.ni.com/public.nsf/allkb/C32E9CD39E234DFB86256DE1007840B2
I tend to think the whole "LabView" system is an "Application instance" when we "Open Application Reference", since we only input the IP address and port of the VI Server into "Open Application Reference" node, regardless of what VI/project we are interested at. And we must "Run" a VI to set up a "server", other than do configurations in Tool/Options. If we run a .vi, it sets up a VI Server according to development system configuration in Tool/Options; if we run a .exe, it sets up a VI server in run time engine according to .ini file, am I right?
You can set up VI server for an individual project (or a target in the project), by right-clicking on the target ("My Computer") and choosing properties. This way you can assign different ports to different projects. Also, in a project, the settings for the target will be copied to the INI file when you build an application, so it will work the same way in both LabVIEW and in an executable. You do not need to run a VI to set up VI server, you just need the project or application to be open (it sounds like you've already discovered this). After you open an application reference (using the IP address and port), you then pass that reference to Open VI Reference to get a reference to the specific VI in that instance that you want to run.
steady wrote:
At last, when I use A and B to communicate with C, I found I can connect C.EXE even without running C. If I am using A.vi and B.vi to call "c.vi in C.EXE" via "Call by reference node" following "Open VI Reference" without "Open Application Reference", it really performs as I exactly want - the data is processed in C but shared by A and B. But after I compliled A and B into exe, the connection between A and B is broken, while they both independently communicates with C very well.
In the compiled applications you need to use Open Application Reference first, then Open VI Reference, and finally Call By Reference to execute the VI inside C that shares the data. I don't know enough about your situation to understand why you have a connection between A and B; all of the communication should be routed through C. If A and B need to share a lot of data, why are they separate applications? You could possibly simplify the entire project by making them into a single program with two different main windows.
steady wrote:
After knowing the mechanism, my new problem is: how do I organize C.vi well? I want C to do some actions like "read", "write" instructed by A and B. In normal situations, I will do C as event structure, put a button or something. But here event structure will not work -- I send a value to the button will not trigger event. Well there is an alternative to use a loop to look up the button repeatedly, but is it consuming too much CPU time?
You can use an event structure here with user events, or you can use a notifier or queue, stored inside a shift register in a functional global variable (FGV) inside C. Say when C starts it creates a queue and stores that in a FGV. That FGV also has an action to put data into the queue. A and B connect to C and get a reference to your FGV, which they then use to put command into the queue. Meanwhile, C is waiting for data in the queue; when it receives a command, it process it. The same approach works with a user event, if you prefer that.
Again, I don't know how your program and communication are structured, but it might be simpler to wrap your communication commands in VIs that can be called directly by A and B. I'm guessing that you have a DLL to handle communication with the I2C device, and that you have calls to the DLL to initialize, open a handle, read, write, close, and maybe other commands. You could again create a FGV to store the handle, then create a VI for each of the DLL calls. When C starts it opens the handle and stores it in the FGV. The VI to read gets the handle from the FGV, calls the read command in the DLL, and returns the data. Same idea for write. If you can use this approach you do not need any VI inside C to run continuously, you just need to make sure that C is open so that A and B can connect to it. This gives A and B both almost direct access to the I2C device.
