Retriggerable DAQ - samples missing

[ceties]

In our measurements we perform retriggerable DAQ. The application is complicated but attached code represents the core of the DAQ.  We encountered following problem(s).

1] If I simulate the process everything seems to work smoothly. But if I use the real device (PCI 6110) and I utilize it to acquire 8000dbls on each trigger it acquires into the buffer only 7994dbls on the first trigger. Following trigger has already 8000dbls but the first 4dbls obviously belong to the end of the data from the previous trigger.

What could cause this? I am able to do some workaround by acquiring 8004 and cutting first four dbls but I would like to know why is this happening and why exactly 4dbls.

2] Is it possible to simulate trigger occurrence in retriggerable DAQ? My problem is that if I use simulated device the triggers occur immediately and it's not what I want. Would be nice to generate trigger on button press.

Thanks for any help

We used LabVIEW 8.2 and NiDAQ 8.3

[Corby_B]

Hello ceties,

Thanks for your post!

So I was able to try out your program on a card I have (PCI-6251) which is of the same family that you are using. When I run your program and set the samples to take as 8,000 on the graph I would show 0 - 799 samples. I also see the same thing when writing to a text file. I wanted to ask where you were seeing the 7994 samples and missing the other samples as I do not see the same result. Is there another revision of your code where you see this problem?  Also when you simulate the device the trigger is always going to be immediate because it is getting a simulated signal from the "board". What I would recommend is trying to set up and AI task for finite and see if you are able to get the right number of samples that you are looking for. Have a great day ceties,

Cheers!

Corby_B
http://www.ni.com/support

[ceties]

Hi Corby and thanks that you spent some time over this issue. To repeat the situation just make the delays between triggers long(couple of seconds) and watch the 'Available samples' indicator. When first trigger occurs you should see, that you have in the buffer 7996 samples (in my original post I wrote 7994-it was typo) instead of 8000 and so it won't read it from the buffer until the 2nd trigger occurs. Then it acquires another 8000 samples so you should have 15996 total samples in the buffer and it will read first 8000 of it and so on. Thanks a lot

[ZachHindes]

Hi ceties!

A quick correction on Corby's post, the 6251 is not actually the same family as your device, the 6110.  However, I can explain the behavior that you are seeing.

The issue is that the 6110 uses pipelined ADC (with a depth of 3 samples).  So, if you get one sample clock you won't actually see the data until the 3 more sample clocks arrive.  This is one off from what you are seeing (4 samples instead of 3), but this may be explained by the FIFO width of the device, 2 samples.  So you have 3 samples stranded in your ADC and a 4th in the FIFO.

This behavior raises a couple of interesting issues.  First is for on demand acquisitions.  In this case we actually provide 4 samples clocks per one sample you acquire.  Another is for a finite acquisition in which case we will generate 3 extra sample clocks.

Now, how do you work around this?  That isn't entirely clear.  Perhaps you could generate 4 extra sample clocks then you want?  But then you the issue of the first retrigger having stale data, but also has missing data at the end of its acquisition.  Its a one step forward, two step backs type of deal.

Here is a KB that explains much of what I said here: http://digital.ni.com/public.nsf/websearch/D64CD277A6B739A186256A73007E7BCC?OpenDocument

If you need help with any sort of workaround post again and we can try to come up with something.

[Corby_B]

Hello,

Thanks Zach for correcting me and the nice clerification you have given us. Ceties please post back if you have other questions or needs for a work around!

Cheers!

Corby_B
http://www.ni.com/support

[ceties]

Hi Zach and thanks a lot.

Your explanation is magnificent! I would never guess that it is actually hardware property of the card itself.

The workaround I have used before knowing this was that I generated one more trigger at the beginning and I read 7996 samples acquired in the buffer. All other triggers had proper amount of samples to be read and because I was anyway cutting first couple of ms of the signal I didn't have to take care of the first 4 samples (that were actually from the previous trigger).

Now if I know what causes this I would like to use the workaround suggested in the KB:

#1 - When the first trigger rises I will utilize the card counter to produce 8004 pulses but I will read only 8000 samples

#2 - On the second trigger I will utilize the card counter to 8008 pulses.  I will read 8004 samples from the buffer. First four samples will be cut off and the rest is my signal. There are still 4 samples in the buffer that will be used to push other data when next trigger rises /ACCORDING TO MY OPPINION THERE IS 8 SAMPLES NOW -SEE Q#2/

