Tag versus parameter

[Bobillier]

Hi

I start to use Tag to send some informations to Vi and find them handy. But i dont know if there is limitations or disadvantages to use them.

I send you a sample of code to show one case of utilisation.

This code run like that: The Master test.vi call asynchronusly the slave Test.Vi and send to it is reference via tag. You can stop the slave alone, but if you stop master the slave stop too.Is it convenient when you call asynchronusly Vi in back ground and the Master stop or crash .like that the slave can stop cleanly.

[mike_spacex]

Hi. I suspect that the intent of tags is NOT to send information TO VIs, but to store information ABOUT VIs. The sample code you made could be done without tags (and without super secret scripting stuff) simply by using the Set Control [Variant] method (see no_tag_utilization.zip). And why not? The master/slave scenario requires the slave to have knowledge about the master anyway, so why not include a front panel control to make it explicit. I think tags could be handy when you want to store information and associate it "with" a particular VI without the VI having any knowledge that you're doing so.

An example of "real life" tagging is when scientists tag animials with a GPS receiver and logger in order to track migration patterns.

I attached a silly example that demonstrates just this (fun_tag_utilization.zip):

Run the GOD VI to create animals (as many as you can handle).

Run the Scientist VI to tag animals and log migration patterns (the scientist can only interact with animals/tags he can "reach"; hint: move stuff)

Run the GPS Sattelite VI to cause tags to periodically update their value to include their latest position.

Take a look at the private/animal.vi block diagram. It's ignorant to any of the tagging & logging. I think this is the advantage.

Here's the mystery: Where in memory is the tag data stored? Memory usage for LabVIEW.exe in the Windows Task Manager shows increasing memory usage BUT the VI profiler doesn't show it piling up in any particular VI memory space.

I hope the example is fun and useful!

[Bobillier]

CITATION(mike_nrao @ Sep 19 2007, 04:37 PM)

Hi. I suspect that the intent of tags is NOT to send information TO VIs, but to store information ABOUT VIs. The sample code you made could be done without tags (and without super secret scripting stuff) simply by using the Set Control [Variant] method (see no_tag_utilization.zip). And why not? The master/slave scenario requires the slave to have knowledge about the master anyway, so why not include a front panel control to make it explicit. I think tags could be handy when you want to store information and associate it "with" a particular VI without the VI having any knowledge that you're doing so.

Hi thanks for your reply. Like you propose i know the solution using the Set Control [Variant] method .But find tag more handy and don't see (now) objective reason to don't use them to send parameter to vi.

Regards

PS: Sorry but i can't see you tag solution because i use old 7.0 version.

[Yair]

I think the major advantage is when you want to add meta data to an object which can be identified by reference. An example would be a service which would handle window resizing - you could embed data into each object which would tell it how to behave when the window is resized.

The biggest disadvatage is that tags are not supported. For that reason alone I would not use them in my production code.

QUOTE(mike_nrao @ Sep 19 2007, 04:37 PM)

Here's the mystery: Where in memory is the tag data stored? Memory usage for LabVIEW.exe in the Windows Task Manager shows increasing memory usage BUT the VI profiler doesn't show it piling up in any particular VI memory space.

I don't think it's a mystery. Most likely, the profile window simply doesn't count them. The profiler isn't fully accurate anyway.

[Aristos Queue]

QUOTE(BOBILLIER @ Sep 19 2007, 11:02 AM)

Hi thanks for your reply. Like you propose i know the solution using the Set Control [Variant] method .But find tag more handy and don't see (now) objective reason to don't use them to send parameter to vi.RegardsPS: Sorry but i can't see you tag solution because i use old 7.0 version.

Objective reasons to use the VI's conpane or some form of VI-to-VI communication:

1) Using a tag is a global storage mechanism. You could just as easily use a Global VI or LV2-style global or, as has been mentioned, Set Control Value (variant). The advantages of the Global VI or LV2-style global is that you can use Find to detect all the places in your code where you are reading or writing the value. With Set Control Value or the tags, you have no such mechanism.

2) Making it part of the conpane means that LabVIEW can do some dataflow optimization as far as copies of the data are concerned. In your case, the data is small, but this would be something to consider if you're passing larger amounts of data to the VI via tags. Tags are extremely heavyweight compared to direct wiring (in fact, tags are more heavyweight than Global VIs in terms of how many times data gets copied during the transaction).

