inter project communication strategy

[X.]

I have two LV projects in which I have developed tools to control two different types of instruments (A and B).

I now need to use both instruments to achieve a specific goal (optimize A for B). Specifically, I need to collect data in B, design an algorithm that sends instructions to A, collect data in B and sends back instructions to A, etc, until an optimum is obtained.

I can think of at least one way to do that:

modify project B to send instructions to a LV global/communication VI/queue/notifier which will be shared by the two projects.

The problem is, I have nver done that so I am not sure what the scope of, say a notifier is. If I create a notifier in a VI belonging to project B, can I refer to it by the same name in project A?

Thanks for your comments.

[nathand]

No.  Each project or application is a separate "application instance."  Queues and notifiers cannot be shared between instances.  One simple solution for you may be to use shared variables.  Another option is to use VI Server, which will allow B to call a VI running within A, and vice versa, so long as you have the appropriate permissions set in the VI Server properties.

[Mark_Yedinak]

The answer is no. (I would avoid using global variables which is why I did not include them.) You can use network streams which are available in LV 2010. You could also use your own simple network protocol using the TCP VIs. There is also a network queue which behaves like queues but can work across applications or the network. If you are using 2010 I would suggest you use network streams. They will probably be the easiest to implement since NI did most of the work for you.

[X.]

I had a quick look at the Network Queue Lava thread. I'd rather use a NI-supported tool although I have no doubt about its quality...

Where can I find a good example of either Shared Variable communication between two projects?

I think I have read everything there is to read on them on NI's website and among the examples, but I haven't found such an example.

I was suspecting I may to go that route.

I did not know about Network Streams (I am looking at the examples). What would be the advantage of one over the other? The "Host Fulness.vi" example seems to warn the user about possible performance issues, but it seemed to me that one of the Shared Variable example had similar issues (too much data sent one way, accumulating in a buffer.

What about Datasocket? Another thing I haven't looked into yet...

[Ben]

Data socket are valid as well.

Can't speak to Shared variables since I have avoided them.

TCP/IP will work and is flexible in that you can split your app across multiple machines if required.

VI server rides on top of TCP/IP (all of its benfits) but does invoke the UI thread to get the data in/out of the Call by reference node.

There is also file I/O that is slower but withstnad power fails if you need to recover in the middle.

I can't comment more on the other options since I avoid the canned solutions that I can not "fix"* if I have trouble.

Ben

* You only have to rewrite a big application once before you find yourself promising yourself "I will never rely on others peoples code again!" No I do not smelt my own iron to make the nails but on the other hand the prefabbed decks never seem to fit the way you want them to fit.

[X.]

Well, since I am temporarily stuck with LV 2009 due to some FPGA support issue I have in LV 2010, I think I will use Datasockets.

I have played around with it a bit and here is what I am planning to do (attached):

- one project (untitled project 1) contains my DAQ GUI which needs to control the other instrument: in the example, it sends a "numeric" via a DS write. However, for my algorithm to be foolproof, I need to make sure that the other instrument has updated its status before I collect data. Therefore, after a write, I wait for the other guy to send an acknowledgment (using a read to another DS). When this is confirmed, I proceed.

- the other project (untitled project 2) is a simple GUI for the other instrument, which the user  can control via a FP numeric. When it is "remotely" controlled by the previous one (that is when, timing out, it gets a new numeric from the DS used by the other GUI to send its instruction), it updates this control (it overrides any user action) and writes this value into the other DS to tell the remote controller that it has updated its status.

Do you see any flow in this logic? At least, it seems to work. Bear with me, this is a barebone architecture.