hooovahh

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.

It is voodoo magic. Explain to me why Copy 1.vi gets executed when you drop the XNode on the palette? This is a neat feature, but it doesn't help us get more insite into XNodes.

That is some voodoo magic. I was wondering how that was done too but never looked into it. If I had to guess I'd say Xnodes have the capability to run something on loading of the Xnode into memory. There are obviously at least 3 files in that library, the _Copy 1.vi, _GetHelp 1.vi, and _State 1.ctl. The two VIs are password protected, and don't really go anywhere. EDIT: So it doesn't have to do with the XNode getting into memory. If you load the XNode file as a library it doesn't launch anything. From there you can't do much other then read the library name, get the locked state, and get the Icon of the library. DOUBLE EDIT: So the GetHelp appears to do nothing and loads nothing other typed controls into memory. It never returns an error and does nothing. The Copy function always returns "FailTransaction" as the reply, and never returns an error and appears to do nothing with the XRef input. It does however run the <LabVIEW>ProjectFind LabVIEW Add-ons.vi with the input Source having a constant. Still not sure how the XNode runs this VI when you select it from the palette, or drop it on the block diagram.

It isn't clear what you are trying to say. On the second PC, what happens when you run the EXE? Does it run? Does the EXE have a broken arrow? What do you see? Have you only been able to run the EXE on the PC that the software was developed on?

If you changed that VI, and restarted LabVIEW, and the behavior of the dialog didn't change, then I would say that that VI isn't part of the low level dialog that you see in that control. That dialog that you see could be buried in the LabVIEW.exe file and there might be no way to edit it.

I was just in the middle of saying this. Make a copy of the PickTime.vi and name is something different. Then have on your front panel the time and date control, but don't show the button for picking the date, instead have a boolean that calls your copy of the PickTime.vi

Yeah I'm guessing Tim is right. You'll need to either install all the needed driver, software, and run-time engines on the other machine, or create an installer that includes all those things. In the project under build specifications right click and create an installer. In the install go to the Additional Installers section and choose the software tools you used. Then when the installer is built these things will be in it. Expect your installer to grow into at least 1GB but it sounds like a big program so it will probably be bigger. Once these things are installed new installers don't need to include all of this extra stuff, but it must be there the first time or else you won't be able to run.

After a Read, Write, Get Property, Set Property, or List Contents I know that the reference is not changed. Meaning the TDMS reference going in, is the same as the one going out and there is no need to update the reference. I think that is what you mean by is the pointer maintained. An open operation does take a long time on large files, and is likely very hard drive intensive. Like most file I/O it is best to open it once, at the start of your application, perform all the read and writes with the reference, and then close once. I wouldn't recommend doing an open, then operation, then close, every time you have any data you want to read or write. I've never used the Asynchronous versions but I would assume they work the same way where the TDMS reference doesn't change between operations.

Who wants to resurrect a post . I have a white board in my cube and posting this example has been on my list for a while. Attached is an example of this progress bar loading splash screen I tried to describe a year ago. Nothing too special but I use something similar to this in my production applications. Build the Normal EXE and you'll end up with a 6MB file that when ran shows no UI for about 3-5 seconds. To make it worst add the 8th actor to the main VI along with the other 7. I removed it because it took way too long to build an EXE. The total VIs in memory with it added was around 4500. If you are missing any VIs feel free to delete them, or that entire actor, it is only meant to bloat up the number of VIs in memory and they are never even ran. Then build the With Progress version and you still get the 6MB file but the UI is shown within a second showing the progress of each actor being loaded into memory with an option to cancel. Then once each actor is loaded it loads the main and runs it. For this to work the Launcher is the top level VI and Main is set to always include. And there is a Pre-Build action that gets a list of the actors, and their relative path to the VI to load and writes it to the config file used in the EXE. This Pre-Build action is more elaborate in my production applications because not all actors sit in a folder called "Actors". Instead it opens the project and navigates based on library names, and connector panes but the idea is the same. EXE Loading Progress.zip