Encoder Problem.

[arun4444]

So i am trying to get these encoders working,

http://www.grayhill.com/web1/images/...ncoder_63r.pdf

Connected pin 1(encoder) to DigitalI/O in digital sidecar Pin Signal 1
Connected pin 2(encoder) to DigitalI/O in digital sidecar Pin Power 1
Connected pin 3(encoder) to DigitalI/O in digital sidecar Pin Signal 2
Connected Pin 5(encoder) to DigitalI/O in digital sidecar Pin ground 3

and here is the java code i am using to test

 public void disabled(){
        Encoder TestEnc = new Encoder(2,1);
        TestEnc.reset();
        for(;;){
            System.out.println(TestEnc.get());
            Timer.delay(1);
        }
    }

i just keep getting a 0, no matter how much i rotate the encoder, both directions.

I tested the encoder with an arduino and it seems to work fine.

I switched to another digital sidecar and the problem persists.

any ideas?

cheers
arun

[F22Rapture]

You never call TestEnc.start();

[arun4444]

Changed code to :

    public void disabled() {
        Encoder TestEnc = new Encoder(2, 1);
        TestEnc.reset();
        TestEnc.start();        
        for (;;) {
            System.out.println(TestEnc.get());
            Timer.delay(1);
        }
    }

still same result

[F22Rapture]

Try taking out the Timer.delay()

[William Kunkel]

Do you have access to an oscilloscope? They're really helpful with debugging encoder problems, and let you see if it's a code-side or electronics-side issue.

[arun4444]

I am pretty sure the encoder works cause it works fine on a arduino

[Ether]

Originally Posted by arun4444

I am pretty sure the encoder works cause it works fine on a arduino

At least check with a handheld voltmeter and make sure the encoder is getting power.

And as long as you're doing that, use the voltmeter to check that channels A and B are cycling.

[slijin]

Try changing "TestEnc" to "testEnc". You're not supposed to capitalize variable names.

If that doesn't work:

• Check the output of getRaw().
• Make sure there's a codewheel on the shaft you're rotating, and make sure that the codewheel has lines for the encoder to read. Improper installation can result in the codewheel's markings getting scratched off, which will wreak havoc on your encoder's readout.

[apalrd]

Originally Posted by slijin

Try changing "TestEnc" to "testEnc". You're not supposed to capitalize variable names.

I don't see any reason it wouldn't work if you capitalize variable names. In fact, I highly recommend using some sort of mixed case or underscores to separate words in variables for readability.

I personally am a fan of capitalizing the first letter of a variable name to indicate it is a variable, and naming all macros in all capitals with underscores separating words to differentiate them.

I've also seen incredibly structured variable naming methods that define everything about a variable in the name. For example, using three to six letter module name prefixes, and coding the type or units in (e.g. p for pressure, or kpa for kilopascals), or type of variable (e.g. m for map, c for calibration, etc.) and these work as well.

It's really all personal preference, as long as you are consistent the compiler really doesn't care at all.

[Kevin Sevcik]

Agreed that capitalization won't change anything. Rearranging deck chairs on the Titanic, that is. I think the C++ convention of variables starting with lower case letters is to distinguish them from classes and functions with start with uppercase letters. Though this may be Java, which has the opposite standard, I think.

I think your reset and start calls need to be in the other order. I'd also suggest putting an extra println in your loop just to make sure you're actually getting into the loop and all that. Possibly with an increment just for kicks.

I'd also recommend checking the outputs with a multimeter just to make sure that's not the problem. We have a different encoder board that's been fried and isn't good anymore. The only way you can tell is the output is constantly at 0.7V, never 0V or 5V as it should be. It's super easy to accidentally fry an output with static, so don't assume that it's still working fine just because it used to. Trust, but verify.

[F22Rapture]

Originally Posted by Kevin Sevcik

Agreed that capitalization won't change anything. Rearranging deck chairs on the Titanic, that is. I think the C++ convention of variables starting with lower case letters is to distinguish them from classes and functions with start with uppercase letters. Though this may be Java, which has the opposite standard, I think.

