12-08-2006 09:16 AM
The issue I am having is that the multifunction DAQ (6220) can not support software configured (Express VI) Sample Rate and Number of Samples using an internal clock for reading digital inputs and Ctr0. I believe this is true for all M-Series devices. The analog section will allow software configured Sample Rate and Number of Samples to be configured and clocked of an internal clock.
To get around the issue I am planning in using Ctr1 to generate a pulse train. I will hard wire the pulse output to PFI_1 input and trigger the Analog, Digital, and Ctr_0 off of this clock source. My question is this the best way to sync readings using different functions in a multifunction DAQ and will it work? The express VI would not let me set the rate for Ctr_0 but able to do it with DAQmx VIs.
12-08-2006 10:09 AM
Hi again on another thread. One of several nice things about the M-series boards under DAQmx is the flexibility available for routing timing signals. You shouldn't need to touch a screwdriver at all to accomplish your synchronization.
However, my only bit of advice about the Express VI's is this: Run away! Run away! Especially after seeing your LV credentials in your .sig there. Now granted, I have an irrational level of bias against them but that mostly came after I had grown a pretty rational bias against them.
Seriously though, for anyone with even a basic comfort level with LabVIEW and DAQ, I really believe they're far more trouble than they're worth. The code doesn't "speak for itself" on the diagram because so much is hidden behind the little config window. They produce a number of different inefficiencies that are mostly figured out by trial and error, judging by the threads here on the forum. Those are the rational biases. They make big icons on the screen. They feel like training wheels. There, those are the irrational ones.
Anyhow, once you generate a pulsetrain with Ctr1, the other tasks can specify Ctr1InternalOutput using the drop down menu in the DAQmx Timing input for "Sample Clock Source." If you don't see a name like that listed, you may first need to right click on that "Sample Clock Source" and select "show advanced terminals...". (I *really* wish I could *always* show advanced terminals by default. Most of the stuff I ever use is only visible after that right-click dance. But I digresss...). With this kind of software config, voila! Look Ma, no screwdriver!
An artifact is that you are required to wire some value into the DAQmx Timing vi to specify the sample clock rate. I personally read arrays rather than waveforms, so I just wire a dummy value of 1. If you're going to read out waveforms, you might need to be more careful to wire the correct value. Querying the frequency property of a running counter output task should give you the true value, though I'm not 100% sure it does. In the past, I recall that even when I wrote a frequency value that wasn't physically possible for the counter, my query would just spit back whatever I had requested rather than what was truly being produced. I probably did the query before starting the task though, because in this type of sync'ed DAQ setup one would normally start the counter pulsetrain last.
Finally, is this the best way to sync? Well, for sure it's the best if you need to change the sampling rate on the fly. This is probably unlikely. A slightly better way may be to borrow the AI task's sample clock using similar software-configurable settings. In that same "Sample Clock Source" drop down menu there should also be a choice for "AISampleClock" that you can specify for your Digital and Counter tasks.
-Kevin P.
12-08-2006 10:57 AM