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

[THE_SNAKE]

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

[Kevin_Price]

I appreciate the effort to describe your needs in detail.  Unfortunately, I'm not sure I still understand what you really need here.  I think you've drawn some conclusions about how to approach this, and I can't tell whether you've drawn the right ones.  It'd help if you would describe the purpose of the app and the meaning of the various counts and time intervals.  Meanwhile, here are some specific things I'm not sure I follow:

• The timing diagram shows "gating" pulses, but the counting seems to continue after the gating pulse finishes.
• The time "T1" appears to be arbitrary -- not related to either gate pulse times or # counts.  How is T1 determined?  What makes it significant?
• The time "T2" seems to be a time of intentional ignorance, choosing *not* to pay attention to counts.  It probably isn't necessary, so why is it desirable?

A few further tentative comments:

• If there's a chance of 0 counts in an interval, you'll want to explore the use of the "Duplicate Count Prevention" property
• I only code in LabVIEW, so can't help much on C-style syntax
• You're likely to benefit from doing a buffered measurement, unless you need to choose future "gating" interval durations T1 based on past count measurements.  Even in such a case, you still *might* benefit from a buffered measurement.

-Kevin P.

[THE_SNAKE]

Dear Kevin,

I am very happy to have your fast response. I will clarify step by step:

>It'd help if you would describe the purpose of the app

This project is intended to be applied into a system for X-ray photoelectron spectroscopy. The photoelectrons emitted are causing the generation of corresponding electrical pulses which should be processed by the counter application, discussed here.

> and the meaning of the various counts and time intervals. 

The application has not only the task to count, but also to drive DAC lines (Digital to analog converter) between the counting intervals. Its simplified algorithm should be like this:

 >   * The timing diagram shows "gating" pulses, but the counting seems to continue after the gating pulse finishes.

May be my first timing diagram is not completely correct regarding the gating signal. I just had not better idea how to represent the things.

> * The time "T1" appears to be arbitrary -- not related to either gate pulse times or # counts.  How is T1 determined? What makes it significant?

The time "T1" is the interval, during which the pulses are counted for a single counting. It is set by the operator prior starting the measurement . During the whole measurement, e.g. for all countings this time is constant. The precision of this interval should be hardware ensured. The goal is to be provided result such like: "number of pulses per T1"

> * The time "T2" seems to be a time of intentional ignorance, choosing *not* to pay attention to counts. It probably isn't necessary, so why is it desirable?

In fact, here is the "knot". After each counting, the DAC lines should be set, thus setting a new level of the energy which is expected to cause a new different result for the pulses counted in the next counting. Exactly this synchronization is the main problem for me. And you are right: during this T2 the pulses are not counted, however, this interval should be as shorter as possible - the DAC driving routine is simple and I do not expect this interval to take more than several ms. I will try additionally to simplify my question. Below is shown the original figure from the 6601 manual, showing "buffered period measurement". There I have marked, that after each counting, the DAC lines have to be set. And my question can be re-structured like this "How to be achieved the synchronization, in order to be driven the DAC lines?".

(Because the characters count limit, I will continue in the next post)

Message Edited by THE_SNAKE on 10-09-2008 07:11 PM

[THE_SNAKE]

(continuation from my previous message, because the 10k characters limit)

> * If there's a chance of 0 counts in an interval, you'll want to explore the use of the "Duplicate Count Prevention" property

Thank you, I will try this!

> * I only code in LabVIEW, so can't help much on C-style syntax

I need to find is there at all a mechanism my goal to be achieved using 6601, or I should better try to search generally different solution for example to apply a microcontroller instead the NI-board. If I know that the mechanism is possible and its main ideas for example through LabView - discovering its analog in C - based environment should not be a big problem for me.

Best regards:

Kamen Ivanov

[Kevin_Price]

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 approach you've planned counts on making a near-real-time update of an analog output DAC based on measured results.  Your data correlation depends on you stopping and starting the counting in sync with generating your DAC update.  It restricts you to doing software-timed AO as well.  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* 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.

More comments in no particular order.  Yes, use buffered period measurement for counting with units set as "Ticks".  Read the values as u32 integers.  I'd set up one counter to generate the continuous pulsetrain that marks the regular period intervals.  The other counter will measure periods by treating the incoming X-ray pulses as the timebase.  I'd use that same pulsetrain as a sample clock for an analog input task which measures a channel wired to my analog output.  Note: the pulsetrain counter needs to be started *last* to keep everything in sync.

-Kevin P.

[THE_SNAKE]

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

[Jiri_K]

Hi Kamen,

I have some ideas about you problem. It is hard to tell you, if the card is suitable for you application, when I am not able to test it with your HW. From the speed and timing of you output digital line, it seems to, that you need to do retrigger operation on counting. This is usually done by using of two counters. Examples of retrigger operations with the counters are on the followed links. So you can modify them to you problem.

http://zone.ni.com/devzone/cda/epd/p/id/4787

http://digital.ni.com/public.nsf/allkb/82DAECADE90CC56F8625659200675B2A?OpenDocument

 

Did you try the suggestion that Kevin told you?

 

Yes, use buffered period measurement for counting with units set as "Ticks".  Read the values as u32 integers.  I'd set up one counter to generate the continuous pulsetrain that marks the regular period intervals.  The other counter will measure periods by treating the incoming X-ray pulses as the timebase.  I'd use that same pulsetrain as a sample clock for an analog input task which measures a channel wired to my analog output.  Note: the pulsetrain counter needs to be started *last* to keep everything in sync.

I think, that you can modify it, that you will use the same pulse train as a sample clock to drive you digital lines output.

 

Regards,

Jiri Keprt

Jiří Keprt | Application Engineer