eaolson

QUOTE(crelf @ Oct 17 2007, 07:26 AM) With the fairly recent addition of OOP, can we call it G++?

QUOTE(Michael_Aivaliotis @ Oct 16 2007, 02:42 PM) I've never been clear about what the "Lite" RTE doesn't do that the full one does do, so always played it safe and used the full one. The NI page says the small version basically only lets you run front panels via a web browser, is there more to it? QUOTE(jpdrolet @ Oct 16 2007, 03:03 PM) The JAVA Run-Time is 119MB... I don't think that's right. The download for the offline Java JRE installer is 13 MB. Even the Developers Kit is only 65 MB. Aren't some of the big patents set to expire very shortly? QUOTE(Val Brown @ Oct 16 2007, 03:04 PM) I don't really buy the cost issue. Yes, a Professional Devlopers package along with SSP (esp Premium level) is not cheap. But how much do you pay for MSDN, Visual Studio, VB, VC/C++, C# as well as the various additional components, 3rd party tools, etc that are involved in designed, building, testing, deploying and maintaining distribution projects/products? For me? Free. Java is free and, if you want an IDE, both Netbeans and Eclipse are free. VB, VC++, VC# all have free Express versions which aren't very limited. (OK, I don't do much with any of these, so I'm not familiar with their limitations so much.)

I've seen a few people here and there talk about LabVIEW and how it could become a general purpose programming language. With some spare time on my hands, I was thinking about that the other day and started to wonder what LabVIEW would need to do to actually become such a language Similarly, but more importantly, what will it take for LabVIEW to be viewed by non-wireworkers as a "real" programming language? I also think it would be great if LabVIEW moved out of its niche. I find it interesting that LabVIEW is used at one end of the spectrum for industrial and technical applications and at the other, very non-technical end, for Mindstorms NXT. But there's not much in the middle. I was actually thinking LabVIEW might make a good to teach beginning programming; it's fairly intuitive, comprehensive GUI widgets are built right in, and the danger of obscure compiler errors is minimal to none. 1. Cost. I hate to be gauche, but this is an important issue. I'm looking for a job now and I've come to realize that, if my job doesn't require me to use LabVIEW, I probably will have to give it up. We have a site license, and I'll lose access to that when I leave. I might pick up the Student Edition or something, but $5000 for a programming language? I'll switch back to VC++ or Java for stuff I fiddle with at home. 2. By reference objects There is just a lot you can do with obkect references that you just can't do with a by-value object. I know it's not exactly fair to be making this complaint when LabVIEW just got by-value objects not long ago. I just think it would go a long way toward LabVIEW being considered a "real" programming language. 3. Better bug support Don't get me wrong, as these things go, NI's dedication to support is fantastic. I wish more companies did half as good a job. And the new Known Issues page and he listing of CARs in the release notes are great. It just seems to me that a major version is released, we get a bugfix version a few months later, then all support for that version ends. I don't like feeling pressured to upgrade every six months or so, just to avoid bugs that crash LabVIEW to the desktop. Especially because each new version introduces bugs of its own. Right now, my main project is locked into 8.20 because I need to remain compatible with a colleague at a different location. I found a crash bug just the other day, reported it, but it's fixed in 8.5, so I'm out of luck. It seems that NI favors the software-as-service paradigm and I understand why that's good for them. As a user, I disike it. It requires me to be dependent on an external factor I have little control over. 4. Executables. It's odd that the whole point of pretty much every other language out there is to create executables that run on non-development machines, but doing the same for LabVIEW requires a $1000 add-on. It makes it difficult to distribute what you've written to non-developers and I suspect that hampers the spread of LabVIEW. Maybe none of this is important and the people that need to know about LabVIEW already know. Maybe NI is content with LabVIEW's niche-ness. Maybe I've just been drinking the LabVIEW Kool-Aid too much and need to get a life, but I'd like to hear what other people think. (What's the best forum for this? It's not really technical and just me bloviating, so I'm sticking it in the Lounge, even though it is LabVIEW related.)

QUOTE(Aristos Queue @ Oct 15 2007, 12:01 PM) I always say I have to get sick every once in a while just to remind myself how bad daytime television is.

