how to shared a FGV between 2 LVprojs ?

LAVA 1.0 Content · May 31, 2008

Hi all,

As mentioned in this thread, since LV 8.2 it is not possible to share a queue between 2 LV instance.

I have to LabVIEW projects (A.lvproj and B.lvproj) running on the same machine and I'de like to make them communicate by "sharing" a FGV.

Basically :

- the shared FGV VI is in project A

- at start, the FGV is set to be accessible using VIserver

- on certain event a value is put into the shared FGV

- project B opens an application reference using IP and port number (the same set by project A)

- project B opens a VI reference on the shared FGV to read a control value

I must be missing the point because it only works if the FGV's front panel is opened... see my code below

Can anybody help me on this ?

Yair · May 31, 2008

I'm guessing that the front panel needs to be at least loaded for the set control value method to work. You can test this by adding a property node for one of the controls to the code.

The better solution is to use the call by reference node. You're already opening the reference with the VI refnum type, so this should make it much cleaner and easier. A simple modification and testing of this example on two projects seems to work fine when the FP of the FGV is closed.

LAVA 1.0 Content · May 31, 2008

QUOTE (Yen @ May 30 2008, 11:27 AM)

I'm guessing that the front panel needs to be at least loaded for the set control value method to work. You can test this by adding a property node for one of the controls to the code.
The better solution is to use the call by reference node. You're already opening the reference with the VI refnum type, so this should make it much cleaner and easier. A simple modification and testing of http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=254951#M254951' target="_blank">this example on two projects seems to work fine when the FP of the FGV is closed.

Hi Yen,

Thanks for the link .

I implemented the "call by reference" like in the example you pointed, but it just doesn't work and returns no error.. is the there any particular settings to set on the shared FGV to make it work ?

Side remark : When the 2 apps are on the same PC it seems to me more difficult than doing it with between a host PC and a RT target. I say this because I did it 2 years ago quite easily with LV 7.1 and I was expecting it to be straightforward..

Is there a significant change on this between LV 7.1 and LV 8 or is it just that I missed a detail of some kind ?

Yair · May 31, 2008

I made no modifications to the FGV. I just placed the VIs in different projects, enabled the VI server access on the "cFP" project (make sure your firewall allows that traffic and that you use a unique port for that project) and pointed the "PC" VI to that port.

QUOTE (Antoine @ May 30 2008, 01:08 PM)

Side remark : When the 2 apps are on the same PC it seems to me more difficult than doing it with between a host PC and a RT target. I say this because I did it 2 years ago quite easily with LV 7.1 and I was expecting it to be straightforward..

It shouldn't be any more difficult. As mentioned in the other thread, the key is using a unique port number for each application instance. When you work with another target it's simpler, because all instances default to port 3363, so you don't have to change it.

LAVA 1.0 Content · May 31, 2008

QUOTE (Antoine @ May 30 2008, 06:08 AM)

Hi Yen,
Thanks for the link .

I implemented the "call by reference" like in the example you pointed, but it just doesn't work and returns no error.. is the there any particular settings to set on the shared FGV to make it work ?

Side remark : When the 2 apps are on the same PC it seems to me more difficult than doing it with between a host PC and a RT target. I say this because I did it 2 years ago quite easily with LV 7.1 and I was expecting it to be straightforward..

Is there a significant change on this between LV 7.1 and LV 8 or is it just that I missed a detail of some kind ?

I have not done this LV 8.+ but I thought about it when the proj was introduced.

I believe Opening a ref to the proj that has the VI and then find a ref to the FGV running in that proj. Watch for name mangling if in a library.

And yes use call by reference.

Ben

LAVA 1.0 Content · May 31, 2008

QUOTE (Yen @ May 30 2008, 12:34 PM)

[...](make sure your firewall allows that traffic and that you use a unique port for that project) and pointed the "PC" VI to that port.

I have.. .

Using the the "get ctrl value" method works (*only* if the FGV's front panel is opened) but it make me think that the VIserver settings (port, VI access list, etc.) are correct, so the reference to the FGV is fine.

The "call by ref" method give no error at all, but I think that I am getting a reference to "another instance" of the FGV because if I add a "write" case using the "call by ref" method, project B write to the FGV and reads what it wrote, the same for project A.

How to do to have only one instance of the FGV and each project refering to it?

See attach code

corrections to do before running :

- in B project, in the VI B_reader_loop.vi change the "shared FGV's parent dir path")

- on both project adapt the port number to your setting (mine is 3385)

