Cat

QUOTE (Yair @ May 4 2009, 12:29 PM) I love TIM! My 13 yr old daughter is hooked on a more recent variant and is chewing thru the levels at light speed. Makes a mama proud. I've forwarded the link to Electric Box to my home email account, because if I start it now, I'll never get any work done today...

QUOTE (neBulus @ Apr 28 2009, 08:43 AM) Sadly, the method I used was trying everything else, first. First, while I was out in the field, I finally saw the error occur; that helped make a believer out of me! Not that I didn't believe something that had been reported more than once, it was just that -- as it turned out due to the computer I was using -- I had never seen the actual conditions under which it was occuring myself. After that I spent a bit of time trying to figure out all the things that were different between how I run the software in the lab during development, vs. how the users run it in the Real World. I set up a matrix of the 5 main differences, and rewote/ran my software in several different configurations to test them all. I actually went into it thinking that it could have been multiple things interacting, so I probably ran a few more tests than I actually needed. Once I pinpointed the problem to running sound, I wrote an exe that would: Output to sound 1 second worth of data, 2 channels, i16, via an array constant (pre-generated with the random number generator and scaled to the card's output range), at a rate of 44100. Repeat in a while loop until you are bored, or until you get an out of memory error. I was running Task Manager and would record the memory usage of my little sound routine every half an hour. On my main test computer, it would be flat for 4 hours, and then around 4 1/4 hours start increasing at the rate of about 1Mb every few seconds. Very noticable. I then added a reset button to the routine. I would poke that button after the memory usage started spiking to reinitialize the sound, and it would run fine for another ~4 hours. I then took out the old sound functions and put in the new ones. I ran that overnight and it was still chugging away the next morning. That's pretty much it. As I said, I've tried this on multiple relatively new platforms (mostly varieties of IBM/Lenovo and Dell boxes) and gotten the same out of memory error. I've only tested it on one IBM T43, but from my experience of the past 5 years, I'm pretty sure it will run fine on all of them. Cat

After many many days of testing with multiple different setups, the problem is solved. Or rather, I don't know *exactly* what is causing the problem, but I do know the circustances under which it will occur. Turns out the problem wasn't with all the TCP traffic, and it wasn't with continually moving large amounts of data around in memory (tho I will have to admit I was using a global to do that -- now it's all properly Q'd up ). I am using old functions from lvsound.dll to output the time series data to sound. For some (as yet) unknown reason, on certain computers, after approx 4.25 hours of continually writing 2 channels of I16 data to the sound card, something in the system starts grabbing memory at a huge rate. These "certain computers" are from different manufacturers and have all been purchased in the past couple years, so I'm assuming there is something in newer computers that doesn't play well with the old LabVIEW sound functions. This is even true within a single brand. My old IBM/Lenovo T-43 works fine, but my newer T-61 doesn't. Unfortunately, because I need to use the old machines in order to develop code on a least common denominator, I've been using the T-43 and of course could never replicate this problem there. That made the whole debugging process even more interesting. I've done a quick fix to the problem by reinitializing the sound output every half hour. This action clears out whatever buffer is building up and the code will run fine for at least 3 days (my longest test). The longer fix is to incorporate the newer LV sound functions (lvsound2.dll), which from my preliminary tests work fine in both the old and the new systems. I'm just not sure if everyone is going to have DirectX8.0 on their computers. Yes, it's been around forever, but so have some of our laptops. I'm not really sure whether or not to report this as a bug, since you have to look really hard to even find lvsound.dll anymore -- all the LV sound functions point to the newer version. Plus, I haven't identified exactly what's causing the problem; whether it's a sound card hardware or software issue. Any thoughts on this as a reportable bug?? Or maybe someone has already reported it and I just wasted 2 weeks. Luckily I have enough other laptops I didn't come to a complete halt on my other projects. Thanks again to everyone who weighed in on this with suggestions and encouragment! Cat

QUOTE (Michael Aivaliotis @ Apr 24 2009, 04:11 PM) Today's mystery is why I can see this video and can never see any of crelf's...??? Cat

Argh! I'm going to have to wait until I get home tonight and can see this on a computer that's not controlled by Big Brother. :headbang:

They look good enough to eat! Seriously, they look like giant hard candies! Would it be possible to make the background transparent? Or if not, maybe only as big as you need to make the button "move". Thanks for posting these. They look great. Cat

