ROBOTC for VEX Robotics 4.29 Released!

We are happy to announce the official release of ROBOTC for VEX Robotics 4.29! There are more than a few changes in this latest version, including the updates that have been rolled in from the ROBOTC 4.28 Beta.

The update for the VEX Robotics (Cortex EDR and VEX IQ) robotics systems includes new features, functionality and a load of bug fixes! This new release of ROBOTC includes the brand new “Natural Language 2.0″ libraries for the ROBOTC Graphical interface. The new Natural Language 2.0 for Cortex allows users to customize and use their own robot configurations with our new Graphical Interface.

In addition, users can also program their VEX Cortex Competition Robots using our new “Graphical Competition Template”!

You can download the latest version of ROBOTC for VEX Robotics 4.29 here, or by navigating to the ‘Help -> Check for Updates’ menu option in your ROBOTC 4.X installation.

Changelogs:

ROBOTC 4.28 BETA -> 4.29 Change Log:
(CORTEX) Updated VEX Cortex Graphical Implementation to support competition (single run autonomous per toggle)
(CORTEX) Modified “BuiltInVariables.txt” to properly show VEX Cortex commands.

(ALL) “Test Communications Link” dialog was not properly storing/retrieving the registry value for the “Ping Type” variable.
(ALL) Debug stream fixed so that “Clear Debug Stream” clears the IDE’s Window at the proper location; previously it was possibly erasing the screen at a spot well after the actual “clear” function was called.
(ALL) Enhance Debug Stream handling to better support (1) Buffer overflow conditions and (2) proper visual appearance on IDE when “Clear Debug Stream” intrinsic is used.

(ALL) Adjustments so maximum size of messages transferred between IDE and emulator increased to 10K from 1K.
(ALL) Fix bug when maximum message size now exceeds maximum flash sector size.
(ALL) Joystick buttons had different enums for real and virtual robots. This affected the joy1Btn() command.

(ALL) Upissue Firmware Version to 10.29 / Upissue IDE Version to 4.29
(ALL) Contents of DebugStream window can now be saved through the menu
(ALL) Automatically select RVW package if one is not selected.

(ALL) Increase number of RVW Packages available to 40 potential options - allows for future level packs.
(ALL) DebugStream can now also be saved as a *.csv file
(ALL) DebugStream Window contents can now be saved to a file.

(ALL) User models (from Motors and Sensors setup) can now use relative filenames for user models.
(ALL) Fix crashing issue when CheckForUpdates get a malformed XML file (typically hotel login pages)
(ALL) Fix crash issue when Version XML file download is corrupted by school/hotel/conference “login” screens.

(ALL) Fix crash issue when licensing libraries return an unexpected return value - error message string formatting command was invalid causing a crash.
(ALL) Added pipe symbol to the LCD Printing Libraries fonts.
(ALL) Fixed backslash character in small font.

(ALL) Better parsing of “If” and dangling “else” clauses. Prevents a compiler crash when bad syntax in the “if” condition clause.
(ALL) Support in GUI for use of user-defined “motors and sensor configuration data files”.
(ALL) New “registry flag” to indicate whether user defined “configuration model” files are allowed.

(ALL) Previously breakpoints could not be defined in header files. This is now fixed.
(ALL) Benign. Enhance output in message trace window for “set breakpoint” message.
(ALL) Command line based activation / deactivation commands. Implemented but not fully tested yet - documentation to follow.

ROBOTC 4.27 -> 4.28 BETA Change Log:
(CORTEX) Fixed issue where performing a new motor PID movement when an existing PID movement is in progress didn’t work properly.
(CORTEX) Allow users to select “Xmtr2” for VEX Cortex Graphical (Expert and higher menu level)
(CORTEX) Added competition control and competition template for Cortex Graphical

(CORTEX) Added Virtual Worlds Natural Language 2.0 Library for VEX Cortex
(CORTEX) Renamed old-style Natural Language mode to “Natural Language PLTW”
(CORTEX) Fixed issue where software inspection would fail without a radio link on VEX Cortex

(CORTEX) Added dialog message to Cortex “Download Firmware” button on large icon toolbar.
(CORTEX) Multiple incomplete consecutive PID moves. Fix issue when current move is in “ramp down” and new PID movement is initiated.

(ALL) Updated Help System Documentation for new commands and features.
(ALL) Updated Firmware for 10.28 / 4.28 compatibility.
(ALL) Added a compiler error when “switch” expression was illegal.

(ALL) Support for optional “int” keyword as in the declaration “short int” or “int short” in addition to “short”.
(ALL) Add USB Joystick control to Graphical (in loop blocks)

and now version 4.30 is on the download page a week later, is there a changelog for that version ?

and master firmware 4.25 for cortex and joystick was released ! I feel like going off on one of Foster’s major rants about software releases with no announcement, no change log that gives any details, compatibility of versions etc. etc. This type of thing drives me nuts. What happened to 4.24, presumably an internal release, for all the students reading this is not the way to do software versioning, there are usually dozens of internal engineering releases before an official version number is used and software released in the wild.

Anyway, this is from the wiki.

