Cat

But LabVIEW is missing! Which might, actually, be a good thing...

Woo-hoo! Congrats!

You haven't even paid up yet for all the work that's already been done for you. $39.95 for a Premium Membership...

Other than LV9, I've tried all of the above, especially waving the dead chicken. FWIW, NI folks generally seem to poo-poo "Anxious Deallocation" as I've seen it be called. I still throw it in occasionally where it might theoretically have some effect, but I personally haven't seen it help too much myself. I actually display up to 4 channels of "real time" waveform data (or spectra or lofar). We use it for what we call "tap-out"; determining if a particular sensor is hooked up where it's supposed to be. Also to watch for transients. But as you suggest, in that case I can break it up into much smaller chunks and memory is not an issue.

Unfortunately, this is a post-run application where the users want to see the entire data set(s) at one time. That is true, in a perfect world. In reality, LV often grabs much more memory than it actually needs. While I understand this is a good thing for performance, it is a bad thing for large data sets. I jump thru lots of hoops to *really* empty and remove queues in order to attempt to get back all the memory I possibly can.

Multi-minute runs at 64k sample rate * multi-channels to track transient noise as it travels around a test vessel. The main problem is not the amount of memory my data takes, it's all the copies of my data that LabVIEW makes, and holds on to. If a data set is 750MB, that shouldn't be a problem, but LV will make multiple copies of it and blow up the memory. I currently decimate like crazy on the longer runs -- which of course slows eveything down and is a matter of taking an WAG educated guess at how much contiguous memory is available and keeping my fingers crossed.

I'm more concerned about the input. More specifically (maybe you've already answered this, but the caffeine just hasn't kicked in for me yet), if I build my 32-bit code using 64-bit LV, will 64-bit LV make my code 64-bit first? I.e., do I have to protect that code to keep it 32-bit during a 64-bit build? Yeah, I admit it was a pretty open-ended question. I'm looking to run on a 64-bit box in order to be able to access more than the measly 2GB memory (or call it 1GB contiguous on a good day) LV can use on a 32-bit box.

