hooovahh

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?

<charming music>

Say you have a generic DAQ system which needs inputs and outputs.

There's a script for that.

And say you want to make your programming life easier by adding tools which automate wiring up controls and indicators.

There's a script for that.

And say you just want to impress your friends, by writing the fastest 'hello world' program in existance.

There's even a script for that.

There's a script for just about any thing.

Only on LabVIEW

</charming music>

QUOTE (Jim Kring @ May 29 2009, 01:27 PM)

Now, what are we going to complain about?

Oh I'm sure there will be some feature that scripting is missing that we expected to be there. Or possibly there will be a lack of documentation, or lack of support, or numerous bugs. And if there is nothing to complain about, we'll complain about the lack of complaints, thereby making complaints, thus solving out dilemma.

I think you're confused, at least I think so based on this statement.

QUOTE

so please can anyone tell me how to make a exe with LabVIEW runtime in it so that my application size is less

Part of the reason that your installer is 62MB in size is because the LabVIEW runtime is in the installer, and the runtime is kinda big, I would say like 40MB.

I don't know what version of LabVIEW you have built your application in, but what you can do is host your small exe (850KB) on your website, and then tell people that to run it they will need to download and install the LabVIEW run time for that version of LabVIEW. You can just link to the file at NI's site. Here is the link to the 8.5 run time. ftp://ftp.ni.com/support/labview/windows/...VRunTimeEng.exe

Or as rolfk said you could try to save the VIs in 7.1, then include the files needed to make a runtimeless executable work. But the download for your website would still be around 11MB for a exe. I think that posting these those files here may be illegal so here is a text file which lists the files I've been using for a 7.1 runtime less setup.

I think the easiest way to find out how much time it takes for a set of operations, is to use a VI global. You write a small VI which just works like a stop watch, with start stop and reset. This VI could have an error clusters in it to preserve data flow. You then put this in before your calculation and tell it to start, it gets the tick count and puts it in a uninitialized shift register. Then you do your calculations, and at the end put down the same VI global with a stop action which gets the tick count and subtracts it from the shift register which contains the original time stamp.

A quick and dirty way is to use a flat sequence structure, have the first case get the tick count, then the second is the actual work, then the 3rd case is to get the tick count and subtract it from the first.

Yeah you can problematically change the mnu files natively in 8.6, I think it's in the app control palette. But every version of LabVIEW (that I've used anyway) allows you to customize the palette by going to Tools >> Advanced >> Edit Palette set. Then the new palette you make will be saved in the LabVIEW Apps folder.

I haven't dabbled in scripting much, but could you code a VI using scripting? I realize that there are many steps to creating objects on the block diagram, but could I write a VI which makes a VI and runs it?

It would be confusing to people who have never heard of scripting, they would just see a whole lot of property/invoke nodes and when they run it a whole UI with code would appear.

Go to the link click on the Resources tab, click Evaluation Software, click LabVIEW Evaluation, click Download LabVIEW (you will then be prompted to log into NI's site)

I didn't download it my self but it appears to redirect to the LabVIEW 8.6.1 install, I'm not sure if the DSC module is included in the download or not.

I think what you are looking for is a running average. I think I found this piece of code on NIs website some time ago and I have found it handy when needing to do a simple quick filter. In the zip is the running average VI, and an example which just shows how to use it. Run the example then move the slider up and down and you'll see the running average on the slider next to it, and in a graph. By default is does a running average of the last 10 values but this can be changed.

BTW it is saved in 8.0