eaolson

QUOTE(yen @ Jul 17 2007, 04:39 PM) These things have been around on other sites for a while now. Thanks to Michael for constantly trying to improve this site, but personally, I hate these things with an undying passion. They're especially annoying in link-heavy text, where I'm scrolling down with the mouse wheel, the scrolling brings the cursor over a link and, *pop*, whatever I was reading is now obscured by a preview of a web page I don't really care about.

QUOTE(Ben @ Jul 16 2007, 09:11 AM) I think part of that is because science hadn't really formed into the discrete disciplines we have today. It was all sort of "so how does the world work?" I always find it odd that Newton was also an alchemist. QUOTE So I wonder out loud, "what is wrong about talking about God?" I think the Hindu guy that tried to give an invoation before Congress recently might wonder the same thing.

QUOTE(Neville D @ Jul 10 2007, 10:58 AM) That's not exactly true. I have one application that uses RT Set Date and Time. When I open the VI from the Project Explorer and targeted to the RT target, it opens fine. If it is targeted to my desktop machine, or I open it by double-clicking the VI in an Explorer window, LabVIEW searches the entire VI search path for the Set Date VI, but doesn't find it. The definition of <vi.lib> seems to change depending on what the target is. This isn't a particularly big deal, but I find it annoying.

Most of the rewards are in the 2-5 cent range, it seems. At minimum wage, 10 seconds of your time is worth about 1.5 cents. Most of these look like they would take significantly longer than that.

QUOTE(Tomi Maila @ Jul 6 2007, 09:16 AM) Except that Aristos Queue has said that notifiers actually are queues, behind the scenes. Have you tried recreating your example with single element queues to see if it still gets stuck?

QUOTE(John Rouse @ Jul 5 2007, 08:47 PM) It sounds like you might be able to use a notifier. With a 0 wired to the timeout, you will always get back the last value put into the notifier. You don't have to worry about the queue ever being empty.

Here's another couple of icon sets, both open-source: Silk and Mini.

QUOTE(Mike Ashe @ Jun 29 2007, 07:26 PM) Of course, that means that bubbles don't rise, either. Water just flows downward around a hole.

QUOTE(GertheDwarf @ Jun 22 2007, 01:36 PM) Try right-clicking the Picture and selecting Advanced : Smooth Updates.

QUOTE(Dchamberss @ Jun 21 2007, 04:31 PM) Your current and voltage indicators aren't updating because they are outside the main While Loop. They don't get their data until that loop finishes. Move them inside it and they will update each iteration. As for the speed issue, you have two delays in your VI. You have the Wait (ms) VI and the ms timer output of that is wired to the Time Delay Express VI. I would suggest removing the Express VI, and putting the GPIB Write, Wait (ms), and GPIB in three frames of a Flat Sequence structure. You can eliminate the need for the sequence structure if you use the OpenG version of the Wait (ms) VI. Use the error clusters with that to enforce the correct dataflow.

QUOTE(Jim Kring @ Jun 17 2007, 03:36 PM) Unfortunately, the concept of a website that works without Flash has left the building.

I'm starting to think this thread should go away. Originally, it amused me in a Time Cube sort of way, but I think it's gone past that. There are, I think, some fairly serious mental health issues involved here. Continuing to bait and mock alfa says more about us other posters than it does about him. Just my $0.02.

QUOTE(Tomi Maila @ Jun 8 2007, 02:33 AM) When I run your VI, I get better performance for the R case in Test.vi, but better performance for the O case in Test_inverse.vi. I wondered if it had something to do with the fact that the two loops were running in parallel, so I put them sequentially. In this case, I get faster performance in the O case 5 times out of 6. The spread is smaller in my case, about 5 ms or 0.1%.

QUOTE(Gary Rubin @ Jun 5 2007, 11:22 AM) The closest I can find is Application Note 168, "LabVIEW Performance and Memory Management," where it says a DBL-to-SGL conversion on an array is done better inside the For loop, rather than outside (page 15). This App Note came with my 7.1 distribution, but I can't find it on the NI website anymore.

