Neville D

The last bit of the data seems to be trailing off to 0. That might be the problem. Neville.

<rant> I wish NI would update that OOOOOOLD junky App Note. It doesn't cover a whole host of issues related with modern PC hardware and even LabVIEW improvements. Hyperthreading is pretty irrelevant with dual and multicore processors now out. Things not covered: 1 How to put two instances of the same VI on the BD on different threads (so they don't interfere). 2 Timed loops (like someone mentioned earlier) and how best to use those with multi-threading. 3 Using multi-threading on LabVIEW RT.. (I know, RT doesn't support it yet, but its about time NI got around to supporting multi-core on RT) 4 Multi-threading specifice types of applications especially vision, DAQ, (or even TCP communication). 5 What tools to use to debug applications (Execution Trace Toolkit? Does it work for RT?) 6 Multi-threading implications for DAQmx if any. I just find with each new release, the documentation just seems to get worse.. no pdf's, no labview manuals, just terse "help" files which are no "help". <end rant> Neville.

It depends on the size/complexity of your application, but when building the exe, the diagrams are removed, "debug" mode on the VI's is disabled, and only the front panels of top-level VI's are saved. This results in a smaller memory footprint and a slightly better speed... I would hazard a guess of about 5% improvement. By the way, the app builder is part of the Pro versions of LV, which also throw in a lot of (mostly useless) toolkits. It might make sense to upgrade to a Pro version instead of spending an additional $1000 or so for the app builder. Try disabling debug mode on your VI's, saving all them and running to see what sort of speed increase you obtain. Make sure you are not using any property nodes in the fft loop part of the code. Property nodes cause a thread-switch to the UI thread, and slows things down. Also avoid any graphical updates until all the calculations are done (the "defer panel updates" property is pretty useful here). You could also play around with multi-threading, priorities, re-entrancy, and code parallelism to speed things up further, but that is a topic for another day! PS. Posting code is a good way to generate a higher quality discussion. Neville.

Just a few comments: 1 Which version of LV are you using? I think Version 7.1 or so there was a major re-write of the math functions. 2 Make sure you don't have any coercion dots (data type conversion) into and out of your FFT routines. This will slow things down. 3 For best speed even with newer hardware, desktop version of the processor is faster than laptop. I have a Dell Inspiron 9400 laptop, and a Dell Dimension 9200 desktop; the desktop is much faster than the laptop. 4 A built application (exe) will give you slightly better speed than the code. Neville.

Moral of the story: Stick to NI Hardware; the few bucks you save using "other" hardware isn't worth it in the long run. Cheers, Neville.

Ben, use a Combo-Box control found in the String Controls subpallet. This allows output of strings as well. Also, as Chris pointed out, use an event structure to change camera properties. Writing properties every time to the camera will definitely bog things down. You can look at the IMAQ examples where they have the same idea going, except that they look at the value of the control. If its "changed" (compared to its prev value frm a shift register), then the control property is written to. This is a bit cruder way of doing things, but works even when you are using the code with LabVIEW RT (which doesn't support the event structure). Sorry, I cant modify your VI, I have LV 8.2, Imaq 3.x on my PC. Neville.

Well Hannibal, if it really is a "problem" for you, take a look at this link: How to ask Questions the smart way People are more than willing to help each other on this forum. But if you want help, explain your application, post some code, show us what you have already tried before posting a question here. Another good place for help is the Examples that already ship with LabVIEW. Neville.

That is the "delete from Array" function in the array pallet. It can delete an element given its index (the 1st instance with index set to 0), OR the default is quite useful behaviour: if no index is given, it deletes the last element in the array (the 2nd instance of this function in my code). The "Add array elements" function is in a somewhat non-intuitive place in the Numeric subpallet. (You would think it should be included in the array subpallet). Just use the search tool on your pallets, and type in the name of the function.. it will take you directly to where the function is in your pallet. Neville.

Seems like a to me..!! Neville.

I think the main issue here is the "multiple re-entrant" VI's. Using notifiers of the same type from multiple VI's causes problems. See notifier signals missed for a recent LOONG discussion on an "issue" (note I didn't say bug!) with multiple notifiers of the same type. As explained by Aristos Q: due to some performance related reasons, you are likely to miss some notifiers. You are better off using even a single elem Q as opposed to a notifier in such a case (a notifier is a lossy single element Q anyway...) Neville.

Why don't you just use the lower-level VI as the top-level VI? From the block diagram of the PlateMotor.vi, it doesn't look like its doing anything special; add the stop functions to the end of the lower level VI. Another approach is to use sub-panels to display the lower level VI in the Main VI's window. That way you have complete control of the subVI's front panel controls AND you can view its indicators. here is a picture from my code, of how you can load a subpanel of MY SUBVI.vi: -------------Later Edit-------------------- Sorry, just re-read your post.. subPanels will NOT work with re-entrant VI's. You could try: 1 writing your indicator values to a regular global, and reading the global in the top-level VI. 2 same approach but with a buffered shared variable so as not to lose data. 3 slightly more complicated but in the same vein: use a Q to write data in the lower-leve VI, and read the Q from the top-level VI. Neville.

I seem to remember reading somewhere that the file write functions now (LV 8.2 ?) automatically take care of the 512 byte chunking before writing to file.. maybe that is contributing to a more efficienct file read and write. Neville.

Your welcome. Sorry, I am NOT going to post the VI. You can easily replicate the diagram on your side. After all, you do have to do SOME work to get your Master's degree! Neville.

Malef is absolutely right about the comment on integration. Earlier VI\'s seemed to be just accumulating values instead of adding up the area under the curve. Here is a picture of a VI that performs Numeric Integration using the Trapezoidal Rule. It assumes that dt (time spacing between each value in the waveform) is constant. Or this is slightly more elegant: Neville.

One way to remove dc-offset, is to calculate the mean of the waveform and subtract it from the waveform (since your signal is sinusoidal). To remove higher frequency components, use the built-in VI's under signal processing pallet. A 5-pole butterworth filter with a low pass response of about 1kHz should do the trick. If you are doing the processing real-time i.e., point by point as the signal is acquired, then use the equivalent point-by-point filter function. You can use the Array Max Min function on the Array subpallet to determine your min and max acceleration values. For the vertical acceleration, measure g without vertical acceleration at start, and subtract this static value for every measurement thereafter. A proper description of your hardware and software (with attached VI's) would really help in trouble-shooting your issues. Are you using smart sensors (TEDS) ? Maybe there is a way to already set up the 1g subtraction automatically. Neville.

See this thread on the NI Forums: USB IMAQ & problems Also, a low-cost solution might be Irene He's IVISION tool-kit. Neville.

No, IMAQ VI's need a run-time licence as well.. but I am not sure about the USB VI's. Neville.

Compact FieldPoint is a more rugged form factor than the original FieldPoint (that has problems with vibration). I would also recommend getting additional memory (atleast 512MB) for your FP system. Also, a quick call/visit from your local NI Rep will save you loads of time in selecting all the components you need for you system. He/She can also explain the benefits/disadvantages of each platform. For example, Compact RIO doesn't at all seem like the right choice for your application if you don't need the high speed FPGA capability, some modules are only available in one form factor etc. etc. Neville.

I'm not sure specifically about IMAQ USB VI's, but for all other IMAQ VI's you need to buy a run-time licence and install the IMAQ run-time separately for your exe to work. Neville.

Hi, looking at your vi's there are a number of errors: 1 If you are looking to find the 2 peaks in your data, the input to the detect triggers should be 2 (instead of default of 1). 2 The dt input to the integration vi is the spacing between consecutive pts in your data array. It is NOT the spacing between the 2 peaks in your data. 3 For trivial operations like abs(x1-x2), avoid usage of the express Vi for performance reasons. Besides the above 3 issues, I am not sure what you are trying to integrate. If you want to integrate the area under BOTH peaks, then your VI won't work, since you are detecting the 1st peak correctly (rising edge), but the second peak is NOT included in the data, since you actually need to detect falling edge for the second peak (see my screen shot of your front panel). You should change your trigger detect algorithm, to separately find the pts in time for the 2 peaks, and then use the rest of your VI. One way, is to reverse the data array and find first rising edge; this should give you the falling edge of the second peak. Neville. Download File:post-2680-1167245490.llb

Hi Dave, Why re-invent the wheel? You can use the Read/write to XML file VI's to automatically read/write any LabVIEW structure to file. I know, I know, people complain it isn't "human readable".. but I really don't understand how text readable you could make a complicated LV structure (cluster of Cluster of arrays of enums for example) without a picture. The OpenG VI's (when I last tried them) had some issues with LV 8.0 and a complicated structure with type-def'd enums. The exact same VI's worked fine with LV 7.1.x. Don't know if they are fixed, but once I moved to the xml format, I haven't looked back to ini files again. Neville.

Hi Tom, Core Duo would probably be a better bet. It is based on the Pentium M processor that has better performance at lower clock rates due to larger on-chip cache. The Core Duo PXI controller doesn't come with RT (yet), since RT doesn't suppose multi-core (yet). You might even look at some of the AMD processor-based desktops to convert to an RT platform. I think the fastest PXI RT controller is the PXI 8196 (2 Gig Pentium M). But Processor aside, you could probably get better performance by replacing traditional DAQ with DAQmx. The new architecture is multi-threaded, and non-blocking. I am sure you would see enough performance improvement to leave your current hardware platform alone. Neville.

Do a websearch for Scott Hannah's Serial Server routines in LabVIEW. They are an example of well-written code that can read/write serial data. Any other improvements really depend on your application. Are you JUST reading and writing? Do you need to analyze the data? What is the Baud rate/Data Rate? In the past, I had a very high data rate serial application with lots of display/file write/analysis. About 20 plots, over 200 variables, and data at 10Hz from the device. There I had two loops, a very fast serial loop, and a slower parse/display/write loop. The 2 loops communicated via 2 separate Q's. One for data read from the device and another for sending commands to the device. Both loops were state-machines. Sorry can't post any code. Neville.

I promised myself I wouldn't get sucked into commenting on this Black Hole of a thread but... I guess you mean Stephen HAWKING? HAWKINS is the pressure cooker manufacturer.... Neville. PS. Its amazing how a single comment from alfa can get 4 pages of responses from people all over the world! Good work alfa!