Jump to content

[CR] Variant Repository


Recommended Posts

  • 2 weeks later...

I assume you meant XNodes not XControls.  After an XNode is interacted with it will make the VI using scripting.  And so in an EXE this VI should be what is used, and therefore no XNodes exist in a EXE, only the VIs they make.  Besides NI uses XNodes all the time.  A common one is the match regular expression so you shouldn't have any issues.

 

...that being said I just tried to make an EXE with my VR package and it fails...so yeah I need to look into that.

 

EDIT:  It looks like this does work.  I've been making a few changes since this release and something in that version broke which doesn't allow EXEs to be made.  This version works fine.

 

Double EDIT:  So it looks like from source works, from the files on the palette it doesn't so something got messed up in the package making process.  But this shows that that XNodes themselves can be in EXEs.

 

Tripple EDIT: Okay so I found the issue was with the Post-Install VI that was being used in the package making process.  It wasn't all that necessary and I got rid of it and uploaded a new version 1.0.1.11 that I have built into EXE without a problem.  The new version uses the UpdateData ability so older copies of the XNode should be replaced with newer ones after opening a VI that used the older version.

Link to post
Share on other sites
  • 5 months later...

Some have asked for the Variant Repository VIs to be available as non-XNodes.  So I wrote some scripting code to make polymorphic instances, edit VI icons, and make the polymorphic VIs.  But what I hope this illustrates is just how useful XNodes are.  

 

The Non-XNodes version is 252 VIs and one control.  That's a lot of VIs to have to load into memory when using these polymorphic instances.  That's 60 normal VIs inside each of the 4 polymorphic VIs.  And it doesn't even support all of the features the XNode counter parts do.  

 

From a reusability stand point polymorphic VIs have many things that make using and maintaining them difficult.  From the number of files loaded, to custom help, icons, and terminals from each instance, along with supporting more types than the polymorphic could.  Don't get me started on when a bug is found and it isn't something you can easily fix with scripting.  So then you need to open up each of the polymorphic types and make changes to each one.  Oh and ever try to use the polymorphic editor with 60 instances?  Yeah I've stopped trying and use a combination of tools so I never need to.

 

Some day, hopefully NI will be able to invest the time needed to make XNodes an official feature.  But until then I'll likely need to support many polymorphic types, when XNodes aren't trusted.

Variant Repository Non-XNode.zip

Link to post
Share on other sites
  • 1 year later...

Hi

Great tool. Considering using it for sharing data between vision functions in a plugin based architecture. Passing the variant repo reference as a DVR to the modules. Though I need some more datatypes Specifically from VDM (point, line, reference coordinate system, ROI etc.). Anyway to do that ?

 

Thanks

Link to post
Share on other sites

Yeah the XNode version works with any data type.  It can read and write references, and ROI's which I think are clusters.  The non XNode version would need to have those types added to the polymorphic VI types.

Link to post
Share on other sites

Very nice indeed  :beer_mug:

 

I am thinking about using this in a project where I have to interface with some external equipment via OPC-UA and some other custom protocol. I have lots of "variables" (tags) and want to experiment how things can be done as much as possible by just using a channel name in my code rather than individual element access.

 

Anybody given any thought as to how best to share the variant between processes? Lots of options here, as Kahrma mentioned perhaps a good technique is a DVR? 

Edited by Neil Pate
Link to post
Share on other sites

It wouldn't be hard to change the XNode to take a DVR of a variant rather than the variant itself. I did something similar so it would take an object and it was a lot easier than I thought it would be.

 

For OPC UA in the past I've used the CVT and just made a small process which reads each OPC UA data value and copies it into the CVT. Then you can define groups for each of your tags and read data by group.

 

NI made something very similar recently, although not as nice as this variant repo. The advantages though are that it has some metadata (last update timestamp, whether or not the value is valid, and then another variant for metadata):

https://decibel.ni.com/content/docs/DOC-47108

Link to post
Share on other sites

Yeah I have other issues with the CVT, like performance.  And when writing a messaging library that is uses a wrapper constantly for variant data, I wanted it to be light weight, and generally I didn't find a wrapper for a look up table that wasn't better when it comes to performance than Variant Attributes.

Link to post
Share on other sites

One of my issues with the CVT is that as it stands everything is a double right?

