hooovahh

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

I'm not familiar with what kind of meta data that is stored in a wave, but if it is ID3 there is some code which reads v1 of that from MP3 files.

http://forums.lavag.org/CR-MP3-ID3v1-Tag-I-O-t7094.html

There are some command line program which reads ID3, here's one I've never used but claims to do read/write. You could always use LabVIEW to read a command line.

EDIT: Apparently ID3 is a MP3 standard only.

QUOTE (crelf @ Jun 8 2009, 06:21 PM)

I agree - it is a great game. I'm sure it was a lot of fun to put together too

If you play through with commentary on they mention how when developing the code for the portal gun, they wanted to make it as robust as possible, trying to not take any short cuts. They did this because they assume that people would hack their code and try to do other things with the portal gun code.

BTW they did, here's a few clips there's tons on Youtube

http://www.youtube.com/watch?v=gKg3TUPQ8Sg

If we're talking social experiments, checkout http://improveverywhere.com/ Their more of a harmless prank site, but I think it says more about how the people interacting react.

Here's a few

Best Buy

The Moebius

Frozen Grand Central

High Five Escalator

I recently went to jury duty, and while I was there it crossed my mind that that environment would make for a great social experiment. A group of individuals, presumably none of whom have met one another before that day, are placed in a small room, with nothing to do but wait. We were given magazines, coffee, and tv, but I thought that a good experiment would be to give nothing for them to do just wait, and see how they interact with one another, and to see what they do to pass the time.

We waited around till 1 and they sent me home, easiest $12.90 I've ever made.

QUOTE (crelf @ Jun 8 2009, 09:53 AM)

It sounds like (during the age of enlightenment, some people were looking to have their cake and eat it too (mmmm cake... where was I?)

Well I was a Portalist, but then I relized that the cake is a lie. The other bad thing about being a Portalist is that instead of drinking poisoned cool-aid you get lowered into a fire by a computer. But there's just something fun about putting your faith in a cool gun, by jumping off a cliff knowing the Portal will always be there to safely guide you to the other side.

I wanted to make this post for two reasons. First I've never posted a new topic in the LAVA Lounge. And secondly I wanted to warn any new comers to LAVA that you may see some odd posts from a member (who is not a bot) by the name of Alfa.

When I first came to LAVA I was very frustrated by the posts that Alfa made, always off the wall, odd and usually not on topic. To add to my frustration he rarly addresses any questions that other members ask him in a reply to his post. And if he does it may change topics drastically.

If you've been a member of LAVA for a while you know to take Alfa posts with a grain of salt, but I wondered how people reacted to Alfa when he first arrived at LAVA.

Alfa came to LAVA with LabVIEW related topics, as you can see in this topic Calling a DLL Alfa asks a question regarding calling a DLL. This is in March of 2005. Some time between March and December Alfa moved away from talking about LabVIEW and started talking about his book in this post The Book Ever since then his posts seem to be related to the topics of religion, math, and inteligence. These are the topics surrounding his two books.

A few examples of odd Alfa posts can be found in the following threads

http://forums.lavag.org/The-Aether-t6206.html

So new comers beware. As stated earlier, take Alfa posts with a grain of salt. If you have a comment to make related to an Alfa post feel free to reply. Just try not to get angry or frustrated by his posts.

QUOTE (rolfk @ Jun 8 2009, 04:42 AM)

Your list is certainly extensive and not really required by many applications. For LabVIEW 7.1 what I have found absolutely necessary in order to get a simple executable running are following files:

lvapp.rsc

vidialogs.rsc

lvrt.dll

That's good information to have. I remember reading an article some where (I was sent a pdf of it) which explained how to create a runtime-less setup for 7.1. It said what files and directories to copy so I did, then I archived those file some where so I wouldn't need to get those files together again. I'd love to do some testing and see exactly what files my executables actually need.

I don't know for sure but I would be surprised if we were allowed to.

Public consumption? Is that like eating the public? Are you sure that cannibalism is the right kind of image we want for VIE?

I completely agree, but some times I would like to be able to get a complete picture of the VI that maybe I didn't make, and I don't know where some controls may be hidden far to the right or left. Sure the scroll bar gives an indication that some thing is over there.

QUOTE (Ic3Knight @ Jun 4 2009, 08:30 AM)

Now, for some reason, every single file within my project has been set to "read only"... None of the files have any subversion properties set, I tried "getting a lock" on the file, but that didn't help either... I can manually (through explorer) set a file to read/write to save changes, but when I commit that file back into the repo and then update my working copy, it reverts to read only!

The files are read only because you don't have the lock on the file. If you get the lock (which it sounds like didn't work) then the files become not read only, allowing you to edit the files. Then you perform a commit which can unlock the file (if the check box for keep locks is off) this will commit changes and allow anyone else on the team to get the lock and edit the file.

If someone has the lock (and their local copy is not read only) then you won't be able to get the lock, and your local copy will be read only preventing you from making changes, until the other member on your team is done editing their copy. You will then be forced to update before getting the lock. Then you can continue to edit the file, picking up from where your other member left off.

Only under rare circumstances should you ever change the file from read only manually with explorer. If you do this and edit the file, then you won't have the lock but will have a different version of the file than what is on the server, which is why performing an update reverted back to the original. You can only perform a commit if you have the lock on some thing.

QUOTE (Gary Rubin @ Jun 3 2009, 09:17 AM)

I wondered whether I was the only one who thought it odd that they entered the reception to "Bittersweet Symphony"

I loved that video, I know it was staged, but when it first came out I thought for a moment that it was real.

QUOTE (ShaunR @ Jun 2 2009, 05:08 PM)

Thats why pictures are better :beer: + :camera: =

I think that expression is up for interpretation on the compiler.

Does it mean that if I take a picture of you with beer you will shake your finger at me? Or does it mean I should not take a picture while I am under the influence of beer? Does it imply that pouring beer into a digital camera will cause it to turn into a yellow face shaking his finger? or is that a near by person shaking their finger because I broke their camera by pouring beer into it?