Gary Rubin

QUOTE (Gary Rubin @ Mar 20 2009, 12:59 PM) Some benchmarking showed that queues were faster. QUOTE (Gary Rubin @ Mar 20 2009, 12:59 PM) Are there queue (or other) performance issues that I might be able to point to? Thanks to those who provided some "ammunition".

QUOTE (jdunham @ Mar 20 2009, 02:39 PM) Queue size changes because the rate at which data is coming in is not constant, and we don't have the luxury of waiting until a queue (buffer) reaches a certain size.

QUOTE (jdunham @ Mar 20 2009, 01:43 PM) That assumption was based on the following from the Obtain Queue help: Note max queue size only limits the number of elements in the queue. It does not preallocate memory. Therefore, resizable data types such as paths, strings, arrays, and so on can still increase and decrease the overall queue size QUOTE (jdunham @ Mar 20 2009, 01:43 PM) So is there a performance problem? You probably shouldn't be worrying about performance unless there is a real problem. This is a system that has to keep up with real-time data flow. The faster the code is, the higher a data rate it can keep up with. There's always need for more performance. QUOTE (jdunham @ Mar 20 2009, 01:43 PM) Now the cost of LabVIEW is a few thousand dollars, which is just a couple percent of the yearly cost of employing an engineer in the US. It's hard to have sympathy for a company that doesn't want to spend an appropriate amount of money on LabVIEW. You'll have to forgive me if I made assumptions about the situation at your workplace, I realize I may be off-base, and there could be real reasons for not wanting to spend money to keep the tools current. This is a project that's been going on for the past 6 years or so. It is in LV7.1.1 because that was the latest and greatest when we started (we might have even transitioned the project from 6, I don't remember). There has been a lot of time spent on code development and fine-tuning, and everyone is finally pretty convinced that it's doing what it's supposed to. Our prime doesn't understand why they should have to fork over several additional $k just for the latest version of the development environment when it won't change the code, operation, or anything else a user might care about. Furthermore, the end-user customer might want to be re-convinced that everything still works after the configuration change (i.e. upgrade from 7.1.1 to 8.6). That is both a time-consuming and expensive endeavor.

I'm sure I've read something related to this, but struck out using the lavag search. I apologize if this is a rehash of something that's already been covered. We have an application in LabVIEW 7.1 in which we're using queues to pass data between parallel loops. Because there are memory allocations associated with enqueueing (and presumably deallocations for flushing?), would it be better from a performance standpoint to use an LV2 Global containing a preallocated array? Also, I seem to recall that there had been some improvement in how queues are implemented in LabVIEW 8.x. I've been trying to get us to upgrade, but nobody seems to want to spend the $$. Are there queue (or other) performance issues that I might be able to point to? Thanks, Gary

QUOTE (zmarcoz @ Mar 17 2009, 10:48 AM) Speaking as a non-software engineer, my feeling is that Software Engineering is a discipline, just like mechanical or electrical engineering. It shouldn't be confused with software development, any more than a carpenter should be confused with an architect, or an electrician confused with an EE. As EEs, physicists, MEs, or whatever else most of the people on this board are, we all have lots of experience doing software development. We might even be really good at coding, algorithm development and implementation, etc., but that doesn't make us qualified to act as a Software Engineer.

QUOTE (TobyD @ Mar 11 2009, 10:03 AM) They're also beneficial for those of us who are not running the latest version of LabVIEW.

QUOTE (Darren @ Mar 5 2009, 11:43 AM) Then you have better penmanship than I do. Is it really a hijack if I'm helping hijack my own thread?

QUOTE (dannyt @ Mar 5 2009, 08:23 AM) If I had a scanner handy, I could show you. Think of a 'Z' with a strikethrough, like this: Z

QUOTE (HOLY @ Mar 5 2009, 04:17 AM) He's baa-aack.

QUOTE (Darren @ Mar 5 2009, 12:47 AM) You don't? How do you differentiate between z's and 2's? I started putting lines through my z's in college, when I started to have trouble interpreting my physics equations.

QUOTE (crelf @ Mar 3 2009, 02:44 PM) It looks like that Unit Test Framework is along the lines of Polyspace. Thanks, Gary

Dannyt, Thanks for the links. We'll have to find out what our partner expected to get out of Polyspace and see which of the LabVIEW tools might do something similar. Gary

A partner of ours just suggested running Polyspace on some of our code. I'm not sure they understood that the code is written in LabVIEW. Does anyone know of a similar code-checker for LabVIEW code? CRelf, does one of your products do that? Gary

QUOTE (crelf @ Mar 2 2009, 09:38 AM) I'm having trouble seeing the PXI chassis built into the keg... Without one, how do you program it?

Plotting of large intensity or X-Y datasets.

Since bsvingen brought up Matlab and LabVIEW, I thought I'd add my two cents. Lately, I've found that I've been quicker to open Matlab than LabVIEW for a lot of my tasks. I still prefer LabVIEW for anything that has to interface with hardware (whether NI or third-party). For other things I find Matlab much easier to deal with. This thread has caused me to try to take a step back and think about what has led me to that preference. 1) Data presentation: I find that Matlab's plotting capabilities are much stronger and easier to use than LabVIEW's. 2) Expandability/feature creep: Lately, I've been primarily writing code to assist me in performing data analysis. In those cases, my product is not the code or the GUI, but the analysis and conclusions I can generate using the code as a tool. For this reason, it can be very difficult to define a priori exactly what the code has to accomplish. My processing/code-development effort might sound something like this: "Show me A vs. Time, B vs. Time, and A vs. B. Hmm.... That's interesting - now what if I perform operation X on A, then plot A vs. C", etc. A text-based language like Matlab makes it very quick and easy to throw an extra operation in between two existing steps. Attempting to do the same thing quickly in LabVIEW tends to cause spaghetti. 3) Toolboxes, etc.: I occasionally do georeferencing of data to match it up with terrain or overhead pictures. Matlab has a Mapping Toolbox, LabVIEW does not. Matlab also has a large community of people who share their code. I have not yet found a Matlab forum or community that is as strong as LAVA in terms of answering questions or having the type of discussion we're having now, but there do seem to be a lot more people sharing their work (~9000 files in Matlab Central's file exchange vs. 74 in the CR here). A lot of that is probably cultural and is quite understandable - if LabVIEW is more heavily used in industry or by consultants/contractors, then of course people aren't going to be quite so willing to give away their work for free. 4) Backward compatibility: This is related to my previous item, and to the "openness" that others have discussed. Because I'm still using LabVIEW 7.1.1, I can't even open a lot of the files that people have posted here. At least with Matlab and other text-based languages, I can still look at the code. Let the flames begin... Gary P.S. bsvingen, good to see you back here. Occasionally I've stumbled across our conversations about execution speed from a couple years ago and wondered if you'd disappeared.