No, numerics, bools, strings, and arrays of the same.

 

Yeah I have other issues with the CVT, like performance.  And when writing a messaging library that is uses a wrapper constantly for variant data, I wanted it to be light weight, and generally I didn't find a wrapper for a look up table that wasn't better when it comes to performance than Variant Attributes.

Doesn't sound like you're using it for an appropriate use case -- if every access is completely dynamic then yes there is no point to it vs a lookup. where it shines is neil's use where there are a fixed set of tags which you want to share globally but, being fixed, you can cache the lookups for. An equivalent but sometimes slower implementation would be using your variant repo where every contained value is a dvr or queue or notifier. The dvrs can be slower if, as in the opc ua situation, you want to access a large number of elements in one go. 

Edited by smithd
Link to post
Share on other sites

Doesn't sound like you're using it for an appropriate use case -- if every access is completely dynamic then yes there is no point to it vs a lookup. 

It sorta is dynamic.  Actors can unregister or register to new events at run-time, but in practice is never really needs to.  And the messaging structure is based on user events, and you can't register for an array of user events, unless each of the data types of each event are the same, which is where I used the variant as the data type.  Also there are times when I might only want some information from the variant, and I don't pull out all of the payload, something like meta data instead, and I believe this is most efficient with a variant attribute, where you don't have to read everything.

Link to post
Share on other sites
  • 2 weeks later...

Well that is concerning for sure.  Unfortunately I don't have 2015 SP1 yet, but this might be as good of reason as any to start the long download process of that whole software suite.  But the fact that this happens on the save makes me even more confused.  If it were on the wire operation then I could do some debugging and look into the VIs that get ran, when the wire operation takes place.  But the fact that the wire operation works just fine, and it is just on the save, makes me think it might be something more difficult to troubleshoot and resolve.  Well I guess I'd send the report to NI...and hope for some support.

Link to post
Share on other sites

I can't really narrow down what causes it.  But it seems like if you copy the read var xnode from the existing diagram and wire the same cluster type to it, its fine.  But if you select a new instance of the xnode from the addons pallette and place it on the diagram and wire to the same constant, then save it crashes.  I don't know if that helps narrow it down to an ability or not.  Also it doesn't seem to happen with the string data type.  So far I have just seen it on clusters.  It may be a labview bug and be unrelated to the xnode.  I have no idea.

Link to post
Share on other sites
  • 4 weeks later...

Well you shouldn't need a license to edit them, they are just XML and can be read in a text editor.  I haven't yet figured out how to link to a specific post in this new format, but the New XNode Editor 2012.zip I posted here should allow you to look at all the abilities in an XNode and do some basic editing like add other abilities.

 

EDIT:  Oh I figured it out, this is the actual post.

Link to post
Share on other sites

I still must be doing something stupid, how do I actually made modifications to an existing (or a copy of) XNode?

I can open the ability VIs fine, but they are locked.

All I want to do is try and modify your XNode to make it accept a DVR to a variant rather than a plain variant. This is my first real foray into XNodes, so I am probably missing something obvious even though I have tried to read as much of the literature as I can.

Link to post
Share on other sites
  • 2 weeks later...
On 4/23/2016 at 9:51 AM, Neil Pate said:

I can open the ability VIs fine, but they are locked.

This is probably because a copy of the XNode is in memory.  Just like an XControl you can't edit an XNode while it is in memory in another instance.  At least I think that is what is going on here.  They shouldn't be locked.

On 4/23/2016 at 9:51 AM, Neil Pate said:

All I want to do is try and modify your XNode to make it accept a DVR to a variant rather than a plain variant. 

Neat addition feel free to post your contribution if you get anything working.

On 4/24/2016 at 4:49 AM, LogMAN said:

Wow, new Lava embeds videos now :o

Super cool BTW.

