Higher sampling speed for accurate counter measurement

[ssomnath]

I have a BNC 6259 USB M series DAQ. I am currently using the DAQ Assistant to perform simple rising edge counting measurement with on-demand single sample measurement mode. I tested my VI with a known square wave signal from a function generator and I am clearly missing a few edges. I think the solution lies in sampling faster. However, I haven't been able to understand how to use the clocks to set up the continuous sampling mode. I tried the forums and i found articles that were close but not quite exactly the problems I am facing like (http://forums.ni.com/t5/Digital-I-O/trying-to-use-NI-6251-s-DIO-port-as-input-and-output/m-p/448035#...) or (http://forums.ni.com/t5/Multifunction-DAQ/Using-Counter-of-PCI-6024E-with-Quadrature-Encoder/m-p/984...). Any guidance here would be great.   

[Kevin_H.]

I believe you're right about needing to sample faster. Are you trying to hardware time or software time this task? There are some great examples in the example finder for either. Hardware Input & Output->DAQmx->Analog Measurements->Voltage. I'd try Acq&Graph Voltage-Ext Clk.vi.

[John_P1 · Accepted solution]

Actually, the timing shouldn't have anything to do with the edges being detected.  Configuring a sample clock for an edge count task just lets you deterministically sample the count register and doesn't have any impact on the edges that are being counted.  Also, the Analog examples don't really have anything to do with what you seem to be asking about.

So... this still leaves the question unanswered as to why you might be missing edges.  Perhaps the following information might shed some light on the matter:

1.  It's possible you are not configuring the counter exactly as you think you are.  Can you post the VI you are using?  As a point of reference, the Count Digital Events shipping example does not use any sample clock timing and just polls the value of the count register with a software loop, but the counter should not miss any edges present on its source input.  There are hardware-timed examples available as well, but these should not be necessary unless you need a constant specified dt between your counter samples.  To use the sample-clocked examples you would need to generate a clock from either another subsystem on the board or use an external clock.

2.  Assuming the configuration of the counter is not the issue, perhaps there is a problem with the method you are using to determine if you are missing edges.  How do you know you are missing edges?  Does the function generator output only a finite amount of pulses?  Are you starting the counter before you start outputting the pulses?

3.  If the above two points don't raise any red flags, it seems likely that the counter is simply not registering some of the pulses from your FGEN.  Can I assume that the output of the FGEN is 0-5V TTL?  What is its frequency and duty cycle?  The maximum external source for the counter on M Series DAQ products (like the 6259) is specced at 20 MHz, but this depends on having a clean signal with good connections.  At frequencies higher than this, the front end bandwidth of the PFI lines becomes the limitation.  If you have a specifications document available for your FGEN I would like to be able to see it.

Hopefully this gets you started on the right track to troubleshooting the issue--looking forward to hearing back with more information.

Best Regards,

[ssomnath]

Thanks for getting back. I haven't had time to fully read your response. For now, I have attached the VI that I am using.

[ssomnath]

Hi, the example worked great up to detecting the TTL pulses up to around 5kHz. After this range it started missing some edges again. Is this the maximum frequency at which I can count edges? I am using an Agilent 33250A waveform generator for supplying a clean 3.3V tall square wave with 50% duty cycle.

Another question I have is that if I use the same board to measure analog voltage data (continuous sampling at 300 kHz with a sample clock) and a counter to measure rising edges, would there be any synchronization problems when I poll for the edge count and analog data separately using DAQmx counter and DAQmx read operations respectively in the same cycle?

Thanks! 

[Kevin_H.]

When you say you're clearly missing edges, how exactly are you determining this? I know it's a nit picky question, but I figured it'd be worth asking while I look for possible causes. Syncronization shouldn't be a problem so long as you're hooked into the same reference clock.

[ssomnath]

I am not synchrnozing any clocks since the signal is being generated from an external function generator. Or rather, I don't know how to synchronize a clock from my function generator and my DAQ.

In my experiment,  I let my VI run for at least 1 sec, find the count and see if the count matches the frequency of the signal being generated by the function generator. It worked fine up to 1 kHz if I am not wrong. Beyond this, I missed some edges. 

[Kevin_H.]

If you're using that example John linked then the software timing of the poll is probably what's making it look inconsistent. The count is running in hardware but the poll is running in software which means that you can't (unless you're on a real-time system) guarantee it will poll at exactly the same time each time. It could be getting a value that is actually slightly behind what should be the current real value. Try increasing the time you're running the count. The percentage of missed edges relative to your theoretical should be diminishing the longer you run it. You can also try running with a much higher sample rate and see if the percentage drops proportionally.

[ssomnath]

I perform continuous sampling of analog voltage data using a sample clock. So, I tried the same approach with counters but I got an error (VI attached). It asks for an external counter... 

Perhaps it is time I explain what I am trying to do with this VI. I am working on a raster scanning experiment that requires me to grab data for each line of my scan. The equipment controlling the scanning process can't save data fast enough and is not flexible in the kind of data I need to save hence the reason I am doing this in Labview. However, one thing that it does provide me is a digital pulse each time a line is completed or a scan frame is completed. I am using two counters to track the ends of each line of the scan and the end of a set of lines (a scan "frame").

Currently, for code-development purposes, I am running the scan fairly slow, such that the line pulses arrive at approximately 1Hz. However, once the code is tested, I will be ramping up the scan speed which means that the line pulses that I need to track will arrive at a few kHz.  I need to keep grabbing analog voltage data as a 1D array in time and then cut it depending on the line / frame pulses to form a 2D array of data that corresponds to data collected in a frame of the scan. Each time a frame is completed, it would be best (in the interest of reducing the load on my memory) to dump the data to disk.

Things worked great when I tested to see if I can use the line pulses to convert the 1D array of data into a 2D array. However, in hte next step when I tried to write the data corresponding to a frame to a file I got an error saying that the analog read was timed out or something. I take it that the file IO took too long and was probably done serially which bottle-necked my main analog data read. I have attached a few VIs of my work. If I were writing this code in C or other languages, I would have solved this problem by maintaining a separate thread just to dump the data to the disk so that the main thread (collecting the analog voltage data) was not hindered in any way.

Is there a Labview equivalent solution for this?  

Futhermore, as I have explained earlier, this entire data saving operation needs to occur much faster. I expect to be saving entire frames of data every 10msecs. How best could I adapt my code to solve this problem? I have been reading up on some sort of Direct Memory Access things but I couldn't fully understand how that would help.  

[Kevin_H.]

If your file output isn't happening async (I thought it was supposed to be default, but I could be wrong), you can always make a subVI whose job it is to write outputs to file and call it async. In order to do this, see the VIs in the Programming->Application Control part of the Functions Pallette. You'll need to open a reference, call the Run function with an invoke node, set Wait Until Done to false. This will cause the VI to run independentally. You'll need to pass the data into the subVI with an Invoke Node and Control Set Value method. It's not too difficult once you figure it out and it'll guarantee an async run. It will not create an independent instance of the VI, but will run it in another thread.