Talon SRX Missing Encoder Counts in Labview

[Chris_Elston]

So tonight we swapped out another encoder. Just to try it. Same problem. If not worst. I forgot my O-Scope today. I walked right out of the office and it's sitting by office door...oh well...I will remember to grab it tomorrow so we can see what's up the encoders.

So we tried plan "B" which was we installed brand new MA3 Analog Encoders from Andy Mark: http://www.andymark.com/product-p/am-2899.htm

Wired them to an Analog Breakout board instead of the Encoder Breakout Board of course...Seemed to get a reading back. The Analog In and Sensor values is like 8.3 to the E6 power. It's some large numbers we are seeing.

I assume it's normal that we can not RESET the ZERO when using "Analog Encoder"? because we were not able to reset our zero. I assume because these are used as absolute positioning. <---NEVER MIND, I downloaded the new manual from the website...section 21.17 addresses this issue... 21.17. Firmware 1.4: When setting the “Sensor Position” of an analog encoder, multiple set commands are required.

But I think what was the fork in the process of using the MA3s, was when we noticed that the SLAVE Talon SRX was not following the MASTER Talon SRX any longer. We noticed that the master's led's was RED while the SLAVE led's would be GREEN. The amperage on the master would spike up to 40-55 amps. Like the slave motor was fighting the master motor. It would not do this all the time, only spikes or momentary.

We NEVER had that problem when the input sensor was configured for Digital Encoder verses Analog Encoder. I am not sure what was causing the master and slave to fight like that. All we did was change the sensor type.

Tomorrow we will go back to the encoders and we will Oscope the encoders we have and check and make sure they work. If we have time, we can feed them into the RobotRio like Mr. Anderson suggests. I do have a 128 cycle count to try verses the 1000 cycle count to see if that helps the Talon's SRX polling.

[Ether]

Originally Posted by Chris_Elston

I do have a 128 cycle count to try verses the 1000 cycle count to see if that helps the Talon's SRX polling.

It wouldn't hurt to try. But I discussed SRX quadrature decoding with Omar. SRX decodes quadrature encoder in hardware, and shouldn't have any trouble with your S5-1000.

[Chris_Elston]

Originally Posted by Ether

It wouldn't hurt to try. But I discussed SRX quadrature decoding with Omar. SRX decodes quadrature encoder in hardware, and shouldn't have any trouble with your S5-1000.

Ether, do you think we might have a bad sensor then? I do have some brand new S5 coming. I selected 360 CPR and 250 CPR this round.

We have QTY (4) S5-1000, so far two of them are missing counts...the second one we installed today seemed to be worst than the first one. An O-Scope tomorrow might be able to tell alittle bit about what the encoders are doing.

ANOTHER THOUGHT...

Would it help to change the Encoder Status Frame from 100 ms to 20 ms? What is the intent of the Status Frames in the Talon's?

section: 20.3. Quadrature Encoder Status
The Quadrature Encoder Status frame has a default period of 100ms.

Looks like it can be adjusted to 20 ms. Would that improve refresh rates?

[ozrien]

Your master and slave driving in different directions sounds like a robot-code issue.

Changing the feedback sensor will not affect the master's applied throttle unless the master is closed-looping. In which case maybe turn off the slaves until you work out a stable closed-loop response on your master before throwing more power into the equation.

The elevated current draw sounds like your master and slave are driving against each other, not a cause, just a symptom.

The status frame rates (section 20 of Talon SRX software ref manual) affect how often the signals are reported on CAN. They have nothing to do with quadrature decoding. It's not like your pressing the Self-Test button every 20ms, or print to dashboard every 20ms.

Changing the status frame rates is possible in case you want to process encoders yourself, like you would if encoders were plugged into the RIO (with a PIDContorller object or your own custom PID code).

[Chris_Elston]

Originally Posted by ozrien

Your master and slave driving in different directions sounds like a robot-code issue.

Maybe, however the code and the Talon worked great when it was selected for Digital Encoder Feedback as the sensor type. No code changes except switching to Analog Encoder. That's when we noticed the slave unit not having the same LED sequence as the master.

Originally Posted by ozrien

Changing the feedback sensor will not affect the master's applied throttle unless the master is closed-looping. In which case maybe turn off the slaves until you work out a stable closed-loop response on your master before throwing more power into the equation.

This might be the case, we did not have a stable PID loop after changing to Analog sensor. We did have a beautiful aggressive PID loop when the encoder was connected, the S5-1000 CPR, except losing counts...If not for that, this application would be just incredible in our opinion and impressive to see.

Originally Posted by ozrien