I believe I can have both LV2009 32-bit and LV2009 64-bit installed on the same 64-bit machine. I believe using LV2009 32-bit I can create a 32-bit application on a 64-bit machine I'm assuming I should NOT open and run my 32-bit code under 64-bit LV because that would recompile it into 64-bit. I'm trying to wrap my head around the best way to write in 32-bit but be able to build both 32 and 64 bit applications out of the same code. Or would it just be easier to have a dedicated 64 bit machine, copy my 32-bit development code to it and build it there?? Last but not least, this very interesting article on the topic on the NI site says there is a performance hit running a 32-bit app on a 64-bit system. Anyone have any Real World LabVIEW experience with this and know what that hit might more-or-less be? (BTW, try searching on "64-bit" on this site. Well, actually, don't. I got real frustrated and then went to Google.)

There was a momentary scare when HR noticed there was some food being served at NIWeek and therefore it must not fall under a training request, because one obviously can't eat and learn in the same 24 hour period, and therefore the approval was unapproved. I had to write a justification letter (liberally plagarized from the one on the NIWeek website), get 3 more levels of approval, and then the unapproved approval was finally reapproved. I just love working for Big Brother...

That was the hope... All drives (whether NTFS or UFS) are the WD Caviar Black SATA 3Gb/s. I've transferred data from drive to drive on this system at upwards of 80MB/s. The answer I got back from tech support at UFS Explorer was something along the lines that 25MB/s was as fast as USB drive could go. I reminded them this was a strictly SATA system, and not limited by USB, so any other ideas? I never heard back... This is still 2-step, right? Translate data from UFS drive to NTFS drive and then process data? And this assumes a Linux utility that reads Solaris 8 and 10 UFS disks on the Linux box. But I guess it would save hopefully save me some time in the UFS to NTFS transfer stage. What I really need is LV for Linux, and then some way to run the data extraction at the some time. Maybe... Ok, but back to the Real World. I am unfortunately working with quite a few restraints. I'm not the person who will be transferring the scads of data (thank goodness -- there was 86 TB of data from the last test). It has to run off of someone else's PC. Or actually several other PCs. At this point I've installed UFS Explorer on all those PCs. I've installed my LV app to extract data from the files. The user sticks the UFS disk in a disk tray, runs UFS Explorer on the files to be processed to transfer them to a Windows/NTFS disk then runs my app on the Windows/NTFS files to extract the data. I also tried the UFS Explorer tech support again to see if there's someway to run it (or any other product they might have) from the command line. Then I could set up a GUI that would make it at least look like 1 step to the User, even tho it wouldn't speed it up any. No response... No, I'm very appreciative of any stabs anyone wants to take at this. Thanks!

I think I've got it! Resize the window first, then reposition the plots, then resize the plot area. Seems to be working, so far. Now I just have to clean up all the miscellaneous controls/indicators. Thanks to Yair, François, asbo, and especially Ton!

The User resizes the entire window manually which resizes the group of graphs. The code only resizes programmatically in one place. Yes, your snippet works. Part of the issue, I think, is that not only am I resizing the graphs, I'm also moving them (back to their original positions). And to make it more complicated, all those graphs are in a group that resizes with the pane size. And of course, I'm also resizing the window to it's original size... I actually discovered just resizing the window to its original size gets at least the graphs fairly close. Unfortunately there are a lot of other controls/indicators on the window that end up in the wrong place, so I've got to tie them down. I also need it to be more than just fairly close, so I'll work some more with incorporating your snippet. I think my main problem at the moment is doing things in the right order. And I would love to get a reference to my group of graphs so I could turn "resize with pane" off and on...

Hmm. I obviously need to figure out why it's not working for me... I was hoping it was something that would only work in LV9 and then I'd have an actual reason to upgrade.

Love those humongous graphics... PlotArea functions just resize the plot area (the black part) not the whole graph (the outside grey part). I will take a look at your toolset now!

It's always the little things that getcha... Short version: I need to be able to programmically resize a graph at run time. For the long version, go here. I've got 18 graphs, with anywhere from 1 (big graph) to 4 (quarter-sized graphs) of them visible at any one time. When one screen-full of graphs gets resized (by the User manipulating the window), they all have to be resized, even the ones that are hidden. After resizing a few times, a lot of the other controls and indicators on the screen tend to get out of whack -- they move or stretch or whatever. I want to be able to hit a "reset" button that puts everything back to the baseline size/position. I thought I could use Position and Bounds to do this, but while Position works fine, Bounds is read-only. Using any of the "Plot Area" functions does just that -- resizes the plot area but the graph itself does not change size. Tell me there's a simple solution to this that I haven't been able to come up with (or found doing a search here)...

Thanks for the info. I plan on hitting the run button today. Results over in the link I cited above...

This was kind of the effect I was hoping to have using tabs. I haven't used xcontrols much since they first came out. If you don't mind, take a look at the first paragraph of my original post. I need to show either 1 chart OR 2 charts OR 3or4 charts at one time. The user can switch back and forth between 2 different types of those sets, with only 1 type at a time on the screen. And the 3rd set is two charts of different sizes. Can I do this automagically with xcontrols?

You'll be the guy in black tie and tux with the smarmy-looking grin, right?

I realized I should update this as opposed to taking over someone else's thread. Resizing the multi-plots on the tab control worked great -- until I hit the run button. Resizing occurs differently in edit mode than it does in run mode. I tried variations on settings for quite some time before giving up. Also I don't know that if I'm going to take a performance hit from stacked plots, it really matters if those plots are stacked by themselves or in another page of a tab control. As far as docking goes -- the User wasn't happy with changing the look of the GUI that much -- plus I told him it would take a little longer while I figured out how to manage resizing all those dockable parts. I will (hopefully) get a chance to use docking on floating window concept for channel selection. So I'm back to stacking plots. Wish me luck...

Is this true for *all* controls or just "modern" controls? I'm in the midst of overlaying 18 graphs/charts with update rates down to 125 ms where various combinations of 1/2/4 plots will be on top and everything else hidden underneath. I posted about it awhile back. Unfortunately, none of the approaches suggested worked well for my application so I'm back to stacking them all. Everything resizes great, but I'm afraid when I finally hit the run button it's all going to come crashing to a halt.

Try bugging Management about it for 10 months. That's what it took for it to happen for me. I feel your pain. We had a tech who played the radio all the time. Then he left. When he asked to come back I said, fine but no radio. Now I only have to deal with the roar of 30+ multi-fan data collection boxes and assorted UPSs, one of my cow-orkers continually ringing phone, and delivery guys knocking on the door all the time. I really get a LOT more done on those rare days that I work from home.

I had to start talking it up 10 months ago, continually remind my management to set aside $$ in the budget, and swear on a stack of technical manuals that it wouldn't interfere with my test schedule, but, I'm actually going to NIWeek!! I need a HappyDance emoticon.

I work for Big Brother. It was a Great Day when we "upgraded" to IE7 about a month ago.

LAVA I content is being (slowly but surely) migrated to LAVA II. That may be what you're seeing. (Jeez! I nearly hit the "Manage Topic Poll" button again! Can't teach an old cat new tricks! )