https://vexforum.com/image.php?u=814017&dateline=1423867235&type=profilehttps://vexforum.com/image.php?u=814017&dateline=1423867235&type=profilehttps://vexforum.com/image.php?u=814017&dateline=1423867235&type=profile

We’re in kind of a “no win” situation here.

4.30 was released late yesterday - our social media + web teams didn’t sync the updates at the same time (the built went live last night, the blog (http://www.robotc.net/blog/2015/02/18/robotc-vex-4-30/) went live this morning with the change log - the forum posts are coming now…)

The main motivation behind 4.30 was a request from VEX Robotics to include the latest Master Firmware inside of ROBOTC. The last time we left a build just “sit” with older master firmware, we got flak from the community for this. Now we’re also getting flak for releasing a new build that includes the firmware at the behest of VEX Robotics but not being fast enough with the documentation. The Master Firmware wasn’t ready / we weren’t aware of it when we released 4.29 just last week… we don’t like pushing out updates this frequently as it does cause frustration.

Not to mention, we spent some development time getting a new 3.XX build released with the latest Master Firmware + fixes to ensure maximum compatibly with the new VEXnet 2.0 keys… we’re committed to supporting this community as much as possible.

We can’t control the flow of information regarding the new Master Firmware releases - so I understand your frustration with that… but 4.30 has been released for about 14 hours now, so please give us just a little bit of time to get all of the applicable pages updated. There’s lots of moving cogs.

Thanks.

I do understand Tim, I was caught totally off guard last night having just installed 4.29 and started on the tedious process of trying to see what it may have broken in old code that I have released for the community. I was updating my VEX IQ environment, which I have neglected for quite a long time, and start seeing new unexpected versions.

and the lack of (apparent) coordination and communication between IFI/Robomatters/Intelitek is one of the frustrations. The file dates in the vex net upgrade utility suggest master code 4.25 was built on Dec 3 2014, more than two month ago. I don’t know if that’s accurate, if 4.25 was created within the last 7 days it has not had enough testing and QC. If it was created last year then your development team should have known, either way IFI should have allowed more time for you to do QC and coordinate a release in a couple of weeks.

The community also needs more information about the necessity of master code upgrades. To be honest, I only do upgrades once a year unless there is some type of critical bug. My teams are still running V4.22, I saw no need to upgrade to 4.23 and all our VEXnet 2.0 keys work (and any new ones I would just downgrade, don’t ask how).

So 4.25 has “Fixed pit channel to competition channel sequencing”, was this critical? ROBOTC V4.3 has “Increased Timeout for VEX wireless communications when using the new VEXNet 2.0 Radios – prevents communications issues”. It seems strange that you would have tweaked such a fundamental parameter for a release needed just to support new master firmware unless the two are related.

Anyway, I appreciate the post, what I would like to see improved in the future is.

changelog on the firmware download page.
coordination between IFI/Robomatter/Intelitek when new master code is available
more detailed information from IFI explaining why the upgrade is necessary or if it can be skipped.

This is what common slobs like me need to know. Everyone is approaching the State competitions, so we need to know if this is something we can just skip until after the SkyRise season is over, or if this is something that will cause everyone to spontaneously combust at States. :confused:

I advised our teams at the last update to hold off until March 1 - the day after states when the larger time block will be available for any updates. I am standing by that on this one too.

Being week and a half away from the one chance to get to worlds, if we did not already run across the bug, I am hesitant to promote an update at such a critical juncture. The one caveat is being told specifically of the detrimental things if I do not update. Even then, it may have to be a proven bug.

We’ve been much more rock solid this year on the 2.0 keys and Robot C v4.26. Debug via long USB cords has fixed many of those issues, and there have been very few drop outs this year in play. So unless there is much more transparency in the issues we may face, the upgrade will have to wait.

I liken it to upgrading from Oracle 8.1.7.4 - we stayed on that version for far too long since it was soooo rock solid.

I would prefer that my teams hold off on the update, but that may not be practical. The problem in Indiana is that most of the event partners expect teams to be on the latest version of the firmware. If a team experiences any connection/control issues and are not on the latest version then they are basically ignored and just told to update to the latest version.

How about RobotC 4.3 now.

http://www.robotc.net/blog/2015/02/18/robotc-vex-4-30/

Ah yes, I remember like it was two years ago. Not one of my better moments as a mentor.

This is sad that this hasn’t changed since 2012. The December dates are a problem with it now being mid February. But at least it’s before the states so teams will have a chance to test it.

Does the test switch put it into competition mode? Teams may be able to do some testing that way to make sure it works. (I remember a thread about this, I can’t find it)

Maybe if we wait a few hours, they’ll have 4.4 or 4.5 ready to try out for the first time at our States. Running untested software on mechanical devices that can wreck themselves is one of life’s little delights I always look forward to.

Nope. Apparently only the software based switch does it from the Tournament Manager software. Not sure the difference in communication patterns that makes this happen differently though.

There’s nothing magic about the way tournament manager puts the system in competition mode, we talked about that a few times before.

I assume you all saw this.
Master firmware V4.25