Leaderboard

One of the main differences is that there are very few support VIs needed (as compared to other by ref patterns) when you are using DVR LVOOP (namely you'll want a constructor and destructor for each class, including descendants). Also, prior to DVR LOOP, most patterns used LVOOP as a wrapper around a reference (e.g. Queue) to data. With DVR LVOOP, this gets flipped on its head -- you have a reference wrapper around an LVOOP object. This is the first thing that really strikes you as different and unintuitive, but once you start using it you'll see that it makes a lot of sense (and, of course, you see some areas where things still need to be further improved). Dynamic dispatch only works on by value methods, not by reference methods. It would be nice if you could pass a reference into a by value method and LabVIEW would dereference and rereference behind the scenes. So, you'll find some duplication is required if you want users of your by reference class to call into by reference methods. You'll need to decide whether you want your users to 1) dereference/rereference the data themselves and then call your class' by value methods or 2) have a by reference method in your base class that calls the by value method. Also, it would be nice if you could wire a DVR LVOOP object into a Bundle by Name and Unbundle by Name and have LabVIEW automagically dereference/rereference the data behind the scenes. Right now, when you want to just get a value of an element of a DVR LVOOP object, you have to use an Unbundle by Name inside an In Place Element Structure. This is too much work for the programmer and makes the code look unnecessarily sloppy. The programmer's tendency will be to create a non-locking Get/Preview data method, but this isn't a great idea, because it makes a complete copy of the data -- by using an IPE Structure with an Unbundle by Name inside, you only copy the element. Those are the main things I've noticed. The bottom line is that if you do by ref LVOOP this way, you're going with the grain and you'll find things to be much easier now and in the future as more native features and usability improvements get added to DVR+LVOOP. Oh, one more thing that I noticed is that edit-time performance seems much better, which is probably due to a combination of: performance improvements in the LabVIEW IDE, WRT projects/classes/etc. fewer support VIs in the by ref classes

Download LabVIEW 2009 (755 MB) Download LabVIEW 2009 (64-bit, 822 MB)

Watch this video to find out about the upcoming LV2009 Features: https://admin.na3.acrobat.com/_a56821929/p67979404/

The reference design that will be presented is already available on ni.com. Search for 'xCE'. Of course you'll need LV 2009 to load the code.

Yes.

Done: However cross calculation algorithm slowed it down quite much. And highlight execution drops "bounce" on crossings...

I begged. I pleaded. I failed. "The project is for file organization, not for defining a single application." But if someone wants to lobby for this, I'd back it in a heart beat. I've kept "ctrl+shift+R" open just in case we need a "Run the VI that my current project has marked as the top-level VI" shortcut key. And, while I'm dreaming, we could even mark *multiple* VIs as the top-level or start up VIs, maybe some of them are on other deployment targets, and hitting ctrl+shift+R could deploy as needed and kick them all off and running. Whoa... a whole new flavor of uber-geek nirvana.