Hi Forum,
So we were at a competition today, and our robot was having a really unusual issue with our electronics system. At seemingly random instances in a match, the robot would just be completely disabled for about 5 seconds, and then turn back on again. The lights on the cortex and the joystick remained green the whole time. Could this possibly be a PTC issue? We have the 4 drive motors routed through a power expander and the 6 lift motors on ports 5,6,7,8, and 9, with one y cable. Here’s a link to a google drive file with our code: link . Any ideas?
That sounds like you are tripping the cortex PTC’s. There are two PTCs one between ports 1-5 and then 6-10. When you use your lift you are putting a lot of ‘stress’ on the 6-10 one. May I suggest spreading them out so you have 3 motors (3 ports) on one PTC and 3 motors on the other (2 ports with a y cable) I would do the same with your drive if possible.
What would the cortex and joystick lights look like if this was the case? Cortex PTC’s were my first guess, but I thought that if that was the case the lights wouldn’t stay green. And wouldn’t it stay off for longer?
No, lights would stay green and not necessarily for any longer than 5 secs. Was it your lift or drive or both that died? And if both was it always both at the same time?
Always both. I forgot to include that the pneumatic claws also shut down.
Oh in that case it sounds like code
You’re using IMEs, so processor reset is always a possibility. RobotC has something built in to handle crashes I believe,not sure if it shows the slow blinking red light of death when that happens or not. This is probably a Jpearman question
We have had the same issue, except it is only for about a second. Lights are all on. It is absolutely not PTCs, because it runs fine after this single second. It does not even twitch, and all code stops. Definitely not PTCs.
Yes, this pretty much resembles our problem. Our stoppages have been ranging between like a 2 second pause to a 7 second stand-still. @jpearman got any ideas?
Our LCD screen goes blank when this happens as well. But yes, only ~1 second.
One more thing about our issue: When the glitch occurs, the value for the red quadrature encoder on the lift doesn’t reset. Everything starts working again as if it never happened. And I don’t think it ever happened for 7 seconds. It was just really scary so it seemed like a long time.
I would need more information to help debug. All of these problems sound similar but the root cause may still be different.
When it goes black, do you think power to the LCD is lost? Do you have the backlight on? Does the backlight turn off as well? Perhaps send me your code.
Power to the LCD is not lost - the backlight stays on. I’ll send you my code when I can. Would you just want opcontrol.c ? The issue never happens in autonomous, at least it hasn’t yet.
Also, wlI had a former teammate (@Highwayman ) look at the code and we couldn’t see anything to cause that, but we may have missed something.
We also tried removing the wire for the LCD screen from the cortex to see if that wire had a short, but the issue still happened.
The same thing has happened to us several times. Way back a month or so ago, when it started, I thought it was because of the LCD, so I tried to fix it using the suggestions I got from the forum. The problem stopped for a little, so I thought that I might have fixed it, but it only worked for a few days. This makes me think that it was just a coincidence that it began working. The robot will randomly stop for about 1-2 seconds with all the lights green, and then continue working normally. However, this has also happened in autonomous a couple times for us.
So you are using PROS?
Except for the lights, this sounds very much like a VEXnet disconnect. Have you tried using a direct USB A-A cable to see if the problem persists?
Also, make sure you have a
wait()
(or equivalent) statement in all applicable parts of your code to allow PROS background tasks to run. We had some bad experiences without
wait()
statements.
Yes, PROS.
I thought of VEXNet issues, too. The lights and the LCD clearing seem to rule that out, but I may as well try using a USB cable. Not like anything else has worked yet. 
We do have a delay(20); in our while loop for opcontrol.c, so that should be fine.
@Aponthis You may as well send me the code anyway (just opcontrol.c and any initialization code, no need for Autonomous).
I definitely will when I get the laptop on Monday.
I thought you were using Github