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

I never experienced anything even remotely comparable to this slowdown in LV 7.1.1 (of course it does not mean that it is not there).

PJM

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 think these problems are related to the LabVIEW <-> Windows interface and as one of the guys on info-labview pointed out it seems to be related to which window has the focus in the Windows operating system and the associated priority assigned by Windows. What NI should look into is why this did not happend in LV 7.1.1. on the same operating system.

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.

Advice on speed.

...

This pre-writting gets the OS to allocate all of the disk space ahead of time and reduces the I/O to just the data going to disk.

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:

Try not to be shocked by my ignorance ...

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

I don't think I've seen this mentioned yet. One improvement I like is that it's now possible to get help by right-clicking on a function within a pinned palette - no need to drop the function on the block diagram first.

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

I would like something like a round numeric guage with a needle that can display continuous rotation. Continuous is a word which here means, "without a sudden jump across the gap from max back to min." Preferably a control that allows me to plot 2 (or more) needles simultaneously.

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:

ok, ok.... (it's not a bear, but still...)

But this is...

It's a part of the control system of our Wind Tunnel that I am currently programing...

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

I don't know exactly what you want but what about something like this...

Very clever!

:thumbup:

Yeah never had quantum mechanics but I'm sure it's like NASCAR. when ever some thing weird happens and their interviewing the driver they ramble on and on about stuff then they usually say "well that's racing for you"

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...

"Why is the sky blue?"

Rayleigh scattering.

(Sorry, couldn't resist)

Gary, it's funny that we have so much in common. I've ordered my state flags in order of residency. I'm a PA native, but moved from PA > CA > VA. If yours are ordered similarly, it looks like you went from VA to CA.

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:

Spelling, grammar and punctuation mistakes are a pet peeve of mine, especially on the internet (my mom is a reading specialist, so she pounded it into me).

This has earned me the title of "Grammar Nazi" on one of the online BBs I administer. It was originally intended to be an insult to me, but I embraced it.

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.

I ran this on both LV 7.1 and 8.2 with similar behavior. I wonder if it's CPU-dependent somehow -- mine's an AMD Athlon XP...

Maybe EVERYBODY gets to be right! :thumbup:

-Kevin P.

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.

Just place an arrow on your front panel from the decorations pallete, then copy it from the front panel and paste into the diagram. You can then move, resize etc. This works with any of the decorations. For some reason NI has not added this directly to the palletes for the diagram, but don't let that stop you.

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.

This answer is not definative... I know that the above is one situation where explicit coercion helps. There may be others.

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

This data set consists of thousands to hundreds of thousands of input output pairs in which both the input and the output are vectors of floating point numbers.

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?

In our VI, LabVIEW is modifying the whole array, not performing an addition on a scalar. And, since both branches must be preserved, LabVIEW will produce an extra copy of the array.

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.

Regarding the selector instead of case structure, I would like to know whether the selector computes all inputs before evaluation or if it smartly evaluates the condition first. It may indeed be smart, but it is not obvious from a dataflow point-of-view. I therefore would err on the side of code clarity to use the case structure instead of the selector.

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

I can save as far back as 7.0 using "Save for previous..." under 7.1.1. I'm attaching all three versions of the 1.0.0 release to this message.

Thanks, I look forward to playing with it tomorrow.

Gary