Jump to content

hooovahh

Moderators
  • Content Count

    3,015
  • Joined

  • Last visited

  • Days Won

    214

Everything posted by hooovahh

  1. 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 op
  2. 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
  3. (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.
  4. 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.
  5. 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?
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. 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 stu
  15. 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.
  16. Not that I know of, that's how I would have done it.
  17. 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.
  18. 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 o
  19. 1,454 downloads

    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 ar
  20. 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
  21. 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 th
  22. 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
  23. 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
  24. 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.
  25. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.