How to get time of change when using ChangeDetection for DI

[espenalb]

Hi there.

I am using an USB-6251 board for Digital waveform capture. I just realized that with ChangeDetection enabled, I can detect changes on the 80MHz clock, which is great, since the 1MHz clock is a little bit slow for my application.

I have connected an MCU to the P0.0 pin on that first toggles 4 times as fast as it can (~110ns), then slower (~4us) and finally really slow (3.5ms)

The problem is that the waveform I get claims to have timestamps - but the timestamps are wrong.

The waveform I get claims to have timestamps (wave.PrecisionTiming.HasTimeStamp is true), but the timestamps in the samples are not correct. Every sample I get claims to be 1ms after the previous one.

This is the code I have:

ReaderTask = new Task("Measure-DigitalInput");

string lines = GetLinesForPins(pinsToMeasure);

DIChannel chan = ReaderTask.DIChannels.CreateChannel(lines, "", ChannelLineGrouping.OneChannelForAllLines);ReaderTask.Timing.ConfigureChangeDetection(lines, lines, SampleQuantityMode.FiniteSamples, numberOfSamples);

ReaderTask.Control(TaskAction.Verify);ReaderTask.Control(

TaskAction.Commit);

// Start the reading asynchronously:

 DigitalSingleChannelReader reader = new DigitalSingleChannelReader(ReaderTask.Stream);

IAsyncResult result = reader.BeginReadWaveform(numberOfSamples, null, null);

... // Some code here that waits for MCU to toggle the pins  

DigitalSingleChannelReader reader = new DigitalSingleChannelReader(ReaderTask.Stream);

DigitalWaveform wave = reader.EndReadWaveform(result);

 

// Make sure we have time:

 if (!wave.Timing.HasTimeStamp)

  throw new NotSupportedException("The captured waveform did not have timestamps");

if (wave.PrecisionTiming.SampleInterval.TotalSeconds == 0)

  throw new NotSupportedException("The captured waveform had sampleinterval = 0!");

The exceptions are never thrown - and the samples in the wave indicate a _wrong_ time!

So my quiestion is this:

Is this a bug, or is there something I have configured wrongly?

I suspect that it is not possible to use ChangeDetection as sampleclock and get timing on the samples. If that is the case - is there some workaround to get the timestamp of the change? (Could I use the ChangeDetection signal as an input to a counter and bugger up the counter values on each trigger for instance?)

I hope soemone can help me with this - I'm stuck.

Espen

[Kevin_Price]

Your suspicion is correct -- when you use ChangeDetection as your DI sample clock, you will NOT get sample timing information about your DI samples.  Fortunately, your other thought is *also* correct -- yes, you can configure a counter task to store the needed timing information by using the ChangeDetect signal as the counter task's sample clock.

Sorry, I'm no help on C-like syntax  -- I only use LabVIEW for data acq programming.  But I have used a ChangeDetect signal as a sample clock for a counter measurement on an M-series board.  So I can vouch for the concept and the hardware.

-Kevin P.

[stilly32]

To add a little more to Keven P's excellent comments: You would want to timestamp with a counter and this is usually done by performing a clocked edge count (where the change detection event signal is the clock) on a known timebase (like the 80 MHz clock) or just a period measurement on the change detection event signal (which amounts to the same thing but you don't have to worry about roll overs and you have to keep a running sum to get the times.) The thing to watch our for on buffered counter measurements are the rates - on the 6251 any buffered acquisition over ~250k runs the risk of overflowing the onboard FIFO (which is 2 samples deep). This KB has some typical benchmarks - Benchmarks for Buffered Counter Input with M-Series Devices.

You may run into this with the 110ns pulses. A couple options to work around this: while we spec correlated DIO on USB products at 1 MHz, we don't limit it in the driver or the HW. USB being what it is, your bandwidth and latency do limit you to less than you can expect on PCI/PXI/PCIe/PXIe, but on a good system you can still get good correlated DIO rates. It is very system dependent, but I've sustained 8MS/s on correlated DIO on my Dell 3400 and for short periods of time I can get 10MS/s. I always throw in this note with USB: performance is system an resource dependent - as well as the HW your memory usage, CPU usage and other USB devices can effect performance.

This would be easy to spot check though - just use the external clock DI example, set it to use a counter's output and crank up the counter rate untill you get buffer overflows - this will give you a good idea of your system performance. Make sure to up the size of the reads so that you don't run into PC buffer overflows. 

The change detection option is nice in that you're not streaming extra data, but without the counters you can tell when the changes occur. Since the 6251 counters can buffer that fast, another option would be to get some HW that can. The USB-621x devices have a 1k FIFO on counters and can buffer at up ~1Ms/s. you could export the change detection event signal and timestamp that with the additional device. I know this isn't desirable and ideally we'd have counters with FIFOs and change detection support (give us time) on the same device, but at the moment we don't.

Hope this helps,

Andrew S.

Multifunction DAQ Product Support Engineer

National Instruments