Encoder Issue - Counting with PCI 6289 using DAQmx Error -200141

[Milqman]

I am having a problem with a counter input on my PCI 6289.

The set up is as follows:

I have two 2000-count encoders each mounted to a shaft.  The shafts are "geared" (I put it in quotes because they do not have traditional gears between them but do track each other).  I have a box that takes 2 quadrature inputs and out outputs the the sum of them.  I have that box connected to my distribution block.  I am using the A channel of one of the encoders as a sampling clock. 

The data I expect to see is the angular difference between the two gears as a function of angle with a resolution of about (360/2000) .18 degrees.  What I am seeing is Error -200141.  You can see that I manually set the size of the buffer (to 10k), but I receive this error before I even spin it one revolution (2k pulses on the sample clock).  What should be noted here is that I used to have an RT set up that this seemed to work ok with.  I scrapped my RT set up (reformatted the PC and just loaded windows and installed) because there was no high speed controlling I expected to do.  The error says I should use DMA (which it is already doing by default), or sample slower (which I can't really do if I want to capture small deviation angles between the shafts).

The app is as follows:
[IMG]http://i23.photobucket.com/albums/b384/milqmandan/Work/CounterError.jpg[/IMG]

I planned on running this this pretty fast, and did not see anything that would keep me from doing that.  It is clear that I missed something.  This error happens when I am moving the shafts with my hands (fairly slow compared to how fast it will eventually run).  Do I need to pull it out of a loop? Or perhaps change something else?  Does this buffer just not apply to this type of task?  Why would it overwrite itself if it has not even filled up the prespecified buffer size?  Is the counter not sampling based on it's clock (just sampling at whatever "frequency" I set in the task, ignoring my sample clock?)

The task is configured as follows:
[IMG]http://i23.photobucket.com/albums/b384/milqmandan/Work/AngularPositionTask.jpg[/IMG]

Any help you guys have would be great, thanks in advance,
~milq

[Milqman]

I discovered that I would receive the error (-200141) only if I started the VI before I started spinning the shafts.  Then after testing some, I found that after it was going, if I altered the speed of the clock (remember it is the A channel on one of the 2 encoders) ever so slightly, it would generate the error again.  Perhaps this sheds some light on the problem?  I also augmented my task set up to do "Continuous" acquisition (because I had specified finite acquisition in a loop).

Other than that, everything is as it was (I also pulled out the explicit buffer size setting as I deemed it unnecessary).

Any ideas on how to alleviate the new concern or remedy the old one?

Thanks a bunch,
~milq

[Kevin_Price]

I can only take an educated guess here.  I know the counters pretty well, but I don't ever define tasks in MAX so I am not confident I know what assumptions it makes.

The -200141 error sounds like the one where "sample clock" edges are received by the board faster than the board can transfer measurements across the PCI bus via DMA.  The board has a very small buffer (2 sample FIFO) available for counter channels and must perform this DMA transfer pretty much continuously.  Based on prior threads, finite acquisition is somewhat less prone to trouble than continuous acquisition.

One typical cause for such an error is a noisy sample clock signal.  Noisy signals can appear like a burst of very-high-speed sample clock edges, too fast for the board to keep up.  Two scenarios that might explain why you see this error when starting the program before the shafts start spinning: (1) the shafts vibrate at high frequency on startup, producing a burst of high-freq edges due to the back and forth motion, (2) the encoders produce signals based on magnetic pickups and don't produce clean signals at low speeds.  Either way, once you get up to a steady speed, the encoder edges become consistent and manageable.  However, I don't have an explanation for why a slight speed change should produce the error in one of those scenarios.

Troubleshooting idea: use a different signal that's known to be "clean" as the sampling clock.  For example, create a dummy AI (or AO) task and specify that the two encoder measurements sample using the AI (or AO) sample clock.   Or use a good TTL square wave generator.

-Kevin P.

[Milqman]

I would agree that finite acquisition would seem to be better, but I have this in a loop, and got error -200278 (I think).  Researching that led me to a knowledgebase saying that I should use continuous acquisition if my "Read" is in a loop.  Changing from finite to continuous made -200278 go away.  Now I am in a situation where it errors out (-200141) if I have it running before the shafts start.  If I start it after the shafts start spinning, it will operate, however, if I touch the shafts ever so slightly (impede their speed by less than 1% probably) it will error out (-200141).

The encoders I am using are optical and rated for a much high speed than they are being run at currently.  It does not seem like the signal would be "dirty" under these conditions.  I will connect my clock terminal to a digital output square wave (does it matter that it is going to be generated by the same card?).

Would a PCI-6602 be able to avoid this problem?  Do all counters just have the 2 sample FIFO?  I see on the data sheet that it uses NI-DAQ.  Does NI offer any high performance counter cards that use DAQmx?

UPDATE: For some unknown reason, the code that was working yesterday now generates the -200141 under all conditions.  Inconsistent is a step down from not working, in my opinion!

Thanks again,
~milq

[Milqman]

UPDATE: Checked the sampling line with a scope, it looks clean both during operation and start up.  The high voltage never goes below 4V and the low never comes above .5V.  I will still check with an AO signal (perhaps I can find the frequency at which it will fail).  That will wait until after lunch however.

~milq

[Kevin_Price]

1.  To preserve the finite acquisition approach, you could bring the Start and Stop functions inside the loop.  The way you'd run is: (a) start task,  (b) read 1 full buffer of samples after it completely fills,  (c) stop task,  (d) repeat a,b,c as needed.

2. Errors with small speed changes are a puzzler to me.  Have you tried a separate example program that'll use a counter to perform frequency measurement on the A channel signal?  That might show more clearly if there's a tendency to receive faster bursts of edges under different conditions.

3. The 6602 is an older design than the M-series boards and I can't think of anything it offers over the M-series except to give you a larger # of counters.  I *do* know that it's a bit less flexible in the kinds of non-default signal connections it allows.  Note that the 6602 definitely IS supported by DAQmx, but the datasheet you found probably pre-dates the existence of DAQmx.  It's also limited to a 2-sample FIFO.   The 6602 is getting old enough (in computer board time) that I like to think we're about due to see NI release a new generation counter/timer board.

4. Agreed, consistently not working is usually easier to diagnose & fix than intermittent problems.  I'd still recommend doing some troubleshooting both (1) on your regular app while using an alternative sample clock source, and (2) measuring the observed frequency of the A channel signal when wired into your PFI pin.

-Kevin P.

[Milqman]

1) I did as you said and put the starts and stops in the loop, unfortunately it did not change any behavior 😞