#3 - Same as #2 and so on.

Q#1- But how to change the number of pulses after first trigger is processed - this is parameter set before the measurement starts and I am not sure if can be changed during runtime.

Q#2- I also don't understand why should I produce 8008 pulses in the #2. I still have 4 samples in the buffer from #1 and if I produce again 8004 pulses and read 8004 samples - the 4 first are from the previous trigger and I cut them off and remaining 8000 is my signal - AND THERE IS 4 SAMPLES STILL IN THE BUFFER FOR NEXT TRIGGER

I will have chance to test it in 14days but I want to alter my software according to this new fact that's why I am asking if got it right.

Thanks a lot 🙂

[Mcdan]

HI ceties,

I'm not sure that the knowledge base is correct.  I'm pretty sure you'll need to issue 3 (and only 3) extra pulses each time.  The caveat here is that the hardware will throw away the data from the first three clocks it receives (basically old data stranded in the ADC's pipeline).  Since you are using an external clock to retrigger your acquisition (ie... this is one long continuous acquisition in the eyes of your 6110), you'll have to read and discard the extra samples yourself on every read following the first (the hardware can't distinguish one record from another, and as such can't know which data is old stranded data).  So I believe what this should look like is:

#1 When first trigger occurs, use counter card to produce 8003 pulses.  Read 8000 samples.  (I noticed that you were using 8004... any reason for this?)

#2 On second trigger, use counter card to produce 8003 pulses.  Read 8003 samples.  Discard the first 3.  Buffer should be empty.

#3 Goto #2

I'll have another look at the KB and see about getting it corrected.

Dan

[ceties]

Hi McDan. The approach you suggest is exactly what I would do and the buffer usage also corresponds to the workaround I did previously. I don't know why there is this one sample difference (4 vs. 3) but if I produce one trigger and I want to acquire 8000 samples I have eventually in the buffer only 7996 samples to read (not 8000, neither 7997!). I tested that many many times. But if there are four or three samples missing I do not care as long as the amount is constant and I have some clue what it causes.

[Mcdan]

ceties,

I think I can explain the extra missing sample (but only if you are using an odd number of channels).  The 6110 produces 16 bit samples, but transfers data from the device to host computer memory in 32 bit words (more efficient that sending each sample over in a 16 bit transfer).  This means if you clock in an odd number of samples on an odd number of channels, 1 sample will be stranded in the devices FIFO.

What I'd expect to happen (assuming you are providing 8004 clocks per record)

1) First Trigger: HW throws away 3 samples.  8000 samples are transferred.  1 Valid sample is stranded in the device's FIFO.

2) Second Trigger: HW throws away 0 samples.  8004 samples are transferred (but one is the last valid sample from the last record). One valid Sample is stranded.

3) Goto 2.

If you are only reading 8000 (1st read) and 8003 (subsequent reads) samples at a time, you will slowly build up a backlog of samples in your buffer, and you might be reading data that is older than you think.  This use case on this device definitely requires some attention to details that are not obvious.  For most use cases we can take care of these details in the driver.  If you want to simplify things some, I'd recommend that you always read an even number of channels.  You can throw away data from the un-needed channel, and not have to worry about the valid sample that gets stranded due to the sample width / transfer width issue.

Hope this helps.  Please let me know if you have any questions.

Dan

[ceties]

Hi Dan,

Yes I acquire signal only from one channel so your explanation makes sense.

What I do not understand is this part: 'If you are only reading 8000 (1st read) and 8003 (subsequent reads) samples at a time, you will slowly build up a backlog...'

I understand what it means but I would read 8004 in subsequent reads so that was just a warning what I should avoid, right?

I will consider your suggestion of using even number of channels but I want to keep the resources as low as possible. So if I still want to acquire only from one channel the proper way will be:

#1 When first trigger occurs, use counter card to produce 8004 pulses.  Read 8000 samples.

#2 On second trigger, use counter card to produce 8004 pulses.  Read 8004 samples.  Discard the first 4.  #3 Goto #2

Using this way the 8000 samples I always get are the proper ones and there is no other problem.

Thx a lot again Dan!

Message Edited by ceties on 07-17-2008 12:11 PM