PXI 6602 - Error -200141 - I can read for a second or two before receiving a data over written fault but my buffers don't appear to be overflowing

[Kevin_Price]

Honestly, I think your "sketchy workaround" might make things worse.  Then you'd have 3 tasks vying for PXI bus access, 2 of them being counter tasks with 2-sample FIFO's.

But more to the point, I went back to review the earlier parts of this thread and am getting a strong whiff that the *real* root cause of your problems may be that the assigner of this project is steering you wrong.  A few particular notes:

1. You *cannot* control the sample rate for a counter frequency measurement with your devices.  If you configure for a buffered task, it'll be the encoder signal itself that causes sampling to occur, and that rate will be variable and out of your control.   (Certain newer devices support a mode that tracks actual frequency intervals, but captures and reports frequency data based on a regular constant clock rate.  I've never experimented with this measurement mode and don't know exactly what it reports for intervals where there have been multiple hardware measurements or none at all.)

2. Sampling an encoder position task at or near the quadrature transition rate almost never makes sense.  Quantization error for calculating speed will be in the 100% order of magnitude.  (If you only expect about 1 incremental count change per sample, then the standard +/-1 count quantization error represents 100% error!)

3. What do you expect to gain or learn by capturing A,B channels via AI that you can't get from an encoder position task?  It's possible there's a decent reason for this, but in my experience around here, people trying these things are usually driven by misconceptions rather than need.

4. You mentioned that details about DAQmx timing has been a "weak point" for you.  Well, it turns out that counters are often a "special case" where the behavior is much more flexible, but only because it's also more complex.  Many counter measurements (frequency, period, pulse width, semi-period) use a special timing mode known as "implicit timing" rather than using a fixed sample clock.  This is because the timing of the instant when the measurement *can* be taken is governed implicitly by the signal being measured.

    If you capture AI at a fixed clock rate while measuring encoder frequency with a counter, the individual samples will almost *never* happen to be taken at the same instant.

-Kevin P

[Matt_AM]

@Kevin_Price

Sorry for the late response, life got busy quick.

Your initial statement that what the person asking me to get wasn't what they actually wanted is correct. I've since worked with them and figured out what I actually need to do (compare 2 encoders against each other at 20 kHz and not measure every A/B pulse at 500 kHz).

Digressing, I'd still like to ask follow up questions so I can gain personal knowledge.

1) Is reading the encoder as a counter considered a frequency measurement? I thought that the buffer Ci angular position tasks was basically a clock running to the counter and every time there was a high, it would query the counter for its count. Or was this just a general statement? I havent really worked much with frequency measurement in LV so I'm not sure how all that works. I believe I remember seeing/hearing what youre talking about in the DAQmx online training.

2) yeah, I was worried about that too. Good news, it's now not a problem

3) It stemmed from the project lead not understanding how the encoder works when talking with the HW lead. TLDR, he thought our encoder IC output both analog and AB simultaneous (they can, but we jsut do AB and get the IC fused that way from the MFC), so he thought that acquiring the AB pulses could somehow back out the analog value or something. Misunderstandings happen, especially in fields you don't know, so I'm not trying to throw shade.

4) yeah, syncing up tasks seems to be waaaaay more difficult than it should be and I've tried reading white papers and documentation but it never seems to stick and make sense. I know LV says you just need to route these things here and everything works automagically, but I can never tell. Digressing, I thought implicit timing was basically a sample on demand timing style where you tell the task to read right now and it gives you the current data. I know that there are difference between cards with MUX and simultaneous sampling where the MUX gives like a minimal difference between channel reads while simultaneous is, well, simultaneous reads.

Looking for some advice if you got a moment. I do sample Ai and encoders at the same time quite often and I will typically create a  clock with a card's counter (we have 6602s almost everywhere and only use 3 or 4 counters per card that are either in a PXI chassis or have a RTSI cable) to route to the Ai and Ci tasks. I start both tasks then start the clock task. Is this "good enough" for most "we want to know the Ai and Ci data at this point in time" kind of things or do I need to find a better option?

