hooovahh

Last year there was an NI Week app that really helped me be organized and see quickly what sessions were at the same time as other ones. Does anyone know if that will exist for this year again? Or is there an easier view for sessions online rather than a list?

In my argument, we are developers, not users. Style guides exist for a reason, and not following them things more difficult for developers. Something about that code bothers me way more than it should. If I ever need to use it I will surely spend making my own copy and fixing it.

Along the same line of thought, why should source code need to be well documented, it will just go into an EXE where the user doesn't see it anyway.

I was posting on NI's forums today and linked to the LIFA page. On their main page they link to LINX saying it includes all the features of LIFA with a bunch more. I certainly wouldn't recommend it. https://decibel.ni.com/content/groups/labview-interface-for-arduino

Well despite the very vague answer of a single picture, I was able to implement some kind of code improvement using that information. Attached is a new version that doesn't perform any better, but does do the GenerateCode in a different way that is more flexible, and removes the dependency on the LAVA Scripting package. I also added code to change the icon image based on the data type wired, and have it so it can read the tag data from the type wired in. As I said before this maybe release as a complete package at some point, but for now anyone interested in doing XNodes can use this as an example on how to do similar things with adaptive terminals, icons, and custom right click menues. XNode Read Variant.zip

I was going to be funny and post a random VI that had all kinds of XNode Scripting properties all linked together in a random way, but I just can't copy his level of intrigue, while still on the surface looking random. I mean what he posted is almost not relevant to what we were talking about, but then I realized it could have been very useful at the same time.

What is that supposed to do? I realize what it is doing but I'm not sure how it is helpful. The XNode Template.vi isn't the VI being ran when an XNode runs, and it already is inlined. Is this supposed to show a simplier way to perform the GenerateCode than the way I did it with using tags on the tunnels of a structure? Because if so I like it. EDIT: Wait so I inline my template, but how do I wire up my controls/indicators? The controls I can look at the labels of the constants, but how would I wire the indicators?

Okay Jack you were right. I thought 2ms was too low. In my test I was reading the same attribute over and over and the compiler must have some how optimized for this. So I did a new test, where I had 1M tags, like your example, then read them all using a normal VI that is inlined, a normal VI that is non-reentrant, and my XNode. For added interest I also had the This VI returned from the Xnode because I figured I would be able to read the execution inofrmation from the XNode VI. With my test the Normal Inlined VI took 607ms. Probably lower than yours because I am just reading, not checking for validity like your was. My non reentrant was 701ms. The XNode option was 606ms. But interestingly enough when I read the VI Name of my XNode VI reference returned it was the name of the calling VI. So an XNode appears to do some sort of inlining, but I can have things like property nodes in my XNode which normally inlined VIs cannot. Of course doing this screws with all the performance numbers I mentioned earlier so I removed that. Attached for those interested is my read XNode, along with the VI to check performance. This has a dependency on the LAVA Scripting Tools. But I think that's it. I made this Read XNode because I wanted it to have the combined ability that a polymorphic VI can have, where you right click and choose the type, or you could wire in the type. So right click the XNode and you can choose from a large list of data types to read, or if you pick Automatic you can wire in the type to use. I'd like to release this at some point but for now it is a learning exercise. EDIT: Saved in 2012 XNode Performance Test.zip

I have used silver controls, but I have two issues with using them. There isn't a silver control equivalent for every classic, or modern control. So UIs will generally need a mixture of mostly silver controls, and then a modern, classic, or system, because that control isn't available in the silver palette. Secondly if silver controls are made for the UI then why would they be used for a driver level piece of code that we should assume no user will ever see? If it is for the UI, then why use it in a program that has no UI? Silver Clusters, and Arrays take up a lot of space on the front panel especially when you have arrays of clusters of arrays etc. Again for a driver level piece of code where we really only care about the inputs and outputs as data, not as they are seen this is a waste. As for strict types. In the past 2 years I have made 2 strict type defs, in the dozen of applications I've made. For me it restricts the things I can do, and again unless it is for a UI why do that?

Hello all, I've been doing some XNode development and I think it is awesome. My first XNode is an attempt to wrap some functionality into a set and get variant attribute, with some adding stuff similar to write once read many. In any case all is going great and I have the Write and Read XNodes working fine. So I wanted to compare their performance to the native, or polymorphic equivalents. For performance I have my normal VI version set to inline, with debugging, and automatic error handling off, and set to reentrant. Calling the this VI in a loop 1,000,000 times takes about 2ms. I then ran the same code but as an XNode and it took 265ms. So I figured this must be because the XNode VI isn't being inlined. So I added code to the GenerateCode.vi and have it set to make the execution settings the same as the normal VI version and ran again. Still about 200ms. I tried the reverse, and made my normal VI not inlined and it now takes 200ms. I put probes in my GenerateCode.vi and see that I am setting the execution correctly, but when I right click the XNode and choose Generate Code from the wizard menu, the VI generated doesn't have the settings I set. Has anyone seen this type of thing before? Is there some extra work involved in setting this execution settings, or is this a bug that there is no need to inform NI about? EDIT: In doing some tests it seems the diagram provided in the GenerateCode.vi is a "XNodeGenCodeScratchPad 1" and is likely not the VI that the XNode runs, so changing the settings of this VI does not change the execution settings of the VI that is ran when the XNode runs.

