I *think* you'll get better results with some code work. I assume the unshown TRUE case in your Read code is pretty much empty and just passes through the data read before the case structure?
1. One thing I notice that may matter is that on an error in the Read code, you stop the task and then perform a Read without an explicit Start. I also didn't see an explicit Start in the Setup code, so it appears that you're depending on the "auto-start" behavior that kicks in when you Read from a previously-unstarted task. I'm not 100% sure of this, but I think the DAQmx State model might make that mode of operation less efficient than if you were to explicitly Start the task outside your main loop (and again inside the error case of the Read). I've made that a personal habit, and I think I based it on reading something to that effect in the help or here on the site -- somewhere. In any case, it won't hurt to try. Also, when you *do* restart on an error, I don't think you should need to call the 'Overwrite' property or the DAQmx Timing vi. The task should remember those settings if you merely stop rather than clear it.
2. I'm a bit uncomfortable seeing 0-valued timeouts, and wonder if those may cause occasional timeout errors which cause you to execute the slower error case in the Read code. Not sure though -- maybe it's ok when you also request -1 = 'all available samples'.
3. In the screenshot, the Timed Loop is set for 5 kHz. I assume you varied the requested rate to try to make the loop run faster?
4. Dunno what's inside the 'Loop % Used' subvi you call, but make sure that isn't bogging you down.
5. When you made calls to 3 counter tasks, were they sequential or parallel? The timing results you reported sounds like their times were additive, kind of implying a sequence. Be sure to try dropping them in parallel. (Of course, there's a chance this might actually become slower as DAQmx negotiates more parallel threads -- you'd have to benchmark it).
6. Dunno much about Shared Variables on RT, but think I recall that you can use them in RTFIFO mode. If so, do it. If they aren't in that mode, they may be responsible for some overhead.
7. This one's more of a style thing than a speed thing. You read 'all available samples' which returns an array of recent values. Then you retain only the first element, which is the oldest value there. I would expect that you'd either want to compute an average on the array, or keep the last array element which is the most recent value.
8. There's another way to extract only the most recent data in your calls to DAQmx Read. In your Setup code you could call the DAQmx Read property node to set RelativeTo = MostRecentSample, and Offset = -n. These settings will persist. Then you could call DAQmx Read to request n samples and it will immediately return the most recent ones.
Hope something here proves useful...
-Kevin P.
P.S. Just followed your link to the other thread. Should have done it before posting -- looks like that thread is the more active one and I'll direct followups there.
Message Edited by Kevin Price on
01-16-2008 05:35 PM
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
