optical shaft encoder

hey can someone help me with coding
i need a code that i can have a motor run for a set time and have a optical shaft encoder read me the number of Revolutions that its made in that set of time?

You probably should indicate what you’re working with - RobotC, EasyC, or what?

ooo ya sorry. robotc for a vex cortex.

Use SensorValue to get the encoder count, perhaps something like this.

task main()
    int  value;

    // assume motor is on port 1
    motor port1 ] = 127;
    // delay while motor accelerates
    wait1Msec( 500 );

    // clear encoder, enc should be the digital port that the encoder is on
    SensorValue enc ] = 0;
    // wait for 1 second
    value = SensorValue enc ];

    // stop motor
    motor port1 ] = 0;

    // send to stdio
    writeDebugStreamLine("encoder count is %d", value );

    // done

Here’s some code i used with an IME a couple of years ago to do speed testing.
motorSpeedTest.c (4.73 KB)

Just remember the count will be in encoder shaft ticks. You will need to find out how many make one revolution.

There are 90 counts / revolution

With the quadrature encoder there are 360 counts per revolution.

Are you sure? The wiki says 90. I guess that this is referring to an older model?

This code is get but i can not get the number to show?

Enable the debug stream window when the debugger is running. You may need to change the menu level to “expert” or “super user” first.

Nothing. i am using a vex two wire optical shaft encoder in ports 1 and 2 of digital and a two wire motor in port 10.

Yes I’m sure. There are two products, the rotary encoder, old product with no direction information, 90 counts per revolution. The quadrature encoder, uses two digital connections to the cortex, 360 counts per revolution.


Did you remember to include code that will display your encoder counts?

Did you get the debugger window to pop up when you run it?

From Optical Shaft Encoder page

90 ticks per revolution with easyC and easyC PRO
360 ticks per revolution, incrementing by 2 with ROBOTC

I trust you but what the hell does ^ mean.

That’s from the OSR product page, the full spec is as follows.

Notice that it refers to the PIC not the cortex.

The TL;DL answer is “the wiki needs updating”.

Let’s back up a little.

The OSR contains a rotating disc with slots in, here’s a photo.


Two sensors detect the slots. Each sensor will out put a logic high or low depending upon whether IR light can pass through the slot or is blocked. The sensors are slightly offset by one half slot so the change from blocking or passing IR will be at a different time.

Software that uses the output of the two sensors is interested the edges of the signal, the changes from low to high or high to low. For each slot that passes there will be four distinct states.

Sensor 1  Sensor 2
low       low
low       high
high      high
high      low

A few months ago I posted some simple code showing how to decode these if we were sampling them periodically. Here’s an excerpt.

        // detect state change and decode
        if( pa != old_pa )
            // input a change state
            if( pa ^ pb )count--; else count++;
        if( pb != old_pb )
            // input b change state
            if( pa ^ pb )count++; else count--;
        old_pa = pa;
        old_pb = pb;

It’s very inefficient to keep checking the state of the two encoder inputs, what we do in practice is to allow the state change (the signal edges) to cause an interrupt to the program (an interrupt causes the program flow to change by jumping to new program instructions). To fully decode the encoder states we need interrupts to occur on both the rising and falling edges of the signals, I’m pretty sure that the PIC did not have this capability and could only detect one edge of the signals, this means that at most 180 counts per revolution could be detected. ROBOTC used a trick where every time it sees an interrupt (remember this is on the PIC) it will increase the encoder count by two, this keeps code consistent with the cortex and also gives a direct mapping from encoder counts to degrees. Early versions of EasyC did not support the quad encoder (this is actually a guess), they had the function block GetEncoder which only used one of the two signals coming from the sensor. As only one signal was used there was no directional information and the count rate was half, 90 counts per revolution.

The cortex has the ability to allow either edge of the sensor inputs to cause an interrupt. ROBOTC can now use the full 360 count per revolution resolution. EasyC introduced a new block called GetQuadEncoder that also uses two inputs and (AFAIK) also returns 360 counts per revolution.

So back to the wiki.

The OSR page was created in 2009, this was pre-cortex, it was probably accurate at that time with whatever versions of ROBOTC and EasyC were current. The page has had almost no updates since then, some links were fixed, Intelitek added the GetEncoderBlock. This is an unfortunate trend with many wiki pages, very few people give them attention and some are now just out of date and inaccurate.

The bottom line is that with the current OSR product (on a cortex), ROBOTC, EasyC, PROS and ConVEX will all report 360 counts per revolution.

Thanks for the info. I guess that explains why I was always having trouble with the quadrature encoders.

I am not sure about a code to display the encoder counts. I am new to programing and not sure that i have that code right. Any code that you code give me?

I gave you code yesterday, however, you do need to change it for your particular setup of ports.

Turn on super user or expert menus.

Compile and download the program, you should be able to see the encoder counts in the sensors debug window. Enable the debug stream to see the printed value I included in yesterdays code.

You need main battery power for any of the sensors to work, not good enough to power the cortex with the USB cable.

This is where i got. but i still have no reading.
Screen Shot 2014-06-29 at 3.59.05 PM 1.jpg

Are you plugged into digital 1&2 (not analog 1&2)? Is the white wire towards the center (vexnet) of the cortex? Is main battery power good?