DAQ wierd behaviour measuring counter input

[Alan_C]

I've attached my current benchmarking code in snippet

What I'm trying to do here is using PFI 10 (external TTL pulse from other device) as sample clock and PFI 11 is attached to a digital PMT so I can get photon count when receiving the external pulse.

I have to use external pulse because the experiment requires sending pulses in different frequency over time.

It seems fine when I'm using MAX test panel as the count goes smoothly up, however I'm facing 50% fail when using my external pulse to tell DAQ to make counter acqusition. The first acquisition success, second fail, third success, fourth fail, repeat. Am I doing something wrong making the external pulse failed to be recongnized by DAQ? My current benchmarking is using standard function generator so I don't think the changing interval between pulses caused the acqusition failing.

[Kevin_Price]

Issues I see:

1. You are starting and stopping the task repeatedly, every iteration of the loop.  No need.  It's a continuous sampling task so you should start once before the loop, iterate over the reads, then stop it once after the loop.

2.  You're following a bad practice by not wiring the error inputs and (especially) most of the error outputs.  This isn't directly causing your problem, but does reduce your ability to pinpoint the source of the problem during troubleshooting.

3. You haven't identified the error you get or other specific symptoms of your "fail" outcome.  Things I'd scrutinize for appropriate values are:

- sample rate (on call to DAQmx Timing).  Is 1000 Hz a reasonable estimate for your external pulse signal?

- # samp per channel & timeout (on call to DAQmx Read).   Are these compatible with the actual incoming pulse rate?

-Kevin P

[Alan_C]

This is just a benchmark vi, not the experiment using one so I've wiped a lot of detail.

We were facing random fails when making acquisitions in the experiment usage version and I've digged into details to find DAQ was the reason.

1.I'm doing this because the experiment will be requiring different settings on parameters so it's not always the same task. TBH I should've made the benchmark vi creating and clearing task every iteration to simulate our condition.

Also, when the start task was successful on read, following reads are always successful; if we fail on first read, we need to stop task and start all over which was the main frustration.

2.Again this is just a benchmark vi so, okay I admit I was lazy on this one, I've enabled auto error handle just to see where can went wrong.

The only error popping out is error -200284 at daq read (read timeout not enough sample).

3.1000 Hz was enough for our need and I'm sure the counts / timeouts are correct.

Function generator was running at 300Hz while every iteration reads 100 samples with 2 seconds timeout.

Half the iterations fail to read any sample while the other half reads 100 successfully.

BTW we were using NI USB 6341

[Kevin_Price]

- agree that a 300 Hz input with a request for 100 samples and 2 second timeout are easily a compatible set of parameters

- the fact it works half the time on alternate attempts makes it seem unlikely to be a DAQ hardware or signal issue.  It sounds more like software, maybe something hanging around in a shift register?

- on the other hand, the timeout error you reported sounds more like a signal, parameter, or timing issue.  Please try the following: set the "number of samples per channel" to read at -1, a special value meaning, "give me all the samples that happen to be available right now."   Add a msec wait timer to the loop to make it iterate every 100 msec or so.  Keep the timeout at 2 sec.   Wire up the error ins and outs for debug probing.   Any difference in behavior?

- the function generator is definitely generating an uninterrupted contintinous TTL pulse train, right?

-Kevin P

[Alan_C]

It's even more buggy now.

Setting sample per channel to -1 and 100ms wait per iteration produces no error but all iterations are getting no sample at all.

Function generator is working properly, verified with oscilloscope.

I don't get what you mean by "something hang in shift register"

I thought DAQ calls are synchronous thus these sequential operations shouldn't produce any kind of racing or hanging

[Kevin_Price]

If the latest attempt ran without error but didn't produce samples, it sure sounds like you aren't getting a good sample clock signal on PFI10.  Lack of good edge count signals on PFI11 could potentially contribute, but that's less likely.  What DAQ device are you using?

The symptoms you describe are very abnormal so let's break this down.  Use either MAX or the shipping example "Counter - Count Edges.vi".  Make sure your board "sees" the function generator edges on PFI10.  Then also check that it sees the edges from the PMT on PFI11.

If those work, please repost the code that *doesn't* work right.  It isn't clear to me whether you're testing with a variation of the simple code you posted or with your more complete application. 

-Kevin P

[Alan_C]

NI USB 6341

Verified both input are getting correct counts in MAX.

NDA doesn't allow me to post the full detailed vi so I cut only the problematic part down along with some related inputs.

This will be performing single measurement and we'll be making a lot of measurements automatically in one experiment, hence failing any will cause huge trouble.

[Kevin_Price]

First reaction: nothing in the code looks particularly suspicious to me.  But you've verified the TTL viability of your signals, so there must be *some* reason for the behavior you're observing.  Thus, I'll get into speculative nit-picking.

1. FWIW, I generally never use DAQmx Create Task.  I start with DAQmx Create Virtual Channel, wiring in a physical channel while leaving the task input unwired.  I don't know what the possible implications of the "auto-cleanup" setting might be, so that's one point of possible suspicion to me.

2. I assume that you've confirmed during your debugging that the correct PFI terminal names are making it through your code to the point where you configure the counter task, right?   Breakpoints, probes, highlight execution, whatever, you *are* sure that the task is getting configured as expected?

3. I've never used the DAQmx Timing property node to "allow overruns" on the sample clock.  Reading the meager help, this seems like a useful property that can help and shouldn't hurt.

4. For diagnostic purposes have you tried removing the call to DAQmx Timing?  That'd make an on-demand task where you would later call DAQmx Read for a single sample at a time.  That would at least help to distinguish between issues with the edge count signal config vs issues with the (no longer present) sample clock signal config.

5.  I recall a time or two where I found that it seemed important to call DAQmx Stop before calling DAQmx Clear.  On the off chance that this somehow contributes to the way things alternate between working and failing, you might want to insert a DAQmx Stop.  (I doubt this is the real problem but is probably a decent habit.)

Other than that, I'd highly recommend that you do some careful troubleshooting.  (Maybe you already have, but I have no way to know that from here.)

    Up in the icons below the menus, turn on the "Retain Wire Values" setting (right next to the execution highlighting lightbulb).  Put a conditional error probe on the error out from DAQmx Read and set it to pause on error.  Run the program and when you catch one of your errors, go probing around to see if any wire values don't seem right.

-Kevin P

[Alan_C]

Okay I guess something has gone nuts in LabVIEW itself.

In Fail.png the code is getting 50% fail in multiple runs

In Success.png the code is getting no fail at all, even if I try using "run continuously".

Simply adding a for loop read is preventing it from getting timeout?

This is getting more confusing 

[Kevin_Price]

Strange.  I can't come up with a theory why multiple reads in a For loop would always work while a single read without a For loop would give a timeout half the time.

It'd be weird if things changed, but have you tried setting N=1 on the For loop to see if it still always works?    Still no theories, just curious.

Meanwhile, try deleting the "DAQmx Create Task" call and insert a "DAQmx Stop" before the "DAQmx Clear".  See if things behave differently.

-Kevin P