Timed Acquisition using DAQ

[Esfahani]

Dear Sir/Madam,

I am conducting a dynamic light scattering (DLS) type experiment. I am using a SPAD type detector and Xseries PCIe 6351 DAQ from National Instrument.

The output of this detector is TTL pulses. So, I basically need to count the edges in some specific time bines. I need a 2D array with time bins as x and number of counts in each time bin as the y axis data, and preferably plot it on time so I can see the live results.

Would you please take look at my code attached to this email and see how can I fix the current issue. 

Many thanks,

Maryam Torfeh Esfahani

[Kevin_Price]

Can you "Save for Previous Version..." back to LV 2016 or earlier?

There are different ways to approach this.  The simplest is set up a 2nd counter as a continuous pulse train that establishes your time bins.  Use it as the sample clock for an edge counting task.  Because this will give you cumulative total counts, you'll need to do a simple finite difference in software to determine "new edges" per time bin.

Another way to approach this is via period measurement, but it's a little trickier to describe conceptually if you aren't too familiar with counters yet.

-Kevin P

[Esfahani]

Hi Kevin,

Thanks for your reply. please find in attachment the 2016version of code. I want to be able to set the sample rate. Also, Could you mind please show your solution in the vi code?

Best,

Maryam

[Kevin_Price]

So what IS the "current issue"?

Your code tackled the trickier (but more direct) period measurement method and looked to have the DAQmx config essentially correct.  I'm not currently at hardware or a signal source where I can really test.

I made a few minor mods, mostly cleanup and tidying.  The main *functional* changes I made were to:

- remove the outer loop entirely.  It didn't look necessary or helpful

- change the graph in the loop to a chart, which is more useful for showing a continuous stream of data

- change the data output tunnel from the (inner) loop to "concatenate" mode rather than "last value" mode.  I suspect this is the biggest "issue" you may have seen in your data -- most of it wasn't being saved.

- change the "dwell time" default value to 0.01 msec (instead of 0.001).  This makes for an effective sample rate more like 100 kHz instead of 1 MHz.  This is a safer, more robust realm to start in.  You can work your way back down toward 0.001 msec once you get things working well at 0.01 msec.

- queried a funny little property known as "Duplicate Count Prevention".  Search here and you'll find lots of past threads and no small amount of confusion (often mine).  True to form, I don't know what the *right* setting needs to be, so for now I'm just querying to make you aware that it exists and *might* be important.  I mostly expect the default value to work out well these days, but it's one of those gotchas that's gotch'ed plenty of us in the past.

- added a data dependency so gui controls related to file saving aren't read until after data acq is done.  This gives you a chance to modify them in the middle of a run

-Kevin P

P.S.  It will probably be a good idea for you to open your file once outside the loop, then stream data to it inside the loop, and close it after the loop.  Right now you'll be accumulating data in memory and saving once at the end.

[Esfahani]

Hi Kevin,

Thank you so much for all the kind help.

Also, that would be great if I could have a control to change the sample rate. Overall time elapsed, or changing the time data is being saved is the other parameter I need to save/know. Eventually, I like to be able to plot this data in some software like Matlab.

. Is 100 KHz you mentioned the reset frequency rate? or is it the sample rate? can you please elaborate?

I was wondering if we can have a quick troubleshooting session, using AnyDesk or something sometime? the code you kindly modified return error number 201313.

[Kevin_Price]

I can't really do any kind of remote-access live troubleshooting, sorry.

Other items:

1. Error -201313.  Here's the error text: "Non-responsive counter detected. NI-DAQmx reset the counter. Counter timebases at the specified speed must remain periodic, otherwise the counter can become non-responsive. Use an internal timebase or an external timebase that remains periodic."

    This is an odd one that I've never encountered.  I speculate that it might be considered a feature of the DAQ-STC3 timing chip in your X-series board, meant to *protect* you from a timebase with erratic intervals.  Most of my experience doing variable-rate period measurement was with older devices (M-series with DAQ-STC2, 660x timer/counter board with NI-TIO, E-series with DAQ-STC), and I don't ever recall being "protected" this way.

    Either the manual or NI support should be able to provide some more detailed info about this error / feature.  There are probably specs for what degree of variation is allowed and what's considered "overly non-periodic."

    One slight possibility: the error text mentions "timebases at the specified speed...".   The code never actually specifies an (approximate) speed, so perhaps there's a partial workaround by expanding the property node to explicitly configure the timebase rate with a reasonable value.

2. The other questions confuse me a little.  The code uses moderately advanced config methods that imply a pretty good understanding of how counters work.  But the questions are framed in a way that imply a lot less understanding of how counters work.

In general, period measurement is timed *implicitly*.  The effective sample rate is entirely at the mercy of the signal being measured.  When an interval ends, you get a measurement.  When the next interval ends, you get another measurement.  If the intervals vary in duration, so does the effective sample rate.  That's what "implicit" timing *means* in counter measurements.

However, you have a special kind of config where you are measuring periods of a fixed 100 kHz clock that you generate with another counter.  So you'll *happen to* end up with a constant 100 kHz sample rate.  Each 10 microsec, you'll be storing a count of how many new photon pulses occurred within that 10 microsec.

   This is an abnormal, somewhat advanced, and occasionally handy way to configure a counter task.

3. Spend time troubleshooting the photon pulse signal.  Bring up the shipping examples for Counter Input, focus on continuous edge counting and continuous pulse width and frequency measurements.  Run them while configured to measure the photon pulse signal and make sure you're getting reasonable results.  This lets you know whether the pulse signal is compatible with your counter.  I'd be sure to verify this before spending much time troubleshooting the real app.

    It's possible the odd error is caused by what DAQmx perceives as a *non-existent* timebase signal which it simply refers to as "non-periodic."   Just a wild guess though.

-Kevin P

[Esfahani]

Hi Kevin,

1) You suggested a simpler way to do this at the beginning of your email (solution 1), would you mind sending me that code?

2) Before we have this "DupCountPrevention" section, the code was running, but now I see this error "Error -201313", considering my hardware configuration, is there any easy way around this?

Best,

Maryam

[Kevin_Price]

1. I don't "have" that code, just knowledge of the recipe for it.  Right now I'm away from LV and only have time to very briefly share the recipe:

- one counter task to generate a continuous pulse train

- one counter task to continuously count photon pulses, using the pulse train counter output as a sample clock

- a simple software finite difference to give you the # new photon pulses per interval

2. I only queried the DupCountPrevention property, I didn't set it, so that *shouldn't* be the cause of an error.

    None of the other changes I commented on should have caused that error either.  Perhaps I changed something else that I didin't remember to comment on?   Or perhaps your original code would also produce that same error under whatever conditions you were trying my code?   Have you confirmed that the photon pulse signals are compatible with your counter as I suggested in msg #6?

-Kevin P