Jump to content

Strict typedef in XNodes


Go to solution Solved by Jon Kokott,

Recommended Posts

Hi guys!

 

I'd like to have my XNode to behave differently when the input is a (strict) typedef but also differently according to the typedef path (or name) if any.

 

In a regular VI, this is easily done by extracting the path of the typedef: Terminal>Control>TypedefPath,

but in Xnodes it's another story!

 

So far I managed to get the regular type in the 'AdaptToInputs' ability (which is the common use of this ability!)

and to see if it is a typedef or not by reading the properties of the control in the 'GenerateCode' ability.

 

But in this last ability VI, an error occurs when I try to obtain the TypedefPath (Error 7).

This error apparently occurs in Xnodes and especially Express VIs when "one of the internal paths is hard coded incorrectly"

 

Is there a limitation due to the XNode or else?

 

I guess that I could get around the problem by scripting the owning VI and retrieve the typedef of the control connected to the XNode directly but it would be quite cumbersome and ugly.

 

Any thoughts on the subject?

post-43646-0-98901500-1383702736_thumb.p

Link to post
Share on other sites
  • Solution

I think its because your terminal on the xnode isn't really a typedef but just an adapted terminal.  Maybe try opening the typedef itself (by using the string of the actual name) and then getting the path.

 

So somethign like:

 

control -> Value-> Strip out typedef name from variant -> open vi reference (with the string name in same application ref) -> then get path.

 

~Jon

Link to post
Share on other sites

Nicely done, I didn't think about extracting the type from the variant!

 

Based on your idea, I used GetTypedefPath.vi which is in the vi.lib folder and it works perfectly in the 'AdaptToInputs' ability without scripting the XNode reference.

 

Thanks!



UPDATE: For the challenge, I also tried to get the type of the control by following wires from the XNode

               back to the control/constant source of the type (since I didn't manage to get it from the XNode control before the solution of Jon)

                and it works also.

                It is a lot more complicated (and stupid?) but it works.

Link to post
Share on other sites

Thanks Jon!

 

Yes, debugging XNodes and figuring their behavior behind the scene can sometimes be a pain in the butt!

 

It is true that because of the lack of support from NI, stability of XNodes and compatibility are not guaranteed.

That said, in my case clients always require the source code but rarely modify it themselves, so I was thinking that replacing all XNodes by their generated code in the release version could be interesting...

(I would then continue the development using XNodes from my private version or replace back the generated code parts by their XNodes for the development of following releases)

 

If we do not use abilities like "OnFontChange", etc. (abilities that depend on the platform), it would be seamless to the user/client...

Of course it would not work if the client wants to modify also the code generated by these XNodes!

Link to post
Share on other sites

For the only Xnodes I created/actually used, I created a method where you could right click on the Xnode and replace the Xnode with a subVI containing whatever the xnode created.  Its really straightforward to implement, I'll try to dig it up but its been a while and I haven't been maintaining it.

Link to post
Share on other sites
  • 2 weeks later...
  • 3 weeks later...
  • 3 weeks later...
  • 4 weeks 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 GregFreeman
      I currently have a project that I am refactoring. There is a lot of coupling that is not sitting well with me due to typedefs belonging to a class, then getting bundled into another class which is then fired off as event data.
      Effectively, I have class A with a public typedef, then class B contains ClassA.typedef and then class B gets fired off in an event to class C to be handled. Class C now has a dependency on class A which is causing a lot of coupling I don't want.
      For my real world example I query a bunch of data from our MES, which results in a bunch of typedef controls on the connector panes of those VIs. Those typedefs belong to the MES class. I then want to bundle all that data into a TestConfig class and send that via an event to our Tester class. But, now our tester has a dependency on the MES.
      I see a few ways to handle this. First is move the typedefs currently in the MES class, to the TestConfig class. The MES VIs will now have the typedefs from the TestConfig class on their connector panes, but at least the dependency is the correct "direction." Or, I can move the typedefs out of classes all together, but then I am not sure the best way to organize them. Looking for how others have handled these sorts of dependencies.
       
    • 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
×
×
  • Create New...

Important Information

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