Delay before sampling with DAQ board microsecond resolution

[Zangetsu]

This is something I’ve been trying to work out for the past couple weeks or so.  How would I implement a software delay (on the order of 150 µs or so) before reading information in from the DAQ board and writing to a data file?  I included a diagram to show what I am trying to do. 

Here is the lowdown:

1. I’m trying to get everything to work with 4 thermocouples.  Once this works, I can build 6 more and put them in parallel to get a total of 24.
2. The 500 Hz signal triggers 4 small pulses when the 500 Hz signal goes high.  Right now these smaller bursts have a 5000 Hz frequency, but I will increase this once I get this working and know the limits of the hardware.
3. The bottom 2 graphs show the timing phenomenon on the oscilloscope.  The bottom is a simplistic representation, but you get the idea:  there is a delay until the output becomes valid (150 µs in the case of a 5000 Hz 4 burst signal).
4. I need to somehow tell LabVIEW to wait this amount of time before reading the data from the thermocouples and writing it to file, otherwise the data is inaccurate or way off due to noise, etc.

Perhaps I could make use of some sort of hardware delay if LabVIEW cannot create a delay to this accuracy?  If so, how would I do this?

If anyone has any ideas/suggestions or know how to do what I want in LabVIEW, I would greatly appreciate it.  Just keep in mind that I am very new to LabVIEW (I am using version 7.1 and a  DAQ 6034E card)

Thank you,

-Paul

[gwd]

There are a number of issues here. The 6034E has only one A/D that is used to sample all available channels. So you will not collect data simultaneously AND you need to allow enough settling time after each channel change for settling. This obviously gets worse if you collect more channels.

I don't have the data sheet so I don't know if this board can use an external trigger. If it does you should have use external triggering from your signal source. If not then you should collect the signal source AND the data of interest. Then you don't NEED to create a 150 us delay in software (which you can't do anyway, at least not without going to real time systems).

[Elijah_K]

Hey Paul,

Lets start by breaking down the application you've described. 

A continuous pulse train requires one counter.  You can create a counter output task with a set frequency in order to create the 500Hz pulses.

However, a finite pulse train such as the 5kH signal requires two counters.   One counter is used to create the pulses, and the other counts the edges of the first in order to gate the output.  In other words, in order to ensure that only four pulses are created, the second counter monitors the output and disables the output by setting the gate low when it has finished four.

At this point we've already exceeded the capabilities of the 6034E since it only has two on-board counters.  One possible alternative would be to create the 500Hz signal in software and trigger the 5kHz signal off a PFI line, but it will be jittery due to the lack of determinism of an operating system.  We don't recommend using software for accurate timing at these rates, but in theory it is possble, though entirely system dependent.

Now, if I understand correctly you want to create an analog output while the 5kHz signal is high.  You could create an analog input that triggers off of the ctr0internalOutput, but in order to retrigger it such high frequencies you'll need another counter.  Add the fact that you want to divide that width between an analog output and input and you'll need yet another counter!

So, that being said, I think you have a couple options:
- purchase a more advanced hardware solution such as one of the scope cards
- setup a continuous pulse train at 5kHz.  Trigger the analog tasks off of the ctr0internaloutput.  You won't be able to limit it to four pulses every 500Hz, but you could very easily just acquire the extra samples and throw them out later.  With a board like this, you're going to want to just acquire more than you need and figure out how to disregard what you don't need.

Let me know if you have any questions.

[Elijah_K]

One more thing Paul,

You actually shouldn't use the counter to drive the analog input since what that means is that you'll only acquire at 5kHz.  I looked at your diagram again, and you're actually wanting to acquire even faster than that!

Just setup an analog input task without the use of any counters and disregard samples you don't want.  If there truely is a discernable spike in your data you could easily use that information to help analyze the information.

[Zangetsu]

Elijah,

I don't think I need to acquire data faster than 5kHz.  If you look carefully, there are 4 pulses @ 5 kHz that begin after the 500 Hz. signal goes high.  I only need one data sample for each thermocouple per unit time.  If I put a delay after the 5 kHz signal (delay of about 150 microseconds) and use this delay to tell LabVIEW to write the data on an analog input channel (only one data entry per TC!) then I will be set.

Unfortunately there is little to no discernable difference between the TC temperatures for my application.  It will also take far too much manpower and time to look at the frequencies manually and figure out the temperatures of each TC.  I need the process to be automated as much as possible.

I'm going to be working on this project again on Tuesday.  Hopefully I'll have some progress.  If not, I'll message here or call NI.  Thank you for your help and patience!

-Paul

[Zangetsu]

I just thought of something.  Perhaps I could use the falling edge of the 5kHz signal counter (CTR1) to trigger the data capture?  This isn't quite 150 microseconds, but the delay should be long enough for my output to stabilize.  Is this possible?

I would also like to correct a mistake on the diagram.  This is the correct output response to feeding a 5kHz signal into the circuit.  The TC output, as you can see, becomes stable at roughly 100 microseconds, so the falling edge idea will probably work just fine.  I just don't know how to do this in LabVIEW.

[Elijah_K]

Paul,

I believe your best bet is to create a continuous analog input task with a sample clock of 5kHz.  You can use the internal AI Sample clock, so no counter pulse train will be necessary.