event counter misses events

[TJWhit]

---

@John_P1 wrote:

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,

---

The DAQmx Start comes later in the program before DAQmx Read is done. Reserving the resources at this point means the Start takes less time later where it is critical. 

Please understand that this program works perfectly when I synchronize the PFI10 pulse with the event (PFI10 comes 32 usec after the event) but I lose event counts when I run PFI10 asynchronously. 

[John_P1]

Are you absolutely sure that the task is being started explicitly before the read is called?  Syncing the sample clock to occur just after the event would allow for the task to restart in between events, so the fact that synchronization prevents the issue from occuring doesn't affect my hypothesis.

Try running my example from message 4 of this thread.  If my example shows the same behavior, then it sounds like there really is some major underlying bug in NI's counters.  If it does not, you'll have to figure out how your program is different from mine (to start, I'd double-check that you are actually starting the task before reading and that you are handling any errors coming from the start / read calls).  

Best Regards,

[TJWhit]

---

@John_P1 wrote:

Are you absolutely sure that the task is being started explicitly before the read is called?  Syncing the sample clock to occur just after the event would allow for the task to restart in between events, so the fact that synchronization prevents the issue from occuring doesn't affect my hypothesis.

Try running my example from message 4 of this thread.  If my example shows the same behavior, then it sounds like there really is some major underlying bug in NI's counters.  If it does not, you'll have to figure out how your program is different from mine (to start, I'd double-check that you are actually starting the task before reading and that you are handling any errors coming from the start / read calls).  

Best Regards,

---

Absolutely, positively sure. The fact that this code runs flawlessly when the PFI10 line is synchronized to occur after the event, and it loses data when PFI10 is asynchronous, is proof that there is a problem. The only difference between these two cases is synchronously vs asynchronously pulsing PFI10. It is subtle and easily missed but apparently the pulse requesting the count  (PFI10) causes some dead time, during which the counter won't update. This nearly drove me nuts when it was dropping only one or two counts - I thought I was doing something wrong. But when I accelerated the PFI10 pulses to read the count much more often, the number of dropped counts increased dramatically. The only solution I found was to synchronize the PFI10 pulses to the events (plus a small delay) so there was no chance of a collision. I can do that because my events are periodic. Not sure what you can do if they are random.

[John_P1]

Can you reproduce the behavior with my example program?  Or if you prefer, provide a simple self-contained example that does reproduce the behavior?  I'm not discounting the possibility of an NI bug, but the snippets you have provided are part of a larger application--without any context the snippets by themselves don't give the whole story (e.g. the DAQmx Start Task.vi is missing but I guess you're calling it somewhere in between the execution of the two snippets, perhaps how this is being done is relevant or perhaps there are other clues in the rest of the application?).

If there is in fact a bug, I'd imagine NI would need to be able to first reproduce it in order to have any hope of fixing it--so the simplest program that demonstrates the behavior I'm sure would be much appreciated (along with instructions for running, what signals to connect, etc.).

---

@TJWhit wrote:

The fact that this code runs flawlessly when the PFI10 line is synchronized to occur after the event, and it loses data when PFI10 is asynchronous, is proof that there is a problem.

---

I don't think there is any dispute that you have encountered a problem, but I am hopeful that the problem is in the application (which would be easy to fix) rather than in the driver or hardware (which would require an update from NI).  Asynchronous sampling of an event counter is hardly a corner case and I'm skeptical that such a bug could have gone unnoticed for so long (considering the 6602 has been released for years a decade).

Best Regards,