This is the preliminary final Changelog for ROBOTC 3.08. Please note that an official one will probably appear later today or tomorrow on the ROBOTC website. The artist formerly known as 3.06 is now known as 3.08. Apparently there was a bit of a mix-up internally with version numbers. Carry on.
Update: Small list of additional VEX changes. Marked red.
Update 2: The official Changelog is up: [LINK].
General
- Compiler check to see if include file has been modified on disk was not flusing cached token parsing results. It now does.
- Ignore “this”, “new” and “typeid” as ROBOTC highlighted keywords. Not supported in ROBOTC.
- Eliminate a compiler warning indicating char string constants are limited to 19 characters. This is no longer a restriction and the error / warning should not be generated.
- Improve NXT “move to target encoder”.
- Source files will be reloaded by “OnSetFocus” if the file has been modified on disk. NOTE: you cannot undo the reload — which is the same behavior as Visual Studio.
- Add support for “memcmp” function.
- Make “sensorSmallBias” visible as a intrinsic variable.
- Compiler error “‘volatile’ may be ignored” was patched out as ‘volatile’ is now properly implemented.
- Fix bug introduced into 3.5 where “++” or “–” operators were generating incorrect code. Code generation was for pre-increment/pre-decrement; code for postfix operators was not being generated. Bug was in compiler function “typeCheckStatement” which had a couple of new parameters added to it for 3.05. The “is this top level” boolean parameter was incorrectly defaulted to ‘true’.
- When variable is declared “volatile”, do not use it as a temporary to hold interim results. E.G. if “X” is volatile. in the statement “X = (Y*Z);” “Y*Z” is calculated using a temp variable and then assigned to “X”. “X” is not used as a temporay as in “X = Y” and then “X *= Z”!
- ubyte struct element references were not being properly converted to 16-bit values when used as target for “switch” variable and when used in “if” condition clauses. Incorrect code was generated. When new sensor was added to a standard model configuration the configuration was not being updated until a name was assigned to the sensor. The same may be true for motors. This fix corrects this bug.
Mindstorms/TETRIX
- Add support for new variable to enable / disable disabling Tetrix servos when user program ends.
- Bottom row for “NxtDrawCircle” macro was incorrectly calculated as “Top – Diameter – 1”. Changed to correct calculation of “Top – Diameter + 1”.
- ‘eraseRect” function in emulator was leaving bottom row of rectangle unerased. The bit map array that stores the pixel mask to keep on bottom stripe was incorrect. The “physical robot” implementation for NXT did not have this bug.
VEX Cortex/PIC:
- Fix digital sensor 4 and 10 shared interrupt. Firmware only allows one sensor to be declared that uses the shared interrupt; the other sensor, if using interrupts, will be set to “none”. VEX Firmware properly disables interrupts when a sensor is removed; it may have left the interrupts enabled.
- Fixed a bug that affected VEX-only RVW users where the joystick wouldn’t populate unless a LEGO License was also present.
- Add support for displaying motor encoder port in platforms (VEX Cortex & Arduino) that allow you to associate a encoder on a sensor port with a motor.
- Change default visibility of “associated sensor port containing encoder” to “visible” for VEX Cortex.
- Modify format of debug “upload motor infor” message to include encoder values.
- Fix drift in gyro value calculation. Make “nGyroJitterRange” and “bHasSensorBiasSettings” #define parameters in “loadBuildOptions.h”. Change bias setting for gyro from 130 to 131. Fix some small bugs in gyro bias calculation. Introduce a “gyro jitter range” setting that ignores very small changes for gyro steady state positiion. Suppose gyro bias in 1840; they the ‘ignore jitter’ would treat values in 1837 to 1843 as if they were the steady state value.
- Make “getSensorRawADValue” apply to VEX Cortex and not just NXT.
- Add support for up to 8 VEX I2C Encoders
- Enable the “nMotorEncoder” command on the Cortex Platform to access encoder values
- Changes in Motors and Sensors Setup and Sensor Debug window to reflect I2C encoder support
- Add new sample programs to demonstrate the I2C encoders
Natural Language:
- Added support for 3 line tracking sensors in lineTrack commands
- Corrected untilDark and untilLight commands for corrected sensor values
- Corrected encoder related commands that were incorrectly using dgtl2 instead of dgtl1
What is that servo variable named?
No idea, can you give me a little more context?
Sorry. I meant the one added with this:
Add support for new variable to enable / disable disabling Tetrix servos when user program ends.
Good question, I can’t find anything about it in the header files either. I will ask.
The new definition “kSystemLeaveServosEnabledOnProgramStop” within OpcodeDefinitions.h appears to define the new index into the opcdSourceSystem variables. I’m thinking this needs to be accessed with something like
intrinsic bool variableIndex(bSystemLeaveServosEnabledOnProgramStop,opcdSourceSystem, kSystemLeaveServosEnabledOnProgramStop );
and then in the user code maybe disable the disabling with…
bSystemLeaveServosEnabledOnProgramStop=true;
No access to FTC robot right now to try it out though.
So it turns out the above code didn’t stop the servos relaxing at program end. Anything come back from the devs on this yet?
Not a peep, I’m afraid. I will ask them again.
What do you mean by “■Improve NXT “move to target encoder””?
I don’t mean anything by it, but I think what the developers have done is make the system that stops the motor when it has reached its target a little more accurate 🙂
Hi Xander,
What do you think is the best and simplest way to send simple BlueTooth messages between two NXTs? Let’s say all I want to do is send through 3 integers or so (back and forth).
The example programs are so outdated they don’t even compile any more.
Also, do you know of a sample program that demonstrates the usage of opcodes? Like simply reading the Ultrasonic Sensor value of a slave NXT?
Thanks!
Laurens
I don’t use BT very much but I would probably use cCmdMessageWriteToBluetooth() and cCmdMessageRead(). As for opcodes, I don’t know of any. Most of them will be similar to the standard LEGO firmware but I believe things like motor control really doesn’t work. You would be better off implementing your own protocol on top of the BT to read sensors, etc.
– Xander