Cat

I should have asked a clearer question. Is there an option during install of OpenG that would allow me to put it in vi.lib now, or does it have to install to user.lib? Just wondering if in the short term, while those of you who decide these issues are deciding, I can go ahead and reinstall OpenG to vi.lib where it seems most logical (to me!) for it to be. My guess is the answer is still "no"...

It's been awhile since I've done a fresh install of OpenG -- does it currently have the option of installing to somewhere other than user.lib?

Yes, please, move it. IMHO, user.lib should be for *user* developed code, not add-ons, which is what OpenG really is. As a practical matter, it would also make my life a little easier. I develop on anywhere from 3 - 6 machines at one time. They are usually not networked, or not networked to each other. Therefore I have to manually xfer my user.lib between machines when I make any changes/updates. While I have a couple hundred functions I've developed myself over the years, about half of my user.lib is OpenG. So it gets copied back and forth along with the rest of my user.lib, doubling the transfer time. If OpenG were in the add-ons directory, I wouldn't have to touch it except when an actual update was available.

This issue has been assigned CAR #313508.

Still just theoretical, but check this out.

DC isn't a friendly habitat for driving, period.

I love my Prius and have had it for 5 years. I get ~45mpg, and that's after replacing the crappy OEM tires with something with actual traction. I'll have to replace the main battery eventually, I know, but there are tons of Prii out there with over 200Kmiles on the original battery. It seems like 1 in 10 cars on the road around here (Wash DC area) is a Prius, so there's no stereotype or stigma attached to it that I've noticed. I will admit I spent the first couple months trying to see how high I could get my mileage if I drove around the speed limit, didn't jump off the line at stop lights, etc. It was around 53mpg, but I eventually got tired of continuously being practically run over by all the aggressive drivers.

The message that only tells me to get on ni.com to get information about some error. This isn't helpful for those of us who don't run connected to the Internet.

Oh thanks, Shaun. I just opened that on a government computer. Big Brother's going to be banging on my cubby door at any moment. You all will visit me in jail, right?

I know NI's answer to #2. My answer would have been a CSV file. It's readable by anything, Excel included. And has the benefit that the character that is separating your data is obvious in any text reader. But that's just me... While we love to help here, we get a fair share of posts from people who don't want to learn, but just want us to do their school project for them. Sorry if I misunderstood your intent.

Ditto! Does dreaming about while loops and event structures count?

Have you reported it to NI? I was thinking about sneaking in a LV2011 upgrade while my boss wasn't looking, but maybe I'll wait. Considering the problems I've had with the sound vis in the past, I'm a little gun-shy on this topic.

Very well could be! But mentioning that up front would have been nice. Especially since he/she is a first time poster. Going back to work now...

My answer to #2 would be "none of the above". Good thing I've never taken the CLAD. Still curious why one would need reference material...

Why don't you tell us more about your specific application. At the moment it just looks you're writing a paper and you want us to do your research for you.

Hmm... yes, that's my concern -- that this isn't just a loopback problem. Thanks for the input. NI is working on this and I'll post here when they get back to me.

Hey! I loved WordStar!

I get something like this on occassion, too (LV2010). Sometimes there's some broken wire somewhere that has nothing to do with the "hidden control". Fix it, and the error goes away. Don't have a clue what's causing it, but once I figured out it would go away if I fixed everything else, I started ignoring it.

I keep trying to do something with "spewing hot schist" and it's just not working out.

Especially appropriate since many of you are probably a lot larger now after all that eating and drinking you did at NIWeek.

No help, but some questions/comments: (Not to get too personal, but ) how large is your app? I don't know why something would have memory issues as an executable but not in source code mode. Does it fail immediately? Have you watched Task Manager to see what resources are being used? And FWIW, in the past when dealing with out of memory errors, I tried setting PAE and all the things you're supposed to do to make LV use more memory, and none of them worked very well. I think you have a good excuse for a brand new x64 machine!

Hmm. It's been a year or two (or 30!) since I read it. My vague recollection is there was some emphasis on hands-on, real world knowledge verses book learning. And plus I probably was looking for any excuse to drop out. I should probably reread it. Hopefully it won't inspire me to quit my job.

It's a good thing you didn't come across "Zen and the Art of Motorcycle Maintenance", then. I read it while in college and it almost inspired me to drop out. I've hidden "ZAMM" until after my daughter gets thru high school and college...

I'm the one setting up the ramdrive and had originally hoped to use ramdrive.sys. The Unix guys got a little glassy-eyed about it until I told them not to worry -- it just looks like another disk to their code. The whole ramdrive thing was a step into the wayback machine for me. I haven't used one since my BASIC/MS-DOS days. I'm using RamDisk and so far it seems to be working. Disabling Nagle's algorithm is something I haven't tried yet, but only because it's supposed to be for optimizing small data packets, and 5MB isn't very small. But hey, I've tried everything else, I can try that, too.

We thought about trying a dll, but none of the C programmers here are experienced with that sort of thing (they are all UNIX programmers and are having enough issues trying to deal in the Windows world) so we dropped it. We're going to write files to a ram drive. It's low enough datarate, plus the fact that all the data is available once a second and not spread out, makes that a pretty good option. Hopefully. :-) My next move is to kick this to NI, I guess. It's such a narrow issue -- I doubt many folks are doing loopback TCP in LabVIEW on a regular basis -- but my concern is that there's some underlying issue with LV that may affect other TCP functions.