http://lavag.org/old_files/post-7452-1212145549.zip'>Download File:post-7452-1212145549.zip

EDIT :

Ok Neb,Yen,

I am just seing your posts now, I will try that.

In the end opening a reference to the project (which is a labview "context" if I understand well) sounds the correct way to do. Referring to LabVIEW turns out to open another instance of the pointed VI in the separate LabVIEW "context" that is the second project.

It's cool to learn, thank you guys !

Yen, I set 3385, because my labview 8.5 is set with 3385

* : I am not sure that "context" is the appropriate technical word for what I mean... I am not a proper software engineer (I use to be thermal engineer )

Yair · May 31, 2008

As far as I can tell, the issue here is with the programmatic setting of the VI server properties. It looks like the settings are only applied after the VIs in project A go idle. I'm not sure, but I think this is a bug.

In any case, if you run the VI from project A, stop it and then run it again, the FGV should work in project B. For me it worked earlier because I set the settings manually (by right clicking the My Computer icon).

As a minor point, if a VI is in memory, you can use its name to open a reference to it instead of its path. Makes you less dependent on its exact location.

LAVA 1.0 Content · May 31, 2008

QUOTE (Yen @ May 30 2008, 01:37 PM)

As far as I can tell, the issue here is with the programmatic setting of the VI server properties. It looks like the settings are only applied after the VIs in project A go idle. I'm not sure, but I think this is a bug.
In any case, if you run the VI from project A, stop it and then run it again, the FGV should work in project B. For me it worked earlier because I set the settings manually (by right clicking the My Computer icon).

Hmmm... this has to be investigated, indeed.

Other point is that I can't find how to open a ref to a VI in a specific project/context.

If someone can clarify the difference between a context and a project, that would help me to understand. :book:

QUOTE (Yen @ May 30 2008, 01:37 PM)

As a minor point, if a VI is in memory, you can use its name to open a reference to it instead of its path. Makes you less dependent on its exact location.

If I only give the VI name I get error 1004 :

LabVIEW:  The VI is not in memory.

To load a VI into memory with the Open VI Reference function, a path must be wired for the VI Path input.

Yair · May 31, 2008

I believe the terms "context" and "instance" are interchangable in this case. I personally prefer "application instance". An app instance determines all kinds of things.

Here are some examples of things that have to be unique within an instance:

Queues, notifiers, etc.
VI names (CTLs, standard VIs, global VIs...)

To open a reference to an instance, you use the Open App Ref primitive and give it the machine address and port number. The port number is what determines which application instance you connect to. Another key point is that if you want to connect to another instance in the local machine you HAVE to connect something (e.g. "localhost") to the machine name input, or it will open a reference to the current instance. This is most likely the source of your problem.

Once you have the application reference, you can operate on the VIs within that application (at least the ones you have permission for).

As for using the VI name - as I mentioned, the VI has to be already loaded in the application instance you're using. In this case, because you didn't actually connect to the other instance, you got the 1004 error because the VI was not loaded in your instance.

LAVA 1.0 Content · May 31, 2008

QUOTE (Yen @ May 30 2008, 08:30 AM)

I believe the terms "context" and "instance" are interchangable in this case. I personally prefer "application instance". An app instance determines all kinds of things.
Here are some examples of things that have to be unique within an instance:

Queues, notifiers, etc.

VI names (CTLs, standard VIs, global VIs...)

To open a reference to an instance, you use the Open App Ref primitive and give it the machine address and port number. The port number is what determines which application instance you connect to. Another key point is that if you want to connect to another instance in the local machine you HAVE to connect something (e.g. "localhost") to the machine name input, or it will open a reference to the current instance. This is most likely the source of your problem.

Once you have the application reference, you can operate on the VIs within that application (at least the ones you have permission for).

As for using the VI name - as I mentioned, the VI has to be already loaded in the application instance you're using. In this case, because you didn't actually connect to the other instance, you got the 1004 error because the VI was not loaded in your instance.

Here is a quick image of what I had in mind.

http://lavag.org/old_files/monthly_05_2008/post-29-1212150784.png' target="_blank"> post-29-1212150784.png?width=400

See the name mangling

Ben

Donald · May 31, 2008

I'm wondering why you do not use the build-in Shared (Network) Variables for this job. I guess maybe not available on your RT platform?

Yair · June 1, 2008

I still don't know if this is a bug or not (there may be a reason behind the design), but when you enable the TCP connection of the VI server it takes the default values rather than the ones you just set. If you enable the TCP connection first than the code should work fine.

In any case, I reported it to NI.