hooovahh

Well you don't have to be technically. A while ago (just to see if I could) I made a single EXE that was LabVIEW 7.1, and 8.5. 7.1 because it is my favorite and does just about every thing you could want for most applications, and 8.5 because that was the newest version at the time. So imagine carrying around a 600MB EXE (for 8.5 or 300MB for 7.1) on your drive that you run and you have a full LabVIEW development environment available on any Windows computer. I was going to post how I made it, so others could too but it's been a while and I'm not sure I remember the steps needed, but I do still have the EXEs floating around maybe if I get time I'll try to make it again. The main issue with this is most people don't have just LabVIEW installed, they have several toolkits for projects they are working on. Adding toolkits to this EXE after it is built isn't impossible it just would take alot of work. And installing new packages via VIPM wouldn't be impossible it would just be manual. There could be a directory structure next to the EXE, which the EXE then uses as relative files. So lets say LabVIEW85.EXE and in the same folder is $user.lib$ and what you put in there will be used as extra files in the user.lib. So basically this EXE would only be useful for making quick VIs, or opening small ones and seeing what's going on, but if the VI needs any toolkits it will be broken.

THOSE AREN'T PILLOWS!!! (sorry for the caps but he was actually yelling)

Get use to constantly needing to clean up the hard drive. My drive is only 64GB, my National Instruments folder alone is over 10GB. Then there's Windows, other Program Files, several SVN repositories, and several gigs of music. I tend carry around a a 2.5'' external drive that I keep larger files on (like virtual machines)

I did a very un-scientific test and timed how long it took to startup LabVIEW in the different versions. I did not reboot after every start of a version, so I don't know that if opening 8.0 then closing it, would have any effect on how long it may take for 8.2 to startup. But I did restart several times and here's what I got. With my installed versions of 6.0, 6.1, 7.1, 8.0, 8.2, 8.5, 8.6, and 2009, the longest taking 18 seconds was version 8.5. On average it took 10 seconds to start a version of LabVIEW on the first start of that version. The shortest time was 6.1 with 2 seconds If I opened 8.0, closed it, waited then opened 8.0 again the times were significantly less with the longest being 5 seconds with 8.6, the shortest 6.1 with 1 second, and the average being 3 seconds. It should be noted that 8.6 had DSC and FPGA toolkits installed, all other versions don't have any. Also no options on the startup procedure was changed on any of these versions. And my PC is a laptop with 2 GB of ram, a Core2Duo at 2.2 GHz and a SSD. I assume the SSD is what makes the startup time relativly quick. For the heck of it I also decided to run all versions of LabVIEW at once, and it took 12 seconds to load all of them, after starting them once already I'll reboot and try a fresh start of all of them at once later today.

Yeah that windows character size limitation is a bugger. We hit it several times when dealing with SVN. If you do a checkout in your my documents then it starts out a C:\documents and settings\[user name which may be long]\[user name which may be long]'s documents\ That eats a large chunk of the possible 255 characters. Then if you have a long path in the SVN it will become a problem. It can also become a problem with VIPM if you are building a project with a long package name, and have long file names in the VI. Once all the VIs are saved they are put into a LLB so as long as the package is built there shouldn't be a problem with the package being installed on another machine. I am very glad to see that LabVIEW now has a more useful error message. Previously LabVIEW would return a General I/O error. To avoid this problem I would say use the advanced build option of Use 8.x layout. It will build the EXE in a flat structure like in previous versions of LabVIEW.

(raises hand) Pick me! I know this one. As luck would have it I already made a clock program when I was first learning about how to use LabVIEW and its draw features. Here's a clock that works with the OS time, or user specified time. http://brian-hoover....k%20Program.zip I do have a disclaimer. I made this code several years ago and while it works, there are several coding advancements that I did not know about and did not use. First I would have created a state machine, and an event structure instead of polling every 200ms. In any case hope this works for you, here's a screen shot. EDIT: I'm sorry I didn't read the post closely enough, what I provided is not what you are looking for, but it still may be useful.

