Jump to content

Xnode wrapper for Preview Queue Element


Tomi Maila

Recommended Posts

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.

Download File:post-4014-1194268900.zip

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

Link to comment

QUOTE(Tomi Maila @ Nov 5 2007, 02:37 PM)

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.

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...

Link to comment

QUOTE(Tomi Maila @ Nov 5 2007, 05:37 AM)

...

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.

...

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 ResponToDrop 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

Link to comment

QUOTE(Gavin Burnell @ Nov 5 2007, 05:20 PM)

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.

Download File:post-4014-1194287745.zip

QUOTE(Gavin Burnell @ Nov 5 2007, 05:20 PM)

NI doesn't appear to have shipped the update DVDs to academic site licensees in the UK yet.

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.

Link to comment

QUOTE(tcplomp @ Nov 10 2007, 09:46 PM)

Uhm, yes...

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

Link to comment
  • 1 year later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.