Function Globals do not work acrross multiple projects.

[German Coast Guard]

Hello I'm using a Function Global (uninitialized shift register on a 1 itteration loop) to share data in my aplication.

I have found that if I write to the Function Global from a VI inside a project that the data is not available to a caller that is not oppened from within the project.

Is there a way for the project to write to the main application instance? or vice versa?

Thanks,

Amaury

[Ray.R]

I haven't used a Functional Global for vi's that were not part of a project..  so my comments are purely from a curiosity point of view.

I would have expected it to work, as long as the vi's that are not in the project were calling the Functional Global that was in the project (full path and same name).

I wonder if there are safeguards to prevent a Functional Global from sharing data with non-project members, in order to protect the integrity of the Functional Global data...  Although I doubt it, it would be an interesting feature if it did..  After all, a Functional Global is just another VI.  And then again, I haven't called any VI's by using another VI which is not part of the project..

I am curious. Did you make the Functional Global a re-entrant VI? (it shouldn't be).  Is it calling the exact same Fn Glbl (exact path & name)?  Did you at any time make a backup copy by selecting the project directory in Windows and then copy & paste to another location?

R

[StevenA]

I was curious about this as well so I setup a test to verify it.    When you call a functional global that is part of a project.  And that same vi is loaded into memory from a vi in the project.  The instance outside the project is a clone of the vi that is in the project.  The project protects data that is part of it's namespace from outside callers. 

I'm a little curious about your application and why you need to pass data as you describe? 

[Ray.R]

---

StevenA wrote:

The instance outside the project is a clone of the vi that is in the project.  The project protects data that is part of it's namespace from outside callers. 

---

That's what I suspected..  It's a nice feature 🙂  But not if you try to call it from outside the project.

Workaround:  Create another project and include the Functional Global into the new project.

R

[TCPlomp]

This is intended, a project functions like a real executable, likewise it isn't possible to use queus between projects (or application instances like they are officially called), to do such a thing you can use shared variables, data socket or tcp-ip.

Ton

[Ben]

Yep that is as intended.

What you can do is (from memory so correct me if I am wrong);

Open a ref to LV and get a ref to the "other" project instance.

Get a list of all VI's open in the project context and locate the target VI by checking the names.

Use Invoke node > call by ref to use the Action Engine in the other project.

Note:

This same approach should work to access AE's on other computers if you open a ref to the LV instance on the other machine.

Ben

[Ray.R]

Nice solution Ben.

That should work well.. 🙂

[tst]

Here are some more details about the method Ben mentioned (and an example).

[Ben]

Thank Yair!

I was thinking of including a link to that thread but was just to lazy to go looking for it.

Ben

[German Coast Guard]

Thanks for the link to the example -- I'll take a look... For my application, though, I can just add some of the files NOT included in the project into the project so they use the same clone of the Fn Glbl... (That of the project's execution, not LV's Main Application Instance.)

Thanks again!

Amaury