[Kevin_Price]

---

1) Is reading the encoder as a counter considered a frequency measurement? I thought that the buffer Ci angular position tasks was basically a clock running to the counter and every time there was a high, it would query the counter for its count.

No, encoder measurement and frequency measurement are distinct things a counter can be used for, and they work very differently.

But then yes, when you set up a buffered angular position task, the count value is tracking encoder position and the clock you configure captures a sample of that count.  If you read as a DBL, DAQmx will scale that count according to the "pulses per rev" you configured along with any further (optional) custom scale you may have configured.  But if you read as U32, you can retrieve the raw count value.

---

4) ...I thought implicit timing was basically a sample on demand timing style where you tell the task to read right now and it gives you the current data.

What you described is typically referred to as "on demand" sampling mode, sometimes also called "software timed" since the timing is driven by when your software requests a new sample.

"Implicit" timing is only applicable for certain counter measurements where the signal itself sets the sample rate.  So the rate is "implicit" in the signal.  Implicit timing is appropriate for measurements like frequency, period, pulse width, and two-edge separation.  Implicit timing is also typically used when generating a continuous (or finite buffered) pulse train.

---

I do sample Ai and encoders at the same time quite often and I will typically create a  clock with a card's counter (we have 6602s almost everywhere and only use 3 or 4 counters per card that are either in a PXI chassis or have a RTSI cable) to route to the Ai and Ci tasks. I start both tasks then start the clock task. Is this "good enough" for most "we want to know the Ai and Ci data at this point in time" kind of things or do I need to find a better option?

---

That's exactly what I'd recommend.  With both tasks sharing the same clock for sampling, *and* making sure the tasks are started *before* the clock is started, you're sync'ed to within some small fraction of a microsecond.  (Just due to signal propagation to the boards and through their sample latching circuitry).  That'll almost always be good enough.

-Kevin P

[Matt_AM]

---

"Implicit" timing is only applicable for certain counter measurements where the signal itself sets the sample rate.  So the rate is "implicit" in the signal.  Implicit timing is appropriate for measurements like frequency, period, pulse width, and two-edge separation.  Implicit timing is also typically used when generating a continuous (or finite buffered) pulse train.

---

 So basically implicit timing is used for things that have a desired voltage transition rate?  I know that's a general statement, so I'll get more specific since I don't know exactly how to ask my question.  Sorry for the word soup ahead.  

Things like period, pulse width, and 2-edge are looking for a voltage transition point from high to low to low to high.  Once they see that transition, it takes whatever measurement/algorithm at that time no caring at what rate the requested clock is at, since the clock isn't "the one making the reading".  Therefore, the task has to keep time itself (hence timing is implied by the task).Additionally, things like frequency (assume sine wave centered around 0V) I am assuming would look for the 0 crossing transition.  Since the requested sample clock isn't monitoring when the signal crosses 0, the task itself must keep track of its own time.  Hopefully I'm in the right ballpark with this logic.  

Follow up question, if the implicit timing source, can you still perform a buffered read?  I am assuming the NI hardware would have the current "here's my measurement value" being constantly read and stored somewhere and when the "transition happens to update the current value", the hardware would over write the old value.  If this is the case, couldn't a second device to monitor the "current value" be used to create a buffered read based on the desired sample clock?

Matt

[Kevin_Price]

I think you'd benefit from reading through chapter 3 of the user manual for the successor timer/counter product, the 6612.  I find it considerably more helpful and clear than the 6602 manual, which was written in the era of the legacy driver that used different nomenclature and terminology.

It illustrates how the sample timing for things like period measurement are implicit in the signal being measured because it's the transitions of that signal that cause the count to be captured.  And what's being counted is cycles of a fixed internal timebase, so the count value corresponds to a time interval.

Have a look, spend a little time with it, I think it'll make some things more clear.

-Kevin P