count for exact time

[johndoe_student]

In LabView example code,

 It counts PFI8 terminal(1000hz input) until PFI13(10000hz output) counts 10000 exactly, right? 

Is it irresistible error (in non-RTOS)? 😂

[altenbach · Accepted solution]

You have (1) OS jitter and (2) a delay cause by the communication overhead with the device. You cannot do anything about the OS, because it is not designed for deterministic timing, but if the delay is relatively constant (a few ms), you could just subtract that from the dwell time to correct for it. It won't be precise.

As I said, you should also simplify your VI. Sorry, I don't have any DAQmx installed, but why don't you just take two identical successive counts and then take the difference? (it is pointless to reset a counter to zero!)

Now the communication overhead subtracts out to some extend if it is similar between calls.

Here's how it could look like (note that sequence structures are rarely needed. The wire going form the first wait to the FOR loop just enforces execution order).:

What is the actual experiment?

[Kevin_Price · Accepted solution]

Attached are trimmed-down versions of the shipping examples I mentioned in msg #5.  I saved them with default values that I think ought to work, but have no hardware on hand to confirm.  My main concern is whether the default powerup state for the PFI pin I used for the pause trigger is high or low.  The code assumes low.   There are workarounds, but I figured I'd try the simpler version first.

As posted, the edge counting task will count edges of the internal 100 kHz timebase.  When you start it running it should keep reporting 0 counts because of the pause trigger action.  Then when you run the pulse generation task for a 1.0000 second pulse, you should see the edge count build up to 100 000 *exactly*, confirming that the counting interval was indeed 1 second exactly.  You can then modify the config to try counting edges on your real signal for 1 second.

-Kevin P

[Edit: I see altenbach posted a reply while I was working on mine.  You'll probably find his approach simpler to understand and implement.  It's still based on software timing and won't be *perfect*, but it's pretty likely to be good enough.  You're talking about an erratic signal with highly varying intervals -- the average counts per second you'll end up measuring will also be highly variable data.  A small amount of timing noise will be hard to distinguish.

   The code I posted uses hardware features of your board's counters and the timing will be virtually perfect.  But the code will get more complicated and require you to understand more about the hardware to troubleshoot or modify.

    Try both and I'll bet the software-timed approach will turn out to be good enough.]

[johndoe_student]

Thanks for everyone.

finally  I made what I want.  

Using Internal timebase clock and samples to count,  it counts 1000(sometimes 999) for 1sec when 999.8hz signal input. 

After I made it , I could understand what I didn't know.

As altenbach & Kevin_Price said, using hardware features of my board's counters and the timing is solution for my error.

It takes so long to be solved, but thanks to two people, I've been greatly helped in the most.

It became a lot of studying about hardware and timing.

[Kevin_Price]

That's a different hardware-based technique than what I was suggesting, but it should be able to work for you just fine.  Plus, you're using only 1 counter to do the job while my suggestion would have used 2.   Nice work!

Description for future readers: the code screenshot shows a technique where the count value is sampled at 100 kHz and 100 kilo samples are captured, meaning 1 second worth.  Then only the very last count value out of those 100K is kept because it represents the total count at the end of that second.

-Kevin P