Gary Rubin

Jason, Thanks for your feedback. I believe we've delivered our only copy of LV8.20 along with a customer system. I therefore can't open my own attachment to review your points. Would you (or someone else) mind posting a screenshot of the BD so I can look at it again? Thanks, Gary

Sorry, I did not intend to imply that your current problem and what I described in 7.1.1 are comparable. I was commenting on molsen's post and adding that I think I've seen some unexpected behavior associated with Labview and Windows going back before LV8.x. Gary

I'm not convinced that such behavior did not exist in LV7.1.1, although I do agree that it probably has something to do with the way Labview and Windows play together. I have a data processing tool that I have written (see screenshot). It essentially preallocates an array (on the order of 200 x 3000 elements) for the big intensity plot, then reads a chunk out of a file and does a bunch of number-crunching to obtain the next column of the intensity plot. There are also some property nodes related to cursors and making controls visible/invisible. When I was running this on LV711 on Win2K, I found that if I clicked and held, but did not release, the Windows Minimize button, this program would run much faster. My system has since been upgraded(?) to WinXP (still running LV711), and I am unable to duplicate that behavior. Edit: Adding screenshot.

Interesting! It makes sense, but it never occured to me that you should preallocate disk space for the same reason as you would preallocate memory. :worship:

Same goes for me. Am being naive in thinking that the fastest you can achieve is just writing raw binary to disk using the OS's file write functions? Of course, you would have to optimize this so you're writing optimally-sized chunks of data at a time. My thinking has always been that this involves the least amount of code/manipulation between the data source and the disk, and would therefore be the most efficient. Is this not true? Gary

If I remember correctly, you used to (pre-LV7?) be able to hit CTRL-H while the pallete was open (and not pinned) to accomplish this. In LV7.x, CTRL-H no longer responds while the pallete is open and not pinned. Maybe NI changed window focus for palletes vs. block diagram in LV7.x? Gary

Use a standard circular guage. With the arrow tool selected, move the cursor onto the max tick mark. It should change icons to a little rotate-looking thing. Click and drag across the gap. That will remove the gap. As for the second needle, just right click and choose Add needle. The needle colors can be modified with a RightClick > Properties. Download File:post-4344-1165602964.vi

If you want a fairly quick read that really makes you think about such things, try Einstein's Dreams. :thumbup:

But this is...

Very cool! What happened to the F-14's wings?

Very clever! :thumbup:

In my 4 physics classes in which I was exposed to quantum mechanics, I don't think I ever heard it compared to NASCAR... Now, if the cars could tunnel through the retaining walls, that would be another story... Rayleigh scattering. (Sorry, couldn't resist)

I did mine the other way around. VA is most recent, so I put it first. Born in PA (didn't bother putting that on there), moved to CA very young, and came to VA after college.

Bryan, You wrote this in another one of your posts: I think that's another big selling point, although it's not directly related to your Labview LabView LabVIEW skills. In my opinion, the ability to express oneself clearly and concisely is greatly underappreciated. I work in a group of ~40 people, including engineers, technicians, and scientists. We do not have a dedicated marketing or business development department, meaning that most of us scientists/engineers have the opportunity to work on proposals, reports, and/or marketing literature. I often find myself editing other people's inputs for these types of documents. One of my pet peeves, as someone from a liberal arts background, is engineers who seem incapable of writing a readable paragraph. BTW, you and I seem to have a lot in common - same flags on our signatures, both have 1-year-olds, and my wife is currently studying to become a reading specialist...

Coding challenge idea: What about simple game AI written in Labview? The game wouldn't need to be complicated, maybe something like Reversi, Connect 4, Checkers... The entries could be rated on not just the coding, but also on the UI and the quality of the game's decision-making. Depending on how they are written, it might also be possible to have two different entries play against each other, to find out which is the "smarter" implementation.

Good point. The numbers I put in the spreadsheet were derived from my IBM Celeron laptop. My P4 desktop seems to execute the implicit faster.

No wonder you didn't find it. That's a really strange place for NI to put it.

Huh? Don't you guys have a Decorations sub-pallete in your BD Functions pallete? I have one in 7.1. It has lines, arrows, a text box, and a frame.

Hmm.... I decided to check this out a bit more, using variations of the attached vi. First of all, for this particular operation, I found that the explicit coercion was faster. In my test, I always coerced a scalar. Maybe tomorrow, I'll try coercing an array. I noticed that the speed difference between the explicit and automatic has a lot to do with the type of coercion being done. It appears that what you're coercing to has more of an impact than what you're coercing from. Depending on the original and final data types, I saw that the explicit coercion was between 5 and 35% faster than the automatic coercion (i.e. coersion dot). See attached data excel doc. Download File:post-4344-1161823302.zip

I see... You must have a lot of memory on that computer...

Now I'm curious. In my 10 years or so of technical computing, I'm having trouble thinking of many times where I've come across a need for randomizing an array. A Labview implementation of Boggle that I did on a long flight, and a card shuffling exercise in college come to mind, and obviously those don't need to be really fast. So, just out of curiosity, what type of real applications require such fast and efficient randomization?

Yeah, you're right. Now I really wish I could find whatever it was I had read to try to figure out what it was recommending.

I wish I could find that App Note... My understanding was that Labview will evaluate both paths. It just happens that for simple things like incrementing vs. not incrementing, performing an unecessary addition is faster than the overhead associated with using a case structure to not performing the operation.

Syrus, There are a couple ways that it seems that you can squeeze out a few more microseconds. I ran some benchmarks for size=1000, and on my 2.4GHz P4, I was able to trim the execution time from ~0.76ms to ~0.70ms. First, get rid of the coercion dots by converting those two coerced wires to dbl. Second, I read somewhere (probably one of the Labview App notes, which I can no longer find), that case structures have a fair amount of overhead associated with them, so for simple things like your Matlab switch, it's better to use a Selector node. Gary

Thanks, I look forward to playing with it tomorrow. Gary