Jump to content

DWarn from Xnodes


jdsommer

Recommended Posts

This is about a problem that I had with xnodes and its resolution, just any case some other poor sap finds themselves in the same situation. There may be others that have done more research on xnodes that are aware of this, but I didn't come across any info when searching.

 

In a set of xnodes I recently created, I attempted to have ModifyCode called immediately after GenerateCode. The last step of GenerateCode, in my case, was always going to be identical to the complete step for ModifyCode. Since GenerateCode has a Response output, I thought a nice clean way to do this would be have GenerateCode respond with ModifyCode. I was wrong. All this does is

 

a) Not call ModifyCode

 

and

 

b) Cause LabVIEW to throw a DWarn on exit.

 

post-2950-0-52862000-1411492012.png

 

Perhaps some more experienced xnoders have some insight as to why what I tried didn't work. In any case, I resolved it by having GenerateCode directly call ModifyCode rather than just responding.

 

 

Link to post

Very interesting.  So let me see if I get this straight because I've actually never used the ModifyCode Ability.

 

So GenerateCode is for making the code that the XNode executes.  What is common is to call this from something like AdaptToInputs after a new input has been wired.  Often the GenerateCode ability will use a template VI instead of scripting from scratch for simplicity.  So you can plop down a template VI, and wire up the terminals to the wires of the diagram, and this is the VI that is ran when the XNode executes.

 

ModifyCode sounds like it is used to modify the already made VI, created when GenerateCode was called.  For this reason I can see why you would want to try to call it after GenerateCode.

 

In my development I've only ever used GenerateCode and I would remake the VI with scripting each time.  I'm betting that in some cases a ModifyCode could be called to modify the already made VI, making that operation quicker.

 

In some of my VIs I keep track if GenerateCode has ever been completed once and behave slightly differently if it has, so that code doesn't get re-generated all the time when it doesn't need to.  I'm guessing I could do something similar where if code has been generated I could call the ModifyCode instead for faster editing of the VI.

Link to post

Yup, you've got the main idea of ModifyCode, so far as I'm using it anyway. Since I've got xnodes in xnodes in xnodes, completely regenerating the nodes was taking an irritating amount of time. In my case, ModifyCode simply handles type repropagation after AdaptToInputs if the code has already been generated.
 

In some of my VIs I keep track if GenerateCode has ever been completed once and behave slightly differently if it has, so that code doesn't get re-generated all the time when it doesn't need to.  I'm guessing I could do something similar where if code has been generated I could call the ModifyCode instead for faster editing of the VI.


I also keep track of whether or not the VI has been generated and use that to trigger whether to call Modify or Generate from AdaptToInputs. I suppose having some conditional code in Generate also would have worked. I just didn't think of it, perhaps being misled by the existence of ModifyCode.

Link to post

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 GregSands
      We've lost something useful in the "official release" of Malleable VIs (.vim files aka VI Macros) in LabVIEW 2017.  In previous versions, because VIMs were built around XNodes, then you could right-click the XNodeWizardMenu to look at the Generated Code given a particular wiring.  There's no such option in 2017, even with the appropriate LabVIEW.ini keys.  Is there another ini key that provides a similar functionality again?  I find it a useful check that the VIM is coded correctly.  The closest is to "Convert Instance VI to Standard VI", however that removes the VIM.
    • By jdsommer
      I've spent two weeks banging my head against this problem and finally found the solution. I thought I'd post it here for posterity.
       
      I have a set of xnodes (in the Live HDF5 toolkit) which are based off of the common use-template-VI-to-generate-diagram-code paradigm. I recently added a number of typedefs into the template VIs. After doing so, when placing or editing the xnodes, I received the following dwarning
       
      Internal warning 0x0 : "xstuffprivate.cpp", line 2211
      LabVIEW Version 11.0.1
       
      but only for certain typedefs. The warnings occurred after GetTerms was called and before AdaptToInputs. (Note that DWarns normally only show during the *next* launch of LabVIEW, but with appropriate .ini magic they can be made to appear immediately.)
       
      A second effect is that, while the xnode generates mostly correctly, the terminal in question does not become a typedef, but a matching type that is not typedefed (U16 enum, in my case, with all the right items).
       
      This sent me on a long goose chase trying to figure out why some typedefs worked, and others didn't. It turns out, that the typedefs that worked were being used somewhere in my xnode ability VIs, while the ones that did not work were only used on the template VIs, but not in the xnode ability VIs. I dropped a typedef constant of the otherwise-unused-in-ability-VI typedef into my GetTerms ability VI, and voila, the DWarns stopped appearing. Problem solved.
       
      Analysis: I think we know that ability VIs run in a different instance of LabVIEW from the one into which the xnodes are dropped. I don't hold open a reference to my template VI throughout the ability VIs. (IIRC, I tried this and had numerous problems.) I open it for Initialize to find the term info which is shoved into State.ctl. When GetTerms is called, I simply get the terms from State.ctl and return them to the output. I open the template again in GenerateCode.vi. Therefore, there may be no reason for the xnode instance of LabVIEW to have my typedefs open in memory at the point that GetTerms is called. By placing the typedef into GetTerms we force LabVIEW to have it open and solve the problem.
       
      Here's hoping this helps someone else in the future!
      Jason
    • By bbean
      does anyone know if the code for the Edit Format String dialog box is written in LabVIEW and is it available somewhere in the LabVIEW directory?
       
        
×
×
  • Create New...

Important Information

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