I'm not sure if this is a bug or just really really annoying, but... Open Project A and edit A.vi. Realize there's some code in Project B you can reuse. Open Project B. Find and open B.vi and copy some code from it (Ctrl-C). Close B.vi. Close Project B. Attempt to paste (Ctrl-V) code into A.vi. It's not available anymore to be pasted. Note that if code is copied directly from B.vi without going thru Project B, it still exists on the clipboard even after B.vi is closed. Unfortunately, B.vi could be buried several directories down, and accessing it from the Project is usually much faster. What gives? Does each project maintain its own clipboard?? Now I just need to write 100 times, "Do not close Project B until code is copied to Project A. Do not close Project B until code is copied to Project A. Do not close Project B until code is copied to Project A..."

I've dealt with this a few different ways. I seem to come back to having, in essence, 2 state machines. One that drives the set up (for me usually frequency and amplitude) and as its last state, an internal state machine that deals with the actual data -- cycling thru channels, collection, processing, saving, etc. All of this is driven by arrays of setup parameters and a pointer variable to each one of those arrays that get updated at the end state. I don't really see any reason why this couldn't be all one state machine, but it's easier for me wrap my brain around it all if I break it up. Plus, there have been a few situations where the setup part was quite easily satisfied with a couple nested for loops, like you mentioned. I would love to post some code, if I could figure out how to get it from my real computer to this Big Brother controlled email machine. :thumbdown: If this method sounds useful to you, but I haven't explained it well enough, let me know and I'll see what I can do about getting some code or at least screen shots.

QUOTE (Mark Yedinak @ Apr 15 2009, 03:44 PM) That's a really interesting idea. I'll take a look at it. Thanks!

I understand ini files can be very useful. I do actually use them with a few of my tools. I always code an editor for them, because my users aren't usually up to hand-editing anything. And under some circumstances, I move the ini files to a different directory, because of other users who *think* they know how to edit them and decide to go mucking around when they're bored. So all of that adds up to me needing the ini files where I need them when I need them. Having LV write to those same files makes me a tad bit nervous. And having it create an ini when I've got the real one stashed away some place safe is needlessly (and perhaps dangerously) redundant. For the record, the solution jpdrolet suggested to use the -pref switch seems to be working fine. It's definitely the easiest solution, tho the batch file idea would have been more technically interesting to implement. Thanks for all the ideas!

I understand ini files can be very useful. I do actually use them with a few of my tools. I always code an editor for them, because my users aren't usually up to hand-editing anything. And under some circumstances, I move the ini files to a different directory, because of other users who *think* they know how to edit them and decide to go mucking around when they're bored. So all of that adds up to me needing the ini files where I need them when I need them. Having LV write to those same files makes me a tad bit nervous. And having it create an ini when I've got the real one stashed away some place safe is needlessly (and perhaps dangerously) redundant. For the record, the solution jpdrolet suggested to use the -pref switch seems to be working fine. It's definitely the easiest solution, tho the batch file idea would have been more technically interesting to implement. Thanks for all the ideas!

QUOTE (jpdrolet @ Apr 14 2009, 01:54 PM) Ah-ha! I was looking all over for those permission settings when you first mentioned this. I finally just figured out that I can't access them anyway, since we have to run with simple file sharing enabled. But at least I now know I wasn't imagining things, and I used to be able to set permissions like that. I got the non-windoze file reference. I'll give the -pref switch a try, since I do run the apps from shortcuts. What? The 3rd option was a joke?!?

QUOTE (PJM_labview @ Apr 14 2009, 01:34 PM) I like this! I haven't had a reason to use system exe (let alone write a batch file) in years. QUOTE (neBulus @ Apr 14 2009, 01:45 PM) Turn that idea inside out. Sub-VI writes then invoke bat file that runs the app and the after the app is done the next line in the bat file deletes the ini. Now *you're* making me all ~~ ~~ !! Okay, I get the idea. When I get a chance I'll play around with this a bit and see what works best.

QUOTE (jpdrolet @ Apr 14 2009, 12:26 PM) I'm working in the Windows world... is it possible to forbid *creation* of files in a folder?? I know I can make a folder read-only, but that's a different thing, and I need to be able to edit the couple ini's I do use in that folder. As for your last suggestion, I agree with what Ben said...!

QUOTE (Antoine Châlons @ Apr 14 2009, 09:29 AM) That link is the only thing I'd found about it, too. Yes, there are sometimes good reasons to have the ini file around. I generally don't use them, tho, and they are cluttering up my EXE folder. Thanks for the idea to delete the ini file from the exe. That should work if the ini is recreated on start of the exe, but probably not if it's recreated on exit. I'll take a look at it.

