2 Period measurements with sychronized Timers

[Kevin_Price]

I don't have any great specific ideas, just some very general troubleshooting thoughts.  What it basically comes down to is the following idea:  make a small, controlled change and observe the resulting behavior.  Use this new observation to help you hypothesize about the original problem.

So, for example:

1.  It sounds like you're already feeding both counter tasks from a single freq generator output.  If not, try it and see if you get different results.

2.  Try putting debug probes on each of the 3 input error clusters going into both instances of the Merge Errors vi.   Run multiple times to get some data both with and without timeout errors.  Observe whether the error always occurs at the same point or not.   Observe whether the counter errors correlate -- perhaps errors always occur either on both or neither counter task.  Whatever occurs, this should give you a few more clues to work with.

3. Between the point in code where you start the counter tasks and where you read from them, place a while loop.  Let the loop terminate on either a user-controlled GUI 'stop' button or a DAQmx error.  In the loop, use a DAQmx Read Property Node to query for the '# of available samples'.  Bring these values out to indicators so you can observe them (hopefully) incrementing. 

4. Try configuring the counters with an explicit buffer size and/or read the counter tasks with a much smaller value for 'Samples to Read'. 

5.  Try configuring the counter tasks to be continuous.

Just a few general troubleshooting ideas to try to help out...

-Kevin P

[WML]

Thanks for the example and the troubleshooting thoughts.

Setup: frequency generator fed to both counters, set to 10kHz sqare wave mit +-1kHz frequency modulation at 1.01Hz (sawtooth shaped).

With the FM sawtooth the synchronitiy can easily be measured.

Some data from my system: without any explicit triggering the counters start most of the time within 1ms. Somtimes - probably depending on system and USB performance they only start within +-20ms (about 2%), which is too much for my task.

With triggering (no matter if that is a PFI Channel or the ai/SampleClock) the counters start synced (measurement says that they are running synchronious within one clock cycle).

The problem is still, that one counter sometimes seems to "miss" the trigger or that the counter gate does not switch through correctly. That shows up by having no or only a few readings from that counter.

I checked that with a few USB 6216 cards (standard and OEM version).

My current workaround:

The initialisation of the counters and the analog channel / trigger stays the same as shown in my first post. The main difference is, that is switched to continous samples and do the readings in a while loop (all available samples). Because no error shows up if one counter missed the start (or gives only few values and then stops) I check the samples aquired within a certain time and compare them to what I am expecting. If there are not enough samples in the shift register -> restart the whole thing again (including initialisation). It takes up to five restarts to one correct measurement.

BTW: I also tested the vi on other machines and replaced the freq generator with another USB-card (connected to another pc).

The result stays the same, the counter measurement does not start for shure at the first attempt.

Annoying and not really what I wanted to have, but better than 1...20ms asynchronity.

Again thanks for your help.

Wolfgang

[Kevin_Price]

I've done a fair amount of counter work with PCI and PCIe M-series boards and haven't ever seen

any similar inconsistencies.  So I begin to wonder if there is possibly something unique about the

USB-based boards.

The behavior of capturing a few samples and then stopping also sounds quite strange.   I can imagine

a scenario that would do that, but I would expect a different error code.  (The scenario: a noisy signal

produces false edges at too high a rate for the board to transfer to PC memory.  This would make a

different fatal error and prevent further measurements from being buffered.)

Is it the same counter task that behaves badly each time?  Or does it switch back and forth?  Is it

ever both at once?

One last troubleshooting idea: try putting each of the tasks inside its own case structure.  Wire up

separate boolean controls to each so you can independently control which of the 3 tasks run.  Try

various combinations such as 1 counter task at a time, etc.

Another last idea: you referred to the AI task as a "ghost."   If you mean that the data is meaningless

and you only use it for syncing purposes, you could try triggering your counters another way.

1. Use a meaningless AO task.

2. Wire up a standard digital output line to the PFI pin used as the counters' "Arm Start Trigger"

-Kevin P