Timing source for a Timed Loop

[tycho75]

Hi,

I'm developing a VI that reads two analog inputs (through a USB-6212 interface). One of the input is connected to a optical fork sensor and the other is connected to a photomultiplier tube (PMT, connected through an amplifier).

The PMT gives short pulses (a few microseconds) so I need to use the fastest sampling speed. The optical fork gives a pulse every ~2 seconds. As in this application timing is important, I decided to use a timed loop.

However, I could only make the timed loop work with the default 1 kHz source. When I try to use a 1MHz source, it fails with error 822. I also tried to create a counter and use it as a source for the timed loop, but it didn't work either.

How can I use a different timing source ?

Thanks for your help !

Cheers,

JB

I attached the VI. I'm using LabView 2009 on Win XP.

[xdaf]

You can't: 1MHz timing source is available only on a real-time environment (such as Labview real-time and Labview FPGA). Obtaining 1MHz precision under a complex operating system (such as Windows) is impossible.

Regards

[tycho75]

Ok, thanks for the answer.

Is it not possible to use a counter ?

[Mcdan]

tycho,

I'm not clear on what your timing requirements are for your application.  You mention a photomultiplier tube which issues pulses that are on the order of a few microseconds in length.  You also mention an optical fork which output pulses at a low rate.  Does one event trigger the other, or are you simply measuring the output of both of these?

The USB-6212 is capable of sampling at 400 kS/s (though this is aggregated over all channels in your task).  This means that if you are reading from two channels, the highest rate your device is capable of sampling at is 400 kS/s / 2 = 200 kS/s, or a sample every 5 uS.  If the pulses from your photomultiplier are not wider than this, then you will miss some pulses.

I'm unclear about why you need a timed loop to run at such a high rate.  With the VI attached, you've programmed your USB-6212's hardware to continuously sample data at a rate of 200 kS/s.  The hardware will sample data at this rate, then transfer that data to a buffer in your computer's memory.  The DAQmx read vi will simply read data from this buffer in your computer's memory and return it to your LabVIEW VI.  You specify that it should read 5000 samples.  Essentially, DAQmx Read should wait until there are at least 5000 sample available in memory, then return those to you.  Since you sample at 200,000 S/s, it should take approximately 25 milliseconds to accumulate 5000 samples.  This corresponds to a loop rate of about 40 Hz.  Since the amount of time it takes to actually acquire 5000 samples is the gating factor on your loop's timing, there really is no need to use the timed loop at all.  Simply calling the DAQmx read function will block a regular while loop until data is available, thus iterating the loop at the rate at which data is available.

Hope that helps,

Dan

[tycho75]

Hi Dan and thanks for your reply.

Actually, my application involves a radioactive source which is put on a turning plate (like a record player).

The photomultiplier is used to record gamma photons produced by the radioactive source. I checked that the pulses are long enough to be recorded properly at 200 kS/s.

The optical fork sends a pulse for each turn of the plate. I use this information to set a counter to 0 each time the plate makes a complete turn. This counter will be used later in order to deduce the position of the plate for each photon detected. 

As I need the best sampling rate for my PMT pulses, I set the sampling speed to the maximum allowed (I set it to 200kS/s because if I put it higher, I have a warning telling that the ADC is overloaded). In addition, I need the best precision for the determination of the position of the turning plate. That's why I used a times loop, to guarantee that the loop is executed at a constant speed, and not at a speed which depends on the CPU load.

When I try to read less than 5000 samples at a time, I get an error saying the buffer is full. If I understand properly, that means that I read the buffer too slowly as compared to the speed with which it is filled.

So I have 2 questions:

+ Can I set the sampling speed to 400 kS/s with the Timing VI or do I have to set it to 400 / number of inputs (that's what I understand reading the documentation) ?

+ Would it be possible to allocate a bigger memory for the buffer so that I can read less samples at a time and then increase the speed of the loop ?

Cheers,

T.

[Mcdan]

tycho,

Sounds like an interesting application!

I'll start off by answering your questions:

Can I set the sampling speed to 400 kS/s with the Timing VI or do I have to set it to 400 / number of inputs (that's what I understand reading the documentation) ?

You'll need to set the sample rate to 400k / number of inputs.

Would it be possible to allocate a bigger memory for the buffer so that I can read less samples at a time and then increase the speed of the loop ?

Yes. When doing continuous sampling, the "samples per channel" input to the DAQmx Timing VI will set the buffer size.  It is worth noting though, that if your loop is taking too long to run (ie... hardware is producing samples faster than software can read them, all this will do is buy you additional time before the buffer overflows.

This might sound odd, but I wonder if you wouldn't be better off allowing the loop to iterate freely rather than trying to force it to run at a constant rate via the timed loop.  Basically, since you're operating on windows, your application will not run deterministically.  Because of this, I would expect that from time to time, you will end up with data accumulating in your buffer.  By allowing the loop to run freely, you'd essentially allow the loop to 'catch up' when the CPU is not busy.

If you read without error, DAQmx will give you all data the the device has sampled in order.  Because of this, you should be able to correlate the data read to your rotating table's position by knowing how many samples you have read so far.  In the example you posted earlier, the first call to DAQmx Read would return you data from time 0 to time 25 mS.  The second iteration of the loop would give you data from time 25 mS through 50 mS, and so on.  If you are measuring signals from both the PMT and the optical fork, you should have a very complete view of when your PMT pulses occur relative to your optical fork pulses without making any assumptions at all about the timing of your DAQmx Read loop.

I hope that makes sense,

Dan

P.S.  This assumes that your turning plate is turning at a constant rate.

[tycho75]

Hi Dan,

Thanks for your answer. I replaced the timed loop by a regular while loop and it works fine.

What I had to do in addition is to change the number of samples to be read so that this number of samples corresponds exactly to one turn of the plate. Then, I modified the number of samples to acquire so that I don't have any error...

I'm still confused with the buffer. I read in the 6212 specs that the input FIFO size is 4095 samples. This FIFO is built-in in the 6212, right ? Is there another buffer allocated in the computers memory ? Is there a way to know exactly what is the size of the buffer ?

Cheers,

T

[Mcdan]

tycho,

Let me start by giving you the simple answer.  Yes, there is a FIFO built into your USB-6212.  This fifo is 4095 samples in size.  Data is transferred from this FIFO into a buffer in memory on the host computer.  The size of this buffer is  settable (either through the "samples per channel" input on the timing VI for continuous tasks or by using the DAQmx Configure Input Buffer.vi).  If you do not set the buffer size by using either of these methods, then DAQmx will pick a default buffer size for you  based on the sample rate of your acquisition.  See this knowledge base for details.

In reality, in addition to the AI FIFO and the host buffer, there are a couple of intermediate buffers used in the transfer of data between the AI FIFO and the host buffer.  You can get an overview of the streaming architecture used by DAQmx for these devices by reading about NI's Signal Streaming architecture.  These intermediate buffers allow DAQmx to maximize throughput through USB, but introduce a bit more latency between when your device samples the input, and when that sample is available in the host buffer.

Hope that helps,
Dan