Is there any way to tell LV not to create its own 'myapp.ini' when one of my executables is run? Cat

QUOTE (PJM_labview @ Apr 13 2009, 02:59 PM) Don't feel too badly for them. These are the same guyze who, everytime I opened up LV7 and they saw the big "EXPRESS" title on the splashscreen, would say, "You know, if National Instruments would ever put out a *real* version of LabVIEW and not just an *express* version, maybe you could actually do something with it." I was ecstatic to go to v8, if only for that reason. Cat

QUOTE (JustinReina @ Apr 13 2009, 01:14 PM) Most of my cow-orkers would think Microsoft Paint was a more appropriate application to open LabVIEW in. It's just a bunch of pictures, right??

QUOTE (Mark Yedinak @ Apr 3 2009, 01:28 PM) Don't get me wrong -- I love state machines and use them all over the place. I just never made the leap into using it to make more simplified transitions between parts of my code that *always* go step1->2->3->etc. I'm giving it a whirl right now with my big, messy, 3x4 screens, dies-after-8 hours vi. If I can make it work there, I can do it anywhere.

QUOTE (crelf @ Apr 3 2009, 01:20 PM) Good point. Thanks!

QUOTE (Neville D @ Apr 3 2009, 12:42 PM) All right! I give! I'm not too old to change my paradigm and think about using a state machine for static states. I suppose it would be useful if there's a lot of info that needs to be passed between the states/sequences. Often, tho, that's not the case (just starting up instruments or dynamically calling vis, for example), and I really think a sequence might be simpler.

QUOTE (shoneill @ Apr 3 2009, 11:56 AM) Don't hold back Shane. Tell us what you *really* think. I'm of the "Guns don't kill people; People kill people." philosophy. Or more to the point: it's really easy to use stacked sequences badly, but that doesn't mean they can't serve a useful purpose. I haven't seen any actual technical reasons posted not to use stacked sequences (if you have a clue what you're doing). Both stacked sequences and state machines (as well as event structures) hide code, so that's not an issue. I'm also not sure what the point is of using a state machine to replace a sequence when the same states always get executed in the same order. That seems like extra code to do the same thing. An aside: It suddenly struck me this morning -- of the 20 or so top level vis that are in my Big Project, there's only one vi that I haven't used my usual setup/main/cleanup sequence, keep it all to one screen design. And that's the vi that's blowing up on me after running for 8 hours. Hmm....

QUOTE (PaulG. @ Apr 3 2009, 09:16 AM) Wow, I think I'm having a flashback. I'm pretty sure I was involved in this same conversation 15 years or so ago. By far my major use of stacked sequences is to put setup code in seq#0, the main program in seq#1, and cleanup code in seq#2. Along with wiring guidelines I am also anal retentive about making my code all fit on 1 screen (not always easy with my standard 1024x768 laptop screen). Sometimes that becomes problematic -- say for instance I'm initializing all the values in a 50 element structure I'll be using for a state machine. There's no nice way to pass all that into a subvi. So it might get its own sequence. I'd much rather have to click once to move to the next sequence than scroll all over the place to see what comes next. So there you go. Reason(s) why someone might use a stacked sequence.

My first thought on reading the subject line was, "There's nothing sadder than an injured mouse." But on a more practical note... Here in the US Fed Gov't there's a big push for only purchasing technology items if they are accessable to people with disabilities. We often have to submit lengthy justifications for an item if it's not compliant with Section 508. LabVIEW does not comply, mostly due to the "keyboard=good, mouse=bad" part of Section 508. You can read all about it at: http://www.ni.com/pdf/gsa/en/labview-508-a...ance-matrix.pdf Until 10 minutes ago I didn't even know about Quick Drop. Tools like this can definitely help answer some of the Section 508 issues (and reduce my justification paperwork!)

QUOTE (psychomanu @ Apr 3 2009, 05:54 AM) All the Bad Things about stacked sequence structures aside... philosphically, I agree with this suggestion. I am very anal retentive about inputs coming in on the left side of a subvi and outputs going out the right side. This means when I use a sequence local as an input, I have to drag the wire all the way from the right side of the sequence and make a couple turns before I can put it into a lefthand terminal on a vi (or vice-versa if I've put the sequence local on the left side of the sequence). This definitely contributes to spaghetti looking code. Don't tell anyone, but I have been know to create a local variable for a later sequence instead, just to improve readability. A shift register-like terminal would solve this problem.