Sample 6602 Counter in Position mode for one second at 100kHz

[Mythilt]

Hello, I am working on a project where I need to read a position off of a quadrature encoder at about 100k Hz for about 1 second.  Currently I am stymied by the need for an external clock source.  My understanding was that I could use another channel on the 6602 card as my clock source for the sample rate, but this doesn't seem to be working; when I reach the read counter vi, I time out rather than read anything.  Which leads me to believe that the timing signal isn't being seen.

My current configuration is

Counter channel 1 setup in MAX for positional reading, quadrature, no Z index.

Counter channel 7 setup in MAX as a 100k Hz output.

I've attempted to use channel 7's terminal as the input to channel 1 in DAQmx Timing.vi, as well as channel 7's corrosponding InternalOutput terminal, but am not having any success.

Is there something that I am missing in how I need to configure the timing source?

I've also had no successes running the example file Meas Angular Position-Buffered-Cont-Ext Clk.vi it also times out.

[Kevin_Price]

There shouldn't be any problem generating a pulse train with one counter and using it as an external sampling clock for another counter that tracks a quad encoder.  I've done this kind of thing many many times with the 6602.

Your description sounds like essentially the right approach, so I could only guess that perhaps there's a detail or two to tidy up. Can you post the code? 

-Kevin P.

[Mythilt]

The attached is a test that I built to try getting this to work.  The main test involves also triggering the read counter via an RTSI pulse along with a CAN bus read, which I removed to isolate the problems.

[Mythilt]

Oh, one other thing I noticed.  I had to type in the /Dev3/Ctr7InternalOutput terminal, the terminal constant only has PFI1-PFI39, RTSI, and the 80/20MHz clocks.  Yet the terminal constants in the example all had the /CtrxInternalOutput, etc lines.

[Kevin_Price]

I'm not near a LV box now, so hopefully my memory is close to accurate.

1.  The easy one first.  If you right-click on the terminal constant, there's an option like "I/O Name filtering..." which gives the ability to "include advanced terminals".  Many of the possible timing signals can only be seen after doing this right-click setting.  I've often wished I could make it a global default because I almost always want to see the so-called advanced terminals.  Don't think it's possible though.

2. Let's do a walk-through of your screenshot.  First you identify a global encoder channel and configure it for finite acquisition.  Next you identify a global pulse generation channel and configure it for continuous output.  Next, it appears that you start the pulse generation task.  Then, you try to read 3 samples from the encoder task.   However, the encoder task has not been started, at least not explicitly.

   Now, I'll admit to some ignorance here.  I never use global channels and I always explicitly start my tasks.  So I don't know what behavior to expect when calling DAQmx Read on a global channel whose associated task has been configured for buffered sampling but has not been explicitly started.  I'm a little surprised you get a mere timeout error, but, well, so be it.

  Suggestion: From the Encoder channel's call to DAQmx Timing, wire the task id output into a DAQmx Start prior to the call that configure's the pulse train's timing.  I would also suggest wiring a non-default timeout value into the call to DAQmx Read, just so you have some way to control it. 

(Aside: I know I've personally been wary what assumptions the DAQmx driver will make when I use an external sampling clock and am then required to specify a "rate" value.  My real sampling rates are almost always in the 100 Hz to 50 kHz realm somewhere, but I always just wire in a value of "1" for external sampling rate.  In my mind and in the rest of the program, the sample rate is interpreted as "samples per external clock edge" rather than as "samples per second.")

Another thing you might do for debug: after both tasks are started, go into a query loop.  Call some of the DAQmx property nodes to query things like "Total Samples Acquired" or other properties that can give you some status about your task.  Then only after hitting a front-panel Boolean stop button would you exit the loop and make the call to DAQmx Read.

- Kevin P.

Message Edited by Kevin Price on 10-11-2006 01:09 PM

[Mythilt]

Thank you, I've got that part working now.

Next part is figuring out how to trigger the start of reading the encoder from an RTSI trigger.  ( I have to read the encoder at the given speed, and a CAN bus at a slower speed and need a synched start so I can calculate offsets.)

[Ed W]

Hi Mythilt,

You can route the start trigger over the RTSI lines for your devices by using the DAQmx Timing property nodes.  Check out the following article – it goes into a lot of detailed synchronization methods using LabVIEW.

http://zone.ni.com/devzone/cda/tut/p/id/3615

Ed Waxler | Applications Engineer |  National Instruments

[Mythilt]

For the final version of what I was attempting to do, we ended up using the RTSI bus.  however, I did run into one question/problem afterwards.  How do I reset the counter/timer card back to the state it was in before I called DAQmx Timing (Sample Clock).vi?  What I am writing is part of a larger program and as such I want the counter task (it gets used by other vi's later on) to be back in the known state before the timing was modified, this is also because I disconnect the RTSI bus at the end of this test.  Currently, the only thing that works is clearing the task and re-creating it, I was wondering if there was another way, I've tried using the timing property nodes, but keep getting errors.

Attached is a proof of concept vi that I wrote to test out the timing issues with the CAN card also added.  I was hoping to avoid using the Analog card, but in the end had to for the CAN synching.  The final version will have several other subVI's controlling two servos for the DUT.

[Kevin_Price]

Since I'm not certain about exactly what aspect of "state" you need to restore, I'll point you to some info that may help you evaluate for your particular situation.  Check out the description copied from DAQmx Help in this thread. 

Even simpler, if you haven't already tried it, is to simply Stop the task.  Some (but not all, as far as I know) config settings can be changed while the task is stopped, then the task can be restarted to use those new settings.  This would have less overhead than completely clearing and redefining the task from scratch.

There's also more than one way to use RTSI routing connections.  Some are explicit, others are implicit, some have persistence beyond the end of a task, others wouldn't.  Again, I'm not sure exactly what you need to accomodate so can only offer pointers about info to look into further...

-Kevin P.

[Mythilt]

Basically, the state that I want to return to is using the defaults generated when the global channel is first used to start the task along with the filter settings that I read from a file.

In the main program it goes like this.

Use create DAQmx task using the given global counter channel (channel defined in MAX as being positional, quadrature, x4, no Z index.)

Setup counter task to use filter settings as read from a file.

Start counter task.

Run some tests.

Synch counter with CAN

Run position response test

Release counter from synch with CAN

Make sure counter is the same as when it first entered the test, (ie, the global counter channel settings and filter settings.)

go on to next test.

When I try to reset the sample clock to the 20MHz onboard clock, when I go to read the channel I get either error -200608 or -200141 if I just use the timing VI. (buffer overrun or buffer to small, in most operations, I just need to read the counter once, no buffering.)  When I tried to use the Timing properties node to set the channel to On Demand, I got a different error.

What I've finally settled on doing is reading the current filter settings from the channel, then stopping and clearing the channel and recreating the task using the prior filter settings and global channel.