Quadrature encoder 6602 bad values

[vr46]

Hi, 

I'm running DAQMx on Linux and testing the example program to measure angular position with a NI6602 counter board.

I'm using the NI DAQ Signal accessory 777382-01 to generate encoder pulses with the knob . A & B are wired to counter 0.

When I move the knob clockwise I can see the angle increasing by 15 degrees for each click.

When I move counter clockwise it all works fine until it reaches the initial position at 0. If I keep moving counter clockwise

I get garbage value -3.xxxe+10

It is strange that as I keep turning counter clockwise I always get the same value but that it  seems to keep track of where it is because when I switch the motion to clockwise it reaches back 0 at the correct position

Here is the code from the example

   DAQmxErrChk (DAQmxCreateTask("",&taskHandle));
    DAQmxErrChk (DAQmxCreateCIAngEncoderChan(taskHandle,"Dev1/ctr0","",DAQmx_Val_TwoPulseCounting,0,0.0,DAQmx_Val_AHighBHigh,DAQmx_Val_Degrees,24,0.0,""))

    /*********************************************/
    // DAQmx Start Code
    /*********************************************/
    DAQmxErrChk (DAQmxStartTask(taskHandle));

    printf("Continuously reading. Press Ctrl+C to interrupt\n");
    while( 1 ) {
        /*********************************************/
        // DAQmx Read Code
        /*********************************************/
        usleep(500000);
        if ((error = DAQmxReadCounterScalarF64(taskHandle,10.0,data,0))) {
            DAQmxGetExtendedErrorInfo(errBuff,2048);
            printf("DAQmxReadCounterF64 Error: %s\n",errBuff);
        }

        printf("Acquired %g degrees \n",data[0]);
        fflush(stdout);
    }

 Here is sample output

 Continuously reading. Press Ctrl+C to interrupt
Acquired 0 degrees
Acquired 0 degrees
Acquired 0 degrees
Acquired 0 degrees
Acquired 30 degrees
Acquired 90 degrees
Acquired 150 degrees
Acquired 150 degrees
Acquired 195 degrees
Acquired 285 degrees
Acquired 285 degrees
Acquired 285 degrees
Acquired 210 degrees
Acquired 195 degrees
Acquired 195 degrees
Acquired 180 degrees
Acquired 150 degrees
Acquired 135 degrees
Acquired 105 degrees
Acquired 105 degrees
Acquired 75 degrees
Acquired 45 degrees
Acquired 30 degrees
Acquired -3.22123e+10 degrees
Acquired -3.22123e+10 degrees
Acquired -3.22123e+10 degrees
Acquired -3.22123e+10 degrees
Acquired -3.22123e+10 degrees
Acquired -3.22123e+10 degrees
Acquired -3.22123e+10 degrees
Acquired 0 degrees
Acquired 15 degrees
Acquired 45 degrees
Acquired 75 degrees
Acquired 90 degrees

[Kevin_Price]

This sounds very much like a problem with the interpretation / conversion of the 32-bit integer count register into a scaled 32-bit floating point value.  I have a vague memory that when I was first getting used to DAQmx, I thought that it did some goofy things when converting counts to floating point "angle" readings.  Consequently, I pretty much always perform my readings as unscaled integer values so I can handle the scaling in ways I can control.

Down in the hardware, the integer count will decrement 3,2,1,0, and then rollover to the max unsigned 32-bit value of 0xFFFFFFFF.  If you were to cast that u32 to an i32, it would be treated as the expected value of -1.  So read as u32, cast to i32 is my rule of thumb.

(Background: your scaling seems to be set for 15 deg per count.  When you rollover to 0xFFFFFFFF, you get a decimal unsigned count value of ~4e9.  Here's where things get odd, and perhaps buggish, in the DAQmx driver.  Most people in most applications would want DAQmx to treat that count value as a signed -1, which is what you would get if you cast the u32 to an i32.  Then DAQmx could easily report the count as -15 degrees.  A really naive DAQmx implementation would treat it as a positive ~+4e9 count and report it as ~+6e10 degrees. 

    What *appears* to be happening is that the DAQmx driver tried to be too clever by half and came up with the wrong result.  I'm totally speculating here, but one scenario is that DAQmx treats the high bit of 0xFFFFFFFF as a sign bit and finds it to be negative.  It carries over this sign bit to the 32-bit float conversion.  It then takes the other 31 bits as a magnitude which comes out to ~2e9.  After scaling and applying the negative sign, it reports ~-3e10.  Weird.

    I'd be curious what would happen as you continued moving in the negative direction.  Check by displaying more significant figures in the printf.   Does the magnitude keep decreasing as the sign stays negative?  If so, I'd want to call this a bug.  A continuous physical negative motion should *NOT* result in a measurement which shows a discontinuity in direction, first growing more negative then suddenly growing more positive.)

-Kevin P.

[vr46]

Thanks !

Yes that was it. If I use  DAQmxReadCounterScalarU32 instead of DAQmxReadCounterScalarF64 I get  the correct  negative count

I guess I'll just have to do the conversion mysel. So much for all those fancy API calls

Regards and thanks again. 

[ZachHindes]

Hi vr46!

The behavior you're seeing certainly seems wrong to me.  I was wondering what version of DAQmx you are using so I can try to reproduce it.

[vr46]

Hi, 

It is 8.0 which is the latest available for linux but it is from december 2005.

It took some tweaking from NI to get the drivers  to work under a current kernel. 

Regards,

Cedric 

[ZachHindes]

Hello again,

I was able to verify the behavior you are seeing, and this has been filed to R&D as CAR#124504 in regards to this bug.  This is a Linux only issue from my testing.  I'm sorry you ran into this, but the workaround provided is indeed the best solution to the problem currently.

[vr46]

Hi,

Thanks for your help.

Regards, 

[kevin_Lin]

hi. how about floating number ? I have similar question as well, however the reading i need is in floating number.

Kevin Lin

[Doug_L._Bear]

What version of DAQ are you seeing this in.  Is it the exact same behavious with workaround or is it slightly different?

[Mroche]

I am seeing this issue with using DAQmxReadCounterF64 with simple edge counting. If the counter reads a negative count value, it returns a number that looks like an unsigned 32-bit number rolled over (~4294967295).

I am using DAQmx v8.9.5. PXI-6602 with WIndows XP.

Has this bug been fixed in the driver?