Link to post
Share on other sites
  • 4 months 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.

  • Similar Content

    • By flarn2006
      LabVIEW's built-in XNode editing tools are enabled using a license file, rather than a simple INI toggle. Presumably they do this for stronger discouragement from unofficial use, as hacking one's way past that feels a lot more "shady" than just adding a line to a config file.
      But what about the Linux and Mac versions? They don't have a license manager, so how is XNode development enabled there? One might guess that those features simply aren't compiled into the released builds of those versions, but there is actually precedent to suggest otherwise. VI Scripting used to be similarly restricted using a license, but then they made it public. At the time, LabVIEW didn't have a toggle in the Options for it. But they didn't need to release a patch to add one. Instead, they simply published their formerly-internal license file, and set their activation server to accept requests to activate it. And yet, Linux/Mac users weren't out of luck: it turned out that for them, it actually was just a configuration key.
      The VI Scripting license had the internal name "LabVIEW_Scripting(_PKG)". The Linux/Mac configuration key was "Scripting_LabVIEWInternalTag".
      At 17:48 in this video, several XNode-related configuration keys are shown, likely found in strings in the EXE or resource files. One of them is called "XNodeDevelopment_LabVIEWInternalTag". Guess what the internal name of the XNode Development license is.
      I don't have the Linux/Mac version to test with, but I know a pattern when I see one. The following command was given in the readme for the VI Scripting package for Linux:
      echo -e "labview.Scripting_LabVIEWInternalTag:\tTrue" >> ~/.labviewrc Here are the Mac instructions:

      If you have either of those versions, it's probably worth a try: follow those instructions, but replace "Scripting" with "XNodeDevelopment", and see if you can open an XNode in the IDE, or create one from File->New. (Also, in the case of Mac, replace 8.6 with your actual LabVIEW version if necessary.)
      (Here's where I got my information about enabling scripting: https://forums.ni.com/t5/LabVIEW-APIs-Documents/LabVIEW-Scripting/ta-p/3535340?profile.language=en)
    • By hooovahh
      View File XNode Editor
      8 Years ago the first version of the XNode Manager was posted to the code repository in an attempt to allow the editing of XNodes.  Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality.
      The XNode Manager had a blank XNode, and blank Abilities that it just made copies of.  This is fine but then the abilities and XNode are quite old.  There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager.  My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create.  Then VI server is used to create the XNode, State control, and Abilities.  This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it.  It also reads in the XNode Ability descriptions to help understand how to use the new ability VIs.
      In addition to being able to create and edit XNodes, you also can edit the XNode icon, and description, along with adding any new abilities.
      Be aware this uses several private functions, and several undocumented features that could be potentially bad.  I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable.  But at the end of the day if it blows up and crashes, don't be surprised, you've been warned.  The original thread with discussion and progress on this tool was started here.

      Submitter hooovahh Submitted 03/15/2017 Category XNodes LabVIEW Version  
    • By Taylorh140
      After working on the set cluster element by name xnode, it made me realize i could use the same concept to convert a variant array to a cluster. The technique is actually pretty simple, the xnode generates a case structure for each element in a cluster in cluster order, wherein a bundle by name is used to set the value and an unbundle by name is used to get the type, a variant to data is used to convert the data. This has some benefits over some methods, you are not limited to 255 elements, although that is not usually the case some of us are paranoid that clusterosaurus giganticous will be larger than expected. It also has a draw back  that is that when converting from a variant array all the elements must have unique, non-blank names, and this is usually the case. 

      I think this technique (though very brute-force) might be useful for some other things let me know what you guys think.

      VariantArrayToCluster.zip
    • By Taylorh140
      This Xnode allows setting a cluster element by label string without using references. I pulled a great deal of inspiration from Hooovahhs Variant Array to cluster xnode, which i suppose this could be used for, another benefit is its not limited to 255 elements. Its mostly experimental because I haven't used it much. 
       
      SetClusterElement.zip

      SetClusterElementLV2013.zip
    • By UnlikelyNomad
      I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible.
      That said, I've started on my first ever XNode and it's a cross between an unbundle by name node and the -> operator in C. It functions just like a normal UBN, however it was also pull items out of DVRs. Having to plop down a UBN to pull out the reference from the class, an in place node to dereference, and then another UBN to pull the data out gets tiresome after about the 100th property VI gets written.
      So far I've gotten the node drawing completed (except for data type coloring of the labels), the type inferencing from the input wire, and the popup menu for selecting an item. Next up will be the menu selection code so that the names will finally show up in the terminals! Then I get the daunting task of scripting up the GenerateCode ability >_>
      Anyone interested in something like this? Following this will be a match to the Bundle by Name node that serves the same purpose except to write the items.



×
×
  • Create New...

Important Information

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