eaolson

QUOTE (Michael_Aivaliotis @ Jun 4 2008, 03:23 PM)

PS. I wouldn't mind an email as much, but a phone call is over my limit.

I have to agree. It's stuff like this that makes me glad I always put a fake phone number in my online profiles, even for NI. Back before the Do Not Call registry, I would get a couple of calls a night and it drove me batty, so maybe I'm a bit overly sensitive. Anyway, telemarketers are teh suck.

QUOTE (scls19fr @ Jun 4 2008, 02:57 AM)

I would like to change the color of a tank according the value of a slider.

The way that came to mind for me is to use your input value as the H on the HSV scale. Scale your input value to [0,360) and http://en.wikipedia.org/wiki/HSV_color_space#Conversion_from_HSV_to_RGB' rel='nofollow' target="_blank">convert to RGB using S = 1 and V = 1. It's not real difficult, but complicated by the lack of a native HSV to RGB conversion in LabVIEW. You might also want to scale the input value starting at 240° (blue) to 0° (red) rather than from 0 to 360.

QUOTE (crelf @ May 23 2008, 12:38 PM)

...and that's why almost all Einsteinian and Newtonian conclusions are theories, not laws. They haven't been prooved, so they remain theories. I actually think that we agree, just on different levels

You mean like http://en.wikipedia.org/wiki/Newton%27s_laws_of_motion' rel='nofollow' target="_blank">Newton's laws of motion? The law vs. theory distinction is one basically of historical usage. Prior to about 1900, things got called "laws", now they're "theories". Almost everything referred to as a "law" is a relationship that can be easily expressed as a simple mathematical equation, but they're almost always approximations. Ohm's Law, Henry's Law, Raoult's Law, Coulomb's Law, Dalton's Law: none of these things are rigorously true, but the mathematical representation is extremely useful so they get called a "law."

Maybe we are just arguing semantics, but I see the "evolution is a theory, not a law," argument so often that it bugs me.

QUOTE (crelf @ May 23 2008, 07:10 AM)

Scientific theories are exactly that - theories. Scientific proofs are indeed true: they started out as theories and were, by their very definition, prooved to be true, and that's why they're not theories anymore - they're proofs. In summary, there is a big difference between accepted theories and proofs - they are two very distinct things and should not be confused.

I have to disagree. The only place you can ever really talk about "proof" in any sort of technical sense is mathematics and that's really applied logic, not science. Nothing in science ever reaches the point of being "proven", just supported by a great deal of evidence. Even that doesn't mean that it's invulnerable: Einstein showed Newton was wrong and someday, we're going to figure out where Einstein was wrong when we manage to explain general relativity and quantum theory.

The problem seems to be that people with ulterior motives like to claim that well-accepted, supported ideas aren't "proven" and then their crazy idea has credence.

It says something that as soon as I saw the black hexagon, my mind briefly went here. I think it means I need to get out more:

I'm actually somewhat surprised there wasn't one like this:

QUOTE (shoneill @ May 19 2008, 03:52 AM)

Athiesm is a belief. It's not (as Justin has pointed out) a lack of belief. It's a belief that there is NO god. Even the idea that believing in NO god does not qualify as a belief is something which atheists have fought against for years.

As Dawkins put it "If atheism is a religion then not collecting stamps is a hobby." To be fair, atheism and agnosticism are fairly squishy words that can mean largely what you want them to mean. There is the strong atheism, weak atheism, etc. That's not entirely limited to a disbelief in god; you'd get a very different if you asked John Hagee if Catholics and Mormons were really Christians than if you asked a Unitarian.

I'm not a Christian, but I'm open to reevaluation after the Rapture.

QUOTE (crelf @ May 19 2008, 07:10 AM)

That's something I never got: what's the difference between belief and faith? I'm not sure you've fully explained it.

I've always thought that a good definition of "faith" was a conviction held either in the absence of evidence or contrary to evidence. Basically, someone hands me a piece of bread and says "Here's a piece of bread" that seems to me to be so self-evident that you wouldn't even call believing that there is a piece of bread actually there an act of belief. Handing me a piece of bread and saying "Here's a piece of bread that's been transubstantiated into the body of Christ" is an entirely different thing and requires an act of faith to believe.

QUOTE (Neville D @ May 16 2008, 01:08 PM)

You can send images with overlays to the monitor connected to a PXI system running LabVIEW-RT. It is a little known, but very cool feature.

It's getting a bit off-topic, but how do you do this? I have a monitor connected to my PXI system (mostly if I need to boot into Windows), but I've never known any way to display anything on the monitor.

QUOTE (Michael_Aivaliotis @ May 13 2008, 12:36 PM)

Unless of course you're a mystical fairy who shoots pixie dust out of your a** when you fly.

I'm going to go put that on my resume right now.

