eaolson

QUOTE(Michael_Aivaliotis @ Nov 21 2007, 03:44 PM)

Whoever at NI told you it's not a bug was probably smokin' the good stuff . I can reproduce it even with a blank new VI with a while loop and not using the "Dynamically Register for Events.vi"

I haven't quite nailed this down yet, but I think that's because the problem is actually happening inside Dynamically Monitor VI's. That keeps an array of running VIs and registers the Panel Close event for each one. I'll try and look into this more this weekend. (Over the holiday, does that make me a geek?)

For even more fun and excitement, there's this odd chain of events, too:

1. Open Dynimically Monitor VI's, Dynamically Register for Events, and Wait for Events (which is a subVI of Dynamically Monitor VI's).

2. Open the Wait for Events block diagram.

3. Run Dynamically Monitor VIs and Dynamically Register for Events

4. Turn on execution highlighting in Wait for Events.

5. As before, close Dynamically Register for Events with the X in the window corner

6. Wait for Events will process all the events it's supposed to, but LabVIEW won't crash.

7. Again, open Dynamically Register for Events. The program will open and you'll notice that the Run button indicates that it's already running! LabVIEW will then crash.

QUOTE(Michael_Aivaliotis @ Nov 21 2007, 03:44 PM)

Whoever at NI told you it's not a bug was probably smokin' the good stuff . I can reproduce it even with a blank new VI with a while loop and not using the "Dynamically Register for Events.vi"

I haven't quite nailed this down yet, but I think that's because the problem is actually happening inside Dynamically Monitor VI's. That keeps an array of running VIs and registers the Panel Close event for each one. I'll try and look into this more this weekend. (Over the holiday, does that make me a geek?)

For even more fun and excitement, there's this odd chain of events, too:

1. Open Dynimically Monitor VI's, Dynamically Register for Events, and Wait for Events (which is a subVI of Dynamically Monitor VI's).

2. Open the Wait for Events block diagram.

3. Run Dynamically Monitor VIs and Dynamically Register for Events

4. Turn on execution highlighting in Wait for Events.

5. As before, close Dynamically Register for Events with the X in the window corner

6. Wait for Events will process all the events it's supposed to, but LabVIEW won't crash.

7. Again, open Dynamically Register for Events. The program will open and you'll notice that the Run button indicates that it's already running! LabVIEW will then crash.

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

I was brushing up on my events and discovered this interesting crash using two of the NI-provided examples:

1. Open <labview>\examples\general\dynamicevents.llb\Dynamically Monitor VI's.vi.

2. Run the VI.

3. Open <labview>\examples\general\dynamicevents.llb\Dynamically Register for Events.vi

4. Run the VI.

5. Do not stop the "Dynamically Register" VI. Instead, close it by clicking the "X" in the upper right corner of the window. A dialog window will pop up asking "Do you really want to close 'Dynamically Register for Events VI'?". Click "Yup".

6. Stop the Dynamically Monitor VI by either using the Stop button on the front panel or the Abort Execution button.

7. LabVIEW will crash with a "LabVIEW.exe has generated errors and will be closed by Windows" window.

I've observed this on 8.20 running under Windows 2000 and XP. Can anyone verify that it does happen on 8.5? I haven't really figured out where it happening, but it's probably at either a property node or a Register for Events node.

I also reported it to NI, but they don't seem to consider it a bug. It's not fair, but I'm not sure I agree. An attempt to access a VI not in memory seems to me should fail out with an error, not a crash to the desktop.

QUOTE(carlover @ Nov 15 2007, 11:11 AM)

Why use of shift registers for initial time "stamp" (are there any performance benefits, or...?). If you just connect initial seconds count to the while loop boundary every time loop iterates it will get same value; that would eliminate need to carry "non-changing" variable through the loop and shift registers. or am I missing something?

What you suggest would give you the total time elapsed in the loop. The way it's written now gives you the elapsed time of each iteration of the loop.

QUOTE(Yuri33 @ Nov 13 2007, 01:59 AM)

32x32 seems big enough for me. In fact, most of my simple (get/set) functional globals are only 9x32. Do you really want a bunch of local-variable sized globals, especially when they become quite large if the data name is long?

I really just meant we have the canonical kind of global which is short and long with the little globe icon, and the functional global which is no more than 32x32, even if that's not the best form factor for that particlar global.

QUOTE(hooovahh @ Nov 13 2007, 08:13 AM)

I don't know about any one else's situation, but if I develop code for money I no longer own the code. The code can be distributed by the people who own the code, the people who paid me to develop it. And since I no longer own it, I can't post it on some community based site (like this lovely one)

I imagine that's because you're doing it as an agent of the company or as a contractor and that's what your contract specifies. I think of writers in Hollywood as similar to songwriters. Singers come along and perform their works and sell the recording. The songwriter gets a cut of that because his creative work is a large fraction of the whole.

