DAQmx allow Regeneration, but...

[torekp]

I need to produce fresh analog output during each cycle of a DAQ operation, as well as reading analog input. One way to enforce the "fresh output" requirement is to set the DAQmx property Do Not Allow Regeneration - and currently, that's what I'm doing. But that's a mistake. I need to Allow Regeneration. Yet, I still need to monitor the DAQ operations and pop up a message to the user if I fail to provide fresh AO data. How can I monitor the writes and see if they successfully "made it under the wire" before the relevant samples were generated?

The reason I need to Allow Reneration is that I want the AO to continue without interruption after the "real" program is stopped. The continuing AO will keep my hardware warmed up, but if the AO is interrupted while the hardware is left on, the hardware could be damaged. In order to reduce the processing load on the computer, there should be no more writing of data after the "real" program is done.

Here is the core "write then read" vi, which sits inside my main loop. Bear in mind that before the loop begins, I have written quite a few more samples to AO than I have read from AI, so there is a bit of breathing room:

http://forums.lavag.org/index.php?act=attach&type=post&id=5525

The vi in which I initialize the DAQ operations is too ugly to post, but suffice it to say that DAQmx write property is currently being set to Do Not Allow Regeneration.

Here's the order of operations to be controlled by my program:

0. Warm-up the equipment by producing analog output (this part is not written yet) - until the user presses start.

1. Another computer, which runs a vision system looking at a belt, tells my computer, "Hey there's an item located at (X1,Y1) and another at (X2, Y2)."

2. Labview constructs about 100kSa of analog output, with the goal of making sure that the mobile sensor will visit (X1, Y1) and (X2, Y2) when the relevant stretch of belt arrives. It writes this into the buffer, and when the DAQ output rolls around to that part of the buffer, everything will be good. That is, as long as the write happened BEFORE it was needed and not after.

(The queue, which holds AO data before it goes into the buffer, is probably dispensable - but this is a work in progress.)

3. Simultaneously as the DAQ output handles that part of the buffer, the sensor data from (X1,Y1) and (X2,Y2) and the periods of travel in between, is going into the AI board.

4. Read the AI, and crunch the data - were the items good, or were they bad? Lots of computation involved.

5. Go to step 1, and pray (see step 2, last point) that step 4 isn't taking too much time.

6. When the user presses stop, the analog output should continue seamlessly and ad infinitum - this part is not written yet.

My question(s):

How can I monitor the writes and see if they successfully "made it under the wire" before the relevant samples were generated?

Or am I attacking this from the wrong angle, do you think?

[torekp]

I forgot the part that makes this a "design and architecture" question: Do you think it makes sense to just allow the DAQ output task to continue, and not stop it? That is my plan at this point. I was also thinking of dynamically loading as many subVIs as reasonably possible, so that when the main program is finished and we're just keeping the hardware warm, there's a small and efficient program taking care of it.