08-02-2007 08:54 AM
08-03-2007
02:46 PM
- last edited on
02-16-2024
11:40 AM
by
migration-bot
Hello Ben,
You do need three counters to accomplish this task. If you want to get a counter board, I would recommend a PCI-6602. However, there might be an easy work around, since you have an M-Series DAQ board.
You could simulate a gate signal from an analog output channel. The analog output signal would be a square pulse at your desired accumulation time. Use this square pulse as the gate to your counter. Effectively, you have created a finite pulse generation with one counter instead of two.
Make sure that you synchronize all of these tasks. The best way to accomplish this is by making one of the tasks a master and the other tasks a slave. Start all of the slave tasks first and then start the master task. This can be accomplished by data flow using the error cluster. There is a great shipping example that illustrates how to accomplish synchronization. (Hardware Input & Output >> DAQmx >> Synchronization >> Multi-Function >> Multi-Function-Synch AI-AO.vi)
08-06-2007 09:37 AM
Rob's suggestion is a good one, based in hardware-level timing. I just wanted to offer up a simpler idea which may or may not work for your needs. Since you said you're new to DAQmx, you're probably not familiar with the tradeoffs of different methods. I'm proposing a method that can work with only 1 counter.
I don't have LV handy to look at your vi now, but I *think* a key sticking point is how you handle the call to DAQmx Read. It sounds like you aren't familiar with some more flexible ways to work with that vi, relying on either reading all the data at once or letting the call get stuck until it times out. These are NOT your only options for interacting with a DAQmx acquisition buffer.
Check out the DAQmx Read Property Node. You can call that to query a property named "NumAvailableSamples". By monitoring this value and also monitoring your elapsed time in a loop, you can put yourself back in full control. You can terminate the loop on the earlier condition, whether it's based on elapsed time or based on accumulating the max # of samples you want. After ending the loop, you can call DAQmx Read. Just wire in as the # of samples to read the # you know is available.
Then your software would just inspect the timestamps you gathered, in case you need to trim off any samples near the end that occurred slightly too late. (There will be a finite software reaction time which you should allow for. Make sure the software elapsed time is allowed to be slightly longer than the true hardware collection time. You can always ignore samples collected slightly too late, but you don't want to read them too early and risk missing some.
There are many variations on this theme, but the essence of it is to let your software monitor both time and samples, putting you back in control of the application software timing.
-Kevin P.
08-07-2007 10:52 AM
Hello Ben,
Either method should work for your application. Just beware of using software timing with your application. If you are using Windows as an Operating System (OS), then you may not be able to get the accuracy that you can achieve with hardware timing. Windows is non-deterministic and cannot guarantee that a specific event will happen exactly when you want it to. Usually, Windows is going to give you an accuracy of approximately in the millisecond range.
With hardware timed applications, you can usually get better timing resolution specific to your application. Hardware timed applications might be a little harder to setup but it is usually a better solution. Software timed might require you to acquire more data than you need and then discarding this information through software. With hardware timed application, you are assured that you will only acquire the data that you want.