Gary Rubin

QUOTE(Louis Manfredi @ Jan 17 2007, 11:23 AM) Sorry for the late reply. My LV2-style globals do not typically generate an output for their "init" cases or (sometimes) their "put data" cases. Does this mean that they would not be executed under LabVIEW 8.x because those particular subVI instances have no outputs wired? QUOTE(Louis Manfredi @ Jan 17 2007, 11:23 AM) But I can't reccomend they buy 8.2 if I don't use it myself, and I'm not sure there's any reasonable way to get them a copy of 7.1 Are you still trying to do this? We were told by NI that it was ok to purchase a copy of LV8.20, but then install LV7.1 from our existing CDs. I think that we may have used the LV8.20 serial number for installing LV7.1, but as I wasn't the one who did the install, I 'm not certain of that. Gary

QUOTE(rkesmodel @ Mar 17 2007, 01:11 PM) Roy, would you mind saving as 7.1? I'd be interested to compare to our boxcar implementations (we've done a couple). Thanks, Gary

QUOTE(Mike Ashe @ Mar 16 2007, 02:36 PM) There are plenty of applications where driver availability precludes the use of LabVIEW realtime, yet you still need high-speed, pseudo-realtime performance. You may have noticed from many of my past posts, I'm very interested in optimizing Labview for those last few clock cycles. I work in the radar world, where data acquisition is in the high MHz, and processing loops have to be kept in the low ms. If it takes me 2 weeks to squeeze those last few milliseconds from a processing vi, it's well worth the effort if those few milliseconds mean the difference between being able to keep the whole thing on a PC in Labview vs. having to go to an embedded or C-based approach.

QUOTE(AnalogKid2DigitalMan @ Mar 15 2007, 02:28 PM) Thanks. Quite the headscratcher... Your signature seems quite fitting at the moment. Gary

QUOTE(John Rouse @ Mar 15 2007, 01:11 PM) I used to use a Kensington trackball, which got rid of my wrist pain. The one that I had was probably the predecessor to http://us.kensington.com/html/2200.html' target="_blank">this one.

Thanks to those who ran this for me. I guess I haven't yet confirmed whether LV8.x FFT is faster than the LV7.1.1 version, but I did notice something interesting. I've attached a new vi that runs the one I posted above and plots runtime as function of FFT length. On my system, runtime starts to increase more-or-less linearly after 128kpoints. I'm guessing, therefore, that below 128kpoints most of the time is spent doing the FFT, and I can see the logN part of the execution time. Above 128kpoints FFT, Labview is spending more time doing memory allocation than actually performing the calculations, so I'm mostly seeing a linear increase in time it takes to do the buffer allocation. All you guys with the faster times than me probably have faster memory, or at least a faster memory bus. Does that sound reasonable? Gary

QUOTE(French LVer @ Mar 15 2007, 11:11 AM) Thank you very much! I have to say that you have managed to raise more questions than answers... My results are: LV7.1.1 2.4GHz P4 , 2GB RAM, lots of other crap open: 249 ms. EDIT: WinXP Pro SP2. LV7.1.1 2.4GHz Dual Xeon, 1GB RAM: 274 ms. EDIT: Win2k SP3. Questions: Why is yours twice as fast as mine? Why is your LV7.1 faster than LV8.2? Why is my P4 with lots of stuff in the background faster than my Xeon? Anyone have any thoughts?

If I remember correctly, there was supposed to be a speed enhancement in some of the math functions between LV7.1.1 and LV8.x. I don't currently have access to LV8.x. Could someone please run the attached VI in both 7.1 and 8.x and let me know the speed results? Thanks, Gary

Spreadsheet String to Array. I don't have 8.x installed, but I can't imagine NI got rid of that one between 7.1 and 8.0.

Everytime I see these topic titles, it makes me chuckle. "French Language Updated"... "German Language Updated"... It must be nice to have the Power of the Administrator... -Don't like all those exceptions to the rules in English? Update the language! -Find French pronunciation too difficult? Update the language! -Nouns in German too long? Update the language!

QUOTE(crelf @ Feb 21 2007, 01:16 PM) I never did. It's My Parties.

