How to simple event count and restart on external (e.g. gate) signal with 660x hardware and C/C++

[ilose]

I am trying to find out if a NI 660x board will be able to do a task fullfilling the following requirements:

Requirements:

1) software arm the counter

2) continously count a selected external (or scaled down 660x internal) source

3) restart/reset the counter value (or reload with "0" ) on an rising edge of an other external signal provided

4) software readout the counter at any time without disturbing the counting process (as can be done with "simple event counting", e.g. through Gi SW Save Register or similar)

5) set-up, arm, and readout the counter with one software instance

6) readout the counter with a second software instance without disturbing the counting process

7) implemented in software with C/C++/MSVC, on a Windows XP

😎 using Daqmx C routines or register level programming (e.g. with the use of DDK components "ni660x" and "nimhddk_visa" ) 

9) using a hardware on a PCI interface

Message Edited by ilose on 11-04-2008 07:45 PM

[Chris_W.]

Hi ilose,

I am unclear on two of the questions. When you say in #'s 5 & 6 that you want to do these things in "one software instance", do you mean perform these functions in one piece of source code, or one line of code? Also, when you ask whether you can read the counter in a second software instance, are you talking about interprocess communication? or just another instance of the call to read the count value that is currently in the buffer. 

The answer to the rest of your questions is yes, this board can do these things. Make sure your desired count rate is taken into account when you select which board you use. The PCI 6602 has a maximum timebase of 80MHz, which would suit most needs.

I would suggest using a buffered period measurement. There are examples of this type of measurement that install with NI-DAQmx and can be found at C:\Documents and Settings\All Users\Shared Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Counter\Measure Period or Pulse Width.

Chris N White

High Speed Products Group

[ilose]

Hi Chris,

Yes, I was talking about interprocess communication. So, I would like to have one executable which starts first, configures and arms the counters etc. , and starts reading out the counter value. A second executable would than start and read out the counter value at the same time.

Regarding the buffered periode measurement: yes, that is what I thought would be the type of measurement I would like to be doing. However, it appears that the counter value (register) is only updated at the end of one periode. Is that correct? Or would I still be able to read the counter value at any given time from two or more executables (software instances)?

Ilos

[Chris_W.]

Hi llos,

As far as having both of your executables reading the value out of the counter register or buffer at the same time, you wouldn't be able to do this. You will run into resource issues. You would have to do some variable sharing between the two executables. Why would you need to read the count value in two different executables? If you're doing some processing, you should just do this all in your main program.

For the buffered period measurement issue, the more I think about it the more I think you should just go with a count edges task, or even an encoder type task, like a Two Pulse Encoder with Z Index enabled. The reason is because of what you had mentioned in your previous post. When you're doing a buffered period measurement, you will only be able to read a new buffer value once a full period of the gate signal has passed because the value on the count register is only transferred to the buffer after each period of the gate signal. Here is a good example of a buffered period measurement.

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

I would take a look at these other options. There is a lot of good  information in the M series user manual.

http://digital.ni.com/manuals.nsf/websearch/2025C99AB0614F9E8625748000577B9A

Page 107/424 is the beginning of the Counter section. I would specifically look at the sections for edge counting and encoder measurements. These encoder tasks could be molded to fit your situation. I think these options would be better for your situation because you would be able to read the value of the count register at any time as opposed to reading from the buffer that would only get updated periodically.

Chris N White

High Speed Products Group

[Kevin_Price]

Interesting thread.  My 2 cents:

It sounds very much like you need a non-buffered approach so that you can perform software polling of the instantaneous count value at any time.  Of the two alternatives, I think you need to go with the 2-pulse encoder approach.  A regular edge-counting task won't reset the count value, and if you count on buffering the edge counts and doing software differencing, you're still stuck unable to poll for an instantaneous value between sample clock edges.

There are some quirks to the Z-index reset mechanism that I have observed, and I suspect are hardware driven rather than driver version driven.  I still think it's your best bet, but you should be forewarned of these things.

A. Polarity cannot be programmed.  You must have a high-state z-index pulse.

B. Z-index reset will only occur when the the 2 encoder input signals are in 1 specific state (out of 4 possibilities - LL, LH, HL, HH).  You can programmatically choose which one.  In your app, you would probably wire the unused 2nd pulse input to digital ground and then pick between LL and HL.

C. The reload action seems to be *state* driven rather than edge driven.  I have experimented with quad encoders and if I hold the z-index input at a constant high state while spinning the encoder, the counts go 0,1,2,3,0,1,2,3,0,...   So if your z-index pulse lasts too long, you could reset 2 or more times during a single pulse.

D. On the other hand, if the z-index pulse is too short and does not overlap the designated reload state (LL, LH, HL, or HH) at all, no reset will occur.

E. I believe there's a spec for the minimum acceptable Z-index pulse width, but don't recall the value.  For the sake of discussion and my example, let's suppose it's 500 nanosec. (I believe it's much shorter in reality, but am not 100% sure).

Here's an idea to deal with this mess.  The overview is that we will try to transform the original reset signal into something that satisfies the quirks listed above.  I think it'll take 2 intermediate counters to do it.  The details follow:

Aux counter A will generate at the highest possible rate of 20 MHz.  (40 MHz is technically possible, but needn't be discussed here).  It will be configured to use the event source signal as a pause trigger that pauses when the event source signal is High.  So, when the event source signal is Low, Aux counter A generates at 20 MHz.  When event source is High, Aux counter A holds state and generates no edges.

Aux counter B is configured for retriggerable single pulse generation.  The reset signal is wired to its GATE input, and the task is configured to use Aux counter A's output as the timebase clock.  Aux counter B's pulse should be set for 2 cycles of the timebase of Low time, and a high time corresponding to the minimal allowed z-index pulse width.

Wire Aux counter B's output to the z-index input of the main counter you wanted to deal with in the first place.  We are creating a minimal-width z-index pulse at the correct time placement relative to the event source.

. 

Now you can config your original counter to be senstive to z-index reload phase of LL.  Here's how it all works:

1. Events come in without reset pulses for a while.  Aux counter A emits bursts of 20 MHz pulses during event signal High times, and maintains constant output state during event signal low times. Aux counter B isn't being triggered so its output remains low.  This low output never resets the main counter which is configured as a 2-pulse encoder.

2. A reset rising edge comes in while the event source is High.  Uh oh, right?  No, not really.  The edge triggers Aux counter B to start generating a pulse that's timed by the output of Aux counter A.  Aux counter A produces nothing until the event source signal goes Low.  While it's Low, Aux A blasts out 20 MHz pulses.  After 2 of them (100 nanosec), Aux B output goes high.  After 10 more (500 nanosec), Aux B output goes Low and stays there until after the next reset trigger.   Meanwhile, the 500 nanosec high output from Aux B causes the main counter to reset its value to 0.

There's a lot packed in here, so take your time to go over it slowly and carefully.  I *think* it should work, but am not able to test it on hw now.

-Kevin P.

[ilose]

Chris,

well, I would need to read out the data as I am doing a hardware timed acquesition and have two applications which use the same hardware timer as a reference (for different acquesitions). Essentially, a HW sync.

I feared that the buffered periode measurement wouldn't fit our purpose. I had a look at the example at a previous time, but we still need to be able to read the counter at any time (and the example is a LabVIEW example, not a C one).

Kevin,

that was a lot of information for 2 cents. Thank, you. I will have a thourough look into your suggestions. It all seems rather messy for a "simple" problem.  Buffered periode measurement would have been so nice and simple 🙂 Anybody any idea how to trick the card to provide the counter value during the bufferd measurement?

Ilos