topic Re: Triggered DAQ too slow with LabVIEW in LabVIEW

Triggered DAQ too slow with LabVIEW

PaulG. — Wed, 01 Mar 2006 22:06:02 GMT

I am using a non-NI daq board with a 2GS/sec sampling rate. If I use the basic VI's included with it to run the card I can acquire 20 usec of data at 2 GS/sec continuously with no trouble. However, when I try to sync the data acq with a 1 kHz external trigger things bog down. I am using a state machine. The board itself never times out, (it barely breaks a sweat!) but I cannot seem to trigger, get the data from "start point" to "number of points", go back to "wait for trigger" then get more data. My limit appears to be around 500 pulses per second at 500MS/sec, 10-15 usec worth of data. Why can't LabVIEW do better than this? I've tried timed loops, queues, I've let it free-run, using the "board not busy" to send the state machine back to the "wait for trigger" state, etc. Would I need "real time" even if I'm dealing with events that occur only msec? What is the time required for a state machine to go from one state to another? It cannot possibly be more than 1 msec, can it?

Paul

LV 7.1, XP

Re: Triggered DAQ too slow with LabVIEW

Dynamik — Thu, 02 Mar 2006 05:40:29 GMT

Hi Paul,

This is a comon complaint, but it's not fair to blame LabVIEW - ultimately Windows is in control and directly responsible for inserting small, irregular, delays.

I can't find it now, but there was a recent post (by Altenbach?) that described a tweak for squeezing a bit more timing-determinism out of some Windows/DAQ loop.

BTW, 2GHz - whoa! I'd like to check-out this board - would you be so kind as to post a link?

Cheers.

Message Edited by Dynamik on 03-01-2006 11:49 PM

Re: Triggered DAQ too slow with LabVIEW

PaulG. — Thu, 02 Mar 2006 13:32:29 GMT

Thanks for the response. I'll look for the additional info. I may have jumped to conclusions bashing LV. My apologies. :-o.

My program works OK if it is just acquiring data. The display is what is killing me. I'm not trying to display that much (20k points) but my program slows dramatically (about 80% !)when I add a display. I know a few tricks (refresh display only every few hundred milliseconds, defer panel updates, etc.) and I should be OK for my application. But I would really like to know how to tweak it to it's maximum potential. Even with refresh of screen subroutine I can watch the downward "glitch" in my loop counter every time the display is refreshed. It's noticable in my loop counter display.

The board is a Gage 82G with 2MB memory. It's a little pricey ($8k) but I love it and you can order LV drivers and vi's with it for a little extra. We've been running these things daily for years now and so far no trouble.

http://www.gage-applied.com/Products/digitizer_pci/8_bit/compuScope_82G.htm

Paul

Re: Triggered DAQ too slow with LabVIEW

Travis_M. — Thu, 02 Mar 2006 17:44:51 GMT

Hello Paul,

Thanks for posting to the NI Discussion Forums! What type of display are you using -- chart, graph, etc..? If you are plotting very large amounts of data in a graph each iteration I would expect some performance hit (you do well with the defer updates,etc...). The UI thread (there's only one for your entire LabVIEW execution system) is notoriously slow, and every UI update requires a context switch to the UI thread. I would perform UI events sparingly -- avoid property nodes, variables, and unnecessary panel activity if you are concerned with speed. It sounds like you are off to a good start with this, but consider using charts with different mode updates to display your data, maybe not even plotting every point. Another possibility is that the method that the board's manufacturer uses to transfer data from the card to LabVIEW is a bottleneck. It sounds like you've traced it to the panel updates, but its always a possibility that the data just isn’t coming over fast enough.

It wasn't much, but I hope this helps -

Re: Triggered DAQ too slow with LabVIEW

Ben — Thu, 02 Mar 2006 18:00:15 GMT

Paul wrote

"The board is a Gage 82G with 2MB memory. It's a little pricey ($8k) but I love it and you can order LV drivers and vi's with it for a little extra."

Does the driver use "call Library Function"?

If so what color is the header, yellow or orange?

Ben

BTW

Is this an NDT app?

Re: Triggered DAQ too slow with LabVIEW

PaulG. — Thu, 02 Mar 2006 19:39:42 GMT

Yes, it uses call library funtions, and the headers are orange.

Re: Triggered DAQ too slow with LabVIEW

PaulG. — Thu, 02 Mar 2006 19:52:40 GMT

I am using a waveform graph. Along with the actual waveform I am also plotting/diplaying up to 8 additional plots (just straight lines that can vary in level and lenght) that track portions of the waveform. The data that are taken from these gates is processed later in the program.

Paul

Re: Triggered DAQ too slow with LabVIEW

Ben — Thu, 02 Mar 2006 21:00:37 GMT

Bingo!

Yes, it uses call library funtions, and the headers are orange.

An orange Call Library functoin is configured to run in the User Interface thread.

Ben

Re: Triggered DAQ too slow with LabVIEW

PaulG. — Fri, 03 Mar 2006 14:00:21 GMT

Thanks, Ben.

"An orange Call Library functoin is configured to run in the User Interface thread."

And the difference would be if the Call Library Function header were yellow? Just curious.

BTW: I would think if you were going to have two different header colors you make make them a little more different than yellow and orange. I'm not color blind, but I would not bet my next paycheck that the color "orange" is indeed "orange" and not yellow. 🙂 Maybe that's a cosmetic but important issue to bring to the attention of the LV developers. How can I do this?

Paul

Re: Triggered DAQ too slow with LabVIEW

Ben — Fri, 03 Mar 2006 14:18:14 GMT

An orange CLF runs in the User Interface thread which is single threaded. That means once something is started in that thread, it must complete before anything else that runs in that thread can get at the the CPU.

If you graph/chart/what-ever is wasting a lot of time, the other stuff just has to wait.

Ben

Re: Triggered DAQ too slow with LabVIEW

Travis_M. — Fri, 03 Mar 2006 15:31:01 GMT

Great information Ben!

Check out: http://zone.ni.com/devzone/conceptd.nsf/webmain/a342b904a68811a0862567c9006bafed for additional information on the differences between threadsafe and non-threadsafe DLLs. You can declare that your DLL is threadsafe by checking the "reentrant" box, but I would highly recomend that you don't do this unless you are completely ceartain that the DLL really is threadsafe (you'll have to contact the manufacturer of the board's software for that though).

best of luck!