Our programmer has hard times uploading code (wirelessly through the controller) with the competition switch connected. Most (apparently not all) of the times he forgets the CompSwitch connected, the upload fails. Most (wish it would be all) of the times w/o CompSwitch, the upload proceeds normally.
Using Windows laptop, PROS with 3.2.1 prerelease kernel (for IMU), command line upload (prosv5 mut --slot 2). Sometimes using the official CompSwitch, sometimes using small home-made clone.
Is there anything preventing uploads while connected to the CompSwitch? Would the brain behave differently based on the “competition” signal?
The comp switch should not impact uploads, unless it had been modified to simulate a field control system and VEXnet had been forced onto a competition channel. I’ll check it out again tomorrow.
I have been experiencing a similar issue. After seeing this, I did some testing and it does seem that the competition switch being plugged in makes a difference. If you attempt to download multiple times, it should eventually succeed.
Wierd. From the hundreds of times ive tested my auton, ive had no issues uploading the code with the comp switch plugged in. I would do basic checks, like if all your firmware is up to date, and make sure your IDE is up to date. On the topic of what jpearman said, try to start the code then plug in the comp switch, see if that does anything. It could also be a PROS thing, but I don’t use PROS so I have no idea.
I’m not seeing any issues related to comp switch, but I was testing with VEXcode on a Mac, will need to fire up PROS later. Program was 200K so not trivial, downloaded 10/10 without issue with switch in all combinations of auto/driver/disable.
I just gave this a test with the latest pros cli/kernel on VEXos 1.0.7 and didn’t see any issues. It’s possible that if you turn up the tracing and post the log when it fails we might see something interesting. I’d start with --debug -l DEBUG --verbose --logfile fileToWriteToHere (eg the highest) as I’m not sure what level would be useful here, though if it’s too much you might want to lessen it.
It was with VEXCode on an ancient windows machine. It is not something that occurs every single time but maybe once out of every four or five tries and more prevalent when the competition switch is set to disabled.
Just to close the loop here:
The issue we have observed was wrong wiring(*) of a custom CompSwitch that indeed forced the robot into the competition mode, as signaled by the solid border of the mode icon on the controller.
When robot is in competition mode, USB is disabled - that is apparently a recent change in behavior, but makes perfect sense.
[*] For the reference, since I have hard time finding a correct/authoritative source on the controller competition port wiring, here is my best take (after spending the night analyzing this deeply):
Pin 1: Controller GND
Pin 2: Auton/Teleop (ground for Auton)
Pin 3: Disable/Enable (ground for disable)
Pin 4: Controller GND (supposedly used by the field to detect connected controller)
Pin 5: n/c
Pin 6: Competition (0: real field control connected to switch to competition mode)
Pin 7: CompSwitch (0: CompSwitch or field control is connected)
Pin 8: n/c