Leaderboard

Hi. I'm working alot with a concept I call AutoQueues - basically named queues that name themselves in clever ways to allow for "automatically" connecting data paths across the LabVIEW instance. The naming logic depends on the context, and the queue scope might be much narrower than the entire LV instance, sometimes all the way down to within a single VI. I can explain a bit more about AutoQueues later, but as an experiment I'd like to share one of my toolsets that builds upon that concept, namely the VIRegister toolset. VIRegisters: The VIRegister LabVIEW toolset is an intra-process communications media. A VIRegister combines the performance and simplicity in use of a local variable with the scope of a global variable – without any binding to front panels or files. You simply drop in these VIRegisters wherever you'd normally drop a local variable to write to or read from, or rather wherever you'd wish you could just drop a local variable . Even though the toolset consists of more than 160 VIs underneath, these four polymorphic VIs are the ones you drop in your code: VIRegister features: VIRegisters are independent of controls, indicators, projects and files – they exist in the block diagram(s) only. The scope of a VIRegister is user configurable, from encompassing the entire LabVIEW instance all the way down to covering a single VI only. So you can use VIRegisters to share data between parallel structures within a single VI, to share data between subVIs, or to share data between entirely independent VI hierarchies for instance. The included documentation explains how the scope is defined - it's all very easy, and has to do with VI references and the call chain. VIRegisters come with and without error terminals to support both parallel and dataflow bound execution. VIRegisters are implemented as single-element named queues, using lossy enqueue for writing and preview queue element for reading. Don’t worry, the queue names are quite esoteric (and dynamic), so there’s extremely low risk of namespace collision with your own named queues (you wouldn’t normally use “eXatvx‚ƒt/</Rtpƒt`„t„t]p|t=…xnatvn_t_tƒt_tst@SXBA” for instance to name your own queue, would you? And no, it's not just random characters ). VIRegister performance is normally in the millions of operations per second. They typically update 2-3 times slower than local and global variables, but since we’re dealing with lossy transactions absolute performance is seldom a bottleneck. Sub-microsecond latency is still pretty useful for most signaling applications. 31 data types are currently supported (very easy to expand, but I unfortunately need an "anything" type input to be able to support generic clusters and such - this has been suggested ad nauseam in NI LabVIEW Idea Exchange ): The code is compiled with LabVIEW 2009 SP1, but should be quite easy to port back and forth. The toolset is released under a BSD license, see the included license.txt file. Any comments are welcome! Cheers, Steen

Dear OpenG and LAVA Communities, I’m happy to announce that the OpenG 4.0 release is now available for download. OpenG 4.0 is a synchronised release of all packages that form the OpenG Library: The release includes the following features: Fix to all outstanding bugs (at design time). Package sources upgraded to, and tested in, LabVIEW 2009. Packages now built using VIPM 2010. I will be posting more about this release in the near future. On behalf of Jim Kring and OpenG.org, thank you. Jonathon Green OpenG Developer Installation Open up VIPM 2010 and if not configured to do so press Check All Package Repositories for Available Packages, then choose one of the two options below: Install the OpenG Toolkit package - this package will configure your system to install all the latest packages as well as remove any non-Library packages no longer required (don’t worry it won’t remove any VIs you are using). This is recommended for new or basic users. Manual installation - upgrade required packages on a package-per-package basis. Note: OpenG Builder is not part of the OpenG Toolkit and therefore will need to be manually upgraded (if required).