QUOTE(dthomson @ Oct 11 2007, 10:53 AM) The angle between two vectors is given by the dot product: X dot Y = magnitude(X) * magnitude(Y) * sin (theta) You have the vectors in polar coordinates, so you should be able to convert to Cartesian and use the above formula, or rewrite it using polar coordinates fairly easily. http://mathworld.wolfram.com/DotProduct.html

QUOTE(Michael_Aivaliotis @ Oct 10 2007, 11:07 PM) Also, the OpenG Sort Array function allows you to sort a 2D array by a particular column. Put your number is the first column, the names in the second, then sort on the second column.

I don't compile a lot of applications to EXEs, but I've been doing some lately and am confused about the .alias and .ini files created by the application builder. Every time I build my app, I get one of each file created in the build directory. The .alias file contains only My Computer <My IP address> and the .ini file contains a lot of VI Server, ActiveX, and web server keys even though I'm not using any of those. The ini file is frustrating because it's cryptic to me (server.tcp.paranoid? why is server.tcp.servic misspelled?) and I imagine even more confusing to an end-user. Now I've discovered that if I delete them both, my program works just fine. The ini file gets recreated empty, but not the aliases file. So if these files are unnecessary, as they appear to be, why create them at all?

QUOTE(Christina Rogers @ Oct 8 2007, 11:08 AM) That very reason is why I've pretty much trained my brain to ignore the icons. It's like the Windows default to hide the file extension; I always want to ask people, "How can you work like this?" Perhaps make it a setting in the Options?

QUOTE(Petersdon @ Oct 8 2007, 05:10 AM) I don't know if the student version has the Picture VIs or not, but you can use Unflatten Pixmap to get a 2D array of pixels. If the image is 24-bit, each value of the array will be the color of the pixel. If it's 8-bit or less, the value in the array will be an index into the colors array, which contains the actual color. There is no "correct" color -> grayscale conversion. The most commonly used one for photos is Y = 0.3*R + 0.59*G + 0.11*B, which emphasizes the information in the green channel.

QUOTE(Aristos Queue @ Oct 7 2007, 03:14 PM) Sorry Tomi, AQ outranks you. Yes, in fact it was a post of yours on a different thread on this very issue. You have an example up somewhere (I forget where) with a dynamic factory example; I figured this was a small enough class that it wasn't worth the effort to go through all that. He has a point. Your method means that the parent has to be aware of its children and that seems a bit inelegant. My original approach was sort of an implementation of the Chain of Responsibility pattern (yes, I've been reading the Gang of Four book again), though because of the way the image data cluster is written, the topmost class still needed to know where to send the data for instantiation, so it didn't really help much. Anyway Tomi, thanks for checking this out and verifying that the error doesn't happen in 8.5.

QUOTE(Tomi Maila @ Oct 5 2007, 05:03 PM) I've attached the whole directory as a zip file. If you open Image Demo.vi by itself, this problem happens (8.2.1), if you open Image Demo.lvproj first, then the Demo, it doesn't. I would appreciate any suggestions.

I am developing a library of classes. The classes are all in a lvlib, the library is in a project, and the project also has a small test VI, which uses the library. If I open the test VI from the project, everything is fine. If I open the VI on its own, running it gives this error in a popup window: The LabVIEW class is not in memory. The dynamic subVI cannot execute. Probe the wire going into the dynamic terminal to see the data type." The problem seems to occur when the dataflow enters into a dynamic dispatch VI. Shouldn't the classes be loaded when the calling VI is loaded? (Crossposted from the NI forums.)

I really hope the title of this thread was supposed to be "question about llb and ctrl + shift+ Run"...

QUOTE(TobyD @ Oct 2 2007, 03:01 PM) The problem here is that there is no such thing as "extended ASCII." ASCII is a fairly well-defined standard that defines the association of characters for the numbers 0-127 (7-bit). Everyone is in agreement that 97 means an "a". When you extend this to 8-bits, the numbers 128 and above are not as well agreed upon. Depending on what character encoding you're using, the glyphs displayed for 128-255 will be different. The underlying number is still the same. My installation of Windows seems to be using Windows-1252, where the high byte characters are primarily accented letters. DOS used code page 437, where the high byte characters are the box-drawing characters without with Nethack would not be possible. So you can write high-byte characters to a file with the usual file VIs, but they will only display as the box-drawing glyphs in certain situations.

