eaolson

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)

So if you are looking for a thread safe way to do things, queues are definitely safer way to go.

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)

I want to use a named queue with a size of one (1) that is "written to" from one place at a time but

is also monitored from 1+ places at a time without concern for timing.

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)

I'll reply to you as I did to my first year EE professor, "with all due respect Sir, only electrons really flow, there is no such thing as 'hole flow' or positive current, protons do not flow, electrons do, and I'll put it down on your test if it will make you happy (and get me a good grade), but I don't have to buy into it, and I don't"

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)

Why does the circle flicker?

Try right-clicking the Picture and selecting Advanced : Smooth Updates.

QUOTE(Dchamberss @ Jun 21 2007, 04:31 PM)

I would be greatly appreciative to anyone who cares to scrutinize my work and leaves a comment. I'm pretty new to labview and I don't have anyone I work with knows labview. I searched these forums (and Google) before posting. I think the Keithley 6487 is a commonly used instrument and I'm surprised not to see any discussion directly related (maybe I'm naive).

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)

Surface computing has arrived.

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)

Both of these test VIs show that VI with required input runs faster than the VI with recommended input. I considered the option that LV schedules VIs according to their name so I switched the names of the VIs. Still the required VI was faster. The speed advantage for this task was about 1%.

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)

I'm glad that you seem to have the same recollection that I do. I'm away from my office right now, but I'll have to look hard for that document when I get back.

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 think you're thinking of a *while* loop.

In a For Loop, since we know at the start how many elements will be needed, the output array can be allocated right away.

With a while loop, it gets reallocated on each iteration to grow as needed.

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)

Am I just imagining a past App Note that recommended operating on arrays rather than on each element inside a for loop?

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)

I agree -- I really dislike having my posting content altered behind my back. If I say "NI Week" I don't mean "National Instruments Week".

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)

This has been discussed here.

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)

I have already tested those VI's , it did not work with me !!

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)

what is the disable and enable ?? I did not understood what u added !?? Could u explain and what I choose disable or enable?

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

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)

No, if I want to "say" to more than one task about new settings, I have to use User Events (or Notifier?) but no queues. Because if I dequeue new settings in a task, than other will dont get it.

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)

Lossy queues are usually needed when the queue writing process needs to be deterministic to avoid source buffer overflow, and the queue consuming process is often undeterministic.

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.

QUOTE(dsaunders @ May 3 2007, 12:00 PM)

Thinking about it that way, do you need to protect it at all? If you have a non-reentrant wrapper around your enqueue function then you already have a sort of semaphore on the writing of the queue. If you want to protect read and write then make it a functional global wrapper.

I think the problem becomes that, if you have multiple threads enqueueing, it is possible that they will conflict. See Aristos Queue's post http://forums.lavag.org/index.php?showtopic=3406&st=15#' target="_blank">here.

QUOTE(Tomi Maila @ May 2 2007, 02:46 PM)

I was thinking of the lossy queue issue today that has been discussed http://forums.lavag.org/index.php?showtopic=3406&pid=16372' target="_blank">on this forum earlier. I came up with a solution that I think should work for most of practical use cases. The idea is to proxy the enqueue operation via an user event and handle the user event in a proxy loop or thread.

Perhaps I'm being a bit thick, but what's the disadvantage to protecting a fixed-size queue with a semaphore? I can see that multiple Enqueue points might experience a slight delay when enqueing.

QUOTE(Michael_Aivaliotis @ Feb 28 2006, 01:14 AM)

I've been considering the idea of having a Member reputation system implemented. This would allow you to rate others and in turn be rated.

I just don't think it's necessary here. On a site like Slashdot, where there are hundreds of thousands of users, it's necessary to winnow out the chaff. But here at LAVA, the signal to noise ratio is quite high. I don't think I've ever even seen an honest-to-god troll here. I think the "Activity level" ratings for each user are as much information as is really needed. I'm not sure how big the community actually is, but it seems like the number of regular posters could be measured in the few dozen.