6602 as X4 encoder/external clock

[wmphysics]

Hello,

Im trying to use a PCI 6602 to read the output of a linear encoder.  I have a few (I think simple) questions about setting things up...

Right now I am only using CTR 0 (channel A hooked up to pin 2, B to 40, and Z to 3).  I have been trying to use the DAQ assistant to set up the code.  When i change the acquisition mode to continuous, it asks me to specify a clock type and source.  The only option I am given for clock type is external (is this right?), and for source I have options like PFIxx or RTSxx.  None of these source options seem to allow me to acquire data in continuous mode (The "test" routine doesn't read back anything).  Any suggestions on what I should be doing differently?  Don't feel bad about "dumbing down" your reply 🙂  Any info is useful, I'm pretty new to Labview...

Thanks

[Kevin_Price]

Two different thoughts for you.  I'm not at my LabVIEW pc now and haven't used the DAQ assistant, but do know the 6602 pretty well.

1. For debugging, try setting up the task so that there is no buffering.  This may be called something like "on-demand" sampling.  Whatever the name, the operation will be that the counter always increments/decrements with encoder position.  Each time you call DAQmx Read, you'll get a snapshot of the instantaneous position.

2. When you need to return to continuous sampling, you'll need to create your own sampling clock with one of the other counters.  I'm sure you could set this up with DAQ assistant.  You may just need to carefully note the PFI pin # for that counter's output so you can use it as the sampling clock when you configure your buffered encoder task.

Good luck!

-Kevin P.

[josef_slg]

I have got hte same issue. How do I set up a counter on the 6602 to be my sample clock source. I want to sample with at least 1Mhz my encoder readings, not to miss any counts.
But how, I read that I have to generate a pulse train or so ? And what is the default sampling frequency of the 6602 counter timer card. I mean, it seems to be in my application, that I miss same pulses
when I do not specify any clock source. Just counter - start - while loop { read - update while loop with 1ms, display } end. So I thought, the pci6602 captures all rising falling edges of my quadratuer encoder and same,

I simply display it with updating the while loop with 1ms, but I miss somehow encoder readings. Note, that I fave six high precision quadrature encoders (400counts/degree).
How do I increase my sampling rate in this case. I do not want to use the DAQ ass, because doesn't work somehow.

Thanks.

[Kevin_Price]

1. First understand that counter tasks are fundamentally different than analog or digital sampling tasks.  Each counter has a count register that will increment / decrement according to the hardware signals coming in from the encoders.  The count register will readily handle encoder pulse rates of 1 MHz.

2. Performing "sampling" is a matter of storing that count register value to RAM so your app can later read it.  The sampling rate will likely be much slower than 1 MHz, but that does NOT mean that counts are being missed.  The count register happily keeps incrementing and decrementing in between samples so you aren't going to lose track of position.

3. You 'll need to learn a bit about DMA vs. interrupts for data acq because you can only sample 3 encoders with high-speed DMA.  The others will need to use interrupts, which will be much slower.  (Or, use 2 6602 cards to get a total of 6 encoder tasks using DMA).

4. So far you talk about a software loop that reads values.  Maybe that means you don't need the precision of hardware sampling or maybe it means that you just don't yet know how to achieve it.  To get hardware sampling, you would generate a pulsetrain with 1 counter and configure your 6 encoder tasks to use that counter's output as their sampling clock.  You should be sure to start the 6 encoder tasks *before* you start the pulsetrain to make sure the readings will be sync'ed.

5. Using 1 card with 3 DMA tasks and 3 interrupt tasks, you shouldn't count on achieving sample rates above a few kHz.

Spend some time looking at the shipping examples and the ni.com "Developer Zone" for more examples, tutorials, app notes.  There's a bit of a learning curve getting used to encoder and counter measurements.

-Kevin P.

[josef_slg]

Hey Kevin,
ok, I got a running software code. But, it seems to be that I miss counts. I do not know what the default sampling of the counter card is, but I have to increase it. The output frequency of six encoder is not more than 300-400kHz, so that having at least sampling of 1MHz, which must be sufficient.
I tried to implement the pulse train (see top left corner), but my buffer is over running, and get an error message. But I do not know what the easiest way is to get all counts in an easy way. I mean, it is not a special application, more standard reading quadrature encoder with frequency at 1MHz.
Have a look at the VI. And what is the default frequency of the 6602. My understanding of my software code is that the counters should count every rising/falling edge and if I desire, read out the actual value. Is this correct.
I appreciate your help.
Thanks.

[MickeyD]

Hi,

I took a look at your application and their where to things I noticed.  You said you got a buffer error.  I would recommend trying to increase the samples per channel this will increase the buffer, which should give you a bit better performance there.  I wouls say make it ten times your rate to be safe.  The other issue I see is that the frequency of your counter output task was only 1 hz.  Maybe this was just the default and you had changed it, but it should be the same as the rate you are defining for the other counter tasks.  Your counters will count every edge and the read you call in the while loop will read out the count value at the time it is called.  Let me know if you are still having issues with reading the 1Mhz encoder signals.

Have a great day,

Michael D
Applications Engineering
National Instruments

[josef_slg]

Hi,
I still have some issues regarding that. I get the error message -200577 (Error -200577 occurred at an unidentified location Possible reason(s):Requested AI Minimum value is too large.), but I do not know what I am doing wrong. I took your recommended values, but it occurs this error. So, you might have a look again at my values. The error occurs at the first sampling clock, view the jpeg. I appreciate your help. I need this sampling frequency of 1Mhz with my pulse train. So, the error causes no encoder reading...
Thanks again.

Message Edited by josef_slg on 05-23-2007 08:55 AM

Message Edited by josef_slg on 05-23-2007 08:58 AM

[josef_slg]

Sorry, it is me again, I found one mistake. First, I have to task the sample clock and then start.
But then, this will give me another error, why I assume, that I still doing something wrong in my setup.
Please have a look at the corrected VI and the jpeg for the error.
Again, I really apprecieate your help.

[Kevin_Price]

I don't have an LV machine available near my network PC and have only been able to look at the screenshots.  To be perfectly frank, I see far too many issues to address and tutor individually with the limited time I have.  As friendly advice, I would *strongly* recommend backing up several steps and first make an app that works with 1 encoder.  Once you get through that part of the learning curve, *then* add the other encoder channels to your app.  Then my prior post about DMA and interrupts will become relevant again.

Other things:

1. I really, *really*, think you've got the wrong idea about how the counters measure encoder signals.  You do NOT need to sample at 2x the encoder pulse rate, the Nyquist theorem does NOT apply here.  The hardware count register tracks encoder position accurately with your 400 kHz encoder signals.  Your app is free to choose how often to sample that count register according to your needs.  This may be anywhere from 1 Hz or less to several kHz.  It does NOT need to approach 1 MHz and even if you tried, the system is almost certain to be incapable of such a rate.

2. After all the talk about sampling at 1 MHz, you have a software loop that reads 1 single value at a time from each encoder and has a timer to run it only once every 10 msec.  There is a *very* fundamental disconnect here.  (It also appears that you have optional file writes inside the same loop, another factor that'll slow you down.)

3. The encoder readings are not hardware-sync'ed in time -- the first value read from each represents their positions at different points in time.  With such high-precision encoders, I'd think you would need hardware sync on the read times.

Finally, why not give us an overall description of your app's needs?  Kind of a big picture description.  I know you've told us what you think the problems are, but I'd wager my NI screwdriver that the 1 MHz sampling rate you think is your main problem will turn out not to be relevant. 

-Kevin P.

I don't have an LV machine available near my network PC and have only been able to look at the screenshots.  To be perfectly frank, I see far too many issues to address and tutor individually with the limited time I have.  As friendly advice, I would *strongly* recommend backing up several steps and first make an app that works with 1 encoder.  Once you get through that part of the learning curve, *then* add the other encoder channels to your app.  Then my prior post about DMA and interrupts will become relevant again.

Other things:

1. I really, *really*, think you've got the wrong idea about how the counters measure encoder signals.  You do NOT need to sample at 2x the encoder pulse rate, the Nyquist theorem does NOT apply here.  The hardware count register tracks encoder position accurately with your 400 kHz encoder signals.  Your app is free to choose how often to sample that count register according to your needs.  This may be anywhere from 1 Hz or less to several kHz.  It does NOT need to approach 1 MHz and even if you tried, the system is almost certain to be incapable of such a rate.

2. After all the talk about sampling at 1 MHz, you have a software loop that reads 1 single value at a time from each encoder and has a timer to run it only once every 10 msec.  There is a *very* fundamental disconnect here.  (It also appears that you have optional file writes inside the same loop, another factor that'll slow you down.)

3. The encoder readings are not hardware-sync'ed in time -- the first value read from each represents their positions at different points in time.  With such high-precision encoders, I'd think you would need hardware sync on the read times.

Finally, why not give us an overall description of your app's needs?  Kind of a big picture description.  I know you've told us what you think the problems are, but I'd wager my NI screwdriver that the 1 MHz sampling rate you think is your main problem will turn out not to be relevant. 

-Kevin P.

[josef_slg]

Hey,
ok, one step back.  My problem is that I have to read 6 encoders (5 rotary, 1 linear) from an serial passive measurement robot. Unfortunality, these do not have a z index. So, I got a stage, where I put the robot in to get always the same encoder readings. Then I can easily calculate the readings, with homogenous transformation matrices. I set my LabView system to zero and add the calculated encoder readings later offline as an offset. Then I move the robot arount, measure the endeffector pos with nan external device and compare the predicted end-effector pos form the encoder readings and my transformations with the external devce. So, now, when I put the robot in this stage, set my encoder to zero, take it out and put it back in again, it seems to loose some counts from the encoders, beacuse the LV displays me a negative slope for my enocders. I did it 10 times and after that, I got an negative offset of 2mm, which is physically not possible.
The loop is just for displaying the encoder motion and right, I just want to read one single value for each encoder when I press the save button, not more.
So, I think, my VI does not work correctly. So, now, we are at the point, where I need help, because my VI seems not to count correctly, why ever...
The quadrature encoders have a max. output of 400 counts per degree (per mm). So, therefore this results in an output frequency.
Yes,  but I loose the counts somewhere, otherwise it doesn't make sense.
So, it should be a standard application, but somehow, it is not working.
Kevin, you are right with there is no need for the 1MHz application, but how do I not loose my counts? I am not an expert, but my VI was running without using an external clock. Again, I just lost counts somehow for the linear encoder and sometimes for the rotary enocers. Please find attached the data sheet for the linear encoder.
Please let me know if you have any further help for me.
Thanks.

Message Edited by josef_slg on 05-23-2007 10:57 AM