Hi,

I've a problem of getting my simple XNode to properly adapt to input type. This Xnode is a simplification of a real problem I'm trying to solve using XNodes but if I manage to solve this, then I should be able to solve the real problem.

In the attached ZIP I've an XNode wrapper for Preview Queue Element primitive. Its purpose is simply to wrap the Preview Queue Element as an XNode and behave exactly like Preview Queue Element. When a queue is wired to the input, the XNode 'queue in' and 'queue out' terminals should be adapted to the queue type. This is currently working properly. What I fail to implement is getting the 'element' output terminal to adapt to the queue element type.

When user changes the type wired to 'queue in' input, Adapt to inputs ability is called. This abilitity now replies with two messages Update Terms and Generate Code. The Update Terms message instructs LabVIEW to call GetTerms3 ability and the Generate Code message instructs LabVIEW to call Generate Code ability. The order of these two messages is important; if Update Terms is not called prior to Generate Code, the Generate Code ability doesn't have terminals of proper type and hence the preview queue element node generated would not properly adapt to the queue type.

The problem is that I find out the queue element type only after I've generated the code by inspecting the element output terminal type of the generated Preview Queue Element node. Now I should update the Xnode terminals according to this new information I receive after I've generated the code but I cannot get LabVIEW to call the GetTerms3 ability multiple times per input change. Even if I send the Update Terms message multiple times, LabVIEW only calls the GetTerms3 ability once.

So I need your help in finding out a way to get the output to adapt to input so that the output type depends on the input type but is not the same as the input type. In this example case the output type should be the element type of the queue type wired to the input.

The attached XNode is for LabVIEW 8.5.

 Preview_Queue_Element_XNode.zip ( 150.63K ) Number of downloads: 146


The XNode Manager tool in LAVA code repository simplifies the development process. If you need any help in scripting when trying to solve the problem, don't hesitate to ask. Queue controls are of class type TypedRefNum and queue constants are of type Constant. The TypedRefNum class has a property Element which gives you a referenece to a queue element type control. TypedRefNum has as embedded element control in a similar manner as a single element cluster has a single control. You can replace the element with a new element using Replace method of the Control class.

Cheers,

Tomi

I don't have 8.5 to play with (NI doesn't appear to have shipped the update DVDs to academic site licensees in the UK yet), but at least on 8.2 the Variant Type vi's will help here. Specifically, the Variant Type.lvlib:Get Refnum Info includes an output that will contain the type of the queue element when fed the refnum type of the queue. So, I think you it all before generating code. In Adapt to Inputs ability check first that the queue input is a queue refnum, then get the queue element type using Get Refnum Info, and put the element type into the XNode state. Then in Get Terms3, read the state to get the Queue type and set the element output terminal accordingly. Finally generate the code...

While I don't have a solution to your specific issue, I can confirm having seen LabVIEW preventing multiple call to abilities through the reply output.
I also notice that some reply will be completly ignored. For instance, ReplaceSelf or AugmentSelf called from RespondToDrop have no effect.
I have come to the conclusion that XNode could benefit from having an ability callable at anytime so the XNode data could be updated bypassing the XNode expected behavior.

PJM

Thanks a lot Gavin! The Variant Type library solves all my problems! I didn't know it existed. Or actually I came across it a long time ago but for some reason this information no longer existed in my active memory. And for those interested, a somewhat functional version is attached.

 Preview_Queue_Element_XNode_2.zip ( 314.39K ) Number of downloads: 150



The same applies to Finland as well. We always get a package of DVDs with an obsolete versions of LabVIEW. That's why we always download the (Windows) evaluation version from NI web site and activate the downloaded version with our site license key.

Do you have any idea where these two ability VIs can be called from?

Tomi

Well, I know by experience that you can call them from the DoubleClick ability. There are probably more but I don't know them.

PJM

Tomi,

I have been looking into this and wanted to expand it to Queue an Array XNode, that would encapsulate this:

Unfortunately I don't have the Internet Toolkit installed at home so I couldn't load the XNode manager
Do you think it is hard to do this piece of code?

Ton

No, it's very simple even without XNode manager if you just no what you are doing. Are you asking me to do this?

Tomi

Uhm, yes...

Ton (hides under a rock)

It's 3.30 a.m. and I arrived from a bar a little more than half an hour ago. I'm feeling a little bit too drunk and eating some night snack. So what else would I do but to help you out from this horrible trouble... So here you go. The icon is not proper but the XNode functions the way you would expect. So perhaps you can fix the icon by yourself

Tomi

EDIT: I forgot to replace one subVI call to an external library with a subVI call to a subVI within this XNode libray. The zip file is now updated with this change.

Did you already download it?

Yes, but I had a missing Scripting Tools VI, and didn't download the tools on this machine yet, but I poked at the code and it looks nice.

Ton