passing data to vi launched using Run VI method

[JohnRH]

What I am trying to accomplish might be kind of difficult to explain, but I'll do my best here.

When launching a 'process' using the "Run VI" method ("Wait until done" set to FALSE) - how would one go about passing information to this process that is needed for the process to execute? For example - if I have a process that handles serial communications on a COM port - how could I specify which COM port to use at run time? I'd like to launch the serial IO process using the "Run VI" method, but it doesn't look like we can pass data directly to it's controls.

I've thought of setting a value in a global prior to launching the process - so that the process could then read that value to determine what COM port to use. I just think there should be a more elegant way of doing this.

To make this even more challenging, what if I'd like to launch multiple instances of this process - where each instance handles a unique COM port? (would it work if I just made the process vi reentrant?)

Any ideas?

Thanks!

[PJM_labview]

John,

You have to use VI server to open a reference to the SubVI and then use methods like "Set Control Value" or "Set Control Value [Variant]".

Attached is an example I made demonstrating how to do this for Sub Paneled VI.

PJM

PassInputToSub.llb - Image:

Download File:post-121-1089670309.llb

[Michael Aivaliotis]

You have to use VI server to open a reference to the SubVI and then use methods like "Set Control Value" or "Set Control Value [Variant]".

1136[/snapback]

PJM's example works well. Using a variant means that you don't really have to get the datatype correct, however the datatype should be in the same family like numeric or string.

Along the same line is this previous post:

http://forums.lavausergroup.org/index.php?...=findpost&p=338

To answer your question about re-entrancy. There should be no problem. I assume you know about the feature included with the open VI reference function? This allows you to dynamically call a reentrant VI.

[jpdrolet]

PJM's example works well. Using a variant means that you don't really have to get the datatype correct, however the datatype should be in the same family like numeric or string.

Incorrect. The datatype must match exactly the control datatype when using Set Control Value(Variant). Unlike Variant to Data function, there is no implicit type conversion with this method.

[Michael Aivaliotis]

Incorrect. The datatype must match exactly the control datatype when using Set Control Value(Variant). Unlike Variant to Data function, there is no implicit type conversion with this method.

1138[/snapback]

Well what do you know!? You're right! I just did a quick test and confirmed this. Thanks for the warning. I mistakenly assumed that it would behave like the Variant to Data function.

[Jim Kring]

Incorrect. The datatype must match exactly the control datatype when using Set Control Value(Variant). Unlike Variant to Data function, there is no implicit type conversion with this method.

1138[/snapback]

That brings back memories

Here is a VI that should do the trick (however, I haven't tested it).

Set_Control_Value__Coercable_Variant VI Image:

Download File:post-17-1089685393.vi

[Jim Kring]

Incorrect. The datatype must match exactly the control datatype when using Set Control Value(Variant). Unlike Variant to Data function, there is no implicit type conversion with this method.

1138[/snapback]

Jean-Pierre, this thread brings back memories

John et al.,

Here are a couple of VIs:

1.) Set Control Value {Coercable Variant}.vi

2.) Launch Generic Process VI.vi

#1 uses the "To LabVIEW Data" function to perform coercion (if possible) before setting the control value. It does this by first reading the controls value so that it can get its type.

#2 is a generic utility VI that first sets the FP control values and then invokes the run method. Additionally, it will open a new instance for Reentrant VIs and it will pass the VI Reference to the called VI, if it has a FP Control called "Self VI Reference".

Cheers

Launch Generic Process VI image:

Download File:post-17-1089685589.zip

Download File:post-17-1089685604.zip

[jpdrolet]

Sorry Jim (welcome back...) Set Contol Value {Coercable Variant}.vi doesn't work either...

The Variant to Data node you use to perform coercion does nothing since you ask it to convert a variant to a variant...

It is possible to make a VI that will coerce variant to another datatype (even numeric string to number...). You sent me an example once from a guy working on variants. I remember it was huge (~1MB) and then not very convenient.

[Jim Kring]

Sorry Jim (welcome back...) Set Contol Value {Coercable Variant}.vi doesn't work either...