I did think it was odd that I couldn't find any USB AIO hardware. In either case I've never used them but am curious too. LabJack was another one I've heard of but never used.

There are way too many things wrong with LINX for me to use it. I made a post on their forums and the response was more or less that nothing is going to change. https://www.labviewhacker.com/forums/viewtopic.php?f=12&t=55 I am so glad to see that I am not the only one who thinks it is ugly. Who uses strict types in a driver level code? And who uses silver controls? And who hides data in a cluster by not showing it? Seriously I found myself changing all of their code just trying to use it. I was digging into the low level VIs and I saw them also constantly making their own subVI to do a function that already exists nativly, or in OpenG. Building relative paths, making a zip out of a directory, create folder if none exist, Get LabVIEW Data folder, Get LabVIEW Directory, Get File Extension, Get Relative Path, Strip Path to EXE, relative path to array of string, etc. These are just a few subVIs that are remade, instead of using the native function, or the OpenG function. If you look at some of the LAVA tools we have they replace even more functions, but I figured I wouldn't include those since they are less popular. In the end I am staying away from LINX. I don't really need it, LIFA does what I need when it comes to Arduinos, and the other supported hardware I haven't needed yet. I was just looking to extend the LIFA features and thought I would start with LINX instead. For me it was better starting with LIFA and adding the functions I wanted.

The scripting function is the Master Bounds Rect on a picture control. I have built executrices that use this and have had no problem. And according to the help on this function it is available in the Run-Time Engine, and even the Real-Time OS which is a little odd but okay.

Oh I'm sure there is. But why is that such a bummer? What's wrong with using a scripting node? It isn't a private function? It is endorsed by NI with documentation. I didn't see anything wrong with using it because of this.

Name: Toolbar Class Submitter: hooovahh Submitted: 16 Jul 2014 Category: User Interface LabVIEW Version: 2011 License Type: BSD (Most common) Toolbar Class Copyright © 2014, Brian Hoover (hooovahh) Author: Brian Hoover (hooovahh) Environment Support: LabVIEW 2011 and up Windows only (likely XP and newer) due to .NET dependency Description: This is a toolbar class designed to make toolbars in the UI, which appear more like normal toolbars seen in Windows. The idea for this came about because I wanted a way to make a simple toolbar, but didn't want to have to make all the button states for mouse not over, mouse over, mouse down. I just wanted to provide one PNG file for a button, and have it take care of how the button should look. I also wanted a way to handle when there are more buttons than there is room for horizontally. When this happens I wanted a More Options button to appear which when clicked gives a vertical list of the remaining buttons, and a veritcial scrollbar if there are too many buttons to show vertically. I also wanted support for basic veritcal and horizontal separators. This toolbar class can do all these things, and all that is needed is to provide the buttons as PNG files with alpha layers. other file types like JPG, and BMP are supported but won't look as good just because buttons don't need to be a rectangle and can have soft edges. The Add Icon(s).vi is a polymorphic and also can add images from Image Data, or the native LabVEW picture data type. But these image types have the same issue mentioned with JPG and BMP that they don't support alpha layers. Dependencies: This relies on the following OpenG packages, a VIPC is included. OpenG Error Library-4.2.0.23 OpenG Application Control Library-4.1.0.7 OpenG File Library-4.0.1.22 OpenG String Library-4.1.0.12 OpenG Array Library-4.1.1.14 OpenG LabVIEW Data Library-4.2.0.21 Installation and instructions: At the moment this is not distributed as a package but just a zip with the required files in it. Install the OpenG packages required or install the Required Packages.vipc. Then run the Example Toolbar under the Example folder. This uses images from within the Example Images folder and must be in the same directory as the Example Toolbar.vi. There is also a Toolbar Tree.vi which shows the public functions as they could appear on the palette. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Click here to download this file

Post an example of your code so others can see what you mean. I don't have IMAQ so I won't be able to try it myself. Also if this is a real bug you will want to notify NI too.

Funny you should say that, I'm actually helping organize this year. So there's a chance I'll give the prize to myself. Conflict of interest? Maybe.

Oh man that is cool. I didn't get anything last year so I should get a myRIO this year right?....right?

Finally got the confirmation I can go. Now to frantically buy everything. Also Hooovahh Incorporated a division of Hoover Corp is donating a Teensy 3.1 microcontroller.

Or have moderators around to split topics...

So whenever I go to use this function for simple programs, I always open the VI copy away the functions it calls (which admittedly aren't much) and paste those into my VI instead of calling that VI directly for that reason. Wouldn't it suck if all VIs on the palette didn't return an error but instead had a simple error handler in each of them? Then why do that for this function?

I agree with the error message. But I found that if you go to File >> Open Package File(s) and select multiple packages, one or more of which is built with 2014, then choose to Add to Library, a error comes up explaining that it was built with 2014 which is incompatible. Not sure why this error wasn't used in more places.

This is generally because the package was built with VIPM 2014 which had new features not compatible with previous versions of VIPM.

Would the UID work? It looks like it applies for all GObjects. The help states that it is only unique for objects within the same VI but you could try to hash the UID with the VI name or something like that.