Leaderboard

I did a presentation at NIWeek 2013 on the new user event features in LabVIEW 2013. I will post a link here when it's ready for online consumption. For now, I'd like to start a discussion on what all the LAVA members think of the changes and additions. If you have questions on how one feature or another work, please post here and we'll get it answered. To summarize, here is what was changed, added: New - Event Inspector Window (you're gonna love this!) New - High Priority events New - Flush Event Queue Function New - VI Scripting methods and properties for events New - Mouse Scroll Wheel Event Improvements to the Edit Events Dialog: It's now resizable (Finally) You can filter search the list of event sources and events. For easy navigation. You can limit instances of the event in the static queue (Similar to Flush Queue function) [*]Finally, there was a behaviour change: Non-handled, dynamically registered events do not reset the Event structure timeout terminal. In LabVIEW 2012 and older: Non-handled, dynamically registered events reset the Event structure timeout terminal. Let's keep this positive. We all need to learn how to use these new features and how to integrate them within our frameworks. I know a lot of you are using user events as the main communication mechanism for your processes and modules. Let's figure out how to make our code better with all this new cool stuff.

The NIWeek 2013 Videos are compressed and ready for down load from Tecnova's ftp server All of the videos are files and are around 400 to 450 MB for an hour presentation. I would strongly recomend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple viedos the ftp client makes things much easier. My ftp client of choise is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found here Thanks to my IT department at Tecnova for giving me the space. V I Engineering has also volunteered the ftp server to help distribute the videos. Thank you Chris for your help. Use this log in information ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. For Use this log in information ftp://tahoe.viengineering.net/LabVIEW_Videos login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. I compressed and uploaded these videos in a rush and didn't have time to look through them all so if you find issues please post to this thread. Please enjoy and share the videos with anyone you can. Mark

I was struck by a number of things at NI Week 2013 but one in particular I want to comment on. Nancy Hollenbeck did a marvelous job of presenting on FGVs, Action Engines and DVRs. It was really a great presentation but I did have a thought about one aspect of what she presented. Nancy drew a distinction between FGVs and Action Engines, essentially pointing out that a "bare" FGV is really just a global and, therefore, doesn't protect against race conditions, etc, etc. From that perspective an Action Engine is an FGV that, because of its "Solitron" like structure does preclude race conditions. OK, fair enough and clear; however, I had a different thought. FWIW I think we should call a "Nancy" FGV a DGV means a DYSFunctional Global Variable because it has ALL of the liabilities of a global AND is far, far slower to execute. That would allow us to agree that a FGV is an Action engine BECAUSE it is functional, etc, etc. OK, I do get into semantics at times so I apologize and Nancy it really was a fabulous presentation.

I don't believe there is one all encompassing "better" answer to this. This was a question I asked AQ and I often think back to his response. If you have your class API passing a reference then you are making the decision about the scope of access i.e. which functions are "atomic". If you want to call subsequent methods as an atomic operation you can't as each method will get and release the DVR. In this scenario keeping the object by value is better as the developer using the API can decide if he wants to use by ref or by value and can also decide what function calls are atomic and which are not. That said there are often cases where classes only make sense to be reference based. For example I am working on a class for a file API. In this case I use the DVRs in the API as this is how most people would expect a file to work. Thinking about the response from AQ now, I wonder whether the whole property node would be atomic, that would appear to be a sensible implementation although I have never tested it.

Do you guys really use FGV or AE much anymore? I would think it's a dying practice now with native classes.

Well what's the price?

You don't use the auto-indexing feature of the outer For loop and the inner For loop isn't doing anything. If you right-click on the pink tunnel on the left edge of the loop and select 'Enable Indexing', you'll be able to remove the 'Array Size' and 'Index Array'. I see you edited your post since I last looked at it. Here's what I've done:

Semantics aside a FGV can have race conditions, just like a normal global. But a FGV gives me the ability to perform other functions, other then just read and write. Because I don't know how my applications needs will change in the future I never use native globals, and only FGV. Lets say I'm storing an array of values, well I can have my method on the FGV "Read" "Write" and "Average" a native global can't do this without extra code which isn't that big of a deal but I prefer this method. Other functionality that can be done is stuff like WORM. Where a global can only be written to once then it will generate an error if it is written to again. Many of the pitfalls of a native global exist in these other VIs, but allowing added functionality, and also adding other debugging tools helps to make sure you don't shoot your self in the foot. But it can still happen.

NIWeek 2013 videos are ready for download. http://lavag.org/topic/17040-niweek-2013-videos/

If you want to update the graph only after events come in, but don’t want the overhead of updating every event in a “burst”, you can put a “-1” constant inside the timeout case and wire it back through shift register into the timeout, and set the tunnel out to “Use default if unwired” so that the timeout is zero after any event other than timeout.

Favorite feature: LabVIEW Web Services in 2013 -- the R&D Team nailed it with the all-new LVOOP API

You're welcome. (And sorry it took so long for us to find a way to address this). The changes that improved this performance were specific to the listbox, multicolumn listbox, table and tree controls. I don't expect that they will conflict with any "programming around the problem" tricks that you've used in the past.

What have you written?