The elevated current draw sounds like your master and slave are driving against each other, not a cause, just a symptom.

Agreed. They are doing that, because when you see the master LED "red" and the slave LED "green", you know we've got some issues there...

Originally Posted by ozrien

The status frame rates (section 20 of Talon SRX software ref manual) affect how often the signals are reported on CAN. They have nothing to do with quadrature decoding. It's not like your pressing the Self-Test button every 20ms, or print to dashboard every 20ms.

Changing the status frame rates is possible in case you want to process encoders yourself, like you would if encoders were plugged into the RIO (with a PIDContorller object or your own custom PID code).

Good to know. Thanks for the explanation of what that does. I see, so this is a software "tunnel" to get the data from the Talon SRX > to Can > to Rio project without hooking up a wire directly to the Rio inputs. Pretty cool.

[Chris_Elston]

Just an update today (tuesday). We still have not resolved the problem. I went ahead and sent an email into support at cross the roads electronic with more specific details. However I wanted to update everyone that was interested in what we have done for troubleshooting.

Tonight we:

1. Removed the MA3 Analog Encoders, because there was something happening to the Slave Talon SRX to become out of sync with the master that we did not understand. So we put back in the US Digital S5-1000 encoder, and change the sensor type from Analog Encoder back to Digital Encoder, and the Slave problem went away. We went back to having a super SMOOTH PID closed loop control, except the sensor counts are not repeatable.

2. Removed the US Digital S5-1000 encoder and replaced them with some older GrayHill 61K-128 CPR encoders. We re-tuned our PID and got the same super SMOOTH closed loop control. However still losing counts.

3. I brought the FLUKE O-Scope home and wanted to prove there was nothing wrong with the encoders we have. Can someone else review a couple of these videos? I don't see anything that pops out here at me that is abnormal? We have QTY (4) US-Digital S5-1000 and QTY (2) Grayhill 61K-128. All six videos are here:
https://www.dropbox.com/sh/yha32m2df...kUVZG16Aa?dl=0

4. Finally what we decided to was disable the robot and only watch the "Sensor value" from the Get Status VI block. We manually moved our carriage by hand after marking a spot on the elevator. The sensor position would not repeat in this case even when in disabled state. We emailed this video and our code to Cross Roads.

Tomorrow what we plan on doing are these things.

1. Removing the sensor from the gear box, and manually turning the shaft and seeing what the values are to the Talon SRX. We will document this via video as well.

2. Re-wiring the sensor direct to the Robo-rio just as Mr. Anderson suggested.

The closed loop control works amazing in the Talon SRX, if we can just figure out this "repeatability" problem....ugh....so frustrating that we are so close with the Talons SRX...

Is there anyone else out there that has a working closed loop controls with the Talon SRX with an encoder with no position issues?

[Chris_Elston]

Update today: (2-11-2015)

As I thought, the US Digital S5 encoders are all "ok", but I wanted a professional opinion so I asked US Digital to review the videos. Here is their response. Which is positive. Thank you US Digital.

"Based on the videos of the scope I would say that the US Digital encoders are working properly. The small blip that you see on the A channel is some minor cross-talk between the A and B channels. In the video it does not appear significant enough to interfere with the motor controller. The size of the blip is dependent on the length of the cable, so if the cable is longer in your application then the blip might be larger in practice. A pull-up resistor on the A/B channels should eliminate this, typically anything between 2.2k-10k ohms is acceptable."

[Ether]

Originally Posted by Chris_Elston

A pull-up resistor on the A/B channels should eliminate this...

roboRIO has weaker pullups than cRIO:

http://www.chiefdelphi.com/forums/sh...3&postcount=22

http://www.chiefdelphi.com/forums/sh...8&postcount=18

[Chris_Elston]

Preliminary information....(2-11-2015) 5:45pm

1. Took the encoder out of the gear box and turned shaft connected to Talon SRX. Loosing counts and the decoding is not even close to the spec of the encoders.... Will upload a video later.

2. Wired the same encoder to the Robo-rio (DI1 and DI2), configured for 1X decoding...no counts LOST... 0 to 128 counts, almost perfect everytime. Will upload a video later.

[Ether]

Originally Posted by Chris_Elston

2. Wired the same encoder to the Robo-rio (DI1 and DI2), configured for 1X decoding...no counts LOST... 0 to 128 counts, almost perfect everytime. Will upload a video later.

Can you repeat the exact same test, except at 4X decoding?

[Chris_Elston]

Originally Posted by Ether

Can you repeat the exact same test, except at 4X decoding?

Sorry Ether, we took it all apart before we was able to test for 4X. Maybe tomorrow.

