Digital Input Change Detection

[tusman]

Hi,

I want to measure rpm of a rotating machine using a optical sensor which has a TTL output with max frequency of 1000Hz. I have implemented a change-detect mechanism using Digital Input with internal clock set to 80MHz. I want to measure the time difference between two successive change-detects to determine the frequency and use the time stamp at the change-detect to calculate certain phase relationship.

I have planned this based on the clear documentation available in DAQ M Series User Manual 371022K-01, page 6-8 Figure 6-3.

Observation is that the accuracy deteriorates for any frequency more than 2Hz. Also, any frequency more than 64Hz always indicates 64Hz only.

The VI is attached for reference. 

Please let me know what could be the cause of this problem.

Thanks in advance,

Tushar 

[tbob]

You are having the loop run as fast as it can, and this chews up almost 100% CPU time.  I'm taking a guess here.  Try adding a 0 mS delay in your loop to allow the CPU time to do other processing.  I've seen this behavior in the past and adding a delay inside a loop fixed the problem.  No guarantees that this willl solve your problem but its worth a try.  If 0 doesn't work, try a 10mS delay.  You can afford a delay if you are trying to read at frequencies in the Hz range.  This will not work as you approach 1KHz because the delay is in milliseconds.

[John_P1]

Hi Tushar,

It sounds like what you actually want is a Frequency Measurement (see page 7-9 of the M Series User Manual) which uses a Counter rather than the DI Change detection circuitry.  There is a shipping example that shows how to perform a Frequency Measurement using a counter, you can find it by navigating to the following from LabVIEW:

Help >> Find Examples... >> Hardware Input and Output >> DAQmx >> Counter Measurements >> Digital Frequency >> Meas Dig Frequency-Low Freq 1 Ctr.vi

When you are using change detection, the actual input signal is the clock and there is no timebase used.  Your current code relies on software to timestamp the pulses so you cannot achieve accurate rates at anything but slow input signals.  Using the Counter will allow you to count the 80 MHz timebase ticks in between events which will give a very dramatic improvement. 

If you want to measure both rising and falling events you can configure a Semi-Period measurement instead of a Frequency measurement so there should be no need for Change Detection in this application.

Best Regards,

[tusman]

Hi John,

Thanks for your inputs. I shall consider the counter approach.

I attempted the change-detect because the M-series Manual specifically states this functionality as -

"You can enable the DIO change detection circuitry to detect rising edges, falling edges, or either edge individually on each DIO line. The DAQ devices synchronize each DI signal to 80MHzTimebase, and then sends the signal to the change detectors".

Further -

"The Change Detection Event signal can do the following:Generate an interrupt. The DIO change detection circuitry can interrupt a user program when
one of several DIO signals changes state." 

Our interpretation of  the above is that DI change-detect enables 'hardware sampling' causing an interrupt to be generated. On the interrupt, my code can capture the time stamp and do any processing i want to do as part of the 'ISR'.

I request you to probe this DI change-detect angle further. If successful, I will not be constrained by the number of counter inputs which is 2 in my card. 

Thanks in anticipation,

Regards,

Tushar 

[tusman]

Hi Bob,

Thanks for pointing out to the possibility of CPU time overload. Will check that out.

Apparently the delay approach may not work since my frequency can go upto 1000HZ. 

Regards,

Tushar 

[John_P1]

Hi Tushar,

I can see how you might interpret the manual in the way that you did--to restate your post:

You can enable the DIO change detection circuitry to detect rising edges, falling edges, or either edge individually on each DIO line. The DAQ devices synchronize each DI signal to 80MHzTimebase, and then sends the signal to the change detectors .

The Change Detection Event signal can do the following:Generate an interrupt. The DIO change detection circuitry can interrupt a user program when one of several DIO signals changes state.

While it's true that the change detection circuitry synchronizes the DI signal to the 80 MHz timebase to generate an interrupt, this does not mean that the task automatically uses the timebase to timestamp the event.  Rather, the timebase is used to align the digital inputs so if multiple lines change at once the hardware does not generate multiple events.  There is a physical signal called ChangeDetectionEvent on the board as well as a software interrupt that can be used (which is also called Change Detection Event).

If you want to measure the frequency of pulses on a single line you should use the counter task mentioned previously.  If you want to timestamp pulses on multiple lines you can do this by using both Change Detection and a Counter (you would use a DI Change Detection task and use the ChangeDetectionEvent as a sample clock for a counter task which is counting one of the timebases).  Does this sound like something you need to do?

Best Regards,

Message Edited by John P on 03-31-2010 10:53 AM

[tbob]

Since you want to go to higher frequenices, your change detection method even with a delay in the loop is not a good idea.  I would use what John P suggested, a counter.  At least I learned something new.  I never knew about Change Detection.  Good to know if you have to record changes that occur at very low frequencies (less than a few Hz).

[tusman]

Yes Bob, one can use Change Detection reliably at at very low input rates. Typically for inputs like Limit Switches that may operate once in a while, but when they do - you want to capture that change.

[tusman]

Hi John,

Thanks for the clarification on how the 80MHz tb is actually used. I have now switched to using the counter, feeding the DI edges to the Gate and one of the onboard clocks to the Source. The time interval between 2 rising DI edges and hence frequency calculations are accurate.

But my next task is to determine the phase difference between the first rising DI edge and the occurence of the first peak of multiple analog signals that are also being acquired simultaneously. The analog signals continue to be acquired for 2 seconds from the first DI edge. This sequence of determining the frequency, the respective phase diff and the acquisition of analog signals repeats continuously. 

I intend to use the timestamps at the DI edge and the respective analog signal peaks to determine the phase diff. The timestamp I understand is a 128 bit datatype! MSB64bits for the whole seconds since 1/1/1904 and LSB64bits for the fractional second after the whole seconds. 

What would be the best way to register/read the timestamp so that I fully exploit the high resolution the timestamp offers?

Regards,

--tushar