Missing/duplicate readings in a 6602?

[MrSethT]

I have a 6602 and I have it collecting 2 trains of edge time stamps (ticks) simultaneously.  I have 2,500 line encoders, running 100 RPM.  4.1666kHz or .24ms period.  4 rotations, so 10,000 ticks per encoder.  I have synchronized the channels to both have the same start trigger.  The routine I use is the BeginMemoryOptimizedReadMultiSampleDouble in c#.

I am measuring the difference between the 2 encoders.  I have been chasing an error in the data I have been getting for a while and realized today what I am seeing... To find the problem I put both NI channels to the same encoder.  The expected output is to have 2 identical pulse trains.  What  I see is identical readings (+/-1 tick) for the first ~180 rows, but after 180 readings they get offset by 1 period (2,400 ticks)  and then later around row 356, the offset increases.  Just before, during, or right after these transitions, I see repeating time stamp/ticks (example: instead of 12,000, 14,400, 16,800 I see something like 12,000, 12,001, 12,002).  At the end of the data, row 10,000 the offset has increased to 126,000 ticks.

What I think is happening is one of the channels is using the same tick at the end of one buffer as the start of another.  Then, at the end instead of 2 sets of 10,000 points, it has one of 10,000 and one of 10,200 and then truncates it to return 2 sets of 10,000.

How can I stop this?

Thanks for reading, you guys have been life savers in the past.

[Kevin_Price]

Though you've given quite a few details, I'm still more than a little puzzled.

- How are the counters configured?  Edge counting, Freq / Period, Encoder?

- Are you syncing via "Arm Start" trigger rather than the typical Start trigger.  You'll need to...

- Are you always reading the same # samples from the 2 tasks?

I'm a LabVIEW-only guy, so I know nothing about how the seemingly special "BeginMemoryOptimizedReadMultiSampleDouble" routine might work.  I've seen

nothing analogous in the LabVIEW API.

The numeric pattern you've observed seems like a very strong clue.  Can you post your config code, your reading code, and an output file?  I'm not certain how much of the C# I can decipher, but I can give it a try.

My best guess at what you're describing is that you're in edge-counting mode using an internal timebase for the source edges that increment counts and using an encoder signal as an external sample clock.  What's a *little* odd is that 2400 ticks would imply a 10 MHz timebase.  I thought the 660x only had 100 kHz, 20 MHz, and 80 MHz.

Where you see something like 12000, 12001, 12002, it kinda seems like the edge source is inducing a couple extra samples.  With both tasks looking at the same signals,  this is a pretty weird one.  However, if something like that were happening, it would make sense that the data from the tasks would agree at 2400, 4800, 7200, 9600, 12000.  The next pair of values would be 12001/14400, then 12002/16800, then 14400/19200, i.e., a growing "offset".

I see some linkage in the data patterns, don't have any insight for root cause since the same source signals are driving both counters.   I guess I'd experiment with different pairs of counters to find out if the problem tracks with a particular counter # (or subset of them).

-Kevin P

[MrSethT]

I am (in this test case) always reading same number of samples.  

I am creating 2 period channels, using counterReadTask.CIChannels.CreatePeriodChannel(encoderPaths[0], "", modelPeriodSeconds * .90, modelPeriodSeconds * 1.10, CIPeriodStartingEdge.Rising, CIPeriodMeasurementMethod.LowFrequencyOneCounter, estTimeToFinishSeconds * 2, 4, CIPeriodUnits.Seconds)

then I set a digitalEdgeTrigger to the same channel on both channels using

counterReadTaskA.Triggers.ArmStartTrigger.ConfigureDigitalEdgeTrigger

Then tell each to collect N samples using Timing.ConfigureImplicit(SampleQuantityMode.FiniteSamples, N);

then set the following for each...

counterReadTask.Stream.ReadAllAvailableSamples = true;
counterReadTask.Stream.Timeout = (10 + (int)estTimeToFinishSeconds) * 1000;
myCounterReader = new CounterSingleChannelReader(counterReadTask.Stream);
mycallback = new AsyncCallback(CounterReadCallback);

My cohort thinks that using DMA instead of ProgramIO will fix this, but I haven't gotten that working either.

reading then sums them into ticks by looping through and accumulating the pulse widths

I have attached an example output

[MrSethT]

I have been saying pulse widths, I meant period lengths.

[Kevin_Price]

Only had a chance to take a brief look at the data.  At a glance, there seem to be at least 3 distinct kinds of anomalies:

1. 2 counters measuring the period of the same physical signal produce an off-by-one difference too often for my comfort.  There *can* be a signal-level race condition between the timebase and the external signal which would make a *rare* off-by-one difference, but your data seemed to show this effect quite a bit too often.

   It's possible the pure raw period data would be easier to interpret.

2. Occasional "periods" are measured with single-digits of Ticks, seemingly on only one counter at a time.  Both are subject to this anomaly though, it isn't restricted to just one of the counters (which might have helped indicate a board-level hardware issue).

   This often happens when an external clock signal is noisy or glitchy and one *real* transition produces artifacts that appear like an additional pair of transitions.  It's a mystery why such a phenomenon would be seen by just one counter or the other.

3.  Most confounding, it seemed that the cumulative ticks for one counter would almost always match *some* row of the data on the other counter, give or take 1 tick.  But as I recall looking at the spreadsheet, I occasionally saw values that differed by 3-5.  *That* seemed particularly odd.

I'd be inclined to use DMA for performance reasons, but am doubtful that it will have an effect on the measurement data.  The values get latched and stuffed in a FIFO on the board, DMA vs. Programmed IO would only influence how it gets from there to your main application RAM.  The values shouldn't be affected.

I'd recommend a test case where you store the raw period measurement values.  And measure them directly in units of Ticks so you have nothing but integers.  Because all 3 anomalies I noted are kinda hard to explain purely from config and signal timing, I'm working up some suspicion of the post-processing code -- maybe round-off or truncation error on the floating point seconds being accumulated?   Whatever, one way to check it out is to measure in raw integer ticks and store that raw data directly.

-Kevin