NI-DAQmx: PCI - 6601 - counting pulses in fixed intervals

Question

Dear friends,
I found, that similar topics to my question have already been discussed, but I was unable to find exactly my case, or where it is near - LabView is discussed. If you know address where my question already has been discussed, please, let me know. Because I still have not decided whether I will use CVI or other C-based environment, my questions are more oriented to the principles, I hope that no matter which C environment is used, the algorithm should be the same.
Now to the question:
For my project, I am using board PCI6601 and NI-DAQmx drivers. What I need to do is illustraded in the following figure:
I time ago I have tried to realize the above function through the evalution CVI environment, but I filed. I have some questions regarding my experience:
1. I have one general question: Is the functionality needed possible to be realized using the board 6601 and LabWindows/CVI (or Visual C environment )? If yes, please, comment the questions below:
2. I suppose, a period measurement should be used, but which type? I suppose, a single period measurement should be used. The buffered continuous period measurement seems to be not suitable, because there is no way for ensuring the time T2 for system processing.
3. How the measurement should be configured, which functions should be used? I tried to apply the function DAQmxCreateCIPeriodChan(..) and I noticed the following:
- in order to be able to set the GATE time T1 according the needs, I must use for the parameter measMethod only value DAQmx_Val_HighFreq2Ctr;
- may be the values for the parameters minVal  and maxVal need to be calculated each time dependently on the time T1 set?
4. How should be organized the reading, which functions should I use to read the counter value? By now I tried to use the function DAQmxReadCounterScalarF64(...) and I noticed the following:
- my system needs to know when the counting T1 is finished, in order to do the processing needed in the period T2. What value should I set for the parameter timeout in respect to this? Shall I use the timeout in order to obtain the result, or I must detect when the result is ready checking the Return Value of the function? Shall I use timeout, depending on the T1 period used?
-  a number of pulses “zero” in my system is a normal value. How to avoid the problems, related to this? When I connect and disconnect the pulse source, an error occurs. I tried to use the function SetBreakOnLibraryErrors() to disable the error messages, and I succeeded to disable them, but it seems, on error the task is automatically stopps and needs to be restarted.
- which variant is the correct way for reading with respect to the task start/stop:
Variant 1:
a) Start the task
b) Start the counting
c) Wait the counting to finish
d) Stop the task
e) Process the result
d) repeat the sequence (a-e) so many times as the number of the countings;
Variant 2:
a) Start the task
b) Start the counting
c) Wait the counting to finish
d) Process the result
e) Repeat the sequence (b-e) so many times as the number of the countings;
f) Stop the task
Thank you in advance,
Kamen Ivanov
Message Edited by THE_SNAKE on 10-09-2008 05:41 AM
Message Edited by THE_SNAKE on 10-09-2008 05:43 AM

Answer 1

Dear
Kevin,
Thank
you for your attention! Now step by step:
> You mention a DAC -- do you have another NI board, maybe a
multifunction board? If you do, or if you can add one, there's a pretty
straightforward way to do this stuff well. Assuming there's an NI multifunction
board available (I'd recommend an M-series board), I would approach this just a
little differently.
The
only NI hardware I have is this 6601 counter board. It has enough general
purpose pins, and I am using them to realize the digital part of the DAC. The
additional analog components, needed to complete the DAC functionality are
existing in the XPS system and they don't need to be added by me. The NI board
only must provide the corresponding binary combination. In fact, by this moment
I realized the DAC in this way, using a simple software routine to convert the
decimal value to a binary output value on the general purpose pins, it seems to
work fine (I have not explored its timing parameters yet – for example the time
needed for the output to be updated).
>The approach you've planned counts on making a near-real-time
update of an analog output DAC based on measured results. 
You
got it right! Here I need to correct myself: the DAC update is always related
to "moving" the DAC output with one step/level prior each counting. The
DAC output value does not depend on the result from the last counting, I know I
have written like this in my first message, excuse me for this! However, this
does not change the task to be solved
>Your data correlation depends on you stopping and starting the
counting in sync with generating your DAC update.
This
is very well said!
>It restricts you to doing software-timed AO as well. 
I
am not sure that I got this right, but if you mean the DAC update itself - yes,
the DAC update is software driven.
>All that can work, but consider the following approach that also
uses an analog input A/D channel. I assume what you care about is the
correlation of AO voltage to subsequent count rate, right? 
What
I need to ensure is that no single counting will be started prior its
corresponding DAC update, and that after finishing a counting, the next DAC
update will be done as soon as possible.
> What *I* would consider doing first is to hardware-sync the
counting task with an analog INPUT task which simply measures the analog output
voltage.  It sounds kinda dumb at first
to create a measurement task that measures a signal you're generating, but
there are benefits to this approach.  It
would free you to change the analog output DAC voltage any time and any way you
want, without having to worry about the processing time spent on it.  Your master data record would be the count
and analog input tasks, which can be synced in hardware.  
Also, you would have a continuous record of count rate vs voltage
with no "blind" time.
I
think I got your idea. But my problem is related only to the board 6601.
May
be we have to think how using only this board similar to your idea can be implemented.
It
seems, I can additionally simplify my question:
Is
the board 6601 suitable to be used for the task I need to solve, without adding
any additional (NI) hardware?
Because,
if my task can not be solved easy using exactly this board, I will try to
search other solution, but I need to know for sure and to have arguments, that
this board alone is suitable/not suitable for the task I have to solve.
Best regards:
Kamen Ivanov