eaolson

QUOTE(george seifert @ Dec 10 2007, 01:30 PM) Have you tried fiddling with the Interpolation Type option in IMAQ Resample? Zero Order is the default and will be the fastest, but will also be the worst. Bi-linear and Cubic may give you better results, but will be slower.

QUOTE(Stevio @ Dec 10 2007, 09:19 AM) Numerical derivatives are often very noisy. Your best bet might be to use some sort of peak detection. The locations of the peaks would give you your frequency. Rise time might be a bit more tricky, since looking at your data, I'm not even sure how to define the start of each pulse.

QUOTE(Aristos Queue @ Dec 4 2007, 05:49 PM) Yes, but tell us how you really feel.

QUOTE(Michael_Aivaliotis @ Nov 21 2007, 03:44 PM) 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) 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) 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) 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 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) 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) 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) 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) 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) 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'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) 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) 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) 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) Ah, I had the first, but not the second. That did the trick. Thanks.

QUOTE(Norm Kirchner @ Oct 29 2007, 10:18 AM) 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) 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 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.