hooovahh

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.

I like your .NET method. In my test, for files less than 16MB the command line version is faster by a little, with both times around 100ms for the 16MB file, while the native is around 2380ms. But as files grow to around the size I want to be process the .NET method works faster. I ran a test with 500MB of files, with a file size all between 50MB and 80MB and the command line took 4900ms and the .NET took 2320ms. I know what you mean when you said it wouldn't open in a newer version of LabVIEW. It opens fine in 7.1, and 8.0 but any thing newer the Invoke node names are slightly different and need to be re-linked but after that it works. So I could determine the size of the file, and use the right method for that file size, but I'm just going to stick with your method since the improvement for small files is very small between them all. Thanks.

Thanks Tom, I got the all the needed VIs and ran again. OpenG still seems to be the slowest. I've played around with the chunk size and haven't been able to improve it much. I did one 2Mb file with a 10KB chunk and it took 2.8 seconds. The command line version took .01 seconds and the native took .2 seconds. For now I'm sticking with my command line version. BTW I reported the fact that we can't upload files.

I didn't expect my code would be put in the next rev. of LabVIEW for several reasons. That wasn't my intent. I just wanted to have a way of calculating the fastest MD5 possible for a directory of files. I ran it on 500MB of random files in the My Documents folder and it took 3 seconds using my version (with command line embedded) and it took 75 seconds using the native code. But I realize the limitations of using a command line. Unable to handle crashes, needs Windows, need access to a temp folder, unsure how it works with new versions of Windows, among other problems. I don't know how to optimize the MD5 algorithm, but what sort of things are off limits for potential additions to LabVIEW? Like if I found a .dll that calculated the checksum quickly could I write a VI which just uses that .dll? I assume there are legal reasons why NI could not include random code from the internet in a commerical product. @Ton I saw that code in SourceForge a little while ago but it's missing two VIs MD5 Unrecoverable U8 padding.vi MD5 FGHI functions.vi I'd be glad to do some testing to see how each stacks up.

So when I think of file integrity I think of checksums and MD5. I realize there are tons of different hash methods and CRCs available but I prefer MD5. So I was exited when I heard LabVIEW 8.2 got MD5 for files natively (I think it was in the vi lib in 8.0 but nothing on the palette) But since I've used the MD5 I've been disappointed it how long it takes to calculate an MD5. So I did some quick tests comparing the native MD5, to the OpenG MD5, against the command line version I've been using found at http://www.etree.org/md5com.html . For small files (less than 30kb) the native MD5 is relativly quick at around 50ms for one file. This is good if you are checking the integrity of a config file, but I'd rather use it as a general purpose file utility, checking the integrity of a directory of files. Any file above 30kb and the command line version process it faster. I performed an MD5 on four 5Mb text files, and using the native MD5 it took 2,786ms, while the command line took 125ms. The OpenG wasn't a good comparison since it processed the whole file at once taking, over 30 seconds. So I wrote an "improved" MD5 calculation VI. I think you'll be horrified when you look at the source, it just uses the command line version but it works, and alot faster than either OpenG or native. I also saved it in 7.1. EDIT: I seem to have a problem uploading (says I didn't select a file) so I hosted it on my site for now. http://brian-hoover.com/Code/LabVIEW/MyMD5File.zip