3) Reading and writing tags requires switching to the UI thread in order to be thread safe. That will slow down code.

4) Reading and writing tags is not type safe at compile time. You put the data into a variant; you pull the data out of the variant. No type information exists on the diagram, so if you change the type of the data you're writing into the tag, you won't know until runtime that you forgot to change the reader of the tag.

5) Making it part of the conpane ensures that the data is sent for to the slave VI and the slave VI only. Putting it in any global storage (be it the Global VI or the tag, which is readable by anyone who opens a VI Server ref to the slave VI) is an invitation to hacks. If you come to rely on these tactics generally, you will eventually find yourself unable to resist the temptation to have someone else shim in between the master and the slave for some reason, perhaps to do some pre-processing before the slave runs, and eventually you end up with a mess of a spaghetti code system. I've seen it happen many times.

QUOTE(mike_nrao @ Sep 19 2007, 09:37 AM)

Here's the mystery: Where in memory is the tag data stored? Memory usage for LabVIEW.exe in the Windows Task Manager shows increasing memory usage BUT the VI profiler doesn't show it piling up in any particular VI memory space.

That's because the data isn't in any VI's data space. It's off in a side "tags table" and only gets made part of the VI during save. And, you're correct, the intent of tags was to store data about the VI, never to serve as a communications medium. But, as I said above, if you provide a global store, eventually someone will abuse it as a hack because they see it as a convenient place to shovel data, rather than taking the time to actually put the data in the function interface. It is always easier to hack than to architect.

[Bobillier]

Thanks for these Objective reasons..

But whitch is the use of Tag ? you speak about meta information .Can you be more clear. You can tag Vi and controls for what ??

Regards

Eric

[Aristos Queue]

QUOTE(BOBILLIER @ Sep 21 2007, 07:03 AM)

Thanks for these Objective reasons..

But whitch is the use of Tag ? you speak about meta information .Can you be more clear. You can tag Vi and controls for what ??

Regards

Eric

One of the uses of tags is to tag copyright information onto the VI.

Another use is to tag a VI that was created by a "wizard" tool. Then when the user opens the VI to edit it, the wizard tool, running in the background, can see that this VI has the tag on it and know to intercept the VI and instead open the wizard up to be the interface for editing the VI.

Ultimately, however, you ask for a use of the tags... tags are not published parts of LV and were never designed for non-NI use. Thus any use you come up with for them is not something intended.

[Yair]

QUOTE(Aristos Queue @ Sep 22 2007, 06:59 AM)

...tags are not published parts of LV

Hopefully they will be in some future version.

[crelf]

Tags are kinda cool, but not necessary. One question I have: The tags are bound by the VI, right? So they're kind-of encapsulated globals, which makes them act like locals. I agree with everything that Stephen said, but (like everything else) tag could be useful if managed well. The management of them is what's important.

[Aristos Queue]

QUOTE(crelf @ Oct 11 2007, 04:24 PM)

Tags are kinda cool, but not necessary. One question I have: The tags are bound by the VI, right? So they're kind-of encapsulated globals, which makes them act like locals. I agree with everything that Stephen said, but (like everything else) tag could be useful if managed well. The management of them is what's important.

Any other VI can read any VI's tag. So, no, they're not encapsulated globals.

For the record, if you want an encapsulated global, an LV2-style global or a global VI can be made private to a library (or protected to a class) so as to restrict access to it. And if you want a "global" that is restricted to a single VI, well, that's an uninitialized shift register.

[crelf]

QUOTE(Aristos Queue @ Oct 12 2007, 02:02 PM)

Any other VI can read any VI's tag. So, no, they're not encapsulated globals.

Of course - you're absolutely right. Any VI that has a reference to another VI can read/write it's tags.

QUOTE(Aristos Queue @ Oct 12 2007, 02:02 PM)

For the record, if you want an encapsulated global, an LV2-style global or a global VI can be made private to a library (or protected to a class) so as to restrict access to it.

Hey - I hadn't thought of doing that :thumbup:

[Aristos Queue]

QUOTE(crelf @ Oct 12 2007, 07:06 AM)

Of course - you're absolutely right. Any VI that has a reference to another VI can read/write it's tags.

Hey - I hadn't thought of doing that :thumbup:

Just don't try it with a shared variable. Shared variables don't respect scope settings. And if you try to CAR it you'll be told that's a design feature. Trust me... I tried to "CAR" it back at the design phase.