The Variant to Data node you use to perform coercion does nothing since you ask it to convert a variant to a variant...

It is possible to make a VI that will coerce variant to another datatype (even numeric string to number...). You sent me an example once from a guy working on variants. I remember it was huge (~1MB) and then not very convenient.

1148[/snapback]

Well, I'm not really, back. I am stuck in a hotel in Albany, NY :headbang:

I was thinking of testing that VI, but I figured that it would work. I didn't realize that the coercion only occurs when the output is strictly typed... too bad. Yes, this would be a non-trivial problem to solve in G. For now, we'll leave that one for the wishlist, I guess.

Cheers

[JohnRH]

Wow! I certainly came to the right place!

Thanks for the help and the examples! The "Launch Generic Process VI.vi" will come in very handy!

:beer: Cheers! :beer:

John

[Michael Aivaliotis]

I was thinking of testing that VI, but I figured that it would work.  I didn't realize that the coercion only occurs when the output is strictly typed... too bad.  Yes, this would be a non-trivial problem to solve in G.  For now, we'll leave that one for the wishlist, I guess.

1150[/snapback]

Non-trivial but possible. Besides, it's done already in the variant config data tools... not?

[Jim Kring]

 

Non-trivial but possible. Besides, it's done already in the variant config data tools... not? 

1278[/snapback]

 

Michael, it is possible and much easier than I first thought. Here (attached) is a working, and fairly complete solution -- it supports compound types including nested variants (variants containing variants). It is currently sub-optimal for arrays, which can be improved... but that solution is also non-trivial :laugh:

Jean-Pierre (et al.), I was thinking that we could use this VI as a replacement for "Remove Typedefs from Variant" in the lvdata package. Maybe we could add a "Recursive?" boolean argument that defaults to FALSE so that the original behavior is preserved for existing users (but would they even want the original behavior?).

Any thoughts?

Cheers,

-Jim

Download File:post-17-1091340674.zip

[Jim Kring]

Michael, it is possible and much easier than I first thought.  Here (attached) is a working, and fairly complete solution -- it supports compound types including nested variants (variants containing variants).  It is currently sub-optimal for arrays, which can be improved... but that solution is also non-trivial  :laugh: 

Jean-Pierre (et al.), I was thinking that we could use this VI as a replacement for "Remove Typedefs from Variant" in the lvdata package.  Maybe we could add a "Recursive?" boolean argument that defaults to FALSE so that the original behavior is preserved for existing users (but would they even want the original behavior?).

Any thoughts?

 

Cheers,

-Jim

1279[/snapback]

I had a lapse of reason -- the VI that I wrote doesn't coerce variants, it strips typedefs. I solved a different, but related problem. I'll think about the original problem some more.

[Michael Aivaliotis]

I had a lapse of reason -- the VI that I wrote doesn't coerce variants, it strips typedefs.

1287[/snapback]

Ah, that explains the blank stare on my face ... I was thinking "man Jim's really lost me here"... I thought it was just too many beers I had... :beer:

[PJM_labview]

Michael, it is possible and much easier than I first thought.  Here (attached) is a working, and fairly complete solution -- it supports compound types including nested variants (variants containing variants).  It is currently sub-optimal for arrays, which can be improved... but that solution is also non-trivial  :laugh: 

Jean-Pierre (et al.), I was thinking that we could use this VI as a replacement for "Remove Typedefs from Variant" in the lvdata package.  Maybe we could add a "Recursive?" boolean argument that defaults to FALSE so that the original behavior is preserved for existing users (but would they even want the original behavior?).

Any thoughts?

 

Cheers,

-Jim

1279[/snapback]

Using "Variant To Flattened String" and "Flattened String To Variant" seem to do just that (remove typedef) by itself or am I missing something ?

PJM

[jpdrolet]

Using "Variant To Flattened String" and "Flattened String To Variant" seem to do just that (remove typedef) by itself or am I missing something ?

PJM

1574[/snapback]