QUOTE(BrokenArrow @ Oct 2 2007, 11:13 AM) You can write the extended characters just as you would a normal character. The problem might be that Windows and DOS use different character encodings. If you have a file containing extended characters and open it with Notepad, you'll see lots of vowels with umlauts and accents. If you open the same file in a DOS window, you see the box-drawing characters. Character 203 (0xCB) is a capital E with an umlaut in Windows, but displays as a double-walled box character in DOS. You can use a string constant with the slash display or hex display to get to the extended characters without worrying about how they are displayed in LabVIEW.

QUOTE(yen @ Sep 27 2007, 01:07 PM) I've already done so. In fact, I included a link to this thread.

QUOTE(Kevin P @ Sep 26 2007, 02:21 PM) Yes, that works, but only if the loop adds the same number of elements each time. It wouldn't work for this (pardon for not doing this in LV): array a = {}; for (i = 1; i &lt;= 3; i++) { for (j = 1; j &lt;= i; j++) { append j to a; } } This creates the array, a = {1, 1, 2, 1, 2, 3}.

The addition of auto-indexing to While and For loops was great. Sometimes, however, I have multiple nested loops and auto-indexing makes a 2D or 3D array, which is not necessarily what I want. It would be nice to have an auto-indexing tunnel that has a "auto-append" option rather than only the default "build array" behavior. Much like how the Build Array function has the "Concatinate Inputs" option. I guess this really makes the most sense for 1D arrays.

There's another KB article which offers a few suggestions. There's also a software buffer, I think. Have you tried increasing the size of that with VISA Set I/O Buffer Size? I've also had trouble with one USB-to-serial adapter. What brand are you using?

This is a possibly crazy idea, and I've never tried it, but can you put a SVN repository inside an SVN repository? While you're away, you check out a repository and use that, then check it in when you get back.

QUOTE(jdebuhr @ Sep 20 2007, 08:02 AM) My initial thought: when the button goes down, put a reference to it in a shift register. In the timeout case (5 s), put the code to reset the numeric if the shift register contains a valid reference. In the mouse up case, invalidate the reference in the shift register. You'll also want to check when the mouse up happens after the numeric is reset that you don't increment it.

All my computers at this point are single-core because they are either (a) in my lab where they are a bit old or (b) at home where I am a bit poor, so I have not had the chance to do anything with the multicore capabilities of LV. I'm just wondering, how much effort is it to take advantage of this? Can I expect to just drop any old VI on a multicore computer and see a significant increase in speed, or would it have to be carefully optimized for multicore execution?

QUOTE(Jim Kring @ Sep 17 2007, 10:53 AM) I'll see your 20:1 and raise you to 200:1. http://www.google.com/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=lSy&q=%22Thank+you+for+suggestions.+So+far+I+found+freedback+and+this+free%22&btnG=Search' target="_blank">Google knows all. A poster asks a question, then comes back several days later with an ad for that site. The questions are different, but the answer posts are verbatim identical. Wow, spammers are getting really sneaky.

QUOTE(Justin Goeres @ Sep 12 2007, 08:17 AM) I believe I can authoritatively say no, you weren't the last. Now, am *I* the last person in the world to learn this? For some reason, I knew you could wire the N terminal inside a For loop, but doing it in the case of an auto-indexed loop never occurred to me.

QUOTE(yen @ Sep 1 2007, 03:00 PM) 1. Art was not one of my best classes, so I'm not so great at making icons. I'll try to come up with some way of differentiating them. My idea, though, was that you'd just use the methods from the Image class and it would dynamic dispatch to the correct child method, so you'd never need to see the icons for the subclasses. 2. No I didn't save it on a different drive and it gives me that notice, too. I'm not sure why. I actually made a source distribution in the project file I'm using to aggregate all the VIs to one folder, so I suspect it has something to do with that.