I may be wrong about this, but I don't believe that there are 32-bit VIs and 64-bit VIs. The only thing that changes is the LabVIEW compile is optimized to use 64 bit. Someone correct me if I'm wrong I've never used 64-bit 2009 with 64-bit Vista.

Nope I'm not an architect, maybe I should've had a V8. Does anyone else thing it's odd the first result in google was yahoo answers for this?

New? I'm sure you know this isn't exactly a new feature. Before the project explorer you could go to Tools >> Build Executable. Then in 8.0, and 8.2 you could still go to Tools >> Build Executable but it would make a quick project and build the EXE for you. 8.5 and 8.6 require you to make your own project to build an EXE for it. I don't believe that any software should remove features between versions unless there is some really go reason to do so. Removing the ability to quickly build an EXE was a poor choice and I'm glad they brought it back.

I'm pretty sure crelf was being facetious. There is a rumor that on more than one occasion our IT guy has throttled crelfs network because of torrents. I'm sure he was just downloading some large linux distro, and not any copyright protected video content.

Do you mean if any VI in the project doesn't have a front panel or the top level VI? Either one I would consider a bug, but one more severe than the other.

As weird as it sounds I really liked that video. One of my co-workers was watching it and showed everyone that was around because it looked so cool. My only worry would be that people would be more interested in the zooming and effects than the actual content of the video. If you don't mind me asking what did you use to edit that video?

Yeah that works but it has the same flaw that mine had where things don't work right if the 2nd array has more rows than the 1st, but it is an improvement over my code.

Yeah I remember running sequences in TestStand in my sleep. The dream didn't end well, the code still didn't work. That was one of those 85 hour work weeks (in 6 days) I had alot of odd dreams.

There's always many different ways to skin a cat. So here's one option I did which doesn't use any transpose array functions (since I was under the impression that it was bad on memory usage) I just realized that this doesn't work in all use cases. If Array 2 has more rows than Array 1 then the output will not be exactly what you want, I guess the code could be modified to work properly. It's not often I need to concatenate horizontally but I wouldn't mind having it be a feature.

Thanks you Crelf for helping me offline. I've attached the newer rev. of my WinWaitActive code. It is now considerably small too (not needing an autoit3 exe). It has the same functionality as described in my first post. WinWaitActive.zip

Hello all, so I've created a VI which waits for a window to become active before going on. This is useful for when you are trying to automate something. Have LabVIEW run a exe then wait for its window to become active, then continue with keyboard presses and mouse clicks. I would submit my code to the Code Repository, except for a few things. First it's not clean enough. But more importantly it uses an AutoIt executable. I've embedded the EXE into the VI so to the user the code is seamless, but I was wondering if I could get rid of the EXE by using standard windows DLL calls. The stumbling block is I don't know how to get the title of the active window. I know that using GetActiveWindow from the user32.dll I can get the HWND for the active window, but I don't know how to get the title of that window. GetWindowText only returns the size of the string of the title. Attached is what I have so far, along with the AutoIt code. Any suggestions?

Very impressive, not sure if you've thought of this before, but with this you could possibly be able to create our own open source VI file format. Pass in a VI into a program and get the SWF equivalent. Then take the SWF put it in another program and get the VI back. Of course there's alot of issues associated with that, like subVIs. But for basic stuff I think it could utilize the quick drop function to find code.

Not that I know of, that's how I would have done it.

When I took microcontrollers 1 and 2, I remember the professor telling us over and over again never to modify your own code while the program was running. By this I mean you have a set of instructions that start at 0x1000, and as the program ran you shouldn't use any thing from 0x1000 to the end of your program, as temporary memory space. I always thought he told us not to do that because you would be changing how the program would operate after the first run, but now I realize he didn't want us creating code, that could become self aware.

