Just go to sourceforge and get the new version, I don’t think PROS downloads the new version for you, or did I miss something.
I actually wish they would just make the plugins available individually or from an update site. This update only changed (as far as I can see) one plugin which has the new firmware version, having to download the whole installer just to get that one plugin is a bit of a pain.
I’ve been trying to redownload and reinstall from sourceforge, doesn’t seem to be working. I’ve done a fresh install of PROS, to no avail. I’ll try again when I get home tonight, I have a tendency to report an issue only to have it fixed when I try again.
Update: I just tried reinstalling on a different computer, same issue. After installing, opened up PROS and the same update message appears, and I can’t update the firmware to 2b08, only 2b07 is shown. Restarting the computer doesn’t seem to help (don’t know why it would’ve, but tried it anyway)
We just tried to download PROS and could not reproduce. Did you select the latest version from the “files” tab? The link on the front page can lag the correct file upon updates.
This worked! I’ll test to make sure the bug is not present tonight.
On a side note, updating a project to the 2b08 version by command prompt can be done by navigating to the project directory and then running the executable as per the release notes (assuming it’s in your PATH)?
At this time, the installers do not set up the PATH very well for command line updates of the PROS project, but using the new project update functionality is still possible with the aid of an environment like Visual Studio. The main issue is that as the version number of the JAR file containing the project is increased on each release, references to it by update scripts may be broken. There is a minor change to the PROS documentation for Visual Studio describing how to create an external tool for updating a project’s version, if that is the intended use case.
I’ve been running the code on 2b08 for the past few hours, and everything seems to be running fine.
Thanks for everything jabibi and James.
We went to a competition this last weekend and the problem still persists. I am using the same basic frame for the code, although it is definitely not an LCD issue (because the LCD isn’t being used). It only seems to affect the 7 and 8 sets of buttons, and it seems to be that when one phantom button press is detected on one set (say the 8 set) then an action also happens that is on the other set (the 7 set).
The issue also seems to become more frequent when you have a serial cable plugged into the joystick (and then into the cortex), so I would say without a doubt it’s a communication issue.
We had to switch to ROBOTC after the second match because the issue was becoming a serious problem.
I can do a bit of testing next week, on your direction, if you’d like.
As you have now observed, potential issues like this are very difficult to track down. Different VEX Cortex units, joysticks, code structures, and even attaching a logic analyzer to debug the issue could be factors. For one, neither jpearman nor us can reproduce it; we ran an entire competition last weekend using code that included instant commands for button 7 and/or 8 presses, and no errors occurred (i.e. our arm never jumped to an uncommanded preset). We also had no de-syncs or runaways pointing to communications/timing problems, and neither did the other team using PROS at this competition.
Have you updated to the latest master code on all joysticks and VEX Cortex units involved? It could be a dodgy joystick button falsely reporting presses or a weak VEXnet key.
I have ensured multiple times that the master code, firmware, etc. are all up to date. I’m sure it’s partially the fault of the keys, microcontroller, and/or joystick. However, I’m definitely not getting this issue with ROBOTC (the only other platform I’ve tried on). We, too, have never had desyncs or runaway robots - just the phantom joystick presses. I will admit we were having desync issues, but we tracked that down to a faulty USB extension cable, that was since removed.
If there any specific test you’d like me to run, I’d be more than obliged to do so next week as my club is off for the rest of the week.
Javid is correct, these types of problems are hard to debug, the worse case I’ve had over the years involved a product in which we created custom hardware to use 48 compact flash memory cards all running in parallel to give us a flash memory recorder capable of a sustained data rate of 360MB/sec (not so impressive these days but quite good in 2006). A compact flash card contains a controller chip a bit like a small embedded computer, the manufacturers keep the details of how these work very secret although the interface is standardized. The problem we had was that once in a while a card would give an unrecoverable error, when I say once in a while the frequency was approximately 1 error every 1500 days for any given card. The way we had to debug this was to setup multiple systems, remember each system had 48 cards, and run them 24 hours a day waiting to capture an error. We had 10 systems running in the lab for about 3 months to be able to collect enough data to be able to eventually understand the issue and write a workaround solution.
Now the PROS bug should not be nearly as difficult to pin down. I say a PROS bug because;
It may not actually be in the PROS library, it may be user code but I’m lumping the two together here.
It is true that my last effort to reproduce this was not successful, but I only spent an hour or two testing as I assumed that the PROS team had fixed it and I have enough other things to do.
It may be the interaction of the specific sensors and configuration of your code, I’ve seen that a lot as well, the developers of a program always avoid doing the things they know may break it, these things are not as obvious to the end users.
So anyway, lets go back to square one.
What hardware rev are you using? You may have said but I forget, it’s on the base of the cortex, is it an A4, A3, NC2 etc. I only have A3 and A4 versions at home, the school has older units but I won’t be able to get my hands on those until after thanksgiving.
Send me the code that was failing on Saturday and I will run it here for a few hours.
Edit:
Daniel pointed out that you may not have upgraded to v2b08, I assume that you have. The behavior you describe also seems different this time, a button push in the “8” group causing an action in the “7” group, that may be harder to reproduce and was not what I was looking for last time.
Before y’all go crazy with the testing, maybe you should check to make sure it wasn’t a silly mistake like Elliot using an unupdated project in pros?
Not sure how you check that but just wanna make sure you folk don’t go through anything needlessly.
You are absolutely right, Elliot, over to you, did you update everything to 2b08?
I am positive I’ve updated to 2b08, I’ve remade the template in Visual Studio with the 2b08 project.
This is my thought process as well - I’ve run ROBOTC code on the same configuration using the same code framework without any issues. It could very well be a slight tuning issue that is not exactly the same as ROBOTC that causes an only slightly broken Cortex/Joystick/Key combo to become significantly more erroneous.
I’ve asked my teammate to look, and I’ll update this post when I found out. Meanwhile, we got all of our microcontrollers when VEX was offering the upgrade incentive, so my guess is the first hardware revision, whatever that may be.
Sent to you and Jabibi.
Sorry if I hadn’t made this a little more clear, to buttons seem to be erroneously detected at the same time - one from the 7 group and one from the 8 group. This is different from what you stated in that it doesn’t happen when our driver presses a button on 8-group, a 7-group action happens, it’s that two buttons (one from 8 and one from 7) are erroneously detected at the same time.
You are probably correct, I have just the right combo of bad microcontroller, joystick, and keys to create an issue, but I have gotten this issue to replicate itself on multiple sets - the holonomic bot from the tutorial series I made and our competition bot. Admittedly, our club has an unfortunate tendency to not take care of the fragile electronics that cost hundreds of dollars, so I have old and slightly broken microcontrollers/joysticks/keys. I can confirm we have used different controllers, different vexNet keys, and different joysticks, though.
I’ll see what kind of toying around I can do in order to give you more details after the long weekend.
Yes but are you also using a new project or have you used the pros project updater? Do remember that all the pros specific code is contained within the project so even though the IDE may be updates, an old project could still have the old bug.
He didn’t, the library in the project is 2b07.
Called it 
Note to the pros folk: Library version should probably be made more obvious, perhaps with a note at the end of the project name or something
It would be useful to be able to read the version from user code and perhaps bury it in the header files.
It’s always difficult to decide whether a library should be part of a project or maintained separately. I’ve done it both ways and had problems with both. Once a project is stable it’s usually not a good idea to update a library, however, during development it’s far easier to fix a bug once and have it available to every project.
Typical me… :o
I’ll get the update done and try it out as soon as I can…
Sorry for anyone’s inconvenience and thanks guys!
No problem, it was Daniel who thought of this, I didn’t spend any time working on it. Let us know how it works out.
we have had the same problem. It occurs only after a while of running the bot. Then, all of a sudden, the bot takes off uncontrollably and we lose the wirele3ss link. Any others have that set of symptoms.
PS I’m just a mentor - I don’t know programming. But one of the kids on my team seems to be pretty gifted at it.