QUOTE (zmarcoz @ Jan 21 2009, 03:44 PM) If your school was anything like my school, the career department probably did not have enough technical background or understanding to help science/engineering majors.

QUOTE (crelf @ Jan 13 2009, 04:23 PM) Must have been good coffee that day, Chris.

QUOTE (gareth123 @ Jan 19 2009, 02:09 AM) Choosing which loop is appropriate for a given situation is the same as any other language. Descriptions of loops can be found here and here. Use the LabVIEW example finder under the Help pulldown (at least I assume that's where it is in newer versions) to find examples.

QUOTE (TobyD @ Jan 14 2009, 02:34 PM) Trees also seem to be pretty common for that kind of thing (i.e. Matlab's Preference screen): http://lavag.org/old_files/monthly_01_2009/post-4344-1231962858.gif' target="_blank">

QUOTE (TobyD @ Jan 14 2009, 02:34 PM) Trees also seem to be pretty common for that kind of thing (i.e. Matlab's Preference screen): http://lavag.org/old_files/monthly_01_2009/post-4344-1231962858.gif' target="_blank">

QUOTE (george seifert @ Jan 14 2009, 09:32 AM) I agree with George. I don't like the fact that the tabs move around.

QUOTE (VoltVision @ Jan 7 2009, 04:57 PM) Not certain, but I think you're describing a Kalman filter.

QUOTE (Yair @ Jan 7 2009, 02:37 PM) I'm still using version 7.1. I don't know if this has changed with later versions or not, but a "waveform graph" in 7.1 does not imply the use of a waveform data type. I never use dynamic or waveform data types either. I figure those both represent a layer of overhead that is totally unnecessary.

QUOTE (Yair @ Jan 7 2009, 01:48 PM) You don't?! How do you look at your data?