However here are the videos from tonight's test.

https://www.dropbox.com/sh/k294ckivf...cvHHaNmOa?dl=0

The key summaries here are the following:

1. We took the encoder out of the gear box and spun it with our fingers to eliminate any questions with the gear box, or shaft slipping. Just the encoder all by itself.
2. When we wired one of the encoders direct to the robo-rio, like Mr. Anderson suggested, this WORKS!!!
3. Not shown in the videos...we swapped out a brand new Talon SRX, made sure the firmware was 1.4, updated the CAN BUS IDs, then tried again. Still missing counts.
4. I got an email from Omar who suggested maybe the small ribbon cable to be replaced, we tried that, and that did not work.

The Grayhill connected to the Robo-rio, we setup at 1X decoding, so the count was exactly 128 and 0. Right on the money as per the video above.

Maybe we are doing something wrong in the software setup? We are using labview. If anyone might be willing to share a working software setup with Talon SRX in closed loop, digital encoder mode, please let me know.

In Omar's email he was testing with a E4P encoder, so we just happen to have one of those laying around. We had an E4P-360CPR. The results are pretty much the same for that one as well, missing counts.

We are completely baffled at this point and getting pretty sick to our stomach, other than we made the call tonight to code a home brew PID loop to get us by for now, we are now 4 days behind troubleshooting software issues. We gotta keep moving.

[ozrien]

Chris, I figured out what is wrong, the problem is your LabVIEW app. Without revealing the details of your project, the brief description of the problem is that "Motor Enable" is being called every loop. Every time "Motor Enable" is called, a frame is sent to the Talon to "set" the current encoder position. Since the caller has wired the position signal to the last received position, it has the negative effect of constantly setting the position to the last received position [not ok]. So changes in encoder position in the Talon firmware are being stepped on by the RIO's request to reset the encoder position.

I reproduced your exact symptom by creating a new Labview project and dropping in your VIs. I teleop'd enabled, moved the encoder to the zero position, marked it, moved it forward one rotation and then back. Encoder pos was no where near zero [not ok]. Then I deleted the call to "Motor Enable" in ElevatorPositions.vi and redid the test, encoder went back to zero successfully [ok].

Long story short, do not call motor-enable continually. If you want to kill the motor drive set the throttle to zero or change the control mode of the Talon object.

[ozrien]

One more thought...
In hindsight, a better approach to debugging this might have been to un-deploy code so that the robot is in the no-code state. Then use the Self-Test in the roboRIO web-based config to measure the sensor position, move one rotation, and hand-calc the difference to confirm the right number of ticks. Probably a good trick to ruling out robot-side influence on future problems involving decoding sensor. Wish I had thought of that earlier, oh well.

[Chris_Elston]

Originally Posted by ozrien

Long story short, do not call motor-enable continually. If you want to kill the motor drive set the throttle to zero or change the control mode of the Talon object.

Omar, Thanks for helping us find this one. Me and Tyler (Lead software student) did not know that Motor Enable reset the counts. We must have missed that one while trying to learn about the Talon SRX.

This was a great mentoring experience for both software and electrical sub-teams. They learned how to use the o-scope and document problems along the way.

We will give this a try tonight and see if that wraps up our problem. Again, thanks very much for assisting us!

PS: You are right about self-test. I think from a troubleshooting stand point, we got focused on something slipping, or bad encoders because they were not new, is the reason we didn't think of doing that step as well. To look at what the drive module sees before any data is processed into the robo rio.

Will follow up one more time with good results tonight. I hope this troubleshooting journey helps others in a positive way.

[TylerStaudigel]

Originally Posted by ozrien

Chris, I figured out what is wrong, the problem is your LabVIEW app. Without revealing the details of your project, the brief description of the problem is that "Motor Enable" is being called every loop. Every time "Motor Enable" is called, a frame is sent to the Talon to "set" the current encoder position. Since the caller has wired the position signal to the last received position, it has the negative effect of constantly setting the position to the last received position [not ok]. So changes in encoder position in the Talon firmware are being stepped on by the RIO's request to reset the encoder position.

I reproduced your exact symptom by creating a new Labview project and dropping in your VIs. I teleop'd enabled, moved the encoder to the zero position, marked it, moved it forward one rotation and then back. Encoder pos was no where near zero [not ok]. Then I deleted the call to "Motor Enable" in ElevatorPositions.vi and redid the test, encoder went back to zero successfully [ok].

Long story short, do not call motor-enable continually. If you want to kill the motor drive set the throttle to zero or change the control mode of the Talon object.

What do you mean by the motor enable vi. Is it the motor set output or something in the begin category?