QUOTE (TobyD @ May 12 2008, 01:47 PM)

I just purchased a Logitech gamepad that allows me to program the 10 buttons to mimic any keypress or key combitaion.

We bought a series of piezoelectric motors and an electronic control system a couple of years ago. All in all, we've probably spent $20,000. (What is that, maybe 1.50 euro these days?) Imagine my amusement when the analog controller that came with the system was labeled "Sony Playstation."

QUOTE (Aristos Queue @ Apr 24 2008, 10:39 AM)

HAVING SAID THAT... it is perfectly legit to have a class that you treat as abstract, not ever actually using anywhere in your top-level VI. And there is a new feature in the next version of LV that will address one key aspect of abstract classes. But that's all I'm going to say about it for now.

You could also have the methods of the abstract parent class throw an error if they run. That might help enforce non-instantiation of the parent.

QUOTE

With 20+ years of history, I doubt any major paradigm shift is easy or quick to do. I was just thinking that if there were built-in numeric classes (e.g, Double) that could be automatically converted to their underlying primitive (e.g. double) at a coercion dot. I'm not entirely clear on what goes on at a coercion dot, but it seems that it has to be more than just a cast, since anything can be coerced to a Variant, and they carry attributes with them which didn't exist for the original coerced thing.

I'm not saying that universal support for classes isn't more important. It's just that, to quote Freddy Mercury, I want it all and I want it now. Please?

QUOTE (Aristos Queue @ Apr 23 2008, 11:42 AM)

The hard part would be streaming the built-in data types (numeric, string, path, cluster, waveform, timestamp etc) -- those would either need to be wrapped in a class or handled by Variant, with all the overhead you were noting.

So it sounds like, if primitives inheritied from Object, that would eliminate this problem? (Hint, hint.) Or even wrapper classes around the primitives, with autoboxing/unboxing.

QUOTE (Jim Kring @ Apr 23 2008, 11:58 AM)

Since you can't have negative posts, I would assume that you have to have 4096 posts to be in that club

But you might want to reserve the option of returning -1 if Michael timed out before posting.

This thread got me thinking: would it be possible to implement something like the Java stream classes in LabVIEW? (And would there be any point in doing so?) The two sorts of things that come to mind are file streams and piped streams for inter-thread communication. The former could be a wrapper around the file VIs, and the latter would be a wrapper around a queue.

On the other hand, with LV's strong typing, you'd probably have to have a different implementation for each data type or handle everything as variants with Variant to Data nodes all over.

I was thinking something like:

Stream

|

+-- FileInputStream (methods for reading data)

|

+-- FileOutputStream (methods for writing data)

|

+-- DoubleStream (similar to Java's PipedStream, has both read and write methods)

|

+-- IntegerStream (same as DoubleStream, but for integers)

|

+-- etc.

Is this a stupid idea? I don't really have much spare time right now, so I can't work up an implementation, but will try to do so when I can.

QUOTE (Cat @ Apr 21 2008, 12:45 PM)

For example, one of my current projects is a data recorder (to vastly over simplify it). I need to set up a connection to a data server, read data, save data, manipulate data in different ways, and then save the results. I would usually write this as a series of modules that perform those functions. Is my only class "Data Recorder" and all of those functions methods of that class?

I imagine a lot of that is dependent on just how much effort you want to put into making stuff applicable to reuse. Just as you could put all your code into one gigantic top-level VI, you could put all this stuff into one class. Or you could break it up into subVIs which make the code easier to read and enable reuse, just as you can create multiple classes.

For example, when you save data, don't think of it as saving data. Think of it as sending your data to some external sink. In your case, that sink is a file being written to disk. But it could also be a chart. You could have a top-level Saver class and FileSaver and ChartSaver subclasses. But do you want to go to the work of making the top-level class and then a child class for this one project you're working on?

Java, for example, has the OutputStream class that sends data elsewhere. You can have a FileOutputStream for writing to a file, or a PipedOutputStream for sending to a different thread.

I never really thought of this before, but it just seems really odd to me that NI didn't release any implementations of anything in LVOOP. That makes it really hard to build a LVOOP class because you have nothing to build on top of. Again, look at Java. There's a huge library of classes that, if you can't find one that does exactly what you want, you can subclass and add functionality.

QUOTE (neB @ Apr 15 2008, 01:23 PM)

I am not saying that everyone SHOULD beleive in a deity.

I am saying that it is OK to be a scientist and beleive in a deity.

I'm not disagreeing. I'm just saying it's not OK to claim "your data and your conclusions must be wrong because they conflict with my religious doctrine", as ID proponents do.

QUOTE (neB @ Apr 15 2008, 09:21 AM)

I think you just did.

Well, maybe I couldn't resist just a *little* comment. Itty bitty. Wafer-thin.

QUOTE

They can only be not-mutually-exclusive in a vaguely Deist sense because otherwise they are inherently contradictory. You just can't have the scientific fossil record and Adam riding a Tyrannosaurus Rex. You can't have Biblical astronomy and the Earth going around the Sun.

Maybe I'm a little over-sensitive because I'm a scientist by training and the stated goal of creationists is to overturn our very ability to do science.

QUOTE (jpdrolet @ Apr 14 2008, 12:09 PM)

Actually the satirical clip is a controversy by itself: some people think it is pro-science and other think it is pro-ID.

Without actually watching the video or getting into the ID-vs-reality debate, I'd just like to point out Poe's Law: "Without a winking smiley or other blatant display of humor, it is impossible to create a parody of Fundamentalism that SOMEONE won't mistake for the real thing."

QUOTE (jaegen @ Apr 4 2008, 12:39 PM)

There's something wonderful about the fact that the link to the http://zone.ni.com/devzone/cda/tut/p/id/6927' target="_blank">"Bug Fixes" page is currently broken. :thumbup:

"If we had access to the bug fix page we could put the broken link to the bug fix page on the bug fix page." Maybe it's just because it's difficult to do recursion in LabVIEW?

(And a cookie to anyone that can identify the obscure, reworded quote.)

QUOTE (Norm Kirchner @ Mar 25 2008, 09:59 AM)

Many of ours may be clean, but after the first flood of pretty ones, I would feel rather....vanilla.

I, for one, would like to see some "vanilla" UIs, if just to get a feel for what more typical VIs look like "in the wild."

QUOTE (Aristos Queue @ Mar 14 2008, 09:47 AM)

I believe the solution in your situation is

a) Make the output terminal be of the Parent class type and