Yes but as commented in Remove Typdef From Variant there was a bug in LabVIEW 6.1 such that Variant to Flattened String did return an invalid type descriptor when used with typedefs. The VI was introduced as a workaround. Typedef information in type descriptors was introduced in LabVIEW 6.1 and this bug was a big disapointment since it did make LabVIEW Data Tools useless on typedef variant.

I did not dig in documentation recently but I think that this typedef information is not yet documented for type descriptors (LV7 is shipped with the same old Application note 154). LabVIEW Data Tools have never been implemented to use that typedef information in variants. The returned type descriptor was invalid anyway.

Now that you have made me look more closely, it seems that the typedef feature was removed in LV7 (type descriptors from Flatten to String and Variant to Flattened String don't include typedef information anymore...). That makes me wonder if that was a feature in LV6.1 or a simply a plain bug. It is from LV6.1 that typdefs are displayed in variants, wire help and that typedef conversion is indicated with a coercion dot. Internally this information is carried in data type and maybe it was just a bug in LV6.1 that made it leaked in type descriptors....

Jean-Pierre

[PJM_labview]

...

Yes but as commented in Remove Typdef From Variant there was a bug in LabVIEW 6.1 such that Variant to Flattened String did return an invalid type descriptor when used with typedefs. The VI was introduced as a workaround. Typedef information in type descriptors was introduced in LabVIEW 6.1 and this bug was a big disapointment since it did make LabVIEW Data Tools useless on typedef variant.

...

1575[/snapback]

Ah, I did not know that LV6.1 Variant to Flattened String was returning invalid type desciptor with typedef information.

...

I did not dig in documentation recently but I think that this typedef information is not yet documented for type descriptors (LV7 is shipped with the same old Application note 154). LabVIEW Data Tools have never been implemented to use that typedef information in variants.  The returned type descriptor was invalid anyway.

Now that you have made me look more closely, it seems that the typedef feature was removed in LV7 (type descriptors from Flatten to String and Variant to Flattened String don't include typedef information anymore...). That makes me wonder if that was a feature in LV6.1 or a simply a plain bug. It is from LV6.1 that typdefs are displayed in variants, wire help and that typedef conversion is indicated with a coercion dot. Internally this information is carried in data type and maybe it was just a bug in LV6.1 that made it leaked in type descriptors....

Jean-Pierre

1575[/snapback]

I did not realized until quite recently that Variant to Flattened String was not working (read was automatically stripping typedef) with typedef in LV 7.x. I think I figure out a way to get the typedef in the type descriptor using flatten to string with expose type def turned on and doing some stripping and "padding". This is not documented anywhere as far as I know, but it seem to work well in LV7x (a quick test under 6.1 seem OK). See attached VI.

Also, I noticed that the only way to get typedef info from controls on VIs is to used Get All Control Values {variant} methods. Every other way return type descriptors with no typedef info.

PJM

Download File:post-121-1093760011.vi

[jpdrolet]

I forgot about this "Expose Typedef" thing...

Yes Philippe, that is the way to extract the typedef from variant data. While Variant To Flattened String does strip the typedef info, it can still be retrieved by flatteneing the variant itself and getting the subtypedef in the flat data string of the variant.

However, I'd like to know if there is any use that can be made of this typedef info, basically the name of the typedef control VI... I'll need to analyze the type descriptor with typedef info to figure its structure and figure how to detect when it is present or not.

For example of possible usage, when receiving variant data with typdef info, one could extract the control name, open a VI reference. get the directory where it is located and find there Method VIs to operate on the data.

[PJM_labview]

Jean Pierre,

Lately I was playing around with the OpenGoop Framework and I realised it would be usefull if we could dynamically update Strictly type VI ref num in each class (being able to keep typedef is important in this case).

Attached is a llb that does that.

Also, check out the following VI "Variant to Flatten String {preserve typedef}.vi", I think it could be used as a possible replacement/enhancement to the native Variant to Flatten String primitive.

Cheer

Philippe

Download File:post-121-1093814922.vi

Download File:post-121-1093814962.llb