QUOTE(Aristos Queue @ Jun 4 2007, 05:46 PM) I can't find the example, but I was pretty sure it used a For loop. On the other hand, I may be getting mixed up with the explicit vs. implicit type coercion on this http://www.ni.com/pdf/custed/us/sample_clad_exam.pdf' target="_blank">old sample CLAD exam. Explicitly looping vs. using the array version of an operation does seem to make a difference of about a factor of 2, at least for casting a double to an I32. Wow, for casting from a U32 to an I32 (I thought maybe the change in size of the data was having an effect) getting rid of the For loop had a big effect. 80 ms down to 5 ms.

QUOTE(Gary Rubin @ Jun 4 2007, 09:44 AM) No, because I remember the same thing. In fact, I the example it used is pretty similar to the attached one, with no contants involved. As I recall, the difference in speed was explained as being because LV was able to reuse a buffer in the array case, but had to reallocate it each loop in the For case.

QUOTE(Jim Kring @ May 30 2007, 07:38 PM) And whoever has heard of The Knights Who Say National Instruments?

My question would be: What is LabVIEW like "under the hood"? It seems that many of the high-level VIs are done by eating their own dogfood and are written in LabVIEW, but others are unexplorable primitives. The number of external DLLs and CINs seems to be decreasing (I could be wrong about this). Aristos Queue once said that the Get Queue Status VI "generates no code" if a particular wire was left unconnected. Ever since then I've wondered if much of LabVIEW is a front-end for connecting bits of pre-compliled code.

QUOTE(crelf @ May 16 2007, 01:36 PM) Odd. I swear I did do a forum search for "CLAD" before asking the question (I have read the Forum Guidelines, after all) and that thread didn't come up.

I'm curious as to what the concensus is about the value of CLAD and/or CLD certification. Is it something that people look for, or is it not something generally worth bothering with? I ask becuase, until recently, I had been under the impression that the CLAD had to be taken at an NI site like the CLD. The closest one of those is a good 400 miles away from me. It turns out there's a location to take the CLAD right here in town. So I'm just trying to decide if the trouble and expense is worth a bullet point on the resume or not.

It sounds like you are getting the image data mixed up with the Picture control that will contain the image. All that Draw Flattened Pixmap does is take a cluster of image data and turns that into a LabVIEW picture data type. You then need to wire the picture output of that VI to a Picture control. You can set the size of the Picture control with a property node using the Draw Area Size property. I don't think you can actually turn off the border, but you might be able to customize the Picture control and set its border color to transparent.

QUOTE(alnaimi @ May 4 2007, 03:49 PM) Again, what does "it did not work" mean, specifically? I would suggest first checking by hand with a voltmeter to make sure your circuit is working properly. The best LabVIEW in the world won't help you if your transistor is fried or if you have a loose connection. Then check to see if your AI/AO routines are working properly. Compare the voltages your DAQ hardware is reading and writing with what a voltmeter says. If they don't match, something is wrong. I've found that students tend to implicitly believe a hardware reading, even if it's not doing what they think it's doing.

QUOTE(alnaimi @ May 4 2007, 02:43 PM) He added structures to turn off the AI and AO VIs that you didn't include with Three.vi. There's also some code to generate some numbers since we don't have your DAQ hardware. QUOTE About ur solution it gave me the same as the prevouis graph ! it did not solve the problem What exactly is the problem? The program compiles and plots lines in the graph. You've never really said what the program should be doing that it's not doing.

QUOTE(Eugen Graf @ May 4 2007, 02:34 AM) I've done something similar, and my solution was to give each task its own queue. If you must have one queue, you could make the Action specific to each task (e.g. Update settings - main, Update settings - read, etc.), and if a task dequeued an instruction that wasn't applicable to it, it sticks it back in the queue.

QUOTE(Tomi Maila @ May 3 2007, 12:25 PM) Most of the solutions discussed in these threads seem to be of the (1) dequeue if full, (2) enqueue element sort. Since step (1) may or may not execute, these all seem guaranteed to not be deterministic. If determinism is important, you probably want an RT FIFO. Since these can overwrite data if the FIFO is full, they seem to act as lossy queues, though they don't work with all datatypes.