eaolson

[Deleted]

QUOTE (Norm Kirchner @ Jul 16 2008, 04:05 PM) Interesting question. I didn't notice this before, but if you just use Open VI Ref with a path to the plugin VI, you won't get an error. If you wire a type specifier to create a strictly typed VI refnum, you do get error 1003 when you try to load the plugin VI. In the first case, you get a valid refnum, but the Callee's Names property does not contain the name of the missing VI. Same with Callee's Paths. In the second case, you do not get a valid refnum, so you can't use the property node. If there is a solution (other than walking through the VI as a binary file and looking for subVIs), I'm stumped.

QUOTE (crelf @ Jun 30 2008, 09:40 AM) Those are very impressive. Any idea how they were actually done? I notice there's a DLL involved. I fear the LabVIEW component is just a wrapper around some low-level window-displaying code.

QUOTE (Michael_Aivaliotis @ Jun 4 2008, 03:23 PM) 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) 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) 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) 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) 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) 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) 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) I'm going to go put that on my resume right now.

QUOTE (TobyD @ May 12 2008, 01:47 PM) 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) 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 It sounds like, if customers would just let me break binary compatibility and not load any existing VIs, this would be easy to implement. (Hint Hint) Unfortunately, it is a non-trivial challenge given 20 years of history, especially since classes aren't yet on all of the platforms that LV supports. It would be hard to tell FPGA "sorry, integers are classes now, so you can't use them". So all platform support for classes has to be a higher priority. 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) 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) 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) 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'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) Well, maybe I couldn't resist just a *little* comment. Itty bitty. Wafer-thin. QUOTE I generally disappoint her attempts at starting a heated debate because I just don't understand why the two view point have to be mutually exclusive. 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) 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) "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) 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) 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) 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.