I like this idea. I think we could do some testing with a small subset of rules. Say you must start with 2 booleans, and a numeric indicator. Then have it randomly write code, dropping primitives and wiring them up, until the state of the 2 booleans gives you the numeric results you want. To make it easy you could say OFF OFF = 0, OFF ON = 1, ON OFF = 2, ON ON =3. Now having intelect we know the easiest (or at least an easy) way to write a VI that does this, but for it to do it randomly would be interesting. How long would it take? How big would it be? Then you could try the survival of the fittest idea, where the smallest fastest VI that performs the task properly, is the one that gets modifed to do a similar task. Maybe add a 3rd boolean. But even this simple task may take a very long time for a successful VI to be created. I imagine alot of system resources too. It would be nice maybe to have an indicator saying how many VIs were able to get OFF OFF = 0...now that I think about it maybe one boolean is a better start.

File Name: Windows Environment Variable Reader Writer File Submitter: LAVA 1.0 Content File Submitted: 02 Jul 2009 File Category: General LabVIEW Version: 8.2 File Version: 1.0.0 License Type: GNU Public Potentially make this file available on the VI Package Network?: Undecided Windows Environment Variable Reader Writer Vc Copyright © 2006, Brian Hoover All rights reserved. Author: Brian Hoover **see email address in readme txt** Description:: Purpose: This Vi was made so that you can easily view and create environment variables from within Windows XP. Features: You are able to read all environment variables which you have available to you at the command prompt by typing "set". It also can write environment variables by writing them to the registry in the following location: HKEY_CURRENT_USER\Environment Also for added safty it will check the name you are trying to use, and won't allow its creation if a variable with that name already exists. Usage: To use this VI you need to be using Labview version 8.20. With Labview 8.20 installed open the VariableReadWrite.vi file, then click run. While it's running open the View Variables tab and click "Refresh Variables" to view all your command prompt variables. Two String arrays are created, the Name of the variables, and their values. A text window is also displaying what the user would see if they typed "set" at a command prompt. To create a variable open the Create Variables tab and fill in the information for Variable Name and Variable Value; then click Create Variable. Please note that you may need to log off then back on for the new variable to take effect. If needed there is a "Run Regedit" button which will open the registry. From here you can see the newly created variables in the location mentioned in the Features section. When you are done click stop to end the program. Version History: 1.0.0: Initial release of the code. Click here to download this file

I have never heard of Dataact's program for choosing LabVIEW versions. I found the link here if anyone is interested. http://dataact.com/downloads.htm However the application has the same problem I asked about. If you have the LabVIEW choosing program installed, and double click a file, it will ask what version of LV to run (this works fine) if you the double click any other LabVIEW file it will open it in the same version of LabVIEW that is already open. Basically their program only works if you have no versions of LabVIEW open which for me at least, is rare. Data Act explains why in their FAQ the software behaves like this. (FAQ number 2) http://dataact.com/LVC_Help/Using_FAQs.htm Something dealing with DDE between versions of LabVIEW. So it looks like there's nothing that can be done about this.

Ok lets say I have LabVIEW 7.1, and LabVIEW 8.0 installed in a Windows machine. If I run LabVIEW 7.1, then run LabVIEW 8.0, then minimize both, then go to the start menu and run LabVIEW 7.1 again, the LabVIEW 8.0 window will be brought up. To me this is a bug. A larger bug (which is related to this one) is if I run the command line "C:\Program Files\National Instruments\LabVIEW 7.1\LabVIEW.exe" "C:\test.vi" it will open the test.vi in the 8.0 version of LabVIEW. I think NI's mentality is that LabVIEW should remember the last version that was ran, for convience when opening new code. But I know what version of LabVIEW I want to run, based on predefined shortcuts and installation paths. So does anyone know of a way, to prevent LabVIEW from remembering what version was last ran? I've tried adding the "RegisterExtensions=False" key in the LabVIEW.ini files (it was suggested at NI's forum this may fix it) I've also probed the Windows registry and any any reference to "LabVIEW 8.0\LabVIEW.exe" I replace (one at a time) with "LabVIEW 7.1\LabVIEW.exe" and it did not help. Thanks.