Other way around, Java uses camelCase(), C++ uses CaptialCase()

[Alan Anderson]

Originally Posted by arun4444

Connected pin 1(encoder) to DigitalI/O in digital sidecar Pin Signal 1
Connected pin 2(encoder) to DigitalI/O in digital sidecar Pin Power 1
Connected pin 3(encoder) to DigitalI/O in digital sidecar Pin Signal 2
Connected Pin 5(encoder) to DigitalI/O in digital sidecar Pin ground 3

Why are you using the ground pin on a third DIO port, instead of one of the ports you're already connecting to?

If you measure across encoder pins 2 and 5, is it actually receiving 5 volt power?

Is there a reason you initialize the encoder object with DIO 2 and 1 in that order, instead of 1 and 2?

[slijin]

Originally Posted by apalrd

I don't see any reason it wouldn't work if you capitalize variable names. In fact, I highly recommend using some sort of mixed case or underscores to separate words in variables for readability.

I personally am a fan of capitalizing the first letter of a variable name to indicate it is a variable, and naming all macros in all capitals with underscores separating words to differentiate them.

Originally Posted by Kevin Sevcik

Agreed that capitalization won't change anything. Rearranging deck chairs on the Titanic, that is. I think the C++ convention of variables starting with lower case letters is to distinguish them from classes and functions with start with uppercase letters. Though this may be Java, which has the opposite standard, I think.

I've ran into weird errors with Java when the leading character isn't a lowercase letter, hence my suggestion.

Originally Posted by Kevin Sevcik

I think your reset and start calls need to be in the other order. I'd also suggest putting an extra println in your loop just to make sure you're actually getting into the loop and all that. Possibly with an increment just for kicks.

I don't believe there's any problem with the order of the reset() and start() calls, as start() initializes the accumulator, and reset() just resets the count to 0 - one does not affect the other.

Originally Posted by Kevin Sevcik

I'd also recommend checking the outputs with a multimeter just to make sure that's not the problem... It's super easy to accidentally fry an output with static, so don't assume that it's still working fine just because it used to. Trust, but verify.

He did say that the encoder worked fine on an Arduino.

[Kevin Sevcik]

Originally Posted by slijin

I've ran into weird errors with Java when the leading character isn't a lowercase letter, hence my suggestion.

I'm skeptical. Mostly because I've seen programmers use all sorts of capitalization schemes and have them work. If they're consistent. If you're prone to typos and accidentally using different capitalization then that's obviously going to cause issues. Similarly if you accidentally name a variable identically to a function or class or something.

Originally Posted by slijin

I don't believe there's any problem with the order of the reset() and start() calls, as start() initializes the accumulator, and reset() just resets the count to 0 - one does not affect the other.

Technically it strobes a reset bit on the counter in the FPGA. I'll agree it probably doesn't matter since it does this during the setup of the Counter object before you can start the Counter. So the reset() call probably sn't even necessary.

Originally Posted by slijin

He did say that the encoder worked fine on an Arduino.

Which was before it was likely rewired or atleast moved to being hooked to the Sidecar. Which is not a 100% guaranteed benign operation. It should take no more than 10 minutes to test this and if it DOES turn out to be wired wrong or blown, it will save you days or weeks of debugging a program that's trying to read a bad encoder. I like to knock off low hanging fruit in my troubleshooting so I don't feel like an idiot later when I've spent hours on something I could've spent 10 minutes checking at the beginning. If you're really that desperately attached to not "wasting" 5-10 minutes, then do the check while you're downloading code or rebooting the robot and otherwise twiddling your thumbs. Or recruit a helper to check for you while you're plugging away at your code. Just check it to give us all some peace of mind.

[arun4444]

Ok, finally debugged the problem - the cable which connects the digital side-car to the crio was not crimped properly? with pins etc switched around? changed that cable and everything works ok!!