Today, at the start of our team meeting, the port 18 on our HS team robot died - it stopped being able to move the motor. The motor does short blink with about 1s period, the brain sees the motor in the device view, but ignores the up/down arrows. The motor is OK, so is the cable:
*) we have tried another motor and observed the same behavior.
*) we have moved the cable to the port 17 and the original motor, with the original cable worked flawlessly.
*) After switching back to port 18, we have reproduced the same problem - brain seeing the motor, but ignoring the command arrows.
We tried various things including power cycling the brain, but our port 18 is gone.
What is super intriguing is that before the end of the meeting, our MS team robot developed the same issue (similar robot design, the same port 18 used for the same purpose - intake roller motor).
Now, both of those robots were heavily battle tested before, worked well for more than a month being used almost daily by the drive team and the team programmers.
So we now have two brains with port 18 unusable, even though the port still apparently communicates. I haven’t tried any advanced troubleshooting so far, I might try observing the power delivery to the motor and checking if the brain sees motor movements next, but for the time being, we’ve swapped to port 17 and went on with the meeting…
Out of curiosity, my team has ports 3, 4, and 5 that don’t function in the sense that the stable red is on for the motor connection but flash indicating a power input but no code “transfer”. Would this be the same issue?
Yes, it most likely is. This discharge is mainly caused by pushing the robot around, turning the motors, which act as generators, and send energy back to the brain.
ESD id plausible, though the failure mode is strange.
(Side note: It’s not the motor back-EMF, the ports (more died today) that die for us are the rollers. We routinely force the heavily geared tray motor so it generates enough back-EMF to boot up and start fighting back, but that one never dies.)
Now, I need to do more experiments and examination on the brain but consider this: There are 2 main chips per port that could get damaged - the eFuse and the RS485 transceiver. I have verified the eFuse is OK - the motor is still getting the power (and I have verified it is a real power, not ghost power through the data lines). But the brain still recognize when a motor is plugged to said port - that could mean the brain is still able to receive the motor messages (which the motor sends on its own). On the other hand, when I spun the motor by hand, the device info angle didn’t update on a dead port, so it’s not as clear-cut.
Either way, the RS485 chip should be able to weather significant abuse (including massive ESD), that’s the whole point of RS485 on the physical layer. I won’t be surprised to find that the RS485 chip actually survived and what died was something down the line where the ESD discharge bridged some insufficient gap or something…