Search the Community

I have a large project with many libraries which I am trying to release as a Source Distribution. I am regularly releasing standalone executables of that project without a hitch. However, the source distribution, once I open the top level VI in a copy of the project I place in the source distribution folder, after updating all paths to the new destination, ends up with many broken VIs. Examining the source of the problem, it appears that it is due to many (if not all) VIMs in my project being replaced by VIs with made-up names (random series of characters.vi), and the Assert Type VIMs in those VIs being themselves replaced by similarly randomly named VIs, and broken. I recall having read threads about some sort of incompatibility between VIMs and libraries, but since I did not have any problems with them during development (or application release), I am kind of at a loss as to what to do next... Is there some literature I can read on the dos and don'ts of Source Distribution release and VIMs + libraries? LabVIEW 2021 SP1 64 bits on Windows 10.

View File Hooovahh Array VIMs Here is the Hooovahh Array VIMs. This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques. In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette. Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels. And a few functions have added performance based on other inputs. For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted. The Filter 1D array can also be more efficient if the input is known to not contain any duplicates. Because these packages contain VIMs, they require LabVIEW 2017 or newer. Having these functions be VIMs mean all functions work with various array data types. Included functions are: Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array, Scalar, Row, Column Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  

For those who have been playing with malleable VIs, the Type Specialization Structure has probably become a common sight and much abused tool. The basic use of it is that if the action it performs is meaningless given one of the inputs, the included code will break and the next case will be tried. This is great, but sometimes, it can be difficult to think of all possible variants of an action, and in particular, if the action needs to be different for two or more types, but two or more types are compatible with different codes, how to make sure which code will be executed with what type? Enters the Types Must Match function: I found this little gem in... Hidden Gems, within an odd-looking VI which I felt compelled to check out, Debug Write.vim Open its diagram and light will shine, opening grandiose vistas and parallel universes remaining to be explored. Of course, as the comment on the diagram says: "This structure and the type-testing primitive functions it contains are not public LabVIEW features. They are experimental and should not be edited, copied, or used in other VIs without conducting extensive testing. See Context Help for details." Here is the context help for Types Must Match: My apologies if this all well-known among expert users, but I couldn't find it mentioned otherwise on the site...

I am getting this strange error whenever I try to drop a .vim into a VI that is saved. If the VI is not saved, everything seems to work but as soon as I save it and try to drop in a .vim, I receive this edit time error. This happens to any .vim file, even blank ones that I have just created. If I double click on the error then it will highlight a specific object that I can delete but the object is otherwise invisible and unclickable. This started happening right after I tried to add a VIM through scripting. I can actually still add a VIM through scripting but it has some pretty interesting context help. So I guess the question of the post is what the heck did I do and how can I get LabVIEW to start behaving again.

After reading this LabVIEW Idea exchange request: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-a-better-way-to-implement-a-polymorphic-VI/idi-p/920487 I was inspired to create VI macro(s) to attempt to address the problem mentioned in the request. Attached is my first attempt and I'm looking for feedback since I know people here have strong opinions. The benefit of this method is that a single vim (or 2 could replace a polymorphic VI with over 48 separate VIs....unless I'm missing something. I know that VI macros are not officially supported by NI, but that hasn't stopped us from using unsupported features before. Some people have probably already done something like this, but I couldn't find an example. To use the files, unzip them and copy them all to your \LabVIEW (version)\user.lib\macros\ directory. Create the directory if it does not exist. For example: C:\Program Files (x86)\National Instruments\LabVIEW 2014\user.lib\macros\ And as described in the wait-ms-with pass through post below, modify your LabVIEW.ini file to have the following ExternalNodesEnabled=True and Optionally XNodeWizardMode=True http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Wait-ms-with-error-pass-through/idc-p/3178218#M31820 Open the Example Changed.vi and review. Changed Example.zip

Name: VIM HAL Demo Submitter: ShaunR Submitted: 25 Sep 2015 Category: *Uncertified* LabVIEW Version: 2009License Type: MIT This is an experimental demo to investigate VIMs (vi macros). It was a bit of fun to see if VIMs could be used to encapsulate events in LabVIEW which was a bugbear of mine for quite some time. You can see the entire thread here. VIMs are a NI experimental technology similar to Xnodes but less mature. The purpose of this release is to clarify the previously unstated licence since other forum topics are building on the original demo so they need a permissive licence (MIT). This release serves as an unambiguous statement to that effect. There are a few differences from the original which I have decided to call version 0.1 but they are minor. Note: This may or may not work for you out of the box. If it doesn't then please do not post. The purpose is to clarify the licence for others to build upon; not to provide a working example. The VIM technology is itself experimental and unsupported by NI so most issues you will encounter will be due to this and It is unlikely there will be another version posted here. Click here to download this file