Leaderboard

Hello everyone, We have started with the development of our own embedded MIPI camera module for the Raspberry Pi with an industrial image sensor. Currently we are in the specification phase and we are interested in your preferences so we will develop a product that does fit your requirements. If you have some time, please consider filling in this 4-question questionnaire.

In the LabVIEW community a phrase that has been used to describe undocumented, or incomplete features of LabVIEW has at times been called Rusty Nails. In searching LAVA it appear this is never explained and so this post is intended to give a brief history with as many details as I know having not been active when this all took place. The earliest reference to "Rusty Nails" found online (thanks to AQ) is by Greg McKaskle of NI in 1999. Someone was asking about all the undocumented INI settings that could be found, and how some weren't exposed to the Tools >> Options dialog. Greg's reply was this: Back in the LabVIEW 5.x and 6.x era there was a new emerging technology that was LabVIEW Scripting. NI had created scripting for their own purposes but the community saw it and wanted to be able to automate editing, or creating LabVIEW code. With the help from Jim Kring and others, the basic tools for enabling scripting in LabVIEW were available. The story of how this came about is worth a post of its own, but the summary is that NI shipped a VI that didn't have a password on the block diagram, which allowed for the creation of any object, given an ID. Using a for loop, you could easily create every object in LabVIEW, including objects which facilitate in creating and manipulating code. Discussing scripting often leads into discussing other INI keys which enable private functions like the well known SuperSecretPrivateSpecialStuff. It is possible this is one of the keys Greg was referring to. Other INI keys from 5.x can be found here. After these discoveries the NI forums started getting users asking about scripting, and private functions. Users were looking for help, and documentation but NI wasn't ready for this knowledge to be public and so they started deleting all posts related to private, and scripting functionality. Some of the motivation for the creation of LAVAG came about by a desire to have an independent place to discuss the LabVIEW topics that NI didn't want to have on the public forums, potentially adding to the number of support calls, and confusing new users with advanced topics that were undocumented or incomplete. After LAVA's creation a subforum section was labeled Rusty Nails, and intended to be a place to discuss Scripting, ExternalNodes, XNodes, Private methods, and general LabVIEW hackery. Over the years several private functions have been made public, and scripting has become an official feature shipping with LabVIEW. Because of this the Rusty Nails and XNodes subforums were combined into what is now the VI Scripting section. Even over on the official NI forums, discussions about private functionality and XNodes has been relaxed since those early days. Asking for private methods and getting unofficial help is something users, and sometimes NI employees will participate in, without the heavy censorship seen earlier. And topics of scripting are encouraged now that the feature has been official since LabVIEW 8.6. If you have anything you'd like me to add regarding scripting's history feel free to reply and I can add it. And if I got any of the details wrong let me know. Again I wasn't around when this all took place and I've just tried putting down the details I've heard from other developers.

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)  

Hey, Derek here. Stoked to see GPM came up. Couple of things I want to mention. The current GPM release is still a beta release. If you find bugs or want to request features, add them to the issue tracker. https://gitlab.com/mgi/gpm/gpm @ShaunR Theres a CLI and a GUI. The CLI will probably be used by CI setups, the GUI will be used by people. Eventually (though not currently) anything that you can do in one you can do in the other.(the "commands" that the CLI and GUI execute are just two different ways of executing the exact same business logic.) I know it needs to support distributing things like quickdrop plugins. I haven't quite decided how I'd like to do it, but I definitely realize it's something that's needed before a full on release. https://gitlab.com/mgi/gpm/gpm/issues/18 Yeah, @David_L I agree, +1 to the number of package managers sucks. Sorry :/ Back to the OP's topic: One of GPM's goals was to answer this question. If you have code that you want to give out for free, I think it should be trivially easy to do so. Using GPM, you just fill out the meta data, create an account on https://gpackage.io/ and then click publish. Once the command has finished executing you're good to go. It's published on the internet so anyone can download it. Someone who wants to use your code just needs to install it using GPM. If your code depends on other packages they'll be installed at the same time. It should be super easy (let me know if it's not!) Additionally, GPM package meta data has all of the fields needed to properly index your stuff and link back to your repo. This makes it easy for people to find your code, and contribute to it as needed. Happy to answer any more questions (or argue about design decisions =P)