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]

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]

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]

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

8801

[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]

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 :)

[Alan Anderson]

So I need to do these DIO opens??

Emphatically YES.

Open a DIO input for each of the A and B channels and run each device reference through a DigSrc to the appropriate input of the Encoder Open.

(Tracing through the library code, it looks like the DIOs are closed for you when you do an Encoder Close, so I don't think you will need to close them explicitly.)

[Lucario231]

I am still having problems and can't read the encoders. I have the begin code and telop attached. I don't see what I am doing wrong.

Any advice will be helpful

8807
8808

[Mark McLeod]

Nothing else with a conflict for DIO 1-4?
For instance, an old default compressor lying around?

[Lucario231]

There is no other DIO using 1-4.

Is my sequence correct in begin?

I have all of the updates installed. Do you guys have them installed and working?
The updates i put in are up to 2.1 and 1.1 in the DS. Could I be missing anything?

Could anyone display their code with begin and telop and auto that is relevant to encoders?

[Mark McLeod]

Tomorrow I can pull and retest a working example and post the full project as a test if you need it.

The LabVIEW example is also a working test case for you. You can run that to see if it has better luck with your first encoder.

P.S. What model encoder are you using? Did you double-check the pinout?

[Mark McLeod]

I ran the Encode Example as-is, and changed the IP of course, but nothing else.
Hooked up a VEX quad encoder to DIO 1 & 2.

It works fine counting up and down on the front panel display.

cRIO V20, LabVIEW Update 2.1
No Driver Station app. needs to be running for this particular test.

-------------------

If the above doesn't work for you, then I'd try a different encoder you can use just as an unmounted test case, and look closely at the wiring.
Did your electrical team use a scope when they tested the encoders before?
Did they test at the encoder end or at the DIO end of the connecting cable?

Or throw your zipped project up here so we can see what might be hidden and interfering.

[Alan Anderson]

Is my sequence correct in begin?

It looks right to me. I'm a little confused by the short stubs of wires visible on the error in and out of the Right Encoder's Refnum Get in Teleop, though.

One more thing to check -- look at the DIO status on the Dashboard and see if DIO 1-4 change as you turn the encoders. That will help determine whether they are wired properly. (The Dashboard DIO lights only update twice a second by default, so don't expect them to react quickly.)

[Mark McLeod]

I'm a little confused by the short stubs of wires visible on the error in and out of the Right Encoder's Refnum Get in Teleop, though.
The cursor was resting on that icon when the screen capture was taken, so LabVIEW was highlighting the unattached nubs. Print Screen just doesn't grab the cursor overlay.

[R2D2DOC]

Just to close this thread. . .

As you know we are all busy finishing build and preparing for competitions. We did an audit of the Crio. First we moved all data streams to SLOT 6 and everything worked. Went back and looked at SLOT 4. Turns out that there was a bent pin in the 9pin D connector on the cRIO backplane. After straightening it, no problems.

Thanks for your time and all of your suggestions.

IT AIN'T ALWAYS THE SOFTWARE. . .