Can choice of programming tool (EasyC, RobotC, PROS, CONVEX) impact VEXnet connection issues? Or is VEXnet connection issues only caused by problems with the master firmware of both the controller and the cortex, the master process in the cortex, and/or the VEX keys?
If there is an infinite loop in the user code (eg, while (1) would it disrupt communications between the user processor and the master processor, and could it impact the VEXnet connection?
Also, could the programming tool impact the likelihood of static shock affecting IMEs and freezing the robot? Or is this a hardware only problem?
Are there any other disadvantages to using a programming tool that is not officially supported by VEX?
Vexnet is not really impacted by software choices, but I would advise against PROS. As much as I love Purdue it seems that PROS has been rather buggy compared to the other choices and offers little in terms of advantages over for example RobotC.
I havenāt had any problems with PROS that werenāt my own fault. Out of curiosity what sort of bugginess are you talking about?
Vexnet is handled by the master cpu if Iām not mistaken, so the environment that you choose to go with shouldnāt affect it.
Starving the user cpu could prevent motors from updating, but I wouldnāt think it could cause vexnet to drop.
IME static Iām not sure about. There are firmware things that can be done to prevent/recover from a processor crash, and Iām not sure what each environment has implemented.
there is one annoying bug with PROS, sometimes when the code downloads the robot has vexnet connection but will not do anything. when this happens I have to take the vexnet keys out, put in a USB cable and download the code again. This happens frequently but itās a minor annoyance. Hopefully when the new release of PROS gets to Linnux it will be better.
As much as I love what the guys @ Purdue are doing, at worlds, PROS has notoriously failed many teams, hence why alot of people use RobotC. (If you have an OSX or Linux machine, you have to virtualize windows)
@Harrison2 I would be very curious to know what failures we have had with teams? If you are referring to Worlds last year and our amazing belly flop with motor performance we have root caused the issue. It was not the master firmware that was the issue. Our internal version of the kernal that was in use on the robots was an alpha from early 2013 that made it into the master branch of our robots when it absolutely should not have. This kernel was missing a MAJOR overhaul to PWM driver, master processor communication, and motor control. Which upon finally realizing this in the fall we tested again the very some code we ran at worlds and everything was perfectly fine.
Are there some shortcomings in the current version of the PROS kernel? None that I am aware of. 2b10 is tried and true with the 4.25 firmware. If you believe there are issues PLEASE utilize the issue tracking on our github page
Are there shortcomings in the current version of the PROS environment? I would say yes. The serial terminal in PROS 1.6 does not work as well as it should. The root cause is our dependency on TMTerminal which appears to be a dead project in the eclipse ecosystem. In addition we still do not have VexNet 2.0 flashing capability. This is due to the fact that we have grown tired of reverse engineering and have thus far fallen on deaf ears to get the documentation that I am fast starting to believe does not exist. Is that to say PROS will never have that? No, I hope with the fact that I will be graduating this semester completing my masters and no longer āa studentā that Vex maybe more willing to work with me and the development of PROS moving forward as I will be a mentor (Letās see if I can match 10% of James).
Now I have a separate very lengthy response with information on the subject of reliability of vexnet to this thread as I believe there is already misinformation posted. Unfortunately, I have a major deadline tn that requires my immediate attention.