From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.


Showing results for 
Search instead for 
Did you mean: 

hardware timed DAQ

PXI 1040 Chassis with:
- PXI-8187 controller running RT
- PXI-6259 M-Series DAQ (32 AI, 48DIO, 4AO, 1.25MS/s)
- PXI-6132 S-Series DAQ (4AI, 3MS/s)
- 2 analog sensors (1MHz acquisition rate and 50kHz acquisition rate)
- 4 quadrature lines (A&B on two different encoders)

LabView RT on the 8187 and LabView 8.2 with Real-Time module on PC for programming and display

I have a process that runs at anywhere from 10 to 60Hz.  A digital pulse (low-high) is generated every cycle.  I would like to use this pulse to acquire a single buffer for every cycle, i.e. for 50Hz the 1Mhz sensor would have 20,000 data points in the acquired array and the 50kHz signal would have 1000 data points.  However, this would change from cycle to cycle. How would I go about using my hardware in this fashion?  I think that the 6259 is the choice for the digital pulse, (especially since I can't get the counters to work properly on my 6132, but that's another thread).

Basically, I want to acquire data at 1MHz and 50kHz on various channels.  However, the "chunk size" must vary from cycle to cycle and be dependant upon a harware interupt.  I want to start each adqusition cycle on the rising edge of a digital signal.  Seems pretty simple, no?

Yet, I'm sort of at a loss on how to proceed.  I've done fairly well thus far at programming the DAQmx using timed loops and FIFOs to transfer the data to analysis and disk writing tasks that get worked on at a lower priority, but adjusting the size of the buffer to acquire based on a digital pulse is a bit tougher IMO.
0 Kudos
Message 1 of 4
Nothing, eh?

Well I have another question that I'd tack on here and give this one a bump.

Question: I have 3 digital signals that do share a common ground (coming from different electronics).  If I connect these signals up to the 6259 DAQ via the SCB-68, and place all three digital grounds on the "D GND" lines (i.e. terminals 4, 7, and 9) I have ground loop problems that cause my electronics to act erratically.  Is there a way to use the digital grounds on PFI lines and create a "differential" digital input?  Or am I do I have to go to a hardware solution like opto-isolators or something?

0 Kudos
Message 2 of 4



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,



Jaime Cabrera

NI Applications Engineering Spain
0 Kudos
Message 3 of 4

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.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 4