I’m not a programmer, but I know that the real programmers are going to come in here and ask you to post the relevant code.
I’ll provide the basic support: Have you triple-checked your wiring? most Encoders have 4 wires: power, GND, A, and B (some also provide ~A and ~B).
Does your loop on your robot code re-initialize the position once at start-up or once per loop?
Anything more complicated than that I probably won’t be able to help you.
Sounds like an electrical issue? Quadrature encoders will behave like that if only one channel is hooked up (brief flashes between a few constants). Double check the electrical setup - use a scope if you have one.
Also, if you post your code, CD might be able to do a quick proofread for you.
Do you have a larger/more hi-res version? I can’t read your blocks
Do you have this all in a while loop, or are you just using “run continuously?”
If you use “run continuously” I can imagine you’ll run into problems with the values constantly resetting every time the loop runs. Although this is the point where I can’t help any more because I’ve never used LabVIEW for FRC.
Maybe try creating an error indicator and pass your error through all of your blocks in series to see if you pick up any errors.
As of now the first picture is in Begin and the second is the teleop code
I’m probably over-stepping my knowledge of LabVIEW at this point, and definitely over-stepping my knowledge of the FRC Control System in LabVIEW (since I don’t know anything).
One more thing I can think of is you might need to store the value inside an indicator (or local variable), or create a shift register to keep the value in memory between loops. I’m really hoping that someone steps in now and tells me that I’m wrong and helps you with the actual answer.
You’re LabVIEW code looks appropriate; it writes encoder position to a network table entry every time a driver station packet is received and resets encoder position while a joystick button is pressed.
I agree with the other comments concerning electrical wiring and/or encoder function. A quadrature encoder relies on two signals to determine which direction to count. When only one signal is present the position count will alternate between two values.
An easy method to diagnose this electrical issue is to unplug one of the encoder signal wires (Chanel A/B) at a time and check to see if the behavior has changed. If unplugging one channel causes the position to stop changing while unplugging the other channel doesn’t change anything then you’ve isolated the issue. If that’s the case then it could be the encoder, the wiring, the roboRIO, or the digital pin assignments (selecting the correct digital I/O). Usually it’s the pin assignments or the wiring, but last night I experienced this symptom and traced it down to a bad encoder module.
When I first started testing our encoders, I ran into a similar issue. Is the shaft for your encoder properly aligned?
I’d go with the flaky connection theory or a problem with the encoder disk.
If the shaft has a lot of play in it (slides a little bit in and out) the disk can be on the edge of detection range. Repositioning it and taking play out of the shaft helps.
In the code you can change the Number of Samples to Average" to 1 and you might witness the flickering values. Such a large average will disguise that kind of problem.
What I have found is that when I unplug the second signal wire nothing changes with the value but when I unplug the first signal no value is displayed. I have tested this with two different encoders and with the two wires switched. I have tried different ports in the code but that did not change the end product. Any advice?
Disconnecting either channel would prevent counting.
Without getting a second signal the roboRIO assumes the encoder is just remaining in one place.
When you disconnected the first signal wire did you also disconnect the power or ground connections as well?
No we did not when we tested everything else the encoder either turned off or stopped giving values.
The help is apprieciated
Does it assume exactly one place? I was assuming standard 4x quadrature decoding which counts every edge - a rising and falling edge on one signal (with the other constant) would, I think, cause it to count up and then back down by one count. Presuming these counts were scaled by a rotations-per-count constant, this was where I originally assumed the symptom of “some constant values” was coming from.
It counts an A edge, then waits for a B edge, before counting A again.
So, repeated A edges are treated as not moving, because they haven’t gone as far as a B edge.
It may try to count up and down 1 for the single A rise and fall combo, but the OP is averaging 100 samples, so in that case it won’t show as a count.