continuous count down USB-6501

[JCAndle]

In Visual C++/NIDAQmx, I want to use the counter channel to prescale the pulses from an optical encoder.  Motion is unidirectional so I can ignore the B channel.  A channel goes to Dev1/Port2/Line7 and Z channel goes to Dev1/Port2/Line6.  The counter counts down from nominally 114 creating a callback on each terminal count.  The unit is still in the mail and i am trying to write code with no testing to meet a very tight deadline.

I have the luxury of some slow revolutions to "find" the metrics and identify the sensors before the system gets to 5 revolutions per second.  The pulse train is then  20,480 Hz.  The divided pulse train (callback functions) will be at 180Hz (5.556 ms/time slice of 10 degree arcs).  I know that I will lose some fraction of this time in USB hardware and driver latency and some more in windows & processor latency.  I am counting on less than 1ms or at least less than 1ms of standard deviation.

If i had more time i would just do this on a PIC chip (ultimately that's where it's going) or something like that.  I figured a cheap NIDAQ DIO was going to be easier to work with and then I find everything has changed in the 5 years sine *I* programmed NIDAQ!  Anyways,

1) I hear horror stories from a couple years ago about NIDAQmx latency.  What can I expect for latency in the callbacks (in NIDAQ thread)?  I know this depends largely on what else is running on the system.  Is 1ms or lower likely?  I am trying to hold synchronization on a 5ms window to read a sensor as it moves by a reader.  Depending on the answers below I have a few options.

2) If I start this task and it counts to terminal count, does it:

      a) roll under and count from 0xFFFF?

      b) revert to initial count and count down again?  *PLEASE!!!!*  (I am tempted to use an external parallel load divider and output an 8 bit divide code to it then just callback on edges)

      c) stop at zero and wait for the callback to kick it into gear again?

3) If the counter does (b) above and I find that my integral divide in this counter is drifting (nominally it will drift 8 pulses excess per revolution out of 4096) can I modify the task to use different initial values on the next loop without interrupting the current count cycle?  ideally i would use logig to know which of 36 10 degree arcs need a smaller divisor to stay in sync.

4) If I detect the zero (Z) channel rising edge and the callback function reads the counter, will it:

     a) interrupt the counter?

     b) read the value within a sufficiently small time?

I could use jitter in the counter reading at the Z-callback to adjust the next count cycle to stabilize the loop IF I could trust the jitter of the reading latency any more than the stability of the default counting chain.

Jeff Andle

Sr. Scientist - Sensor Technology

SenGenuity, a Division of Vectron

(hoping you can teach an old dog new tricks!) 

[Aaron_W.]

JCAndle,

Thank you for posting on the NI Forums. Answers to your questions are as follows: 

1) If you are talking about the time from when your program performs some action in software and then how long it takes for the signal to show up on the USB-6501, I would assume it takes more than 1 ms in general. As you mentioned it varies so much depending on what computer and what other processes are going we don't even specify the delay. However, the latest versions of DAQmx are going to behave much better than those from a couple of years ago. 

2)  If you give your counter an initial count of 20 and then get below zero the count will revert back to 0xFFFF, but you could determine when this happens and then in software change the count back to the initial value. 

3) Counter will not revert back to Initial Count, but you cannot set the Initial Count of the counter to a different value while the counter task is running. This would mean you would have to stop counting, stop the task and then set the initial count and then start the task again. 

4) I am not quite sure what you mean by point 4, could you clarify for me a little? 

I hope some of this information helps out, if you could clarify point 4 for me I could provide some more insight. Thanks. 

[JCAndle]

In item 4 I am referring to the phase (in counts) between the zero pulse of the encoder and the positions of the sensors.  There is one encoder for the entire system but each bank of rotating sensors has a different but deterministic phase relative to it.  I was going to use the drift in phase of the counter vs. the top dead center Z pulse to measure and correct for drift.

Unfortunately it sounds like this DIO card is only useful for static measurements and not for real time control. 

I will construct a board of counters and glue logic to do the real timing and just use this to program and monitor it.

[Aaron_W.]

Jeff,

You are correct, the USB-6501 is designed primarly for static measurement but is not capble of doing hardware time acquisition. If you have any other questions please let me know. 

[JCAndle]

Monday I will have my counter board to physically test but simplistically it's two 4-bit counters that preset to N when either a control line fron the DAQ is asserted or terminal count is reached.  The incoming "A" pulse train clocks it.  At each terminal count I get an edge triggered event that I'd like to have as little latency on as possible.  At least as little variability 😉

On receipt of a "Z" pulse I latch the counter and signal the DAQ to read the latch.

With this setup I can adjust the periods of each 10 degree arc as needed without upsetting the current count - it will just load at terminal count.  I can keep the synchronization fine tuned by adding or subtracting counts.  I can even try to estimate latency and advance the timing of the loop but I expect that the overhead to determine latency would cause more of it...

Now to devise a plan to complete the whole project (this is a small part of it) in 8 days while servicing my other commitments!

Is it just the 6501 or does NI not think someone would want to divide an incoming pulse train by N in real time?

Counters that need software intervention to do this are not very useful and it's a very simple programming step to allow it.

[Aaron_W.]

Jeff,

When I mentioned the limitation on the hardware earlier it was in regards to being able to set the initial count of the counter while the task was running. The DIO part of the device is only static, and the counter can only edge count. In other hardware, such as our M-Series boards, you are able to divide down the incoming pulse train and have more functionality from the counter.

[UCbrian]

wrong forum.