Gary Rubin

QUOTE(yen @ May 30 2007, 01:41 PM) Does not work for me on IE 6.0. It does work on FF 2.0.0.3

QUOTE(jpdrolet @ May 30 2007, 10:32 AM) Think of the neck ache you would get staring down at that all day. On the plus side, I guess it would force me to get the piles of paper off my workspace.

QUOTE(Michael_Aivaliotis @ May 30 2007, 01:40 AM) Nope...

QUOTE(Michael_Aivaliotis @ May 23 2007, 04:34 AM) Yes it does feel a little faster. Thanks! Clicking on the "Last Post" link brings me to the top of the page on which the last post is located, rather than right to the last post.

QUOTE(zeldAIS @ May 18 2007, 08:54 PM) I think this wins the prize for the most interesting/unusual application of Labview! :thumbup: Hmmm... It got me thinking - if I had a PDA with Labview on it running an application like this, maybe I could finally figure out how to pick a good melon at the supermarket...

I'm not Crelf, but I'll venture an answer. I don't believe that wire has any effect on when the delay occurs. What it does do, however, is provide a ms timer value of when the last loop finished. This could be accessed by wiring the output tunnel to something. Gary

QUOTE(crelf @ May 16 2007, 01:42 PM) Do you hafta sing too?

Does Labview Bytestream just refer to this? http://forums.lavag.org/index.php?act=attach&type=post&id=5887 Thanks, Gary

QUOTE(BrokenArrow @ May 15 2007, 12:46 PM) Regardless of whether they're "someone else's" local variables, I would think this experience would cause you avoid local variables like the plague in all of our future coding. I've run across code similar to yours (although not nearly to that scale), as has anyone else who's ever tried to use the example Labview code for the ICS-554 A/D card. I never used locals much anyway, but after slogging through that, my knee-jerk reaction was to avoid them even more.

QUOTE(BrokenArrow @ Apr 29 2007, 09:45 AM) Are you serious? Aren't you the one banging your head against the wall because the application you are trying to debug uses too many local variables? QUOTE The following searches gave a "Search Aborted. Too many search objects were found".... Globals: >2000 Locals: >2000 Front Panel Terminals: >2000 and... 347 VI's 594 sequences 1368 Attribute Nodes (old term for Property Node I guess) This project is a morph of something that was started 10 years ago, has had 5 or so programmers in it, with almost weekly additions. There's almost no wires. If something is more than a few inches away or in a different frame, a local variable was used. There are hundereds of "read only" variables, and even "write only" variables !!!

QUOTE(Mikkel @ May 15 2007, 07:53 AM) :thumbup: That's certainly easier than my suggested approach.

QUOTE(Bryan @ May 15 2007, 06:51 AM) Bryan, I haven't tried anything like this before, but you might look here: http://msdn2.microsoft.com/en-us/library/aa363256.aspx and here http://msdn2.microsoft.com/en-us/library/aa363188.aspx and here http://msdn2.microsoft.com/en-us/library/aa363214.aspx Gary

QUOTE(Rimmergogo @ May 11 2007, 03:59 AM) Here is a quick-and-dirty solution that you might try. Your acceleration profile looks pretty symmetric, so you can likely use the same technique to find the stop as you did to find the start. Use Reverse Array on the acceleration data, negate the result, and run it through the same VI that you used to initially find the start-up acceleration. Just remember that because you've reversed the array, the answer is really going to represent the number of elements from the end of the original (unreversed) array.

QUOTE(Bernd F @ May 11 2007, 03:42 AM) That's certainly a unique debugging method. I wouldn't recommend relying on it very often though

QUOTE(van18 @ May 10 2007, 12:55 PM) I can't duplicate it in 7.1.1 either.

Try deleting the current output of that build array, then right click on the right side of the build array icon and select Create > Indicator. I don't have LV8.20, but I assume that they haven't moved the Create Indicator

QUOTE(Michael_Aivaliotis @ May 2 2007, 07:37 PM) What, no LAVA romances?

It's also about how we phrase responses to those who don't follow your guidelines. If we are too harsh, then we intimidate or scare off the the non-HH newbies along with the HH culprits. QUOTE I understand that this is how everybody feels about basic questions, but Ben, dannyt, dsaunders, and I have all remarked recently that we have doubted whether our questions are worthy of LAVA. Despite the remarks from you, id2x, and others that we shouldn't feel this way, the fact is that something is giving us that impression. Do we just happen to be meek people, or are we getting (inaccurate) vibes about whether LAVA is too exclusive for us? Who knows? Yes, we want people to think before posting, but we also don't want them to be afraid to post.

QUOTE(Ben @ May 2 2007, 08:46 AM) This makes me think of the cliche that explaining/teaching something is the best way to really understand it yourself. I think Ben really has a good point, especially when I think back to the many posts in which a veteran has remarked "I didn't know you could do that!" when someone has explained to a newbie one of LabVIEW's many little tricks and features. I think we're starting to see a pattern here. In the last week, I've counted 4 people with 23 years combined LabVIEW experience expressing doubts about whether they were advanced enough to be posting here at LAVA. I understand the desire to run off the homework hustlers, but if it is done in a way which makes others feel unwelcome or intimidated, then LAVA will eventually become a forum that is, in essence, dedicated to a handful of people who are primarily interested in discussing GOOP and X-controls.

QUOTE(crelf @ Apr 28 2007, 11:25 PM) It's not part of what raised Michael's hackles, but I do think it is part of the issue of treatment of new members. I have seen more than one post answered with the comment "This is an advanced forum. Go spend time on the NI forums and come back when you've learned more". That might not be as rude as some comments have been, but it certainly doesn't sound welcoming either.

QUOTE(chrisdavis @ Apr 28 2007, 09:56 PM) I was thinking about USB. Not sure how I would package that. I guess I could strap it to the back of the rack, if the customer's ok with it. Thanks.

QUOTE(chrisdavis @ Apr 27 2007, 04:31 PM) What about just output? I was thinking along similar lines recently. I have to send a timing pulse to 8 different locations to start a process. My first thought was to use a cheap NI DIO board, but the idea of being able to use the parallel port and save myself a PCI slot sounded pretty good too. Thanks, Gary

QUOTE(Michael_Aivaliotis @ Apr 28 2007, 09:06 PM) Thank you Michael. I think that really needed to be said, and it certainly helps that you are the one who said it. I know I'm a relative newcomer to the board and the recent abuse of Nullll and Sally have had me second-guessing my own past postings. Am I advanced enough? Am I really an "architect"? I shouldn't have to think such things. I understand the desire to keep the SNR high at LAVA, after all, that is one of the main reasons I hang out here rather than the NI forums. There's got to be a better way, however, than telling users that they aren't good enough to post here. You shouldn't have to have an CLD to ask a question, no matter what the forum. :2cents: Gary

QUOTE(ned @ Apr 16 2007, 02:23 PM) I see. Thanks. I was expecting it to just add a dimension to the input type.

I've searched the LAVA and NI forums for this, but haven't found anything. I'm trying to transition a LV2-style global to a queue. I have to admit that I'm quite inexperienced when it comes to queues, so I may just be making a stupid mistake. In the attached snippet (LV7.1.1), shouldn't the output of the 'flush queue' be a 2D array of type double? That's what I would expect from the Labview help, which is the source of that text box in the diagram. http://forums.lavag.org/index.php?act=attach&type=post&id=5527 What am I missing here? Thanks, Gary