04-27-2007 09:37 AM
05-07-2007 02:10 AM
05-17-2007 03:48 AM
hi,
Well just a couple of things...
You can use any kind of source for your timed loop. That is... you can use a counter output or any other DAQ hardware digital signal to set the timing of your Timed loop (see the DAQmx Create Timing Source), or you can use any other software/hardware signal... just check the timed loop and its palette. So then with this i do not see any problem referring to your timed loop from 10 to 60 hz Signal.
When talking about the PCI-6259 card you say it will work to 1MS/s. That is true but only for one channel, in fact the specifications explain the card can work up to 1.25MS/s for one channel and 1 MS/s for multichannel. BUT this 1MS/s has to be divided for the number of channels you are using.
Example : 1 Channel Rate --> 1.25 MS/s
2 Channel Rate --> 1MS/s / 2 channels -> 500 KS/s per channel
3 Channel Rate --> 1 MS/s / 3 channels -> 333.33 KS/s per channel.
This is because all inputs share one ADC converter. If you need to go to this high rates you will need to check out for a series S card (one ADC converter for each input).
Regarding to your ground problems I will highly encourage you to the use of optocouplers. The DAQ board is inside the PC, that means it takes the PC ground and uses it for the AI, AO and Digital GNDs (in fact they ar all the same).
When using digital inputs there is no possible differential configuration (as it could be the Ai situation) so then you experience the mentioned problem. Please use optocouplers if you plan to have differant references for different digital signals coz all the inputs/outputs in the board are referenced to the same point (D GND).
Hope that helps,
05-17-2007 11:14 AM
I have some ideas, but want to be sure I understand your app's needs to be sure they apply. Let me describe what I *think* your app needs and you can correct my misunderstandings.
1. You get a digital pulse at a rate of anywhere from 10 Hz to 60 Hz. These pulses functionally act like triggers that mark the starting points of different segments of data.
2. The actual data collection would like to be either virtually or truly continuous, but you also want the sensor data to be broken into segments that correlate to the time between the 10-60 Hz pulses.
3. At the time you receive one of these starter pulses, do you have any means for knowing when the next future one will come? I'm guessing not...
Based on those assumptions, I think that you need to perform a continuous acquisition on all sensors, making sure they're all sync'ed to start simultaneously. You'll also need to have a way to "timestamp" the incoming 10-60 Hz pulses. Then, finally, the segmenting would be done as a post-processing step.
It looks like you've tied up the M-series' 2 counters with quadrature encoder measurements, so you'll need to use the S-series board's counters. To keep things sync'ed, I'd use the 1 MHz analog sample clock as a master clock. Then I'd generate the 50 kHz sample clock with a counter, using the 1 MHz analog sample clock as the timebase -- this way there's no chance of having 2 clocks from different boards "drift" with respect to one another.
The other counter would be configured to do the timestamping. In pricinciple this is more of a buffered edge-counting app. If you use the 50 kHz clock as the timebase, you may be ok here. The thing to watch out for is the potential for counter rollover -- I think the S-series board only has 24-bit counters, right? At 50 kHz, you'll get about 5.5 minutes of timestamping before rollover occurs. Another alternative is to do buffered period measurement so you won't get count rollover. Then the timestamps values would be calculated as the cumulative sum of all the periods.
-Kevin P.