LabVIEW Scripting officially released today. In case you've been living under a rock (or you never visit LAVA), LabVIEW Scripting is an (until today) internal LabVIEW feature that allows you to write VIs that create, modify, and inspect other VIs. In my 7+ years in LabVIEW R&D, I have worked on *a lot* of products that utilize scripting...VI Analyzer, Simulation Interface Toolkit, and the Ladder Editor, to name a few. I'm really excited that I'll now be able to discuss scripting with the LabVIEW community, since it's been such a big part of my job for so long.
If you're looking to get your feet wet with scripting, I think the best way would be to write a plug-in for the JKI Right-Click Framework. With this framework and LabVIEW Scripting now available, we can write all those little features for the LabVIEW editor that we've always wanted. I know I plan on writing some plug-ins as soon as the framework is available.
Another benefit of the scripting release is that I can post utility VIs to the NI Forums that utilize scripting *without* having to password-protect their diagrams anymore. :)
Monday, May 4, 2009
Ok...maybe I don't have *quite* 2009 reasons, but I am a big fan. In case you hadn't heard, the next version of LabVIEW will be LabVIEW 2009. This wasn't a big secret or anything...the new versioning scheme was revealed when we announced the beta. Going forward, each LabVIEW release will simply be versioned based on the year of its release. In no particular order, here's why I like this idea:
- It's immediately obvious how old of a LabVIEW version we're dealing with. As it is now, I can't even remember what year LabVIEW 7.0 released (I just looked it up...2003 apparently).
- We become more consistent with other software out there that is moving toward year-based versioning.
- Most toolkits will also be adopting the year-based versioning. So now we don't have to remember that Report Generation Toolkit 1.1.3 only works with LabVIEW 8.6, or that VI Analyzer Toolkit 1.1 only works with LabVIEW 8.0, 8.2, and 8.5. Going forward, Report Generation Toolkit 2009 will work with LabVIEW 2009, VI Analyzer Toolkit 2010 will work with LabVIEW 2010, etc.
- The internal version of VIs saved in LabVIEW 2009 will be 9.0. So it's pretty convenient that the year '2009' lined up with that.
- This one is minor, but up to this point, we always had a code name for LabVIEW releases in R&D. 8.6 was Saturn, 9.0 is Orion. (Again, not a big secret here...I figure if one of our VPs can talk about the code names, so can I). So when you'd talk to somebody about the release, half the time they'd use the code name, and half the time they'd use the version. Now we'll just be referring to each version by the year of its release...no more code names. Trivia question: Any non-NIers out there know the code names for prior LabVIEW releases?
- We won't be using this versioning scheme for drivers. Again, I think this makes sense, because a lot of drivers release multiple times per year. Plus, I don't think I've seen any other driver developers out there use year based versioning. It appears to be primarily for application software.
- I've noticed that people have interpreted LabVIEW version numbers in very different ways over the years. Some people think "x.0" releases are unstable and won't touch them. They prefer to wait for the much more 'stable' "x.1" release. Other people think "x.0" releases are the only ones that have any worthwhile new features, and the "x.1" releases are only 'minor updates'. Truth is, every LabVIEW release (barring x.y.z maintenance releases) is a major release. I've found must-have features in every LabVIEW version since I started programming LabVIEW. I think year-based versioning will help us all gain a more unified vision of what to expect out of a yearly LabVIEW release.