event counter misses events

[TJWhit]

The only posts I saw close to this are quite old and I didn't see any real solutions so....

I am using LabVIEW 2014 with a PXIe-6612 counter/timer to count fringes in a Michelson interferometer. I need to check the count so I can know the location of the travelling mirror. "Checking the count" means I send a pulse to the counter to dump the count to a buffer so it can be read. I noticed when I put a 3 ms delay in the loop that checks the counter, few if any error occurred in a short-duration count but if I let the loop go as fast as possible, or I kept the counter going for a long period of time (or worse, both), errors would always occur. Errors always manifested as a count that was too low - I was missing counts. Further checking showed that the slower I checked the counter, the fewer errors I had.  

I am convinved now that this happens when the request to read the count coincides with the actual event arriving at the counter. Obviously, the more times the "read count" request is made, the higher the probability that there will be a collision with the actual event arriving at the counter. This is a hardware issue and the only fix I can see is to implement synchronous read requests that are separated from the actual event by some minimum time. I have done this and I now get zero errors. The question arises as to how one might get around the problem if the events are random, say in a photon-counting experiment. Does anyone know a workaround that allows you to count random events with zero errors (other than not checking the count)? 

[Karen_M]

Hello,

I have a few questions for you. The first is what are considering a long period of time? The second is what is the frequency of counts at which you are reading? 

Also I was wondering if you could attach your work around code that you made, and why reading less often is problematic for you? 

Thanks!

[TJWhit]

---

@Karen_M wrote:

Hello,

I have a few questions for you. The first is what are considering a long period of time? The second is what is the frequency of counts at which you are reading? 

Also I was wondering if you could attach your work around code that you made, and why reading less often is problematic for you? 

Thanks!

---

A long period of time in this case is anything more than about 3 seconds. The events I was counting were coming every 63 microseconds or about 16,000 per second.

The work around was to synchronize the pulses that probe the event counter with the event pulses but delayed about 30 microseconds. I just use the event pulse as the trigger for a delayed single pulse, which is then used to probe the event counter. Then there is never a chance for a collision. The annoying part of this workaround is that it requires another counter (for the delayed pulse).

The reason reading the event counter less often is problematic is that I want to change the gain on the detector at a specific position. I suppose I could monitor less frequently and then as I get close start monitoring more often but the simple method is to monitor often for the entire time. If I monitor on every 3 milliseconds, I may not catch that I've reached the desired location for as many as 48 fringes, which is barely acceptable. 

A quick analysis of the "dead time" - probing the event counter every 3 milliseconds for 3 seconds of mirror travel is a total of 1000 probes. In this case, I see a one-fringe error maybe 1/5 the time (2-fringe errors occur less often, etc). Without going into Poisson statistics, I think that means there is about a 0.2 msec dead time after a probe pulse before the counter will "see" a count again. This is easy to test. Set up  1 million pulses (50 KHz) on a counter and input them to an event counter. Then run asynchronous pulses to the event counter to read it at least 10,000 times while it is counting. The counter will have read less than a million at the end of the million pulses. The more often you read the event counter while it is counting, the fewer events it will actually count.

[John_P1]

Can you post a code snippet showing how you have configured your task?  What you're describing doesn't make sense to me unless you happen to be restarting the counter input task.

If you run something like this you shouldn't be having these issues:

Best Regards,

[TJWhit]

---

@John_P1 wrote:

Can you post a code snippet showing how you have configured your task?  What you're describing doesn't make sense to me unless you happen to be restarting the counter input task.

Best Regards,

---

John, I'll post a snippet tonight (don't have access to it where I am now) but your example doesn't use a reference trigger. I'm supplying an external reference trigger to read the counter at the time of the reference trigger. It is this reference trigger that I believe is colliding with the event pulse and causing problems. 

Regards,

[John_P1]

I would be interested in seeing the snippet.  If you're using the term "reference trigger" in the same way that NI does, then this could be your problem in that a reference trigger stops the acquisition.  However, as far as I'm aware reference triggering should not be supported for counter input tasks and trying to configure it will generate error -200452 (unsupported property).  Having said that I don't have a 661x to try it on, but on my 6351 I do get the expected error when trying to configure a reference trigger for a CI task.

In any case, from what you've described (you'd like to "read the counter at the time of the [signal]"), you should have this signal configured as a sample clock as in the snippet I posted.  The sample clock stores the value of the count register into a buffer which can be read from software.

Best Regards,

[TJWhit]

---

---

@John_P1 wrote:

I would be interested in seeing the snippet.  If you're using the term "reference trigger" in the same way that NI does, then this could be your problem in that a reference trigger stops the acquisition.  However, as far as I'm aware reference triggering should not be supported for counter input tasks and trying to configure it will generate error -200452 (unsupported property).  Having said that I don't have a 661x to try it on, but on my 6351 I do get the expected error when trying to configure a reference trigger for a CI task.

In any case, from what you've described (you'd like to "read the counter at the time of the [signal]"), you should have this signal configured as a sample clock as in the snippet I posted.  The sample clock stores the value of the count register into a buffer which can be read from software.

Best Regards,

---

I'll check for that error tonight. I've done this on a PCI-6602 and a PXIe-6612. It works beautifully as long as I make sure my "reference" trigger (I'll check if that is the correct name) is delayed from the rising edge of the event by a few microseconds.

But I can't use the snippet you posted. I have to know the number of events exactly when the external trigger pulses. Being off by even one is not acceptable. By the time I see the "reference" pulse on a Digital Input, then read the counter, the number of events could change.

Thanks for your input. 

Regards,

[John_P1]

---

@TJWhit wrote:

But I can't use the snippet you posted. I have to know the number of events exactly when the external trigger pulses. Being off by even one is not acceptable. By the time I see the "reference" pulse on a Digital Input, then read the counter, the number of events could change.

---

This is precisely what a sample clock does in the context of a counter task.  The signal connected to the source of the counter will increment the count register independently of the trigger sample clock.  When the external trigger sample clock occurs, the current value of the count register is stored into a buffer.  This all happens outside of software involvement.  You will end up with one sample per edge of your external trigger sample clock stored in a buffer that you may read from whenever you like (including while the acquisition is still taking place as in my example).

The X Series user manual describes this in more detail in chapter 7 (the counters on the 6612 should be the same as those on the X Series devices and I prefer this manual to the 6612 one--be aware that the 6602 uses a different chip and has some slightly different behavior in a few cases).  

EDIT:  Changed "trigger" to "sample clock" to be consistent with NI terminology.

Best Regards,

[TJWhit]

I should not write these things without looking at the code. Ignore my last couple of posts. I am not using a reference trigger. What I'm doing is in the two snippets below. This looks a lot like your snippet but I had to use interrupts rather than DMA because the 6602 doesn't have a DMA channel for each counter and all the DMA channels were already used.

With this code, I lose counts! The number lost is higher when I pulse PFI10 more often to read the counter. For example, when I read the counter every 3 msec for about 3 seconds, typically none to 1 count is lost. However, if I pulse PFI10 as fast as I can read the data buffer from the counter, I get a couple of hundred counts lost over that same 3 seconds. 

 

[John_P1]

In the intialization portion of your code (the first snippet) call DAQmx Start at the end.  You can do this instead of reserving the task.  

As it is right now, the task is implicitly (re)started each time the read is called.  With a higher sample rate the read would execute more frequently assuming a fixed "samples per channel" input to the Read.  During the time it takes to restart the task, the counter is not armed which would explain the missing counts.

Best Regards,