Leaderboard

Where to start. A wiki here a wiki there, everywhere a wiki. We used to have a section on LAVA which was like a Wiki many many years ago. However, I shut it down. Reasons: Users didn't know it was a Wiki and instead of posting questions to the forum, would create new Wiki pages with their questions. This was a nightmare to moderate. It was setup so that when you created a Wiki page, the discussions for that page, would be linked to dedicated forum threads. Again, more confusion, since it was not a model commonly used elsewhere on the web. The forum\wiki blend was not very intuitive and it made the site hard to "figure out". Nobody cared or understood the wiki. A handful of people used it and never really caught any steam. After that experiment was shut down, I decided to create a separate domain dedicated to the LabVIEW Wiki. It was labviewwiki.org. I still own this domain. I think this was 2009, I don't recall. But anyway, I used the same open-source software that powered wikipedia, mediawiki. Here's the wiki-index page: https://wikiindex.org/LabVIEW_Wiki. Seems like it had around 300 pages. MediaWiki is super powerful, but not intuitive for new editors. I spent most of the time creating templates and documentation describing how to edit pages. I created a lot of the content but there were some others who added unique content like all the LabVIEW ini keys. All the keyboard shortcuts. All the hidden scripting features (before it was mainstream), etc. It was pretty cool. And yes, we had awesome landing pages and getting started pages that I spend hours and hours crafting. I was young and motivated. The problem was that we got struck with a rash of spammers. More like bots. They would go through and create hundreds of pages overnight. In that environment, you need moderators and editors to delete the pages and watch for edits. I was the only moderator and admin. So my plate was full. I ended up locking it down and forced it so that you had to have a login account to edit pages. On top of that, the login's had to be manually approved by me to prevent bot accounts. Of course, a wiki cannot be maintained or augmented by one person. The whole point is to have a community edit the pages. Not sure if Wikia (or MediaWiki) has solved the spamming issue. @The Q, I noticed a lot of the content is scraped from ni.com. Have to be careful about this and copyright claims. One thing I was very careful about with the LabVIEW Wiki I worked on was to create original content as much as possible. Also, what's the point of just duplicating ni.com. That's pointless in my opinion. Google does an excellent job of getting the info you need from multiple sources. But that's my opinion and the community edits should drive that of course. Sounds like the community wants to reboot the Wiki idea like Hollywood reboots comic book heroes. Sure, let's see where this goes. @The Q seems to be enthusiastic about it. Are there others here willing to put the time and effort into building the content? Any volunteers? If there is some real interest, then I can try to resurrect the old Wiki content and domain (not sure if the content it's salvageable, but I can try). Then we can go from there. I don't have time to admin the site but I can hand over the keys to someone that has more time.

Hi All Apologies if this isn't the correct forum to post this on but I wanted to let the community know about a new LabVIEW podcast series I am running - The Quick Drop Podcast QDP LogoQDP is a community driven podcast that I want to use to talk about LabVIEW and engineering/Science in general via a medium that I don't think we currently make the most of. So far we have 2 episodes which are available on most podcast platforms (i'll link some below too): Ep 0.1 - Intro: A brief intro to me & rasons behind the podcast Ep 1.0 - NI Linux Real-Time Controllers with Neil Crossan: I am Joined by Neil Crossan, a Certified LabVIEW Architect, TestStand Developer & Certified Professional Instructor who works in ATE development. Neil shares his experiences with the cRIO platform & some headwinds he's had using the current platform as well as addressing some of the ways he's customised and optimised the NI Linux Real-Time OS. I am actively looking for more people to do episodes on, so if you have an idea please contact me: E-mail: info@tthequickdroppodcast.com Twitter: @quickdroppod Links: Apple Podcasts Spotify Anchor Stitcher Thanks! Jono J Hobson Certified LabVIEW Architect

Recent versions have a WYSIWYG editor. Requiring an account makes sense, especially if you already have an SSO to integrate MediaWiki accounts with forum accounts. A project I'm in uses the Moderation extension for MediaWiki: https://www.mediawiki.org/wiki/Extension:Moderation. It's quite decent; it shows a list of pending edits to be approved/rejected, so the public won't ever see the vandalism and a moderator won't have to waste time reviewing an edit that has already been greenlit by another moderator. Moderators can also mass approve/reject edits by a single account. You can also whitelist certain users so their edits get auto-approved.

It does not crash if you typecast the integer to the right refnum (be it DVR or any other LabVIEW refnum), But it can badly crash if you ever convert DVR_A into an int and then try to convert it back into DVR_B or any other LabVIEW refnum. The int typecast removes any type safety and LabVIEW has no foolproof way to detect in the Typecast to Refnum conversion that everything is alright. LabVIEW does have some safety built in there such that part of the uint32 value of any refnum is reserved as a random identifier for the refnum type pool it resides in (so a file refnum has another bit pattern for those bits than a network refnum) but it can not verify safely that the int coming from a DVR_X is fully compatible to the DVR_Y you want to convert it to. And then as soon as it attempts to access the internals from DVR_Y according to its datatype it badly reaches into nirvana. So if you do the typecasting all safely behind the private interface of a class so that nobody else can ever meddle with it AND you are very very careful when developing your class to never ever typecast the wrong integer into a specific DVR (or Queue, Notifier, Semaphore, etc) you are fine, but there is no LabVIEW holding your hand here to prevent you from shooting in your own feet! The original idea comes from before there where DVRs and LabVIEW GOOP. In LabVIEW 6 or 7 someone developed a first version of LVOOP, which used a private "refnum" repository implemented in the LabVIEW kernel and accessed through private VIs using a Call Library Node. It was basically like a DVR that was also the class wire. Obvriously DD was not something that would work seemlessly but had to be programmed explicitedly by the class developer and hence was seldom used. The pointer (which was back then an int32 since all LabVIEW versions were 32 bit only) was then typecast into a datalog file refnum with a specific enum type for typesafety so that you had a typesafe refnum wire to carry around as class wire. Some of the DVR based class design (reference based classes) in the Endevo/NI GOOP Framework still reminds of this original idea, but now using proper LabVIEW classes as the class wire. Additional bonus is that this buys them automatic dynamic dispatch capability.

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.