b) do not make that output terminal "dynamic dispatch output".

Would (b) prevent you from overriding the VI in a grandchild class? I should probably know the answer, but I have not had the chance to work with LVOOP as much as I'd like.

QUOTE (7J1L1M @ Mar 11 2008, 09:03 PM)

I don't have LabVIEW 8.x, which would explain the Set File Position :headbang: . Isn't it nearly equivalent to "Seek" in LabVIEW 7.x?

In 7.x, you can use Write File and wire pos mode to 0 and pos offset to the start position for your write. You can also call Seek first, set the start location and use Write File with pos mode set to 2. That will work if you are actually replacing x bytes in your file with x new bytes. If you're changing the number of bytes in the file, you'll have to open the rest of the file to make sure you don't overwrite good data or leave remnants of the old data behind.

QUOTE(george seifert @ Mar 5 2008, 01:47 PM)

I think I see how your sketch works with two circles. The center of the encompassing circle has to lie along the line between the two circles, right? I have three circles that I have to encompass and I'm not sure how your method would work in that case.

Oooh, three circles is much harder. If you want an exact solution, it's not straightforward. It sounds like you're talking about http://mathworld.wolfram.com/ApolloniusProblem.html' target="_blank">Apollonius' Problem.

QUOTE(rpursley @ Mar 5 2008, 12:14 PM)

1. Find Xmin, Ymin, Xmax, Ymax for each smaller circles (Xmin = Xcenter-radius, Ymin=Ycenter-radius, Xmax=Xcenter+radius, Ymax=Ycenter+radius).

2. Use the smallest min values and the largest max values of all of the smaller circles to define a rectangle.

3. Find the center of this rectangle (Ax, Ay). This should be the center of the circle that would encompass all of your circles.

4. Measure the distance from this center (Ax, Ay) to the farthest edge of each circle relative to this point (magnitude of distance from center to center plus radius of each smaller circle.

5. The largest of these measures should be the radius of your encompassing circle.

I think that's close, but not exact. If I understand your description correctly, I don't think the center of that box is guaranteed to be the center of your circle. See attached sketch. Sorry for the poor quality.

I also attached a sketch of what I think will define the minimum containing circle.

QUOTE(normandinf @ Mar 4 2008, 03:22 PM)

The best strategy will indeed be of calculating your way through this. Since you have three circles that represent your mass, you have their centers and radii, I assume.

I don't think normandinf's solution will work, exactly. If you consider the case where R2 is smaller and entirely contained within R1, then the containing circle is obviously centered at (x1,y1) with radius r1. But (xc, yc) != (x1, y1). So you get a circle of the right radius at the wrong location.

If the red and blue circles are indeed known and are actual circles (not thresholded outlines from some measured image, for example), you can also calculate the containing circle directly:

1. Find the line that passes through the centers of both circles.

2. Find the two points where that line passes through the outer edge of the circles. (Did that make sense? There will be four points of intersection with that line, since there are two circles; you want the two that are farthest apart.)

3. Those two points define the diameter of the containing circle.

Easy to do geometrically, but there's some algebra to do for a numerical solution.