[CR] OpenG Array XNodes

[hooovahh]

Yeah the merge solution is probably the right one, which sucks because I just got the post install hook idea to work, where it scans the installed files for MNU extensions, and then adds them to the root palette (the blank one) automatically.  I guess the only downer is that you would then have to manage another VI for every XNode you have, editing the icon, description, and terminals to reflect what you want the XNode to be but that seems like such a minor complaint.

[Michael Aivaliotis]

Speaking of xnodes in the palettes. Can someone explain what this is and how it's done?

 

[hooovahh]

That is some voodoo magic.  I was wondering how that was done too but never looked into it.  If I had to guess I'd say Xnodes have the capability to run something on loading of the Xnode into memory.  There are obviously at least 3 files in that library, the _Copy 1.vi, _GetHelp 1.vi, and _State 1.ctl.  The two VIs are password protected, and don't really go anywhere.

 

EDIT:  So it doesn't have to do with the XNode getting into memory.  If you load the XNode file as a library it doesn't launch anything.  From there you can't do much other then read the library name, get the locked state, and get the Icon of the library.

 

DOUBLE EDIT: So the GetHelp appears to do nothing and loads nothing other typed controls into memory.  It never returns an error and does nothing.  The Copy function always returns "FailTransaction" as the reply, and never returns an error and appears to do nothing with the XRef input.  It does however run the <LabVIEW>ProjectFind LabVIEW Add-ons.vi with the input Source having a constant.  Still not sure how the XNode runs this VI when you select it from the palette, or drop it on the block diagram.

[lordexod]

Voodoo magic .

xxx.zip

[hooovahh]

Voodoo magic .

It is voodoo magic.  Explain to me why Copy 1.vi gets executed when you drop the XNode on the palette?  This is a neat feature, but it doesn't help us get more insite into XNodes.

[lordexod]

"This ability VI is called by LabVIEW after a new copy of an XNode is instantiated.
 
State In is the same as the original XNode's state.
The generated code is copied from the source XNode and will not be regenerated for the destination Xnode unless you return the GenerateCode reply.
 
If the source XNode has any linkages (added via the AddLinkerReference method on XRefs), LabVIEW will automatically copy these linkages to the destination XNode before calling the Copy ability. This means that you may want to delete/refresh any such linkages in your Copy ability.

Default behavior: Produce an exact copy of the original XNode without regenerating the code.

This ability does not provide UI and OS messages are not handled.

See also: Initialize"

[SDietrich]

Hi folks,

 

am I the only one hit by an incompatibility issue between versions 1.3.2.31 and 1.3.2.32?

 

If I place an OpenG Index Array Element.xnode with version 1.3.2.31 (or earlier) and then upgrade to version 1.3.2.32 (or later), I get the following error message:

Library version is incompatible with XNode version.

 

I have to replace the Node with a fresh one from the palette, then everything works as expected.

 

Note that this seems to be the only XNode suffering from this problem, all others I used upgrade just fine.

 

As fixing this bug would probably mean breaking code that was created with version 1.3.2.32 or later I would suggest to investigate it only for the sake of avoiding it in the future?

 

Thanks and keep up the good work, OpenG Array XNodes rock!

 

 

 

[hooovahh]

There is an XNode ability that can define how the data should mutate between versions.  When the data behind it doesn't change between versions this is usually just a VI that converts from variant to the same data type but when versions need new data this mutation can mean more work. 

 

I'm guessing this UpdateState ability was accidentally not made for this XNode and so LabVIEW doesn't know how to convert the data from the old library to the new one.

[gb119]

Hmmm, not sure what has happened there. I'd have to go back over those versions, but I don't recall that I made a change to the state type of the control which is where I'd expect to have to use the UpdateState ability. Unless that was the point where I jumped from LabVIEW 8.6.1  to LabVIEW 2012, in which case the version jump might be causing the problem.

[SDietrich]

While replacing all the broken nodes in our code I found the OpenG Empty Array.xnode to also suffer from the mentioned incompatibility. It could be in a different version though, because I am now updating directly to the newest version of OpenG Array XNodes.

[SDietrich]

I found the reason for the error message and thanks to hoovahh

 

There is an XNode ability that can define how the data should mutate between versions.

 

a solution, too.

 

When comparing the .xnode files from the two incompatible versions, the offending line is this one:

<Property Name="NI.Lib.Version" Type="Str">0.0.0.0</Property>

