Jump to content

Seeing a Malleable VI (.vim) implementation

Recommended Posts

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.

Share this post

Link to post
Share on other sites
1 hour ago, Aristos Queue said:

The convert to standard is the only mechanism. I have intentions of opening up the instance VI, but I've run into some *fascinating* historical code... malleables will get a nice power kick in 2017 SP1 and some potent assist features in 2018, but opening the instance won't be in 2018 at this rate (seeing as how I need to be feature complete on the 18th). In the meantime, convert to standard and then hit ctrl+z to put the malleable back. Suboptimal but it does work. 

Yes, that's what I've been doing, and it's ok, though suboptimal as you say.  I'm looking forward to seeing the development of Malleable VIs - I've held off on trying to convert some of my XNodes to VIMs, but if things stay fairly stable, I'll have to give it a go.

Share this post

Link to post
Share on other sites

Join the conversation

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

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 the_mitten
      The introduction of parallel, read-only access for DVRs in LabVIEW 2017 adds a great deal of flexibility to using DVRs to monitor values in parallel executions of code. Fo\The downside of this, of course, is the necessity of using the In Place Element (IPE) throughout your code simply to read the value. Having IPEs throughout your code just to read a value both takes up block diagram real estate and also takes more clicks than desirable to insert.
      Similarly, though less frequently, there are times when you only need to update the value within a DVR without actually performing any logic inside of the IPE.  This situation is less frequent, at least for me, as I am usually using arrays or classes with DVRs such that I actually need to modify the existing data rather than simply replacing it.
      A more preferable solution to the above situations would be to have Read/Get and Write/Set VIs for the DVRs to simplify the process of working with them. This way, and IPE on the block diagram would only be needed when you were actually modifying the existing data within the DVR, rather than simply overwriting or returning the current value.
      Thanks to the power of malleable VIs and the type specialization structure that is now officially released in LabVIEW 2018, a better solution is now available. I’ve created two malleable VIs, Read  DVR Value (Parallel) and Write DVR Value that allow you to perform a write and a parallel read on any DVR data type.
       Now, you can use a single VI that you can insert via Quick Drop to read or to write DVR values.  
      Download the attached ZIP file to access the two malleable VIs and example code, and please let me know your thoughts in the comments!

      DVR Read and Write VIs 1.0.0.zip
    • 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!
    • 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?
    • By jdsommer
      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
      b) Cause LabVIEW to throw a DWarn on exit.

      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.
  • Create New...

Important Information

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