Encoder Problems after update???

[Lucario231]

I have wheel encoders on our bot and they worked before the update (2.1) but now they don't work.

Electrical checked them and they are working
The encoder open do not display when double clicked the values of the constants
and they all say disabled not DIO 1 for example.

I noticed the devref says for Counter index says invalid

I have 5 NEW encoder and none of them have worked.

[DonRotolo]

Originally Posted by Lucario231

Electrical checked them and they are working

Being an electrical mentor, I have my doubts here. How did they check them? Did you SEE with your own eyes that they generated an AC signal on the A and B channels? We use an oscilloscope to verify signal.

If that's OK, use the encoder VI all by itself, none of your own code, and see if you can read them then. If yes, your code is broken.

[Alan Anderson]

Opening a SubVI like Encoder Open will show you the defaults, not the actual values being fed to it. Don't worry about the "disabled" and "invalid" things you see there.

It's possible that your DevRefs aren't doing what you think they are. If the names aren't exactly the same on the Set and the Get, it won't work. If you try to do a Get inside Robot Main before the Begin vi has done the Set, it won't work. When you get a chance, run Robot Main, open the block diagram where you're trying to read the encoders, and probe the DevRef going into the Encoder Get to see if it looks reasonable.

Oh, and make sure you're doing an Encoder Start immediately after the Encoder Open.

[Lucario231]

I have tried putting a start right after the open vi in begin.vi

That didn't work. The rest of my code is working. It seems like the encoder library could be bad. idk

Would start vi be needed in telop? I tried that and no success

When looking at the devref in the probe everything is fine except for the counter index which is invalid.

I am guessing that is the problem.

[Vikesrock]

Originally Posted by Lucario231

I have tried putting a start right after the open vi in begin.vi

That didn't work. The rest of my code is working. It seems like the encoder library could be bad. idk

Would start vi be needed in telop? I tried that and no success

When looking at the devref in the probe everything is fine except for the counter index which is invalid.

I am guessing that is the problem.

The counter index is not used for 4x decoding so Invalid is fine.

[Alan Anderson]

Originally Posted by Lucario231

I have tried putting a start right after the open vi in begin.vi

That didn't work. The rest of my code is working.

It would help to see the code that you say isn't working. Please post the relevant parts of Begin and Teleop. Include Robot Main too if you've modified it.

And please tell us exactly where you have each wire from the encoder connected to, so we can match the hardware to the software as we look at the code.

When looking at the devref in the probe everything is fine except for the counter index which is invalid.

I am guessing that is the problem.

No, an invalid counter index is expected if you are doing 4x decoding, which is the default. Only 1x and 2x decoding use FPGA counter resources.

[R2D2DOC]

Thanks all for the hints. Lucario231 must have been in a computer lab at school. And, I'm doing this during lunch. We will post code as soon as feasible. I'll take a shot at describing when we have:

Before the recent update, and it worked fine:
OPEN ENCODER feeds into DevRefOut in BEGIN
DevRefIn into GET in TELEOP

After the recent update, we have done everything suggested by Mr. Rotolo to verify that the encoders and wires are fine. To test the encoder signals, we manually turned them until we read 5V or 0V. More primitive than the scope but effective.

We have done most of Mr. Anderson's suggestions, but we apparently do not understand the GET & SET requirements. We tried to mimic where the Gyro's are placed, but since these are WPI libraries, the protocol is different. Please correct me on location of OPEN, SET, DevRefs and GET in the code. We tried unsuccessfully:

OPEN, SET, DevRefOut in Begin
DevRefIn, GET in TELEOP.

I cannot recall the order of the code booting up. For example, last year NI had said, for example that Teleop launched Auton which looked counter to what was in the code. Mr. Anderson's suggestion seem consistent with what we tried above.

Long story short, we will post code later this afternoon.

Thanks

[Lucario231]

Here is the code I labeled the sides of the .jpg with begin and telop.
When running the code and spinning the encoders the distance value in telop is 0 all the time.
yes the encoders do work.
I have no idea what is wrong

[Mark McLeod]

Um, isn't your encoder Start a tiny fraction of a second before you do your Get?

There won't be anything to count in the time it takes to get from your Start to your Get...

Move the Start into Begin.vi

[Lucario231]

I have tried moving it in to begin.vi and had the same problem.

[Mark McLeod]

Where do you Open the DIO's?

Where do you Configure the Timer?

P.S. Take a look at the LabVIEW Encoder Example accessible from the Getting Started window.

[Lucario231]

Ok i am looking at the example and I am still lost.
So I need to do these DIO opens?? and the timer config??

In past versions aka 8.5.1 and before update 2.1, I never needed to do DIO and timer before.

[Mark McLeod]

That Encoder example is from 2009.
It isn't new.

[R2D2DOC]

Hello,

If this is 2009 code in the example, is it still valid for 2010? We have the next version of Labview, 8.6 and update 2.1. We never did anything this elaborate in 2009 to have the encoders operate.

So from the far left through Start Encoder is in BEGIN.
Use the DevRef to go from BEGIN to TELEOP and BEGIN to AUTON.

We'll give it a try. . .

[Mark McLeod]

Originally Posted by R2D2DOC

So from the far left through Start Encoder is in BEGIN.
Use the DevRef to go from BEGIN to TELEOP and BEGIN to AUTON.

We'll give it a try. . .

That's a correct division into the vi's.
I can't comment on what you may have done in the past. Sometimes, system defaults get you through, and sometimes they don't.

We can always try