It was changed to:

<Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>

This again makes LabVIEW look for an UpdateState ability-VI so it can migrate from the old version to the new one. Because there is no such VI, an error is displayed.

 

The OpenG Filter Array XNode already has such an UpdateState ability VI (which basically only passes its input back as output) and it works as expected. No errors are shown, even if I mess around with the version number by hand. So I would ask to create such a VI in all the XNodes and no future update will break existing code.

 

The interesting question remains, why the version number was increased in the first place...

[hooovahh]

The interesting question remains, why the version number was increased in the first place...

In my opinion the XNode version should be updated every time it is released, assuming there were some changes made to it.  If the version of the XNode stays the same then the UpdateState will never be called when opening loading an existing XNode.  If the data types changed then as I mentioned some mutation may need to take place and this is done through calling the UpdateState.  

 

I handled this in my Circular Buffer XNode as well.  I did several tests where I would open a VI that has version 1.0.0 of the XNode, when version 1.0.1 was installed.  If you look at the UpdateState you'll see the data mutation, but you'll also see it goes through the re-init process.  Otherwise the code behind the XNode would still be version 1.0.0.  So my code will replace all the 1.0.0 XNodes with 1.0.1 which has improved algorithms and may have different terminals.

 

Basically updating version numbers, and the UpdateState ability ensures that when I install a new version of the XNode, all of my existing copies of that XNode are updated.  Otherwise they will stay the same code as before.  XNodes aren't like subVIs.  If you install a new version of a subVI, when you open a VI that called that it will load it from disk and you'll have the new one.  But with an XNode the VI lives in the calling VI, not entirely on the location on disk.  Installing a new version of the XNode doesn't automatically replace all the existing versions, but loading the UpdateState can cause that to happen.

[gb119]

It's on my list to overhaul the update state ability and ensure the version numbers are sanitized for a future release - but, whilst I happy that folk are using the code, the XNode versions tarted up as a 'proof of concept' to show that it could be done....

Unfortunately the update will be delayed by small things like teaching undergraduates :-)

[hooovahh]

It's on my list to overhaul the update state ability and ensure the version numbers are sanitized for a future release 

Yeah if you do ever get around to updating it, there has been improvements to the OpenG array functions since this release.  I opened the template source and noticed that it does things is a different way than the OpenG does with the latest release.  And even the latest OpenG array stuff could use some improvements.  Still lots of great things to learn about with these XNodes.

[sonmer]

Hello everyone,

 

and here comes my first post on lavag.org .

I encountered a problem when using the "Delete Elements from Array.xnode" and already posted an issue on the github-page. I'm not certain if it is the right place, so im just copy paste the text here.

 

"While using the Delete Elements from Array.xnode i recived some warnings from Labview (14.0.1 32-bit). In the Logfile it says:
DWarn 0x9F70176B: OpenG Delete Elements from Array:XNode method "GetDisplayName" must return non-empty type string
In the mentioned GetDisplayName2.vi there is nothing wired to the string output. Wireing a sting constant solves the problem (see attached image)."

I know it's not a big deal, but i hope it helps:

[hooovahh]

I've actually never used that ability and wasn't sure what it is used for.  Here is the description pulled from the resource files in LabVIEW 2014 for GetDisplayName3.

 

 

This ability VI is used to supply LabVIEW with the names of your XNode. There are two types of name that an XNode can have, one is the 'TypeName,' the other is its 'InstanceName.' The TypeName is used as the type of node that this XNode is, such as 'Match Regular Expression' for a MatchRegularExpression XNode, and is used for the error list, difference list, and the title of the context help page (if GetHelp is configured to use it). The InstanceName is used as the value for the XNode's label and will also appear in the error list after the XNode's label is shown. (The error list format is [TypeName]"[instanceName]":[error].) 

 

This ablity will be called on when the XNode is dropped, when its label is shown for the first time, or when an UpdateLabel reply is recieved. In order to control edits to the XNode's label, this ability can be used in conjunction with 'OnLabelChange' which will notify the XNode when a user attempted to change the label.

 

I wonder if the warning comes from the fact that in 2014 there is actually two things to return, Type Name and Instance Name, where the older GetDisplayName2 looks like it only has Name.  The GetDisplayName2 is probably deprecated.  Still in the future when this ability is used it is probably easiest to just pull the name of the owning library and use that as the Name.  Then this ability is more generic and would work on all XNodes.