LabVIEW
AI Acquire Waveform takes up alot of processor time
Well, it'll solve the problem and stick a 50 ms gap in between your data reads. If that's fine, go with it. Otherwise I'd suggest re-ordering your vi and using some sequence structures.
1. Check out the example muliple acqusition examples that ship with LV. Help->Find Examples. Search for "multiple" and look at the software triggered vi's.
2. Use a general sequence structure around the entire vi. Typically, I use the first frame to initialize things and do anything that only needs to be done once for the entire vi (like an intro). The middle frame holds the 'body' of the vi, with all the acqusition and other goodies. Finally, the last frame is the conclusion, or shutting down stuff (cleari
ng memory, resetting buttons, etc.).
3. You may be better off using parallel loops, a fast one for doing the reads, and a delayed one for other stuff.
4. You're also saving every read. While this isn't bad if you have a low data load, at higher rates, you may be better off holding the data and saving at the conclusion of acqusition.
G'Luck
~j5
1. Check out the example muliple acqusition examples that ship with LV. Help->Find Examples. Search for "multiple" and look at the software triggered vi's.
2. Use a general sequence structure around the entire vi. Typically, I use the first frame to initialize things and do anything that only needs to be done once for the entire vi (like an intro). The middle frame holds the 'body' of the vi, with all the acqusition and other goodies. Finally, the last frame is the conclusion, or shutting down stuff (cleari
ng memory, resetting buttons, etc.).
3. You may be better off using parallel loops, a fast one for doing the reads, and a delayed one for other stuff.
4. You're also saving every read. While this isn't bad if you have a low data load, at higher rates, you may be better off holding the data and saving at the conclusion of acqusition.
G'Luck
~j5
So running with a bare bones version, the original w/ delays, or an example like the one attached precludes you from running any other programs? The CPU monitor may say it's 100%, but it should dump that over to any new program you open.
It's actually a fairly simple reprogram. The simple vi's are just that - simple. Note that the previously attached example uses the second level of analog input vi's. Why?
OK, acquisition hierarchy goes like this:
Set Up Acq Params (AI Config)->Start Up Acq (AI Start)->Read Data (AI Read)->Shutdown (Clear AI).
Simple AI Multiread does this EVERY time it runs, so it's constantly reconfiguring the DAQ card, starting it, reading it, clearing, EVREY 10 ms (at 100 Hz scan... every 1 ms at 1000 Hz, etc.). By using the advanced vi's, as in the Contacq example, you do all the config and start junk at the start vi JUST ONCE. So all your computer has to do during ac
quisition is read the DAQ. It's the good ole Set It & Forget It mentality (any Ronco fans out there?). As long as you stick AI Config and AI Start outside the loop and pass the Task ID to the AI Read inside the loop, and finally have AI CLear at the end of the vi outside the loop, everything should be hunky dory.
THERE IS ALWAYS A CHOICE 🙂
OK, acquisition hierarchy goes like this:
Set Up Acq Params (AI Config)->Start Up Acq (AI Start)->Read Data (AI Read)->Shutdown (Clear AI).
Simple AI Multiread does this EVERY time it runs, so it's constantly reconfiguring the DAQ card, starting it, reading it, clearing, EVREY 10 ms (at 100 Hz scan... every 1 ms at 1000 Hz, etc.). By using the advanced vi's, as in the Contacq example, you do all the config and start junk at the start vi JUST ONCE. So all your computer has to do during ac
quisition is read the DAQ. It's the good ole Set It & Forget It mentality (any Ronco fans out there?). As long as you stick AI Config and AI Start outside the loop and pass the Task ID to the AI Read inside the loop, and finally have AI CLear at the end of the vi outside the loop, everything should be hunky dory.
THERE IS ALWAYS A CHOICE 🙂
