set control value & sciware-goop reference

[didierj]

Hi there,

Long time I didn't post something...

...well, a friend of me showed me recently an odd behaviour in a program he wrote in LV7.1.1.

The architecture is: main.vi calls a template (with vi-server) and embeds it as a subpanel. From this subpanel and also from main.vi a 2nd template is called with vi-server. The reference of a sciware-goop object is given to this 2nd sub-vi with the node "set control value (variant)"... seems complicated but there is the clue.

In the development environment everything works like a charm. But from the moment a built app is done, the "set control value (variant)"-node that resides in main.vi returns error 1, but not the one in the subpanel . The goop-ref points to the same object. Do I replace the node in main.vi with the traditional "set control value" (which needs a flatten to string), everything works again.

To me quite strange, since the goop-ref was also given to the subpanel with the "set control value (variant)"-node, and there it works.

The only answer I could give was "???"

...or did I oversee something, since I don't use LV that much anymore?

Didier

ps. have to ask him to break down his program, or do it myself

[Tomi Maila]

Set Control Value doesn't work in a built application unless you force the VI front panel to be included in the built. By-default the front panels are removed. In headeless environments the front panels are always removed so Set Control Value is never availbale in headless environments. I and Jim Kring brainstormed this set control value issue a few months back and came into a conclusion that the best way to pass data to an asynchronous VI is using a named queue. As this question seems be popping up often I try to explain in more detail

When you want to use a named queue to pass data to another VI, you must verify that the name of the queue is unique and that both VIs use the same queue name. VI name is a good choise for the queue name but it's not unique for reentrant VIs. Therefore a unique name can be constructed from VI clone name which is always unique for any reentrant instance of a VI.

After opening a reentrant reference to a new VI, use clone name property for the reference to get the VI clone name and create a queue using that name. Then inside the reentrant VI itself use static VI reference to get the clone name of the VI itself. The simplest way to do this is simply place the clone name property node without VI reference input to the block diagram of the reentrant VI. Use this clone name inside the reentrant VI to get a reference to the same queue you create inside the calling VI. Now you can use this named queue to pass data asynchronously between the calling VI and a reentrant instance of another VI that works in built applications and headless environments.

EDIT: If you do not have access the VI reference because you have not written the template by yourself, then you may force the front panel to be included in the build from build settings.

See also this thread: http://forums.lavag.org/Question-about-Lab...y-VI-t7669.html

Tomi

[Kurt Friday]

Nice answer Tomi

One way that I force the front panel to be included in the build without having to manually specify it in the build config is to include a property node in the desired vi to return a control name, take a look at the process code for an active object.

Another way of passing the object arround without having to pass through front panels is to use named object instances, you just get the object by name inside your desired subpanel vi.

Please tell your friend that they are always welcome to contact me for support, I am more than happy to help. It sounds like an interesting application as well.

[didierj]

QUOTE(Tomi Maila @ Jun 7 2007, 10:28 AM)

Set Control Value doesn't work in a built application unless you force the VI front panel to be included in the built. By-default the front panels are removed. In headeless environments the front panels are always removed so Set Control Value is never availbale in headless environments. I and Jim Kring brainstormed this set control value issue a few months back and came into a conclusion that the best way to pass data to an asynchronous VI is using a named queue. As this question seems be popping up often I try to explain in more detail

Haven't mentioned, but 2nd template starts also as a frontpanel. But either way, please explain me why does it work once and once not? And with the traditional (set control value-) node it works all time.

Myself I used this node quite often in my 10 LV-years and hadn't one time problem with it.

QUOTE(SciWare @ Jun 8 2007, 01:44 AM)

It sounds like an interesting application as well.

It is, it's a test-framework. The main.vi is an overview of the test rigs in his lab. Since the ammount of test rigs vary over time, their overview are implemented dynamically in the main (sub-panels). The overview shows the status of each rig. If there are more than the 8 rigs the main can show on one window, the operator can flip pages. With a click on the sub-panel the full-blown test-panel (2nd template) of this rig is opened in a new window, the operator can now interact with the rig. In the main itself the operator can set up a new test-rig (after clicking <OK> the overview gets one more element).

The SW & HW are connected with daq & imaq, and everything is stored in a mysql db (have a good server for all the datapoints ).

The framework is well thought-out, built full modular. And it should be something to show to customers (who buy his products) when they visit the facility.

Didier

[Tomi Maila]

QUOTE(didierj @ Jun 8 2007, 10:01 AM)

Haven't mentioned, but 2nd template starts also as a frontpanel. But either way, please explain me why does it work once and once not? And with the traditional (set control value-) node it works all time.

Myself I used this node quite often in my 10 LV-years and hadn't one time problem with it.

As always, it would be easier to explain should you submit a project that reproduces the problem.