Disabling data overwrite Error 200141 NI-DAQmx

[sprice]

I am currently trying to setup a two channel buffered period measurment for photon counting in LabView 8.2.1 using a PCI-6602 counter-timer card.  If I use a pulse generator everything seems to be fine but if I go to a real signal where the spacing is random I always get a data overwrite error.  If I use a LabView program using the traditional DAQ code I can just bypass the error for the read buffer module and continue with my measurement. 

I have spoke with some other groups and this is their method for dealing with the data overwrite error as the FIFO buffer on the 6602 card is very small and can't handle bursts of photons.  The data loss was minimal for the other groups but they had programed with the traditional NI-DAQ drivers so ignoring the error was not a problem.

My experience with LabView is only about 2-3 weeks so I'm still trying to learn but would like to write our programs using the NI-DAQmx driver.  However, even with all error handling removed from my programs I still get the data overwrite error for detector dark counts which are a very low count rate (~100Hz).  It seems that the NI-DAQmx modules have a built in error handler that cannot be disabled making them useless for these type of measurements and forcing me to learn the traditional NI-DAQ drivers and lose the extra funcionality of the mx drivers.

If I should post this over in the counter/timer boards please inform me and I appoligize for the error.

[falkpl]

are you counting the time between photon triggers or the number of photons within a time sample? ther dark counts are 100/sec what is the fastest rate (saturation?) you expect?

[sprice]

I am currently trying to count the time between photon triggers.  The fastest count rate that I would expect in my measurement would be ~100,000 counts per second.  But the counts come in bursts of photons.  I am trying to do measurements with fluorophores passing through an excitation beam and collecting the fluorescence as they pass by.  This causes short bursts of high counts and then a short period of low counts when there is nothing being excited.

[Matthew_W]

Hello Sprice,

 The Clear Errors.VI found in the Dialog & User Interface Palette will supress error messages that are generated.

  Let's see if we can get your buffered period measurements happening without errors. How are the photon triggers
wired to the counters on the PCI-6602? A buffered event count would use active edges on the source of a counter
to increment the count, a edge on the gate to latch the count into memory. Are you using both counters for this operation?

 Thanks, have a great weekend.

 MatthewW
 Applications Engineer
 National Instruments

[falkpl]

Also make sure the edges are clean (TTL) a bouncing signal will cause the trigger to be astable and act as many photon counts.  If you use the test pannel in MAX you can see if the counts are incrementing as expected. (IE dark counts are 100/second and increase with small light leaks)

Paul

[sprice]

Sorry for the delayed reply.  Had a small flood in the lab today to take care of.

Matthew W - The way the vi has been set up and the photon detector hooked up is the source edge is the 80MHz timebase on the 6602 card and the photon detector is wired to the gate for the counter.  I've got two counters going in my measurement one for each photon detector that I am using.  Unfortunately the Clear Errors.VI does not work as the error that is generated persists even after being cleared.  I did find a way to turn off the automatic error handling for my vi which let me bypass the DAQmx Read.vi with my error handling.  Now when my vi encounters the -200141 error it continues to run but there is no more data coming from the card.  Almost as though the FIFO buffer clears and doesn't accept any more counts from the counter.

But it does not behave that way using the Traditional NI-DAQ drivers.

falkpl - my edges are clean and I get the counts/sec that I expect but that was a good thing to check that I had not considered.

[falkpl]

So if you are counting time between photons, you are essentially using the photon signal edge as a trigger and the clock as the source, and taking continious retriggerable counting.  This will only overrun if the photons come in at a faster rate than you can read from a buffer, 100kHz is not fast enough to cause a problem, but make sure of this:

1.  Make the buffer big enough to hold at least 1 second of data - that is at least 100,000 samples.

2. Read the buffer faster that 1 second and read all points. I would suggest to use a producer consumer loop where the data is read fast 10Hz and ququed up to an asynchronous loop for processing and display/file IO. (see producer consumer template)

3.  MAKE SURE YOU ARE USING THE DMA CHANNELS*** the 6602 has only 3 so use 2 for your counters.

4. Disable the CI.DupCountPrevention, this is true by default and will filter out events with zero (probably not going to happen in your case since the 80MHz clock is fast enough to have many counts between photons.)

There is no reason that you will ever get a buffer overrun if your photons are not comming in faster than 100kHz and the trigger is clean.

Paul

[sprice]

Thanks for the suggestions.  I went ahead and attached my vi that I'm trying to use with NI-DAQmx.  I believe that I have already implemented all but number 4 from your suggestions and I am possitive that I am not getting any zero events as the dead time of my detector is at least 50-80ns.  I have no problem with a clean 100kHz signal from a pulse generator but 100kHz from photons happens in bursts such that there could be an instantaneous count rate of say 1Mhz which is what fills the FIFO buffer before we can read it out.

I did find another thread after searching for awhile last night that looks like the exact same issue that I am having:
http://forums.ni.com/ni/board/message?board.id=40&message.id=4734&view=by_date_ascending&page=1
Reply 10 is exactly what I am experiencing with my vi when I encounter the error

I really cannot accept the option of using a small finite buffer and contunuously resetting and restarting the task as I need to perform a time dependent correlation on all of the data and stopping and starting would lose all of my correlation information that I am looking for.

I have a vi written using the Traditional NI-DAQ drivers that ignores the data overwrite error and am able to continue to collect data even after the error occurs.  I can continue to develop my software using the old drivers but am having trouble figuring out how to trigger my two channels so that they start at the same time (but that is a whole other issue that I can work on later).  I know how to do the triggering to start the two channel measurements using NI-DAQmx (hence my desire to develop using it).

Thanks
-Shane

[Matthew_W]

Sprice,

There is a DAQmx property node to enable Data Overwrite Mode, this will allow the driver to overwrite samples that have not yet been read without throwing a error and disrupting the acquisition. This can be found in Labview by placing a "DAQmx Read Property Node", then selecting Overwrite and wiring a constant to the input of the property node. Here is a forum post where they talk about implementing this and what other measures will help obtain the latest data from the buffer.

Additionally, the Clear Error VI should be placed on the output of the DAQmx Read to clear the errors.

Unfortunately, once a DAQmx Error occurs then you will need to handle the error and re-start the task to begin acquisition again. This can be mitigated in this situation with techniques such as enabling OverwriteMode, reading the buffer more often, larger buffer, reading all available samples from the buffer etc.

Hope this helps, best regards.

MatthewW
Applications Engineer
National Instruments