QUOTE(crelf @ Feb 21 2007, 12:49 PM) My two incorrect guesses and the right answer were all from the same album... I guess I need to listen to On Every Street more often.

QUOTE(crelf @ Feb 21 2007, 12:35 PM) Gold. I can't remember the song though. I want to say Calling Elvis, but I'm not sure. Edit. Heavy Fuel! Damn, you got me.... I had to look it up... :worship:

QUOTE(crelf @ Feb 21 2007, 10:52 AM) You're going to have to try harder than that! I've got 6 Dire Straits and 4 Mark Knopfler albums on my iPod...

QUOTE(crelf @ Feb 21 2007, 08:37 AM) Strong? Is this a quiz?

QUOTE I've got Mark Knopfler playing on my iPod as I type :thumbup:

QUOTE(tomstickland @ Feb 14 2007, 07:12 PM) <soapbox> I would guess that most Labview programmers view Labview, and the applications they generate with it, as tools or as means to an end. I would suspect that a "software engineer" is less likely to take that approach, and instead see the software itself as the ultimate goal. Lest I get flamed by software engineers, I'd like to clarify that I don't think that ALL Software Engineers (capital-S, capital-E) would necessarily see the software itself as more important than the problem it's solving, just that someone with lots of formal software engineering training and education may be more likely to focus on the software, while as a group, we ad-hoc Labview programmers are more likely focus on the problem. After all, isn't that why we all became physicists, MEs, EEs, etc., rather than software engineers? </soapbox>

I believe you are not just timing the FFT, but also the build array that is implicit with indexing the output of the for loop. If you want to just find out how fast the FFT is, turn off auto-indexing on the output. I expect you'll see a little bit of difference. I'm assuming you do need the 2-D output in your application. In that case, try preallocating an array and use a shift register and replace subset instead of the autoindexed output. Gary

Thanks for the information, and the link. I wonder if I should be considering Matlab script nodes as well. Well, at least I have multiple options to choose from... Thanks, Gary

Hi all, I was just reading the NI pages about Mathscript, but still have some questions. I am looking at a project in which I'll want to take advantage of some of Matlab's volumetric plotting capabilities. I was planning on doing this all in Matlab, but have begun to consider whether LV8.20's Mathscript would allow me to do what I want solely in Labview. Now for the questions: How does LV's native multithreading work with Mathscript? I'm thinking that this will be running on a multi-core processor; if I have two Mathscript nodes running in parallel, will the load be split between the two cores, as I would expect for "standard" Labview functions? This would be one of my main reasons for doing the Labview-based solution, as Matlab does not easily support multithreading. Also, in searching LAVA for info on Mathscript, I found this from bsvingen: Just how bad is the performance? Am I going to lose any benefit of multithreading due to the inefficiencies that bsvingen alluded to? My particularly application will not be very calculation intensive, but will be pretty memory intensive. Thanks, Gary

I don't see the front panel thing in there. Just this: (1.) You include the following copyright notice "Copyright

The last digest I got was timestamped 2AM on Jan 3.

Thanks. I am grateful for the explanations of Labview's inner workings from you and the other NI experts who hang out here. Gary

By "efficient", I am refering to writing the code in a way to minimize the CPU cycles needed to execute. It sounds to me that overlaying a transparent graph on a picture control provides the same UI look-and-feel as using the bgimage, and does so with less CPU time devoted to the UI thread. Is that correct? You certainly have a point there - it took a good half-day to get everything lined up, and if I want to change the size I've got to do it very carefully. I guess that's consistent with the whole Express VI philosophy (and any high-level language, for that matter); you're sacrificing some speed and efficiency in exchange for ease of programming. Are you saying that a transparent control on top of an indicator is a bad thing, but a transparent indicator on top of a control isn't so bad? Hmm, that's interesting. Thanks, Gary

Don't have access to 8.0 right now either. disclaimer: I'm going on memory that implementation #1 is the overlaid controls and implementation #2 is the new LV8 background image. If this is not the case, please ignore the following comment So, does that mean that despite the warnings about overlaying transparent controls on top of other controls, that's still more efficient than using the new background image feature?