spastic motors when encoders plugged in - even when not referenced in code

[albfrc]

---

     We are having a problem that occurs when plugging in an encoder.

The encoder is wired into 2 digital I/O ports on the digital sidecar, with careful attention made to plugging in gnd and signal to one port and 5v and signal to other port. The problem occurs when plugged into any 2 ports.

With the encoder wired, when the code is enabled, and in teleop mode, the motors start to run, with no joystick input.

With the encoder unplugged, everything works as expected, with no movement until the joystick is moved.

We are using C++ and this happens even when deploying the unmodified FRC Default Program (current with imaging tool), which when loaded into workbench is titled BuiltinDefaultCode.

That code does not explicitly reference digital input ports or the encoder classes at all.

Why does hardware plugged into the digital I/O ports effect the motor control?

I need some guidance to troubleshoot this.

Ann

[Kevin_F]

Hey Ann,

This seems pretty strange to me. The default setup shouldn't change based on whether or not there are encoders connected. Do you have access to an oscilloscope that you would be able to use to look at the motor output signals and compare when the encoders are plugged in to when they are not. Are there any basic motor control examples you can run (in LabVIEW there is an example that strips out most of the robot framework and just leaves motor joystick control)?

[sciencewhiz]

I'd guess a power problem. Where are you powering your digital sidecar from? Are all three LEDs brightly lit (battery 5v, and 6v)? If the digital sidecar doesn't have power, it will still get leakage current through the DB37 cable, but that will only be enough for a few items. Do all 3 lights stay on if you remove the DB37 cable?

If all of that checks out ok, it could be a short in your encoder or wiring.