COMM lost way to many times

[Al Skierkiewicz]

Originally Posted by Monochron

We are considering moving to mostly solidcore wire to avoid troubles in the future.

Please don't do this. Solid wire is not for use on moving objects. It has a real tendency to fatigue and break just when you need it the most. (Al's Murphy's law corollary...If it can go wrong, it will on Einstein.) Most of the contacts on the components are designed for stranded wire so that the wire can conform to the internal shape of the contact. The ferrules are specifically designed to be used with a certain product so be sure to buy the type for your application. The ferrules for use with the PDP are not round.
Be careful what you use for static discharge, any damage to the field (carpet or other) will irk the field supervisor who will then tell the Head Ref. More importantly for those who suspect static issues is to look where your wiring is running through the robot. If it is near the wheels, or other moving parts, what static might build up will rapidly jump to that wiring. While most of the components are designed to survive that discharge, that doesn't mean they will continue to function during the match. It is entirely possible that a power reboot is the only way to correct the condition. Power wiring that receives the static discharge will pass that along to other wiring that might run in parallel. Most wiring teams use only has a 300 volt rating for the insulation.

[Road Rash]

Originally Posted by Al Skierkiewicz

Be careful what you use for static discharge, any damage to the field (carpet or other) will irk the field supervisor who will then tell the Head Ref.

Good advice. The tinsel breaks easily leaving pieces of copper behind and is the reason we don't use it anymore where I work. I envision snagging issues with chains. Static string is the best bet. It's expensive, but it's lightweight, very durable and works as intended in the environment we use it in. However, even with the cost, a 72' roll of it will last for years considering you only need to use a few inches at a time. It's basically some stranded copper wire with a durable conductive sheathing.

I also agree, it's best to engineer the static issues out of the build altogether. If you cannot do this, then use the string.

[sgeckler]

Originally Posted by Al Skierkiewicz

The ferrules for use with the PDP are not round.

Al, I don't see any mention of ferrules in the 2016 control system wiring documentation I can find. Not the basic and not in the PDP user guide from CTR. Is there something more specific for the PDP that describes the "proper" shape of ferrules you could use? I assume all Wiedmuller would take round? - Sam

Ferrules not mentioned here:
http://www.ctr-electronics.com/PDP%2...7s%20Guide.pdf

Or here:
https://wpilib.screenstepslive.com/s...control-system

[Alan Anderson]

Originally Posted by sgeckler

Al, I don't see any mention of ferrules in the 2016 control system wiring documentation I can find. Not the basic and not in the PDP user guide from CTR. Is there something more specific for the PDP that describes the "proper" shape of ferrules you could use? I assume all Wiedmuller would take round? - Sam

Ferrules are not recommended. It's expected that teams will use the Wago connectors as designed, with stranded wire.

Ferrules are not actually discouraged, but you should do your research to see what Wago and Weidmuller have to say about them. The "proper shape" of a ferrule almost always includes flat sides. You must use an appropriate ferrule crimper to make them. Square shapes are probably going to work best for the connectors we use, because they provide a large connection surface and you won't have to worry about accidentally getting them in the wrong orientation.

[Greg McKaskle]

As a CSA, the most common category of comms failures are power related. It stinks for a robot to lose power or reboot in a match, but if I'm able to show them the cause of the failure and discuss solutions, I consider that a good outcome. My favorite is when I narrow it down and the students actually find the issue and identify a solution. Many of these are simply loose nuts on the battery or breaker, -- sometimes the PDP. Sometimes it is a bad crimp on the same connections. Loose fuses on the PDP are another source of failure.

I have less familiarity with it, but I have occasionally recommended replacing the circuit breaker/switch because it seemed like the softest touch would cause a loss of power.

I have not seen that many issues with radio power, but I'm certainly not a fan of the barrel connectors and generally encourage some form of positive retention, at least a strip of electrical tape stretched front to back across the jack. In previous years, it was quite common to see a bad DLink at an event. Whether this was damaged through mechanical shock or vibration, static discharge, or was bad from the factory wasn't ever clear, but some DLinks simply had high loss that went away with a radio change. I have yet to see that with OpenMesh.

I would really like to see the OP logs. The cursors, messages, and timings give very good evidence of what happened on the robot. When the disconnect happens, several things take place. The DS starts to ping each element in the chain to identify what it can still see, and the roboRIO, if it is still up, will also ping the radio from its side and post-inject messages into the log.

Key things to look for:
If the comms disconnect is only a few seconds long, I generally find that the ethernet cable was not snapped in or wiggling/tugging will cause link lights to go out.

If the roboRIO reboots but the radio is still up, the FTA can easily see this and will often tell the CSA or team. The second tab of the DS also shows the ping status of each device. Also, the results of the pings are printed to the log file as messages. As the robot comes back up you will also see a code start message.

If the radio reboots and not the roboRIO, there will be a green vertical cursor between the orange and yellow ones. Hovering over pretty much anything on the graph displays a descriptor in the lower left. The green cursors are the roboRIO telling the DS when it saw what radio go away and return. This is also in the event messages.

If the radio went out and there is no green cursor and no code start message, both devices lost power.

If the code restarts and the outage is five to ten seconds, it is more likely a code crash and restart rather than a power issue. This also looks different because the radio and roboRIO are still present and the CPU trace will sometimes help indicate the type of crash.

I hope to be able to make the log or even DS make a diagnosis to categorize the issues, but it just hasn't happened yet. As for logging while the robot sits still. Some teams do this, and it is a fine thing to do with your team. I'm pretty comfortable with the diagnostic capabilities of the existing log files and I'm not sure that RIO logs will actually be that much more effective at diagnosing problems.

Several times as CSA, I've intended to keep details about each failure and keep stats of what was found. But it quickly becomes more important to help teams than to keep count. And some teams don't ask for help and you don't find out until second-day afternoon that they have had multiple issues and you were not at the field to observe them.

Greg McKaskle