I think a lot of new TV shows happen because some writer sits down, comes up with an idea, and writes a script. That script then gets pitched to a studio, who licenses the idea for filming. It's not a straight up work-for-hire that a lot of programming is.

QUOTE(Aristos Queue @ Nov 12 2007, 07:28 PM)

As far as the writers are concerned, if you transmit the show over the Internet, that's no different than a broadcast over airwaves or cable or purchase on DVD.

I'd also like to point out that in the mid 80's the writers agreed to a temporary 80% reduction in their royalties for VHS sales, in order to boost the feasibility of the infant medium. The "temporary" in that turned out to be not so temporary, and lasts to this day.

There's a little video I've seen that has an explanation of the whole thing (told from the writer's perspective). As I have no idea how to embed a YouTube video, http://www.youtube.com/watch?v=oJ55Ir2jCxk' target="_blank">here's the link.

jdunham has some interesting suggestions for icon conventions when working with classes. I was wondering if anyone had any other conventions they use for icons.

I'll admit, I rarely bother with graphic icons for VIs. I'm no artist, so they always take me forever and wind up only looking like the thing you're supposed to look like if you squint and use your imagination. And let's face it, 32x32 pixels isn't a lot of space. It seems to be fairly common to use a text title in the top 6 pixels or so, with a text description in the rest.

I've also started using a couple of other conventions. It would be nice to be able to make a functional global the same shape and size as a regular global structure, but we can't. So I've been putting a little globe icon in the upper left corner of an icon to show it's a global. (See attached FG.png.)

I've also had a large application that spawned a handful of while loops, each being a separate thread, communicating with notifiers and queues. That many while loops made the block diagram large and confusing, so I stuck each one in its own subVI. But that means now I've got multiple blocking VIs. So each one of those got a little while loop in the corner. (See while.png)

Does anyone else have any conventions they use for icon design?

QUOTE(crelf @ Nov 7 2007, 01:11 PM)

Now that I've got your attention: no, this isn't an OO question. Consider a VI that has a required input. If I then drop that VI (child) into another VI (parent), create a control that wires into the required input of the subVI and then put that control on the parent's connector pane, should the parent's connector pane node become required?

I would say no. There are plenty of cases where the parent VI could put an acceptable default for the control, which didn't need to be wired. Take VISA Configure Serial Port as an example. (That VI uses a property node, which can basically be treaded as a subVI with required inputs.) The Configure VI has many default values which usually don't need to be changed.

QUOTE(Rimmergogo @ Nov 7 2007, 08:52 AM)

When a picture has a resolution of about 320 X 240 the 3D surface graph is resonable quick but when the image is too large the 3D surface graph becomes unreasenable slow.

I managed to downsize the image resolution. In combination with a zoom function I'm able to see all the pixel data if necessary. But then again when the images become too large (>1280*1024) the methode it self becomes unreasenable slow.

I'm not entirely clear on what you're doing with regards to 2D and 3D images, but if you have Vision, there's IMAQ Resample to change the size of an image, with different interpolation methods available. Also for a 2D image, a quick and dirty way to resize it might be to throw away every other pixel before displaying it. Inelegant, but fast.

QUOTE(menghuihantang @ Nov 2 2007, 08:33 AM)

The neighbors I mentioned here refer to those foreground pixels, which are part of an object.or put it in a simple way, the neighbors with a value 1

I don't know a built-in function for that (but have only lightly ever used Vision), but couldn't you just do a correlation with a matrix like:

1 1 1 1 0 1 1 1 1

QUOTE(menghuihantang @ Nov 1 2007, 11:22 AM)

And another function which can return the numbers of neighbors for each pixel seems also unavailable in LavVIEW.

What you mean here really isn't clear. On a 2D grid, any pixel has eight neighbors.

QUOTE(Justin Goeres @ Oct 31 2007, 03:54 PM)

I propose Scripting Fight. A reference to a blank VI is passed to two different VIs running in parallel. These two VIs (each written by a different individual) should compete to accomplish some block diagram goal while preventing the other VI from accomplishing the same goal. The "winner" is the VI that, after a certain time period or number of nodes, is closer to the goal by some metric (functionality, aesthetics, etc.).

I've never played it, but that really reminds me of http://en.wikipedia.org/wiki/Core_wars' target="_blank">Core Wars.

QUOTE(RodolfoAcialdi @ Oct 31 2007, 01:32 PM)

So, to get the correct reading from the A/D i must joint these two parts of the A/D register into a 12 bit word. Does anybody have an idea for this?

From serial communication, you will get bytes. LabVIEW doesn't have 12-bit data types, so you will have to store the results in at least a 16-bit integer. Look under the Data Manipulation sub-pallette, under the Numeric Pallette for the VIs you'll need, most specifically Join Numbers. Depending on how your data is transmitted, you may also need Logical Shift or Swap Bytes.

If your data is unsigned, you don't care about the highest 4 bits of the result. Be careful if your result is supposed to be signed, that can be trickier.

QUOTE(Jim Kring @ Oct 30 2007, 04:42 PM)

Actually, that's not true, in this case. Since these VIs are members of seperate classes/libraries, their names are scoped/prefixed with the class name. So, it's perfectly fine to have them in memory together. They simply cannot be stored in the same folder (or inside the same LLB/EXE) on disk. This is the heart of the problem. LabVIEW starts the build process, but fails to detect that there will be a name collision on disk, during the build. The build progresses and then fails.

Oh, that's right, I forgot about class/library namespace. I'll just go sit in a corner and be quiet now...

QUOTE(Jim Kring @ Oct 29 2007, 08:42 PM)

I believe that the algorithm that LabVIEW uses to detect and avoid VI name collisions, prior to the build, is case sensitive and not catching the fact that "MyMethod.vi" and "mymethod.vi" cannot occupy the same location on disk (on MS Windows, at least).

This is also true for two regular VIs, at least in my 8.20 version, application builder and LVOOP notwithstanding. (I'm not sure if that's what you meant in this sentence or not.) If MYVI.vi is open, you can't open myvi.vi.

QUOTE(dannyt @ Oct 29 2007, 11:30 AM)

SuperPrivateScriptingFeatureVisible=True and SuperSecretPrivateSpecialStuff=True to my 8.2.1 labview.ini file as talked about http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">here

Ah, I had the first, but not the second. That did the trick. Thanks.

QUOTE(Norm Kirchner @ Oct 29 2007, 10:18 AM)

Boy oh boy!! you hit on one of my favorite hacks!

I can't replicate this; those properties don't seem to exist for me. I thought maybe I hadn't turned on scripting for my 8.2 version, but can't find much information on that. Some tidbits in the forums suggest it now requires a separate license from NI and is now denied to us lowly mortals? The wiki article is just a stub.

QUOTE(Justin Goeres @ Oct 18 2007, 10:22 PM)

...or an MP3-playing app with playlist management...

Darn you for starting me thinking about that. But then it occured to me, is such a thing really possible? Looking under the Sounds pallette, there seems to be a function to play a WAV file, but not an MP3. I guess you could decompress an MP3 to a temporary WAV and play that, but that seems inefficient.

I am developing a small app that needs to run in a room kept as dark as possible. So we sometimes use the Windows "High Contrast" display theme, which sets the window background color to black. Some LabVIEW dialog boxes (e.g. the "Build Status" window when building an EXE) default to the system color for the window background, but just black for the text. This resulted in black-on-black, unreadable text when using that theme.

Kudos to the application engineer for looking for and finding other cases where this was happening, rather than just fixing the one case I found.

Found in 8.20, but I believe this exists in 8.5 as well.

QUOTE(Justin Goeres @ Oct 16 2007, 11:08 PM)

I don't think LabVIEW will ever be "free" (beer or speech), and FWIW I don't think it necessarily ever needs to be. But the fact is that you can learn a tremendous amount of C/C++/Java/PHP/Perl/god-knows-what-else without shelling out any extra money^*. For LabVIEW, the barrier to entry starts in the http://sine.ni.com/nips/cds/view/p/lang/en/nid/1385' target="_blank">$1200 range and goes up from there. For those of us who use it as a professional tool, the value is apparent. But for the kind of people who should be being taught to think in G (to coin a phrase), that's a gigantic difference.

I can't agree more. I imagine one of the big fish in the programming game is Visual Studio, which pretty much maxes out with the Professional version for $670, a factor of 2 cheaper than LabVIEW's starting version. The Standard version is $250. Some LabVIEW versions are an order of magnitude more expensive than that.

I didn't go to NI Week, but thanks to the videos and pictures posted here, I saw some of it. Didn't one of the presentations from NI have something to do with specializing in niche products, basically selling fewer units at I assume a higher price? Maybe NI is content with LabVIEW having the market that it does, and the niche that it does. That's up to them. It's their ball and they can take it and go home if they want. I'm just saying that from my point of view as a user, I think LabVIEW has wide applications and I think it would be great if it got more play.

QUOTE(crelf @ Oct 17 2007, 07:26 AM)

I agree, but "G" is already a registered trademark of someone elses...

With the fairly recent addition of OOP, can we call it G++?

QUOTE(Michael_Aivaliotis @ Oct 16 2007, 02:42 PM)

I prefer at least to always remind everyone that the 24MB run-time works just fine thank you.

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)

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)

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.)