Leaderboard

Rather than getting worked up about useless (or even dangerous) parts of LabVIEW, here's a couple of nodes from the New VI Object list that are actually useful, along with what it appears they do: Swap Vector Elements Takes a 1D array, and swaps one element with a new value in a memory-efficient way. Get Fixed-Point Components Pulls out information about the nature of a Fixed Point variable. And here's one that looks like a no-op -- though I'm happy to be corrected Transpose 1D Array

LabVIEW Champion Jeff Bohrer (featured here and here) aka the Spinning 8-Ball will be donating the BBQ's second mystery prize... Whilst Jeff cannot attend in person, the wonderful Fab will be bringing the gift. What will it be? Who knows (I don't) Come along to find out Showering us with further gifts, Jeff imparts some wisdom for the LAVA masses before leaving: All shall be well and all shall be well and all manner of things shall be well" -Julian

Use the Dialog using Events template and use the Timeout case of the Event Structure to stop the vi. Set the timeout value to 2000 (ms) for a 2 second display of the vi. The front panel will close when the vi stops.

I think your proposed fix is not a fix but just a change of the bug. With the fix as proposed by you you end up with an index in the range -1 to n-1 instead of 0 to n. So you replace the invalid index at the end of the range with one before the range. The -1 should be better placed after the Array Size function.

HEY!!! I have a perfect example for everyone of stuff to not go poking around in! The "Get LV Class Default Value.vi" ... if you pop it open with your favorite password cracker, you'll find a Call Library Node. You pass into that Call Library Node a path and an app instance refnum and out comes the LV class. And now you're thinking, "HEY! Aristos Queue didn't put that app instance refnum on the conpane of the VI! He's hiding functionality from me! I can use this to get the value of a class in another application instance!" And so you wire up a different application instance. And you run your VI. Now, sometimes you crash right away. Other times, you don't crash until you try to close the project. Other times you just get a crash on exiting of LabVIEW. In any case, you've thrown off the reference count for LV class data because -- ha -- it is an ILLEGAL OPERATION TO PUT CLASS DATA FROM A CLASS INTO THE WRONG APPLICATION INSTANCE. You have to marshall the data from one app instance into the other app instance, because the *class itself* might not exist in the other instance, or might exist with a different definition (i.e., in one app instance you loaded c:\x.lvclass and in the other you loaded d:\x.lvlclass). And, hey, if you want to go indexing off the end of a pointer into undefined memory, this is a great way to do it. I swear, by all the nodes and wires in Heaven, none of this stuff has any business being on any block diagram except for the one that it is on and that we password protected. It is either useless to you or subject to change in a future version of LV because we're still refining it and have no intention of supporting the current version (unless it passes testing and we decide to make it official, but we might not have time to do that in a given release, so it may take a while, so just because it has been there and private for a few releases doesn't mean it will be there forever).

I think NI shares a lot with the community. There are a lot of internal details about LabVIEW in the NI KB. There are special INI tokens documented, how we flatten data, how LabVIEW behaves in a lot of solutions. You might want to look through some of our KB articles if you're curious about the internal workings of LabVIEW. However, I do not think that alpha releases are for incomplete features. Just because we have a feature that's half-done doesn't mean that everyone should be able to use it. There are good reasons we don't finish some features -- they aren't stable enough, they're too resource-expensive, they don't meet the needs of our customers, etc. If we release a feature, we will support it. We still support some decade-old hardware. NI has great technical support. But we can't support everything. I don't speak for NI, but I suspect we would rather support everything we release rather than release everything and have holes in what we support.

There's a board on the NI forums dedicated to that kind of thing - http://forums.ni.com/t5/Version-Conversion/bd-p/VersionConversion

V I Engineering, Inc. is donating 2 x Microsoft Kinects for Windows, compatible with LabVIEW! Upgrade your test systems to a virtually real* HMI! Track gestures and objects in the room and control your virtual world through the power of Kinect and LabVIEW (you can find out more about communicating with the Microsoft Kinect here and here, and you can download drivers here). *This door prize will not make you look like Tom Cruise. Unless, of course, you already look like Tom Cruise. In that case, sure, let's say that this door prize will make you look like Tom Cruise. Yeah, that sounds pretty good - put that in post. Wait, are you writing that last bit down? No, the "...let's say that this door prize will make you look like Tom Cruise" bit. No, don't put that part in the post - I don't want anyone to think we're actually promissing to make them look like Tom Cruise. I mean, c'mon, they'll never fall for that. Will they? You know what, maybe you're right - put it in there and let's see if anyone falls for it. Wait, why are you still writing?

Hi So thanks to a very very kind "insider" I am in a position to offer a very rare door prize to a lucky LAVA BBQ attendee: a LabVIEW iPhone hard plastic cover. This is for a 3G / 3GS model. Cheers Chris Roebuck CLA , CTA and all round nice guy