Max sampling rate on 6602 and interrupt programming.

[ChrisErven]

Hi,

I have two questions. I've developed a time stamping system in LabView using the PCI 6602. I first created a single module that takes the 80MHz clock as input and uses my signal that I want to time stamp as the clock. So I should get a time stamp resolution of 12.5 ns. Now everything worked fine when I was using a slow (20Hz - 30Hz) pulse train generator to test my program. But now that I'm ramping it up to faster rates things start to be going haywire. When I test it with say 2000Hz it seems to run fine, but when I look at my output file there are far fewer entries in it then 2000Hz would produce (there should be 2000 per second, it's not even close to that). If I go much higher the program quits altogether. So my question is there a max sampling rate? The website stated -> 80 MHz maximum source frequency, I thought this was the max sampling rate. Is this correct? If it does have a max sampling rate of 80MHz, why isn't my application working at this rate? Is it a max sampling rate of 80MHz on each counter channel? Or spread out among the 8 counter channels? I know that once I'm above the 3 DMA channels that I'll have a slower transfer rate to memory, but I was told that the counter should still record the data. What's more, I'll probably have data rates of max ~100kHz, this seems like it should be well within the counter limits. I was also told that interrupts would probably almost be able to handle this rate in real time too. I've posted my code and my tester application. Any help would be appreciated.

Second question is currently I have only 3 time stamping subVI's running (because only 3 DMA channels), now I want to increase it to 8 time stampers so I'm going to have to program it to use interrupts. Any good examples or resources to show me how to program the interrupts?

Thanks for any help anyone can offer,
Chris

[Kevin_Price]

Hi again Chris, I think I remember you from a previous thread...

I can't look at your code now b/c my internet PC and my LV PC are far from one another.  However I'll take a shot at addressing some of your questions.

1. Sorry, but you can't expect to perform sampling at 80 MHz.  It is true that the hw counter will be able to detect TTL edges and increment its count register at an 80 MHz (12.5 nsec) rate.  That's the meaning of the 80 MHz source frequency spec.  However, you won't be able to sample the contents of that count register value at an 80 Mhz rate.  The sampling rate will depend on getting those count register values off the board and over the PCI bus into the PC's system memory.  This is (groan) system-dependent but I'd guess you might be able to handle several 10's or perhaps even 100 kHz per channel using DMA (available for 3 counters).  The next 5 counters would need to use interrupts, where you're likely going to be limited to single-digits of kHz each.

2.  The method for programming interrupts is quite simple, though a bit obscure to find.  Essentially you will just add a single VI into your config chain where one of the input parameters specifies that you will use interrupts for data transfer.  That's all.  I don't recall exactly which VI it is at the moment, but can check it out and reply later if no one else answers in the meantime.

3.  You described data rates of ~100kHz.  If this is per-channel, you'll almost certainly have trouble with the interrupt-driven channels.  You may need to rethink the time-stamping.  As I recall, right now you are using the 80 Mhz clock as a Source and your photon detectors as Gates (sampling clocks), right?  This method will record the exact firing time for each photon.  Nice info, but lots of bandwidth required.

Can you consider a different measurement for your app?  One where you use the photon pulses as the Source and some other signal as the sampling clock?  You could probably sustain a 1 kHz sampling clock, and buffer up a bunch of "photons per millisecond" readings rather than timestaming every individual photon.  Just a thought to consider b/c I don't think you'll find long-term success with 100 kHz sampling using interrupts.

-Kevin P.

[Kevin_Price]

Chris,

Quick followup on DMA vs. interrupts.  In DAQmx, you can select it with a Channel Property node, though it takes some digging.  It's located at  DAQmx Channel Property-->Counter Input-->General Properties-->More-->Advanced-->Data Transfer and Memory-->Data Transfer Mechanism.  Whew!

I made a little utility that allows you to request DMA by default, but on failure it will then try for Interrupts.  On return it tells you which mechanism succeeded (or -1 if neither).  And for symmetry's sake, if you request Interrupts it'll try for DMA on failure, though I'm not sure there's a real-world situation where that's likely to help.

Here's the subvi which can be inserted into your config chain.

-----Begin edit------

One caveat -- I put this together on a machine without DAQmx hardware.  I expect it to work, but let me know if it doesn't.

-----End edit-----

Kevin P.

Message Edited by Kevin Price on 07-21-2005 08:31 AM

[ChrisErven]

Hi Kevin,

Thanks for your help. The labview solution with PCI 6002 card is a temporary solution. However, single digits of kHz should still be worthwhile until we start our second solution (using an FPGA to timestamp). However, I'm not getting even close to kHz. Currently testing with the pulse train generators and only 3 counters going (so they should all be DMA transfers) I get maybe 10 timestamps a second from each channel. So I'm assuming something must definitely be wrong to get so low a rate. Would changing the circular buffer size (samples per channel on the DAQmx Timing.vi) or the number of samples to read at once (a number used along with the property AvailSampPerChan to determine when to read) have any effect? Any other ideas? Also when the signal gets up in the 20kHz range rather then just being able to sample say 50% of these the program dies, it doesn't read any samples. Any ideas?

Unfortunately, I can't really consider a different measurement for the app. We're doing coincident measurements, so highly accurate time stamps to tell which photons go together is a pair is necessary.

I'm going to try your suggestions on interrupt programming now.

Thanks again,
Chris

[ChrisErven]

Hi Kevin,

One more quick question that I was thinking about. So when I mentioned about the circular buffer size, the 6602 card has a buffer built onto it? Do you know roughly how many events it can store? Sorry I guess what I'm asking is how the sampling works. So what I'm thinking is, say the 6602 has a buffer that can store 1000 samples. So if I wait until there's 1000 samples there and then read from the card, then I'm actually only doing a data transfer across the bus 1/1000th as much. I'm just wondering if I can optimize how many samples are stored vs how many times stuff is read for the card. Does any of that make sense? Or have I misunderstood how the card and buffers, etc work?

Thanks,
Chris

[ChrisErven]

Hi Kevin,

Silly me, I think I found my error for why I have such a low data rate. I went back and looked at my code which I wrote over a month ago, the DAQmx read returns an array (the size I'm assuming is "the number of samples to read at once" which I use with the AvailSampPerChan), for whatever reason I didn't realize that this was an array of data, so instead in my data processing loop I read only the first array element (don't know why, wish I could kick my past self, since this problem has been bugging me for days), instead there's usually a couple of hundred data points in the array. Anyways, so I think I'll have that fixed, I'll post a message if that isn't the problem.

As for the interrupts, I'm playing with that now. Where exactly in my setup should I be putting that subview, I tried putting it anywhere before my call to DAQmx Start Task, but LabView is still complaining about not enough DMA channels. I'll play with it some more, but if you know exactly where I should be putting it, let me know.

Thanks again for all your help,
Chris

[Doug M]

Chris,
I was looking at your post for awhile and playing around with the counters on my E Series board.  I was able to achieve around 200 kHz reads on the counter before getting an error using DMA on a single channel.  Using interrupts I was able to get around 20 kHz. You may not be able to get this kind of speeds using multiple channel counts, but I didn't test that.

I believe the reason you may be still getting an error message using the subVI that Kevin created is that it checks for an error, then changes the data transfer mechanism if there is an error, however I believe that an error won't be thrown until after the task starts, so and I don't believe this is a property that is settable at run-time, so you would need to simply use the property node that Kevin mentioned and set the data transfer type to be 'Interrupts'.  This channel propety node would be placed somewhere before the DAQmx Start Task VI.  I hope this helps!

Doug M
Applications Engineer
National Instruments

[Kevin_Price]

Chris,

I'm going out on a limb here a little, but here goes:

You wrote:  "...Would changing the circular buffer size (samples per channel on the DAQmx Timing.vi) or the number of samples to read at once (a number used along with the property AvailSampPerChan to determine when to read) have any effect? Any other ideas?"

There are two aspects to buffering.  One has to do with the DAQ board delivering samples from itself into system RAM, using either DMA or interrupts.  This is probably your most serious bottleneck.  However the other aspect has to do with your app issuing the DAQmx Read command to retrieve samples from the RAM buffer.

Changing the circular buffer size or the # to read at once will only affect the 2nd of these two aspects of buffering.  If the buffer is too small or you fail to retrieve data often/fast enough, the buffer will get overwritten.  The next time you do a default DAQmx Read, you'll get an error and no data back.  However, if you're setup for continuous sampling AND you setup DAQmx Read Property node values ahead of time, it's possible to request the most recent samples.  In such a mode, the circular buffer can overwrite over and over, but at any time you can retrieve recent data without getting the error.

However, I think your main problem at the moment is the DMA vs interrupt issue of filling the buffer as fast as the samples come in.  I'm not personally aware of a workaround that will let you ignore this error and retrieve whatever data happens to get transferred successfully.  I suspect the driver is designed (rightfully) to prevent you from retrieving chunks of data that may be missing samples at various points.  Better to throw an error than to give you mysteriously wrong data...

P.S.  Sorry about the little subvi -- one of the hazards of submitting without testing on hw.  Doug M figured out the problem with it and gave a solution in this same thread.

You wrote: "...So when I mentioned about the circular buffer size, the 6602 card has a buffer built onto it? Do you know roughly how many events it can store? ...  say the 6602 has a buffer that can store 1000 samples. So if I wait until there's 1000 samples there and then read from the card, then I'm actually only doing a data transfer across the bus 1/1000th as much. I'm just wondering if I can optimize how many samples are stored vs how many times stuff is read for the card."

I don't know how the exact size, but I think the on-board buffer is pretty small.  However, when you issue a DAQmx Read command, you are not reading directly from the board anyway.  You're reading from system RAM.  The DAQmx driver is busy behind the scenes making the board deliver its samples into system RAM for you, and I don't know of anything you can do from the app level to affect this.   Errrr, wait a minute.  I might know of something after all.

Here's another thread I got involved in a little while back.  It related to a different board doing Analog Output, but the "Data Transfer Request Condition" property just might also be relevant for counter input operations.  Again, I'm not near hw to check it out. 

Hope this helps,

-Kevin P.