DAQmx Event 'Every N Samples' vs. Read Timeout in LabVIEW

[FTI_Newton]

This is not really a question as much as the start of a discussion, but here goes.

Consider the DAQmx Event  EveryNSamplesAcqIntoBuffer.

Furthermore, let's say we have an event structure responding that event with a call to  DAQmx Read.vi. Make the sample count to read = '-1' (all available). If the event structure keeps up, you should always read the N samples specifiedwhen you registered the event (or a few more).

However, this is not too much different for DAQmx Read.vi in a loop by itself with a read count N. We don't really gain anything in that department, do we? 

When responding to this event for a continuous acquisition, events generated by the DAQmx task get queued up, the Event structure in a loop will keep trying to play catchup with events that got generated while it was executing.

Let us register the event for N samples, then in the event structure call DAQmx Read with a read count ...

... equal to N. THe Event structure keeps up.

... equal to N/2. THe Event structure keeps up, but you arent' pulling enough data; buffer overrun is inevitable.

... equal to N*2. THe Event structure does NOT keep up. Events will queue up twice as fast as you read them. Try to stop your program elsewhere, and your loop will have to run through them all before it completes. A stop button event doesnt' seem to help much, as the DAQ Events get queued up ahead of your stop button.

Assuming all I want to do is trigger a read (no other processing) I don't see much benefit to using events to do it. It seems like DAQmx Read may be doing that very thing with a count > 0, or at least the behaviour seems the same.

So what kind of application have any of you found using this particular DAQmx event useful for?
The others seem more obvious (counter output, Digital change detect).

[JÞB]

I think the utility of the event you are speaking of is dependant on a rather large number of factors. So I'll mention a few examples.

A: 
SYSTEM ARCHETECTURE: suppose I have a P-C loop reading from a DAQ but I'm starting stopping and changing my data rate programatically.  By using the n event and a continious acq task I can optomize the performance of my code so that it essentially automatically adjusts how often it runs.  if I used the Read n sample vi in my producer loop I would need to query the task conditions and I may run into TMOs or buffer overflows if my DAQ utilization covers a broad range of sample rates.  Usuing the event in this case allows a highly re-usable P-C DAQ module that is easilly maintained and decoupled from the actual task settings.

B:

NI-DAQmx VERSION:  You won't always have the opportunity to chose the DAQmx version (or even use the latest) The events are 1 possible workaround to the "Auto-start property bug", CAR 185781, that was not resolved prior to NI DAQ 9.1.1  Although other workarounds exist, the event is a bit more elegant that a brute-force case-by case if the bug hits  then force the autostop method as it is independant of the poly instance of Read.vi and the bug is dependant on the instance.

All that said:  sometimes you just need code that works for a specific task- Read.vi is the minimallist approach and still makes for highly readable and scaleble code that meets rapid deployment needs very well.