Can't read encoders

[intellec7]

My hardware setup works with the Encoder Example that came with FRC LabVIEW, so hardware is not the issue in this case.


Here is where I open the encoder (in begin). I created a "drive encoders" struct, but I don't think that should be the problem, as I am unbundling it.


Here is where I read from the encoder (In periodic tasks)


I tried it both with and without the shift registers for the encoder. The LabVIEW encoder example does use shift registers, though I don't know why since I don't think the "get" vi modifies the Device Reference.

Thank you.

[intellec7]

Haha. Three seconds after posting I realized that I'm "overwriting" the Left encoder device reference with the wrong pins (the ones of the left encoder) as is clear from the first picture. Now it works!

If anyone could clear up the shift register question, I'd appreciate it.
--
EDIT
It looks like I'm not reading the proper encoder velocity -- not even in the example. No matter how many samples I average or what I set the minimum rate to, at slower speeds, I read +/- 83333.3 (depending on the direction) If I speet it up, the numbers change. I can't tell whether they are accurate or not, though.

If it is relevant, I'm doing quadrature decoding and am using an NXT motor, which produces 720 quadrature transitions per rotation (180 rising pulses on a single channel per rotation).

I am using the latest cRIO image and LabVIEW edition.
--
EDIT 2
This symptom only occurs when doing 4x decoding, and not 2x or 1x. I did read about something similar before, but I can't recall where.

[rwood359]

Originally Posted by intellec7

If it is relevant, I'm doing quadrature decoding and am using an NXT motor, which produces 720 quadrature transitions per rotation (180 rising pulses on a single channel per rotation).

I am using the latest cRIO image and LabVIEW edition.
--
EDIT 2
This symptom only occurs when doing 4x decoding, and not 2x or 1x. I did read about something similar before, but I can't recall where.

LabView Update 3.0a and cRIO Version 11 corrected the problem of different rates being returned by the encoders.

You don't have a distance per count going into the open for the bottom encoder, I don't know what the default will be.

The values returned by the Encoder routines are not a function of the decode type (1X, 2X, or 4X). You should get 180 counts per revolution. Have you looked at the distance that is being returned? If you can go slow enough, you should be able to predict the distance based on revolutions.

[intellec7]

The count works fine in all three modes. The default distance / tick is 1.

The problem I'm experiencing has to do with the tick rate when doing 4x decoding.

[Joe Ross]

Could you be seeing this bug: http://forums.usfirst.org/showpost.p...5&postcount=34

[airnate]

Regarding the use of the shift registers:

I believe you are correct in that the Get.vi does not modify the device reference, so the shift registers are not strictly necessary in this case, but shift registers are good form for this sort of thing.

If you were writing this code and someone later decided to update the Get.vi such that the device reference was changed (admittedly unlikely), then the shift registers would cover that eventuality; whereas if you had wired straight through tunnels, then you would lose the changes on the next loop iteration.

One other consideration is that LabVIEW may have to make a copy of the data (internally) when you wire through a loop tunnel. So the tunnel may require more memory to execute than the shift register, but I would be rather surprised if this caused a problem in anyone's code in FRC. This would be more of consideration if you were passing extremely large quantities of data through the wire (e.g. large array or cluster of arrays).

[intellec7]

Thanks for the explanation, airnate.

The 4x velocity decoding fails to work when averaging is set to 2-10, so I don't think it is the same bug.

[Greg McKaskle]

I didn't read the entire thread, but I did test the latest encoder stuff just a few days ago.

If you have the latest FPGA and WPI, update 3 and v11 are the latest I think, then we think everything works except for the 4x with averaging set to 1. This also affects only the velocity, the distance is still correct even in the 4x and 1 case.

Is the rate wrong because the Min Rate is set too high?

Greg McKaskle

[tyson2010]

Originally Posted by Greg McKaskle

I didn't read the entire thread, but I did test the latest encoder stuff just a few days ago.

If you have the latest FPGA and WPI, update 3 and v11 are the latest I think, then we think everything works except for the 4x with averaging set to 1. This also affects only the velocity, the distance is still correct even in the 4x and 1 case.

Is the rate wrong because the Min Rate is set too high?

Greg McKaskle

Where do you get update #3.

Carolyn

[Ceal Craig]

I imagine the problem you are experiencing has nothing to do with the problem we just found the root cause for... but wanted to share.

After installing the encoder on the transmissions with the AndyMark encoder mounting plate, crafting two modified (PWM style three-wire) cables to attach to the US Digital four wire cable for the encoder (2 signals from the encoder, 5V power and ground), soldering (shrink wrapping too) the connecting wires, then installing these two cables (one with three wires into it, signal, power, ground; other with signal wire) to the Digital Sidecar, then using the LabView standard encoder wizardry (hey, I'm a mechanical, not a SW gal) package, the encoder did not work! yikes! only a value of 1.

We spent hours hooking up scopes, DVMs, measuring many, many things, Thank you mentor, Bill S! Next, we called on a local Subject Matter Expert (high five to Laura Rhodes, of Team 100 for taking the calls and the Woodside/Carlmont team for helping on the phone during their busy day too). We were seeing strange voltage readings on the side car itself (only the 5V LED lighted up [remember this one....], not seeing 5V on digital I/O pins using a DVM, strange and inconsistent ground readings across the various items. We tried a different sidecar, checked so many many things. Laura suggested we mock up a signal to the program that didn't depend on the encoders and sure enough the LabView wizard was able to read it.

FINALLY.... those pieces of data all came together (thanks to mentors Tim, Steve, and JohnG and all the students who stuck through it)....we swapped out the Wago connector from the Power Distribution panel to the Analog breakout board that we KNEW was working (battery readings, accelerometer) and used it. [insert drumroll please....].

ALL the lights now on the SideCar lit up! We didn't know there were supposed to (all this time) AND the encoders send out readings and LIFE IS VERY VERY SPIFFY.

REMEMBER: check all the wires on the Wago connectors (Jaguars worked just fine on the Digital Sidecar which misled us into thinking all was ok w/ Sidecar and kept thinking it was the encoder wiring); and don't give up!

Sincerely, the scribe for Team 1120, Week 5, almost 6 with only 9 days left to go!!