need help with TimeStampChangeDetection.c

[Steve O]

I found a limitation of TimeStampChangeDetection.c and I'm looking for suggestions to fix it. I am using TSCD.c with a 6533 and 6036E. GPCTR0 on the 6036E is setup for ND_BUFFERED_EVENT_CNT using double buffering. I have been able to run TSCD.c successfully using this hardware and I'm very happy with the results however I realized a major limitation. If the time between changes is greater than 167.772 seconds using 100KHZ source or 0.8 seconds using the 20MHZ source, the program misses the overflow and the time stamps are incorrect.

I've tried to fix this problem by using CONFIG_DAQ_EVENT_MESSAGE using DAQ Event #1 with N set to the terminal count. However it doesn't seem to work. The callback is never called regardless of the value of N. So I'm assuming callbacks don't work with this counter. Next I'm going to try using the second GPCTR on the 6036E to send out a pulse train at a slower frequency and use that as the source for the first GPCTR. I would like STCD.C be able to detect changes that can be up to 20 minutes apart.

Is there a way around the overflow problem with having to use the second counter as a source? I may want to use the second counter for another purpose. Is it possible to use callbacks with the GPCTRs? Would I benefit from purchasing a dedicated timing card such as the 6601/2? Do the 6601/2 support the ND_BUFFERED_TIME_MSR application?

This program and hardware will be used as an automated quality assurance tester. So I need the time stamping to be consistant and accurate. I have been using STC_Timer.c to produce a hardware timer and whenever a change was detected I would get the current value of the hardware timer for the time stamp. Using that method, I was not getting consistant time stamps. Using the same input sequence to the NI6533, I could get time stamps that were off as much as 20ms each time. Then I came across TSCD.c and I feel this would better serve my purpose.

I am using LabWindows 5.5.1 with NI-DAQ 7.0 Drivers.

Thanks in advance.

Steve

[mhaag]

Steve,

As you suggested, the problem is that during your counting you are causing the counter of the 6036E to reach its terminal count and then roll over. The reason for this is that the 6036E contains a 24-bit counter. Using a 20 Mhz clock, then we can do the math to determine exactly how long this clock will run before rolling over:

0.8/(1/20,000,000) = 16,000,000

2^24 = 16,777,216

(1/20,000,000) * 2^24 = .8389 seconds

From this, we can see that just past .83 seconds, the counter will roll over and will cause the problem you are seeing.

If you used a 6601/6602 then you will have a 32-bit counter which will allow you to run longer. But if we do the math again, at 20 MHz clock, the counter will roll over after 214.75 seconds. If you can run at
a 100 Khz clock the you might be able to use a 32-bit counter if the math works out for your application. As you can see the two key parameters in determining how long the counter will run before rolling over is the resolution of the counter and the clock frequency.

In order to handle this roll over of the counter in your application, the best approach is to really use two counters. The first one will behave just like yours does now and will be configured to output a pulse whenever the TC is reached. Then the second counter will be used to count the number of times the first counter rolls over. Using this method you can simulate a "48-bit counter" and your application can count for about 3900 hours.

Hopefully this will help get you going in the right direction, and if you have any other questions or concerns then please let us know.

Regards,
Michael H
Applications Engineer
National Instruments