2) I hooked the A Channel up to an O-Scope, it looks clean, and I do not see any craziness upon start up or under load (my shafts are connected to an engine :))

3) Boo, is there seriously no way I can do what I want to do with available hardware?

4) 1) I set something up really quick but could not get it to go fast enough to make generate the error (I have little experience in DO or AO so my squarewave driving app was sort of silly if I could get ahold of a better squarewave app, I could try it)  Also, the DO I saw look nearly identical to the output off of the encoder (I looked at both of them with my scope).
2) I checked it out with the scope, and like I said, it looked clean.

What is my next troublshooting step here?  If you or someone else can either make, or give me directions to make a fast squarewave generator then I can test it with that as a sample trigger.  If I can find the frequency at which it starts failing then I might be able to resize the wheels on my encoders (which infuriates me, because I can't find any information about the limitations of the DMA and 2 sample FIFO on my hardware.  Given the other specs of my card, I was expecting very good performance out of this set up!)

When you say that you never use MAX tasks, what exactly do you mean?  Do you specify everything in the VI with create channel and all of the buffer and timing polys and nodes and such?

Where do I go from here?

Thanks,
~milq

[Kevin_Price]

I'm not really an electrical whiz -- dealing with erratic / noisy signals still seems a bit like black magic to me.  However, I've had a few situations where signals looked just fine on a scope but they still generated too high of a "burst rate" for sampling when connected to the DAQ board.  Sometimes I could see a bit of ringing by dialing down the scope's timebase setting into the realm of nanosec while triggering off the edges.  Other times, I never did see anything suspicious and chalked it up to the scope probes offering a kinder gentler electrical path than my regular DAQ wiring.

1. Yeah, I'm not real surprised.  The finite vs. continuous acquisition change would mainly give you some benefit if you were dealing with high rates (maybe several 100 kHz or more) and a definitely clean clock signal.  At this point, I'm still suspicious of your clock signal.

2. If you're talking internal combustion engine, spark plugs are notoriously "dirty" in terms of electrical noise transmission.

3. I very much expect that you *can* do what you want with the hardware you've already got.  One additional option for you to look into is the PFI Line digital filtering available in the M-series boards.  I haven't found myself needing it yet, so I'm afraid I'm no help on the details.

4. I'd use one of the shipping examples for continuous AO.  As long as you don't wire the output to anything, it doesn't matter what the example generates.  All you care about is that the sample clock gets generated continuously at the rate you desire.  Just start that example vi and let it run in parallel with your app.  In your app, drop down a DAQmx Timing vi for your encoder measurement tasks.  One of the inputs will let you specify that the AO sample clock gets used as the sample clock for your encoder tasks.  All the internal signal routing needed for this is handled automatically by DAQmx, and I've NEVER seen this type of sample clock show any noise-like behavior.

  I won't say that scopes lie, but a scope probe will represent different termination characteristics than your normal wiring.  This can in turn change the transient behavior of the signal.  Or maybe there's some deeply embedded scope setting that's suppressing or filtering the transients in question?

5. I don't have exact specs on sustained sampling rate capability for that board either, but I would certainly expect you to be able to achieve 100 kHz or so but probably not as much as 1 MHz for any significant duration.  Since you're talking about an engine, I'd guess you're maybe in the 10's of kHz?

6. Yeah, I use the Create Channel and the Timing and DAQmx property nodes, etc.  Kind of an old-school habit so that all the configuration can be right in the executable, and doesn't depend on an operator setting up stuff in MAX on a deployed machine.

-Kevin P.