Quote:
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.
Quote:
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.
Quote:
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...
Quote:
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.